SitePoint Sponsor |
|
User Tag List
Results 101 to 125 of 142
Thread: MVCP - MVC missing a layer?
-
Mar 9, 2004, 21:06 #101
- Join Date
- Nov 2002
- Posts
- 841
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by dagfinn
Originally Posted by Web presentation patterns
Code:http://localhost/front.php?page=articlelist
Code:http://localhost/article/list.php
Originally Posted by dagfinn
-
Mar 9, 2004, 21:33 #102
- Join Date
- Nov 2002
- Posts
- 841
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Captain Proton
Originally Posted by Captain Proton
Going back to the idea of half-requests with commands and views. Perhaps its better to say a page is what links commands and views.
Originally Posted by Captain Proton
Originally Posted by Captain Proton
Originally Posted by Captain Proton
-
Mar 10, 2004, 01:58 #103
- Join Date
- Jan 2004
- Location
- Oslo, Norway
- Posts
- 894
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Selkirk
Code:http://localhost/front.php?command=articlelist
In this particular case, the practical result is the same, but if the URL is representing an HTTP request from a form, it's different. Imagine a form with method="GET" just to simplify the example. The form might generate this URL:
Code:http://localhost/front.php?command=submitArticle&title=MVC&text=Blah%20blah
Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
-
Mar 10, 2004, 04:26 #104
- Join Date
- Nov 2000
- Location
- Switzerland
- Posts
- 2,479
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Just throwing in a curveball, prompted partly by Nativemind reminding me of my first experiences with PHP, using PHP itself as the "framework" and partly because it's raised it's head in WACT.
One thing that's always struck me about me about web applications is what seems to be the first leaky abstraction - links - that <a/> anchor tag and I've yet to find anything that really deals with this. Even with native, "tag-soup" PHP, if you change the name of a script acting as a controller, you may have to make multiple modifications to your HTML to point links at the right location. And it may not only be the HTML which ends up being rendered as a result of the renamed controller - there may be many, more or less unrelated, pages of HTML to modify. Yet everyone keeps on embedding them busily embeds them into their templates... Ignoring discussions of what goes in which layer for a moment, it basically sucks having to make tons of changes like this when you rename a single file.
In a GUI, there the "links" in the interface do not typically point directly at a controller - a menu or a button will emit an event can be diverted to the correct controller.
Perhaps the real advantage of MVC frameworks like struts is that they do encourage you to use a structure for URLs to determine actions, so you at least have to be consistent in how you use links. This gives you at least some chance to store the address a set of links point at in a single location, making them easy to change later. At the same time, with an environment like PHP, you feel the loss of flexibility. More broadly, web "applications" tend to be "bigger" than desktop applications in the sense that a given website may be comprised of many applications doing very different things (e.g. Sitepoint with a CMS + a discussion forum) but still needing some ability to communicate (how do you think those blogs are getting written).
The leakiness of links even turns up in Sun's Petstore application. Here's an broken online demo of the petstore (has anyone noticed how hard it is to find online demos of the Petstore?).
Here's the JSP file IncludeQuickHeader.jsp
Code:<center> <html:link page="/shop/viewCategory.do?categoryId=FISH"> <img border="0" src="../images/sm_fish.gif" /></html:link> <img border="0" src="../images/separator.gif" /> <html:link page="/shop/viewCategory.do?categoryId=DOGS"> <img border="0" src="../images/sm_dogs.gif" /></html:link> <img border="0" src="../images/separator.gif" /> <html:link page="/shop/viewCategory.do?categoryId=REPTILES"> <img border="0" src="../images/sm_reptiles.gif" /></html:link> <img border="0" src="../images/separator.gif" /> <html:link page="/shop/viewCategory.do?categoryId=CATS"> <img border="0" src="../images/sm_cats.gif" /></html:link> <img border="0" src="../images/separator.gif" /> <html:link page="/shop/viewCategory.do?categoryId=BIRDS"> <img border="0" src="../images/sm_birds.gif" /></html:link> </center>
The first problem, as I see it, here is the "?categoryID=DOGS" points directly at a value in the database but that's kind of specific to the Petstore app.
Perhaps more important is the question of whether you page designers should be making the decision that to view any category, the application developer will use "viewCategory.do" to handle it. Rename the viewCategory.do handler and you'll need to change this template (plus others).
If, instead, we make a tag for links in a template something more abstract like;
Code:<action name="ViewCategory" value="DOGS"> <img border="0" src="../images/sm_dogs.gif" /> </action>
-
Mar 10, 2004, 05:37 #105
- Join Date
- Jan 2004
- Location
- Oslo, Norway
- Posts
- 894
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by HarryF
Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
-
Mar 24, 2004, 06:24 #106
- Join Date
- Jan 2004
- Location
- Oslo, Norway
- Posts
- 894
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Selkirk
Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
-
Mar 24, 2004, 09:17 #107
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi...
Originally Posted by dagfinn
1) Same content, but choice of Mozilla optimised page or IE optimised page (view chosen by browser not user).
2) Same content as HTML or PDF (view mode chosen by user).
3) Embedded content of page different, e.g. RealPlayer or Quicktime for embedded video.
4) Frames.
5) Composite pages such as RSS aggregators or side by side comparisons.
6) Embedded flash application or Java applet.
7) Decoration views such as a content borders and menus.
8) Pop up windows.
9) Delayed redirects and automatic timed refreshes (blog roll).
10) Different stylesheet for printing.
11) Page that adapts to previous visits.
The first three are really view modifers, I just put them there for completeness.
yours, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Mar 24, 2004, 10:03 #108
- Join Date
- Jan 2004
- Location
- Planet Earth
- Posts
- 1,764
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Jolly good show, ... Old chap
-
Mar 24, 2004, 10:52 #109
- Join Date
- Sep 2003
- Location
- Glasgow
- Posts
- 1,690
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
And, if client pages are built in blocks (header, footer, sidebar, etc), the one-model-to-many-views relationship becomes one-sub-model-to-many-sub-views.
Last edited by McGruff; Mar 24, 2004 at 17:31.
-
Mar 24, 2004, 13:54 #110
- Join Date
- Jan 2004
- Location
- Oslo, Norway
- Posts
- 894
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by lastcraft
So now I'm wondering when a View is a different View. Where exactly is the dividing line between variations on one View and two different Views? At the point where you make separate mechanics for each? In the form of, say, different templates or different controlling classes?Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
-
Mar 24, 2004, 14:30 #111
- Join Date
- Jan 2004
- Location
- Oslo, Norway
- Posts
- 894
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
More precisely, perhaps, nearly all your examples seem to be composite Views, so there might still be a one-to-one correspondence between the composite View and the page. But, if I understand correctly, 10) seems to be something else, two different layouts for the same page, in which case my previous question is relevant. I hope I'm making sense here.
Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
-
Mar 24, 2004, 15:03 #112
- Join Date
- Jan 2004
- Location
- Planet Earth
- Posts
- 1,764
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Yep. Sort of
According to M Fowler, wouldn't this be the 2 Step View pattern ? I think that what's it's called, but not that far off though
Reading with interest - please continue folks
-
Mar 24, 2004, 15:56 #113
- Join Date
- Jan 2004
- Location
- Oslo, Norway
- Posts
- 894
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Widow Maker
Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
-
Mar 24, 2004, 16:21 #114
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi...
Originally Posted by dagfinn
. How about if we avoid "view" for a moment? The nastiest example seems to be frames and composite views so I'll randomly poke around here for a sec...
If you have a menu frame that you click on to pull a framed subpage then all of these phrases are still pretty clear: template, server request, action, action handler. The menu click sends a request which becomes an action that is picked up by the action handler that either hands off to a more passive display handler or populates a template itself. Both the page and view words defeat me here. I would like to call the whole ensemble a "view" as this would fit with MVC in desktop applications, but web MVC seems to be rather different by convention.
If we were to unframe this arrangement into a single page where the composite is assembled server side, things get a little easier. Here the whole ensemble (view) is rebuilt on the request. This means that the action must know from which ensemble it belongs so that the whole ensemble can be repainted. Here the dual notions of MVC are being forced together somewhat by this more primitive set up. Something of a shotgun wedding.
I am getting stuck for names that haven't already been used somewhere else. The old OpenDoc system used the name "part" for the pieces of a composite view. This word fits both the framed version and the single page version of my imaginary menu driven site.
Still groping...
yours, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Mar 24, 2004, 20:59 #115
- Join Date
- Jun 2003
- Location
- Iowa, USA
- Posts
- 3,749
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by dagfinn
YMMVJason Sweat ZCE - jsweat_php@yahoo.com
Book: PHP Patterns
Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
Detestable (adjective): software that isn't testable.
-
Mar 25, 2004, 11:45 #116
- Join Date
- Jan 2004
- Location
- Planet Earth
- Posts
- 1,764
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Try to avoid FRAMEs if possible, but in the event I need to use them, what I cannot get me head around is the idea that any one (of one or more) can independently refresh it's self, as you say SweatJ.
Now, how would you accomplish this, from
a) Front Controller point of use, and
b) MVC ?
In the sense of how you reference a given FRAME ? Might be able to imply Javascript into the equation somehow, for example, to determine exactly what URL to refresh with ?
My head hurts just trying to figure it all out
-
Mar 25, 2004, 15:22 #117
- Join Date
- Jan 2004
- Location
- Oslo, Norway
- Posts
- 894
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by sweatje
In rich-client MVC, Views are runtime instances (simultaneous ones, in fact). In Web MVC, it seems we usually speak of Views in terms of the code that generates what the user sees. It's hard to pin down, but I think that's the case.Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
-
Mar 26, 2004, 03:40 #118
- Join Date
- Mar 2004
- Location
- Netherlands
- Posts
- 138
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Dagfinn, it's good you bring up those two notions of 'view'.
I think that a lot of people forget that in web applications (in the abstract sense, the application that you use, that you experience) a both the view and the controller are spread out between the client and the server.
The view is not only the HTML output, or the code that generates it, it's also the styling applied to it by CSS, some parts may even be hidden! It's also the place of the HTML page within your browser window. It could be in a frame. This could be a called a 'framed view'.
The controller isn't only the HTTP request handling. It's also the javascript. Your browser is in fact a very important part of the controller (again, in the abstract sense).
A web application is more than HTTP request handling. I think MVC can't be applied to HTTP request handling without remembering that a part of V and C are in fact on the client side, on which you (as a PHP developer) do not have direct control.
-
Mar 28, 2004, 03:25 #119
- Join Date
- Jun 2003
- Location
- Elsewhere
- Posts
- 107
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by lastcraft
The "composite view" is a single Document with multiple Blocks of content. In another thread (I think it was about data driven web apps, started by Harry), I already tried to explain that multiple Blocks in a single Document are either unrelated to the main Block (so they don't depend on the Request's parameters) or they can deduct their own parameters from the parameters used for the main Block.
A framed 'page' consists of several Documents: the frameset, and one or more HTML pages. There is a separate Request/Action/Document set for each part of the page. The main difference with normal web pages, is the lack of a main layout inside the frames: instead of a header/footer/menu page, each frame Document only consists of the content of the Block it contains.
Off Topic:
This would be a nice argument against automatically prepending and appending headers and footers to each page; which IMO is a bad smell.
-
Apr 15, 2004, 14:54 #120
- Join Date
- Nov 2002
- Posts
- 841
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I see the idea of a view as concretely rooted in the HTTP protocol. The view, composite or not, is tied to response generated to an HTTP request.
Does page = view?
I'm a bit surprised at how difficult it is to define a page. I think the idea of a page has to account in some way for the URI of the request. Perhaps the answer lies in some Human Factors oriented definition of a page. For example the nouns and verbs concept that Mark Rickerby posted to the WACT mailing list.
The "what is" discussions about MVC remind me a of the discussions that we used to have when we were trying to follow Ivar Jacobson's OOSE definition of a use case. We had endless discussions of uses versus extends, detail levels, best practices, formats, etc. Then we found that Catalysis had a better definition of a use case. once we understood the catalysis definition, all those issues that we used to argue over all went away because the catalysis definition provided clear guidance where the OOSE definition did not. The switch from confusion to clarity occurred for us almost overnight. It would be nice to see the same thing happen in this forum regarding MVC.
I am not sure where clear guidance will come from in this issue, but I am inclined to tie definitions to concrete concepts such as the HTTP request, response, and perhaps resource (URI).
I wish I had more time to research this issue. I've started to collect some related references regarding URIs here.
I am just thinking out loud here, but perhaps in order to clear this up, we have to let go of the idea that the default pattern in PHP is the page controller. Perhaps this idea makes our concept of what a page is too broad?
-
Apr 15, 2004, 19:30 #121
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi...
Originally Posted by Selkirk
Originally Posted by Selkirk
Form filling strikes me as a special form of search mode. You just want to fill in enough widgets to get to the end of the task. The goal here is simply to finish and anything else is just a distraction. The form filling could be JavaScript or multiple HTTP requests, but the user probably won't notice.
Perhaps "doors" and "rooms"?
Originally Posted by Selkirk
I find the composite view (esp. custom tag) a more powerful concept with web apps. A view talks to itself or it sends a command to higher level (different view, frame or page). A view that talks to itself (introvert) has it's own handler and higher handlers (URL/page) just pass it through. That the page is repainted is an unfortunate accident. An extrovert request is intercepted with the intention of finding a new room.
Both types are sending HTTP requests.
yours, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Apr 16, 2004, 03:40 #122
- Join Date
- Jan 2004
- Location
- Oslo, Norway
- Posts
- 894
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by lastcraft
What's more, it answers the question in the very first post in this thread:
Originally Posted by McGruff
Tell me I'm wrong, it couldn't possibly be this simpleDagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
-
Apr 16, 2004, 03:54 #123
- Join Date
- Jan 2004
- Location
- Oslo, Norway
- Posts
- 894
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Selkirk
Originally Posted by Selkirk
Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
-
Apr 16, 2004, 03:57 #124
- Join Date
- Jun 2003
- Location
- Elsewhere
- Posts
- 107
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
My advice: forget pages, and ban the use of the term 'view' in web development. These two terms both have strong ties with the user's experience created by following a chain of requests using a web browser. And while this is how the majority of our applications will be used, it has NO relation to the actual workings of web applications. Processing (or rendering) the output of our applications is the job of the client software. The user (if there is one) creates his own interpretation of the presented content based on his expectations, prior experiences, and the context and style in which the content is presented.
Our applications return a Response for each Request sent by a client. An Action needs to be performed to create the Response. In most cases, we need to include a Document in the Response with links to further related Requests. That is the core functionality of a web application. What we perceive as a 'View' or 'Page' is no more than one or more Documents rendered by the web browser in the same window. These two terms only have real meaning at the user level.
But if you start your conceptualization from the perspective of a User, you're going to paint yourself into a corner, because you end up completely missing the point. For example, lots of people on this forum have been trying to solve the problem of 'Form validation'. But forms don't even exist from the application's point of view. A form is just an HTML structure which lets a User manipulate the parameters that will be sent along with the next Request by the client software. All the application sees is a list of parameters, and it doesn't give a damn whether these came from a regular request or from a form. But everyone's trying to solve the form 'problem', because they see a form on their screen.
I can understand how people are having problems with form validation, composite views, and all that other crap. Because most of these 'problems' arise when we define our application from the user's perspective, and they become completely befuddling when we combine these misconceptions with the ultimate anti-pattern in web applications; an MVC-based architecture.
Thank god I don't use MVC.
-
Apr 16, 2004, 04:16 #125
- Join Date
- Jan 2004
- Location
- Oslo, Norway
- Posts
- 894
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Azmo
Then there's the Action. Fowler would place that as part of the Controller in the Front Controller pattern.
You may not like it and you're free to reject it, but what I think is that it's good to be able to think of a design from different perspectives.Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
Bookmarks