| SitePoint Sponsor |
Arborint: Fowler doesn't make the distinction which you have suggested between CM or VM separation. He talks about separating presentation from domain, and about separating view and controller in the presentation layer. Possibly you have misunderstood the presentation layer: this encompasses both view and controller.
Not taking a stab at you McGruff, but it (presentation) can emcompass both View and Controller, which I've seen in a lot of Swing and is common in this area. But I speculate that both View and Controller require separation.this encompasses both view and controller.
Even if Fowler gives it may not be neccassary to do so, but tha's just my view
You are correct that the presentation layer encompasses both view and controller. But then you simplify it to that point you have just created some sort of Super Transform View. My experience is that the degree of separation between View and Controller can vary, and for that matter the degree of separation between the View and Model, and the Controller and Model can vary as well. And maybe the last project wasn't perfect and pure, but as long as it was better than the one before it then we're still learning and improving. And the choices on degree of separation were hopefully made with an understanding of the tradeoffs.
My problem continues to be churning in search of some dogmatic definition. I am less interested, at this point, in what Fowler said two years ago than, for example, things like sweatje's Double Switch Controller idea. I love the devilish details. To have to hear "that's not MVC" everytime anyone proposes an implementation idea gets old.
Christopher
I have to wonder what your motives are here. This isn't the first time you've been snapping at my heels. You seem determined to try to finesse my attempts to help explain the MVC pattern despite your obvious lack of understanding. My main reference for most things is Fowler: please go and argue with him instead. This is the sitepoint advanced forum not the Jerry Springer show.
OK, I've done some thinking, and I believe I have a reply to McGruff.
On a framework-level, I don't distinguish much between Controller and View. The Action encompasses both roles, but one at a time. Say that I wanted to update the model - I would have an Action instance that does it's job, then redirect to a View-oriented Action. For example :
As such, all the Action classes in my first example must be regarded as part of the View.PHP Code:class MyUpdateModelAction extends Action
{
function bind()
{
$model =& new MyModel();
if ($model->update()) {
$this->view =& new Forward('?action=MyUpdateSuccessAction');
} else {
$this->view =& new Forward('?action=MyUpdateFailedAction');
}
}
}
I did it this way, in an attempt to overcome the mismatch between the MVC as it was originally thought out as an architecture for GUI-applications, and how it could be implemented in a web-application.
An Action is merly a response to a http-request. Technically, I believe the browser could be thought of as being the View in a web-application. Thus a request could be either a message to update the Model or a requst for View-data.
I guess this means that I don't distinguish between View and Controller on a code-level, instead I do it on a design-level. It might be more sane to enforce it by simply subclassing Action into View. I'll consider that.
Pretty straightforward really, but here goes (removed comments):kyberfabrikken, can you post your ListIterator code so I can try you code out?
PHP Code:class ListIterator
{
var $_data=array();
var $index=0;
function ListIterator(&$data)
{
if (!is_array($data)) {
trigger_error("Wrong parameter given. Array expected.", E_USER_ERROR);
}
$this->_data =& $data;
$this->index = 0;
}
function hasNext()
{
return $this->index < ($this->count()-1);
}
function hasPrev()
{
return $this->index < 1;
}
function advance()
{
if (!$this->hasNext())
return false;
++$this->index;
return true;
}
function retreat()
{
if ($this->index < 1)
return false;
--$this->index;
return true;
}
function & next()
{
if (!$this->advance())
return false;
return $this->current();
}
function & prev()
{
if (!$this->retreat())
return false;
return $this->current();
}
function & reset()
{
$this->index = 0;
return $this->current();
}
function & end()
{
$this->index = $this->count()-1;
return $this->current();
}
function count()
{
return count($this->_data);
}
function & current()
{
if ($this->index >= $this->count() || $this->index < 0) return null;
if ($this->count() == 0) return null;
return $this->_data[$this->index];
}
function push(&$value, $refMode=null)
{
if (is_null($refMode)) {
$refMode = is_object($value);
}
if ($refMode) {
$this->_data[count($this->_data)] =& $value;
} else {
$this->_data[count($this->_data)] = $value;
}
}
}
Back to the main problem...
I found some interesting links about the Composite View; it was a good suggestion to look after that!
Core J2EE Patterns - Composite View
Blueprints - Composite View
They talk about a template (represents a complex page layout) which include subsections like banner, footer, some boxes …
So every subsection is a atomic part of a complex page. My first question was from where do I get the data for such subsections? My supposition was, the one “Command” collects all the data and passed it with a single DTO Object to the view, not very nice, because the DTO gets huge and complex, but a good separation of content and design?! (Only a push concept, nothing to pull!)HTML Code:<html> <body> <jsp:include page="/jsp/CompositeView/javabean/banner.html" flush="true"/> <table width="100%"> <tr align="left" valign="middle"> <td width="20%"> <jsp:include page="/jsp/CompositeView/javabean/ProfilePane.jsp" flush="true"/> </td> <td width="70%" align="center"> <jsp:include page="/jsp/CompositeView/javabean/mainpanel.jsp" flush="true"/> </td> </tr> </table> <jsp:include page="/jsp/CompositeView/javabean/footer.html" flush="true"/> </body> </html>
The Kyber approach?!:
If I understand you right kyber, you said the data is assembled by subactions, so every subaction matches one subsection?!
The Proton approach?!:
If I understand you right … ;-) One “main action” for e.g. “UserEdit” with a template which includes subsections. The main action gathers the data (only for which belongs to the “UserEdit”!) and passed it to the view (A push concept). The view uses a complex template which consists of subsections. Each subsections pull the data from Viewhelpers (?!). In that case the View collects data! So Captain Protons approach is a combination of a push and pull concept?!
Core J2EE Patterns - View Helper
To my opinion the Proton approach is not so complex like the kyber approach. I would prefer Protons suggestion.
My question now, what do you think about my theories? Have I misunderstood everything or I am right?
Perhaps we could create some easy to understand sample code for the Proton approach? :-)
Greetings from Germany
-----------------
http://www.xbox-profis.de :: The german Xbox Community
Yes. And as I put it in my previous post (witch you didn't read, because we posted simultaneously), the class that I call Action may in this case be a View.If I understand you right kyber, you said the data is assembled by subactions, so every subaction matches one subsection?!
I honestly think of my solution as simpler than protons, because all the complex logic is kept in one place (in the Action's), rather than having ViewHelpers.To my opinion the Proton approach is not so complex like the kyber approach. I would prefer Protons suggestion.
I think you got it about right.If I understand you right … ;-) One “main action” for e.g. “UserEdit” with a template which includes subsections. The main action gathers the data (only for which belongs to the “UserEdit”!) and passed it to the view (A push concept). The view uses a complex template which consists of subsections. Each subsections pull the data from Viewhelpers (?!). In that case the View collects data! So Captain Protons approach is a combination of a push and pull concept?!
For a complex template (as an example think of one with a user login form, a poll and a search box or something like that) I would probably use a ViewHelper indeed.
The way I see it you even have two choices, depending on how strictly you want to layer your application. You can have your Controller create the ViewHelper and pass it onto the view or you can have your view create the ViewHelper itself (breaking layering of course).
As far as I know, mine doesn't have any complex logicI honestly think of my solution as simpler than protons, because all the complex logic is kept in one place (in the Action's), rather than having ViewHelpers.
I think my take is a kyberfabrikken / Proton mix
I agree with kyberfabrikken that most actions are requests from the client to perform some action with your Model classes. So I might have some classes like UpdateUserPrefAction or ChangeCriteriaAction. All of these actions would eventually issue a redirect to the application indicating the desired view to show.
Views are then the "default action", i.e. if no other action is specified, show a view. If not specific view is selected, show a default view. I have view classes which
a) create a template object
b) access the Model classes to polulate template vars
c) render the template
I think these might be considered Protonish view helper classes.
Whether my "View" class is a part of the controller (becuase it is brokering data to the template) or a part of the view, I will leave to the MVC philosophers, as I have no idea how many angles can dance on the point of a $model->get('pin')
Jason Sweat ZCE - jsweat_php@yahoo.com
Book: PHP Patterns
Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
Detestable (adjective): software that isn't testable.
My point exactly.Originally Posted by sweatje
I implicitly presumed the "or you can have your view create the ViewHelper itself (breaking layering of course)" solution. I probably didn't mean complex as in "advanced piece of code" as much as "hard to figure out where it's initiated from". If the ViewHelper is instanciated in the Controller, and passed to the View, I get the idea, but I'll argue that the ViewHelper belongs to the Controller-layer.
I believe it's actually more of a domain layer (model) object, according to Fowler. I haven't got the book at hand here, otherwise I would look it up.If the ViewHelper is instanciated in the Controller, and passed to the View, I get the idea, but I'll argue that the ViewHelper belongs to the Controller-layer.
My thoughts are with the Captain in regards to the View Helper. As from what I can tell, I suppose the View Helper should wrap a given Model
By wrap I mean it [the View Helper] resides over the Model in layering terms...
I'd have to beg to differ Kyber... A View Helper can be seen as being a part of a View, in the tradiontal sense of what a View is, but in a few cases I've seen, this isn't the case.I get the idea, but I'll argue that the ViewHelper belongs to the Controller-layer.
There had been no presentation at all in the View Helpers.
I believe it's actually more of a domain layer (model) objectAdmittedly - I stay corrected.My thoughts are with the Captain in regards to the View Helper. As from what I can tell, I suppose the View Helper should wrap a given Model
By wrap I mean it [the View Helper] resides over the Model in layering terms...
I never actually used the pattern myself, as you may deduct from my posts. I do acknowledge it as a feasible replacement for my Controller-push architecture. Does anybody use this pattern in combination with a XSLT-based view ?
Anyway - ViewHelper or not - how do you people assemble complex views ?
You do? I've yet to see any example that implies a View Helper has any involvement with a Controller [MVC]. Anyways, to answer your question I stated earlier the Composite View?Admittedly - I stay corrected.
I stated that your implementation was static, and to some degree this is the case in the sense I was meaning you need to build the composites on the fly, to be dynamic but I didn't see this in your script.
I've tried a few approaches on building the web page as a whole from a number of segments though I've never been really happy with the results. The problems have been in relation to building the composite structure it's self.
Recursion has never been my strong point
To add more confusion to this discussion, or maybe to help give a clearer picture, I've quoted from an article on MVC from object arts dot com,
Where AM is an Application Model.What we really want, though, is a tight coupling between AM and View but a loose coupling between Domain Model and View. Rotate the triad slightly and we get the Model-View-Presenter framework.
http://www.object-arts.com/Education...tterns/MVP.htm
That's what I meant to say. You're right.
Obviously - but how does the concrete implementation look ? code-samples please
Yup ... I read that as well, and I think it's a good point to keep in mind the distinguishing between DM and AM.
By the way : http://msdn.microsoft.com/architectu...tml/DesMVC.asp
It's rather hard to see in the posted example, but the idea is that Action::getOuterAction() can return different actions depending on whatever. In the posted example I just return a hardcoded action so in reallity it becomes static. But it's quite simple to extend the method to return something else. In contrast the MainSectionAction vs. MainMenuAction is truly static.I stated that your implementation was static, and to some degree this is the case in the sense I was meaning you need to build the composites on the fly, to be dynamic but I didn't see this in your script.
Eg.:
PHP Code:class DisplayArticleAction extends Action
{
function bind()
{
$this->view =& new Template("article.tmpl");
$this->view->setValue("title", "Title of the Article");
$this->view->setValue("body", "Lorem Ipsum ...");
}
function & getOuterAction()
{
if (rand(0,1) == 1) {
return new MainSectionAction();
} else {
return new AlternativeSectionAction();
}
}
}
Watch my upcoming thread "To hopefully clear up some confusion about 'To hopefully clear up some MVC confusion...' "
Just kidding
Nothing concrete at the moment, just pieces of script flying all over the placebut how does the concrete implementation look
Once I do have something of worth, I will post the script on these forums, but I've not had the time recently to look into it more.
As I've said, the problem I have is recursion over the structure. What I need is a Walker to walk through it but the script I posted (Using Compsites) has a bug which I've yet to solve
First, please excuse my earlier comments. There's been some history there which I won't go into. Rightly or wrongly I felt that an entirely unambiguous point was being spun out into a point-scoring argument.
That looks like an ApplicationController. What I think you are calling a view seems to be a whole new request with - possibly - a further MVC trinity containing a view.
I really don't know what else to say about the basic idea of view and controller separation which I haven't already said. It just is what it is.
One possible approach to MVC design is just to forget all about it: decompose the presentation layer as you see fit.
As long as you follow the usual presentation/domain/data layering, and the principle of "one class one task", you'll almost certainly end up with something MVC compliant. Controllers receive input, make decisions and tell other entities to do all the heavy lifting. Calls to the domain for the data to be displayed, presentation logic, formatting, printing the final page: these are all aspects of the view. The two don't have anything in common and if you tend to write nice, tight little classes perhaps there's not much chance they'll get mixed up in the first place. Separating decision from action is an obvious refactoring, in general.
The "MVC" label doesn't say anything much in any case. FrontController? TableGateways? DataMappers? TemplateView? These explain something meaningful about the design choices. If a travelling salesman came to my door selling MVC, I'd frankly be a bit suspicious.
Hello,
Still a bit thin on the ground though currently I'm looking at an XPATH solution, here is an idea?code-samples please
The XML is kept simple at the moment, using attributes for labeling but using nodes shouldn't be a problem, ieCode:<?xml version="1.0" encoding="iso-8859-1"?> <templates> <!-- a very typical example of a webpage structure --> <template id="page"> <template id="header" parent="page"> <template id="searchbox" parent="header" /> </template> <template id="body" parent="page"> <template id="leftside" parent="body"> <template id="news" parent="leftside" /> <template id="polls" parent="leftside" /> <template id="signon" parent="leftside" /> </template> <template id="rightside" parent="body"> <template id="breadbrumbs" parent="rightside" /> <template id="content" parent="rightside"> <template id="menu" parent="content" /> <template id="document" parent="content" /> </template> </template> </template> <template id="footer" parent="page" /> </template> </templates>
Some script, which I might add I'm embarrassed to postCode:... <template id="blahblahblah" parent="blahblahblah"> <url>segment-template.tpl</url> <handler>../handlers/segment-controller.php</handler> ... </template> ...
Would certainly welcome suggestions from SleapEasy btw (hint hint)PHP Code:$dom = new DomDocument;
$dom -> load( 'recursion.xml' );
$xp = new DomXPath( $dom );
$fragments = $xp -> query( "//template[@id='page']" );
// DOMNodeList
$id = $fragments -> item( 0 ) -> getAttribute( 'id' );
$tmp[$id] = array();
$fragments = $xp -> query( "//template[@parent='".$id."']" );
foreach( $fragments as $fragment ) {
$node = $fragment -> getAttribute( 'id' ); echo( $node.'<br />' );
}
Still searching for ...
... the perfect solution (a complex page with MVC in php5) ...
At the moment I study some interesting things:
A sample shopping application:
http://www.asp.net/IBS_Store/
=> Take a look at the documentation ;-) :
http://www.asp.net/IBS_Store/docs/docs.htm
Design and Implementation Guidelines for Web Clients
Frontcontroller Pattern
...
Perhaps "Using page inheritance" is a solution approach ?!
-----------------
http://www.xbox-profis.de :: The german Xbox Community
Another solution, but very complex:
HMVC: The layered pattern for developing strong client tiers
What do you think about that? Sounds like a nice solution?
Perhaps we could translate that into a nice and small PHP example in order to discuss that?!
Do you think such an approach is usefull for a web application?
(It looks a littlebit like Kybers Actionchaining?!)
-----------------
http://www.xbox-profis.de :: The german Xbox Community
I think this is the approach that WACT takes with a hierarchy of controllers. It would be interesting to see a basic Application Controller implementation with parent/child capability.
Christopher
Just refactored a little:
This way the code is more expressive about what it is doing: getCommand gets a command, rather than a large switch block in a run() method. It also exposes more functionality of the FrontController, as it is basically acting as a factory. And you get shorter code too.PHP Code:class FrontController
{
function run()
{
$command = getCommand($_GET['page']);
$command->execute();
$view = $command->getView();
$view->render();
}
function getCommand($command) {
switch ($command)
{
case 'add': return new UserAddCommand;
case 'edit': return new UserEditCommand;
case 'list': return new UserListCommand;
}
}
}
Douglas
Hello World
This part still could be refactored as SWITCH is a bad code smellPHP Code:...
function getCommand($command) {
switch ($command)
{
case 'add': return new UserAddCommand;
case 'edit': return new UserEditCommand;
case 'list': return new UserListCommand;
}
}
...
Posting Permissions
Bookmarks