The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Uhm, although we obviously have different opinions on how a View and the parsing of it works, I quite like it. It's a darn shame this is in php4, instead of php5 though, you might wish to reconsider that? Also, as I think this is for people new to the subject, I would choose to actually implement at least one model and one view. For people without any MVC experience, it's often unclear where responsibilities lie.

Wait, for those who are experienced in MVC, it's still unclear where responsibilities lie.

You could... However you are going to be faced with a nightmare in regards to maintainance and for future growth; What happens when one part changes? You should be able to do those changes, without effecting the others.

So, you are looking for Composite, where you separate each component into it's own Controller, ie

The $context is a container I have, which I pass in the class methods (not shown) which is the content generated by the Views. You would need to understand how the recursion works, to better understand the underlying approach how the container plays its part in how the Home View is put together

You can implement the Composite as you see fit, it doesn't really have to be implemented from the View layer in particular yes?

I implement the Composite in a number of ways, so you are not really restricted to the View [MVC] alone; Some people implement their Views as Composites, using one controller for example...

But that is but one implementation, and it's not written in stone that you need to follow that particular implementation. So the pattern Composite is exactly the same as that of the Composite View. There is no difference, so it's down to your own implementation of how you manipulate an hierarchacal structure.

Assuming that most of these 'modules' (however you define them) will have some output in the page (composite view), then you could write a module manager that fits into the front controller (same layout for every page) or the page controller that is selected by the front controller (different layouts for different kinds of pages). Then, I suppose, you only have to do repetitive coding for each module whose output makes up the page.

Assuming that most of these 'modules' (however you define them) will have some output in the page (composite view), then you could write a module manager that fits into the front controller (same layout for every page) or the page controller that is selected by the front controller (different layouts for different kinds of pages). Then, I suppose, you only have to do repetitive coding for each module whose output makes up the page.

I can see this approach working well within WACT.

The different components that make up a page on my applications goes like this:

Code:

+ layout
+-- content
+-- header
+-- footer
+-- box1
+-- box2 etc..

I don't want modules loading on every page because some might not require them such as when using ajax.

> If there is any one who can given an example with the code I have done showing how to
> implement the composite pattern with my controller it would be great

I'll download your file now and take a look later

> I don't want modules loading on every page because some might not require them such
> as when using ajax.

As you recurse over your structure, it's just a case of pulling a given Composite out, prior to execution thus it's ignored altogether. This is what you want, since you can have a base layout structure generated for you on each request, rather than have a different layout for each request.

In this case, you don't really need any sort of configuration, other than how your recursion would know which Composite to pull out.

You couldn't make that a Composite controller in particular, but you would need to encapsulate what you are doing here, in this class method, into a separate controller; I refer to this as an Action Handler myself.

Your Controller I refer to it being a Application_Action_Controller, akin to Zend Framework (but differing implementations). But it depends really, on how involved you want to get?

By that I mean, you could have a Composite based Controller structure, but do you need that level of refinement... You could just as well manage easily enough with just a Composite structure on your View instead, going by your posted example (found in download) in my view.

At the end of the day, it really depends on the complexity of your Page structure. If you've got a tonne of separate individual components your page is comprised of, then go the Controller route, otherwise take the View route; Take the wrong route and your going to give yourself more work to do.

Now... Where I talked about pulling out a specific Composite, or for that matter, putting one in, I would do this within the *::create() function it's self, based on a number of rules for that given Composite in question.