http://en.wikipedia.org/wiki/PortalOriginally Posted by mwmitchell
Views = Web Pages
SubViews = "Blocks" or "Portlets"
HTH
| SitePoint Sponsor |
http://en.wikipedia.org/wiki/Portal
Views = Web Pages
SubViews = "Blocks" or "Portlets"
HTH
I was thinking more about the model that knows about validation and forms. What about MFV for Model Form and Validation? This has only to do with the model (when looking at MVC).
If the model could simply have properties that define what each member is (firstname, char, min=1, max=10), you could have a Form class that could read the model (knowing it's interface) and then after the form was submitted, the Validation would be able to validate by looking at the model also. It would know that the firstname (for example) must be a string, and have atleast 1 character, but no more than 10. These 3 together would make up a nice group. A pattern? Get model, build form, validate.
Any good?
Matt
Hi, I'm - like all of you - trying to develop the Ideal Pattern for the Web as part of the framework I'm developing.
I don't claim that my approach is revolutionary. You may have seen something similar - I don't know. I also fear it may not be that far from the MVC as I once thought it was. Not a bad thing in itself - it's just the "possibly wasted time" aspect. For now I'll just identify and briefly explain the main components of my approach. Maybe I'm going in the wrong direction, or maybe not. Feedback is what I want - good or bad.
Pipe / ActionQueue
This is a queue of actions. Actions are instantiated as they go into the pipe, processed while inside the pipe, and their data (if any) retrieved (by the response component) as they leave.
Actions
Actions are the Business Logic. Groups of actions make up whole Applications (forum, advertising, webmail etc.).
There are two types of actions - Silent and Verbose. Silent actions just do processing, Verbose actions also produce data that has to be presented to the user.
Actions can range from logging user clicks, to displaying a thread in a forum, to processing a form. A typical web page would consist of many actions.
Actions can attach themselves to events.
Persist
For the persistence of objects - in a session or database, as serialized text or XML. Actions can be wholly persistent and/or may use other persistent objects.
Events
Events drive the system - they can occur at any time and from most components up until the last action in the pipe completes it's process() method.
They are used to notify interested actions that a certain event has occured - usually corresponding with action objects succesfully completing their process() method although this is not a rule.
Example
One of the main events is the Event_NewRequestEvent. It occurs on each page request. The event carries some properties including the url of the page requested, etc. Actions can be configured to respond to Event_NewRequestEvent events that have a certain url.
Example
A Menu action is responsible for generating a menu. If the user is logged out the menu should have 'Log In' and 'Register' items. If the user is logged in: 'Log Out', 'Preferences', etc. The Menu action is instantiated and attaches itself to the UserLoggedIn_Event event. The Menu action completes its process() method, and has generated a menu for a logged out user. The next action logs the user's click. The next action is the processing and validation of a log in form (which succeeds). A User action (which is a silent action that has session state, and database persistence) is added to the pipe. The UserLoggedIn_Event is triggered. The Menu action receives notification of the event and modifies it's menu accordingly.
Notifications
When an event occurs any actions that have registered their interest in the event are notified.
Action objects may or may not be instantiated at the time of an event. If they haven't been instantiated they are "Woken Up" (instantiated) and put in the pipe. Otherwise the action object is immediately notified of the event. In both cases the notified action object knows why it was notified and can react accordingly.
Notifications also allow communication between the object that caused the event and the object receiving the notification (depending on the event).
Response
Data for presentation/transport is pulled from verbose action objects. "Templating" (with XSLT) and transportation is controlled by a set of classes suited to the different clients (Web Browser, SOAP Client, Terminal).
The framework does have some other components but this post is already too long.
I hope that was clear enough - I know I have a tendency to ramble on a bit.
If you want some more details let me know.
Off Topic:
Great thread BTW, I've just got back from my Christmas break and was hoping there'd be a few good threads waiting for me when I got back. I wasn't dissapointed. This forum really is the place to be (as was mentioned earlier).
Last edited by sleepeasy; Jan 7, 2004 at 05:06.
Always open to question or ridicule
Not badPHP Code:$page->addMvcBlock('login');
$page->addMvcBlock('productList');
Was thinking the same myself that something like this would be well smart... Want to share some more about how you implemented this with some script ?
Again, our Site Point Forum crew has abolutely amazed me. I've just done a quick read through and I feel as though I've barely skimmed the surface of what can be learned here. I wish I wouldn't have fallen behind here so that I could hav etaken it in chunk by chunk
sleepeasy - Would you be willing to provide some quick psuedo code about how some page (maybe a sample like the portal that was discussed earlier) would be built. Your method seems quite workable to me, but I'd need to see a more application based approach to grasp it.
Also, someone had mentioned that a big problem with things is that people end up picking a pattern and trying to fit their problem to it rather than the other, and proper, way of coming up with a clear problem and then coming up with a pattern that is a workable solution. It's spot on and I noticed that I was doing it as well. OOOOO!! MVC! That sounds cool. How can I use it now if I want to make my website. It is a terrible way to do things, but what's a "newbie" to do
I do believe that it is not completely worthless to do the above though. It does allow a beginner to learn a pattern, but more importantly it teaches people that knowing the problem is important in the first place. I never went through any sort of application design before I coded in the past. Now, after attempts at using MVC (and a few other patterns) both successfully and otherwise, I find myself sitting down and coming up with at least a set of requirements for my applications.
Keep up the discussion!
Yes I'd be very happy to. I need to comment some code and clean it up a bit. Then I'll put it as an attachment.Not badPHP Code:$page->addMvcBlock('login');
$page->addMvcBlock('productList');
Matt
That'd be great. Can't wait
OK, here it is:That'd be great. Can't wait
http://telegraphtomcat.com/SimpleMVC-example.zip
It's nothing amazing, but to me, putting miny MVC's into other mini MVC's could be a a pattern? I guess that doesn't matter, what's important is that this is what made MVC work for me. In the examples there are no DB calls or whatever, just pretend that the data in the 'Actions' is coming from a db etc...
Now, you'll see that this is a lot like Mojavi (using the same directory structure) but very simple, and it allows you to mix and match modules. A module is a group. a group consisting of an action, a view and anything else related (models and templates etc...)
This isn't intended to show a framework, just the "idea" of binding MVC blocks together?
Let me know what you think...
Matt
Okay, at the moment I'm having some real trouble with my Win98 installation, so I'm going to have to do a FORMAT C: /S and instead of Win98, I'll install WinXP Pro tonight
So might be a wee while before I get back to you on my thoughts
The most basic of pages could be built something like this.
PHP Code:$eCentral = Event_Central::instance();
$eCentral->start();
$pipe = Pipe::instance();
$pipe->add(new Menu());
$pipe->add(new RSS_RemoteFeed("http://foo/bar/news.xml"));
$pipe->add(new Login_Form());
$pipe->add(new XML_Document("foo/bar/about.xml"));
$pipe->add(new Advertise_Sponsors(Advertise_Sponsors::RANDOM));
$pipe->start();
$response = new Response(Client_Factory::getClient());
while ($action = $pipe->next()) {
if ($action instanceof Action_Verbose) {
$response->add($action);
}
}
$response->send();
Always open to question or ridicule
Wow, any chance you could explaing what's going on, and maybe a little source code?
Looks very interesting to say the least,
Mat
I'll explain how it works but I can't show you much source code because I've just started to change a few things so it's all a bit of a mess.Wow, any chance you could explaing what's going on, and maybe a little source code?
Looks very interesting to say the least,
Mat
Event_Central (Singleton) is the class that notifies actions when events they're interested in occur. We have to start() this before any actions are processed.
Next we add some actions to the Pipe (Singleton), and start them.PHP Code:$eCentral = Event_Central::instance();
$eCentral->start();
Next all action objects (each will have finished their main process() method) are passed to the Response object.PHP Code:$pipe = Pipe::instance();
$pipe->add(new Menu());
$pipe->add(new RSS_RemoteFeed("http://foo/bar/news.xml"));
$pipe->add(new Login_Form());
$pipe->add(new XML_Document("foo/bar/about.xml"));
$pipe->add(new Advertise_Sponsors(Advertise_Sponsors::RANDOM));
$pipe->start();
The Response object retrieves the applications data from each action object. This data is a DomDocument (XML) object (or a subclass). All the DomDocument objects are joined to form an XML document ready for transformation.
In my previous post I mentioned that actions are part of an application. Every application has it's own settings (stored in XML or database table). When an action is added to the pipe the settings for the application it belongs to are retrieved by it's superclass.
It uses the object passed to it to find out what content type it will need to send (and to check that the application has a template to transform it's data into that content type). In this case Client_Factory::getClient() is used to detect the client and return a suitable object.
Each action object's settings are also retrieved by the response object. This is where the response object gets the names of the templates to use for each action.
(This next bit isn't quite finished yet)
A check is also made for whether the action requires a different object to transport the response. For example, an action "foo" may be setup to have it's data transformed and displayed in the default way, but (due to a user selecting an "Email it" checbox) may need it's data transformed into HTML but need it be sent via email. In this case the Response object would create a new Client_Email object to use to transport "foo"'s data.
And finally, the page is displayed. The way send() will work will be different depending on the object passed to Response(). But for a web browser it just echo()'s the XSLT transformation.PHP Code:$response = new Response(Client_Factory::getClient());
while ($action = $pipe->next()) {
if ($action instanceof Action_Verbose) {
$response->add($action);
}
}
PHP Code:$response->send();
I hope I explained it well enough. I should've been in bed a long time ago
Any questions/ comments?
Sounds like a very clean approach, I really like it. Very thin controller pages is definetly a good goal these days to me.
Been away for a while on a new year trip after starting off this discussion (a happy new year to you all
Thanks to everyone who chipped in. Lots of fascinating comments which will take some time to digest.
MVC causes a lot of confusion. I think I've also been confused at times. The key is, I think, that MVC is great for printing a page BUT an http request to a dynamic website has a lot more going on than merely printing a page - at times that might merely be a side issue to the main meal.
I think a common mistake (which I've also been guilty of) is to try to fit the entire process inside MVC. However, it's maybe better to view MVC as just one part of a three-stage process that may also include pre-output tasks and post-output tasks. Interpreting the request might be another stage.
Sandwiched in between, I'd see a layer with responsibility for selecting dynamic & static content, formatting it, and finally printing it. Anywhere some data needs to be defined and sent to client/written to file etc is perhaps the place to apply the MVC pattern - and nothing else.
Some details of a front controller along these lines in this thread http://www.sitepoint.com/forums/showthread.php?t=148280.
Last edited by McGruff; Jan 22, 2004 at 06:20.
Pre output tasks I can grasp, though post output tasks ? I do not understand this point, where once the server sends the page, that's it....may also include pre-output tasks and post-output tasks.
A scripting langauge can not have anything more to do with that page, true ?
Maybe you can give some examples of what you mean by post output tasking please ?
Pre- and post-output tasks are very well handled using the InterceptingFilter pattern. See http://java.sun.com/blueprints/corej...ingFilter.html. Although this pattern does not strictly belong in MVC, it is a piece of the puzzle of how the problems with 'just MVC' can be solved.
MVC is a very course-grained pattern of course. Although it speaks of only three objects (Model, View and Controller), each one of those objects can contain of a virtually unlimited number of other objects and even layers within layers. It is very well possible to create your own layers within the Controller, like you describe.Sandwiched in between, I'd see a layer with responsibility for selecting dynamic & static content, formatting it, and finally printing it.
Sending an email, logging page views to a db, capturing a buffer and writing to file.. anything really - and I guess as much as you can possibly push in there to gain whole hundredths of a second on page load times...
The script, as you point out, has to come to an end sometime but state can be maintained with sessions.
Is it better to embed MVC in apps not whole apps in MVC?
A single http request might spawn several "print something" requests (eg email, write a log file, & of course the page sent to the client). Each one should possibly have its own MVC-based sub-routine with each controller responsible for its own model and view and nothing else.
I think so. MVC is in a way embedded in applications, I guess. But you have to design your application in such a way that this embedding is possible.
The Model is the key to this. You have to design the model of your application in such a way that it is completely independent of the presentation layer. Doing this right the first time may be hard if not impossible.
The Model of an application should be coded in such a way that it can be used by any type of presentation layer: command line, XML-RPC, HTML, WAP. I think it helps if you think of the model as being a completely separate tier of the application, which might even be on a different server. If your app is structured in a way that this is conceptually possible, then you have coded a good model
When you are in doubt of whether a certain piece of code belongs in the model of an application or in the presentation layer (= Controller + View), think of the above.
When an application model exists, the VC of MVC is a way to structure (part of?) the presentation layer of the application.
In conclusion, MVC is part of an application, it's definitely not that an application consists of only M's, V's and C's.
In the discussions on this forum, people (including me) also often mention thinks like FrontController and InterceptingFilters. The way I see it, these design patterns are not part of MVC, they merely complement it.
An output filter works on "suppressed" output. That means to say that you can Save output Content until the absolute end of the request. A better way to think of this scenario would be an email template system. I say this because when folks think of Http Requests and Responses, they automatically see it as a one way street... it is and it isn't.
Imagine creating a text file that will serve as a template for an email message. You put in place holders that should be replaced before the message is sent such as email address (from and to), subject, body, and maybe even some other headers.
1. You query a database for all the data you need
2. You pull in the contents of the external text file containing the email template text
*3. You run your "OUTPUT FILTER" upon the contents of the text file
4. You send this output to your send email routine (function, static method, etc)
5. Now you will probably have browser output here letting the user know if the message was sent successfully or not.
6. Even this output could have been "saved" until the end and place holders replaced
Another way of thinking of Post Output is logging.
After all the above steps, you may need to log to a file or database what just happened.
Think about caching... Say we wanted the email output to be cached so that the next time this sequence is run there is no database query run, there is no file parsing, and there is no variable substitution. This could easily make the app 400% faster.
This would all have to happen at the end of the request.
Hope this helps.
Wil Moore III, MCP | Integrations Specialist | Senior Consultant
DigitallySmooth | HotBusinessDirectory
BTW, the best way to do this in php is http://us4.php.net/manual/en/ref.outcontrol.php
Wil Moore III, MCP | Integrations Specialist | Senior Consultant
DigitallySmooth | HotBusinessDirectory
Thanks, it does make things a lot clearer
This is an amazing thread. Better late than never.
I think the term MVC is wrecked. Perhaps it no longer has any definite meaning.
I think you are on to something with this idea of "two half jobs." Imagine an alien software anthropologist studying 20 applications written to use 20 different so-called MVC frameworks. Surely, he would not come away with the idea that the central abstractions of the application were models, views, and input controllers. He would come away thinking the central abstractions were commands or actions (*_handler.php) and views (*_display.php).
Depressing, isn't it. There seems to be no consensus on the issue. As you say in a later comment, people seem to be pursuing MVC for the sake of MVC:
An alien web software anthropologist would almost have to add TemplateView and FrontController to the list of successful web development patterns. These are tried and true.
I would like to think that our alien anthropologist would find a segregated model in each of the applications he examined. But I am not so sure.
Its hard to imagine making such huge changes in the UI of your application without having to change both view and controller together. Its Mvc with vc being the UI. I think thats why we have Document/View. The benefits of separating the input and output sections of the program just aren't clear and aren't easy. There is definitely a relationship between the input and output, but perhaps sometimes there can be too much of a relationship?
So is there no benefit for separating input and output in a PHP web application? I think there is some benefit, but I am still developing this idea.
Signs your application mingles input and output code too much:
- It would be hard to move it to different url?
- If POST were deprecated, I would have to change alot of code.
My list needs work.
Every program grows until it implements a front controller or is replaced by one that does?
Controlling the outcomes for a single page is the job of a Page controller. Its the job of the page controller to determine if the request for that page should trigger a login, search, command, etc.
I've noticed that every Front Controller/MVC framework has a cinderella page controller pattern hidden inside somewhere. The Front Controller takes the credit and they won't let the page controller out in the daylight or even give it a proper name, and mostly doesn't even realize how important it is. But, the page controller there, toiling away. Its time to give cinderella her glass slipper back and sharpen the page controller abstraction that is inside every front controller.
I had this epiphany about page controllers when I was acting as an alien software anthropologist and studying struts. I noticed that struts had an ActionMappings object in between the front controller in the framework and the action that the framework user wrote. I noticed that it performed the exact same functions as the FormController page controller in WACT.
So, then I started looking at other Java & PHP frameworks. They too had similiar objects. I found in the ones that didn't, the users ended up writing page controller code in their action. None of the frameworks called their objects page controllers. Many of them blurred the responsibilities between the action, page controller, front controller, application controller, intercepting filters, and commands.
Fowler talks about a Front Controller dispatching to commands. Core J2EE patterns talks about Front Controllers being responsible for managing commands and managing views. I no longer think of it this way. I think the front controller's job is to dispatch to a page controller. Its the page controllers job to manage views.
Look for wherever component(s) decides if a form should be redisplayed because of invalid input, that is where you find the page controller in that application.
Just because an application has a front controller, doesn't mean that it doesn't have pages.
I think there is something to be gained by embracing the inner page controller. This philosophy is reflected in the current WACT controller design.
Add page controller to the tried and true web application patterns catalog.
Actually, as long as the domain code that gets executed doesn't change the model, but merely reads the model, I think that its still MVC safe. If there is one long term goal that I hope that WACT can acheive, its moving the language of template markup out of the programming realm and into the domain realm.It could, but then it wouldn't belong in an MVC architecture. In a clean MVC only the controller can nudge domain code into execution. It then collects the domain objects that result from the logic and hands them off to the view for display. The view should strictly speaking do nothing more than use getters on the domain objects and put their data into the right template variables (if you use one).
I think that this is the case in DocumentView. I think the point of smalltalk MVC was that the view would present the button and the controller would be responsible for the click. (Controllers would query the view as part of finding out where the cursor was located.) Also, there was a hierarchy of controllers and a heirarchy of views. Applications Programming in Smalltalk-80(TM):
How to use Model-View-Controller (MVC)
One aspect of the the GUI MVC pattern is that it seems to emphasize multiple simultaneous views and instant updates of each view when the model is changed. This doesn't seem like it would matter in a web environment.
I think you are spot on with this. until we feel the need for a specific separation of concerns, we won't understand it. There are others: segregating HTML from code (templates), natural language from code (i18n), SQL from code (DAO), etc.I think that a lot of people haven't "found the need" to use MVC, but they just want to use it because it is indeed a buzzword (at least on these forums
Also, I think that MVC is part of a "bigger whole", something that I've seen called "separation of concerns" or "SoC". That is after all what MVC is about! putting code with different responsibilities that should not be mixed into different classes (layers if you will), to create more flexible and reusable code designs. But MVC is not where SoC stops, you can apply it to your entire application. I even believe that SoC is something like a 'natural cause of evolution' of object oriented programming.
I think this helps explain the variance on this issue. People have different needs for separations, and they all tend to call theirs MVC.
I'm still trying to understand the idea of separating input and output in a web application. I do it in my programs. Not with iron discipline all the time, but I do try. I do think that its a good thing. I just can't explain which problem it solves.
I've been struggling with this idea in WACT. Do the templates contain control information? I think there is a difference between control information (sounds like you mean navigation information) and a controller.
I am not sure that building a capability into the template for this would break MVC. If the controller places the information in the model and the template just reads it out, what harm?
BTW, struts has a tag library to generate anchor tags based on querying the front controller. WACT will soon have similar capability.
I've been trying very hard in WACT to prevent these interactions from going through the view. Its an optimization issue. Imagine submitting a form as a three stage process: Initial presentation, validation review, and process result. When the valid form gets POSTed back to the server in the last phase, it is likely that the view that contained the form that produced the input data will not be the next form you want to display. (perhaps a thank you page instead.) So why should we create the view that contains the form and its components when we aren't sure we are going to display it? This would violate the principle of "half jobs" that you described at the beginning of this thread.
Therefore, we define the action and data handling for the form seperately in the page controller/action portion of the application. Note that JSF and .NET define this part as an event on the component, which is a DocumentView approach. But then, being stateful, they already had the view loaded in the server when the request came in, so they don't care about the cost of building it up again.
So here is some code which registers an action that will occur when a button is pressed on a form:
ConvertToLower is the name of the class which will handle the action. The action is not invoked unless a value for lower has been passed as input to the page. lower is the name of the post variable from the template (view) :PHP Code:$Page->registerAction('ConvertToLower', array('lower'));
They are related, but loosely coupled only by the name which they share.Code:<input name="lower" type="submit" id="lower" value="Convert To lower Case">
I am finding with the current WACT implementation that I am instantiating a semi-generic controller:
EditPage is a re-usable Page Controller. 'category' is the thing getting edited. The EditPage uses this to load the correct model object and correct view based on a naming convention. It will also dispatch to the correct action based on a naming convention. The View is also generic and parameterized. it takes a template name. The template itself is highly modular, wrapping a custom defined form with components inside a standard 'edit form' layout. I am finding that for stupid CRUD applications, even the action and the model that get loaded might also end up being generic classes configured with a parameter. This is a very dynamic setup and I am not sure if its a good thing, but I will say one thing. There is very very little duplicate code.PHP Code:$Page =& new EditPage('category');
$Page->run();
Working on this issue is challenge for the near future. I've run into the issue of needing viewlets and subviews. I've programmed some support for the CompositeView pattern, but have not yet determined what impact this will have on the controller structure.In the OO world you are likely to have multiple domain objects, each with viewlets say, so that you can rearrange the content flexibly. Does each subview have it's own controller? If you do then in MVC you will have to build your C tree as well as your V tree. I think MVC is anti-OO here. It requires a god controller indeed if it is going to assemble all of the views and read all of the input data, rather than let them build their own children. This is an unlikely case (I have never needed it), but one that is easily dealt with by custom tags.
Smells like shotgun surgery. I'm seeing the same thing using the WACT FormPage. Item c is automated in the framework in WACT, but its still shotgun surgery. What is the alternative though? It seems like even the DocumentView model of .net separates the definition of the field from the processing of it.
Naked Objects works for simple CRUD, but for complicated user interactions, you will either have to complicate your model to make the UI simple, or complicate the UI (for the users) to make the model simple.
My previous EditPage example is very close to a naked objects approach. I think it will break when the pages get complicated. Fortunately, there are always a few simple pages laying around in any application of sufficient size.
I think the mark of a good pattern is that it keeps getting independently re-invented.
I do not think loading this information in the view itself violates MVC in any way. The view doesn't need the controllers help to go fetch some data from the model and display it to the user. The only place the controller would come into the picture is if the information in the subview was dependent on the user's input for that request. The view has free access to the model.
Well, to sum this thing up, lets go back to our alien anthropologists list of tried and true patterns for web application development:
Front Controller
Page Controller (optional application controller)
Command
Model
View
Template
So what is web MVC? Well, what ever GUI MVC was, this is what I think web MVC means post struts.
Great - that looks like progress.Well, to sum this thing up, lets go back to our alien anthropologists list of tried and true patterns for web application development:
Front Controller
Page Controller (optional application controller)
Command
Model
View
Template
So what is web MVC? Well, what ever GUI MVC was, this is what I think web MVC means post struts.
Posting Permissions
Bookmarks