how should the model communicate its result?

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: how should the model communicate its result?

Post by josh »

Because FCs dispatch. If you're repeating a lot of behavior you could extend the action/input controller or look into an application controller
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: how should the model communicate its result?

Post by Christopher »

VladSun wrote:Another question that bothers me - do we need an Action Controller at all? Isn't it the Front controller enough for building a web MVC application?
These "thin controllers" look too much similar to each other, so why not put'em into the Front controller?

If we have an interface that every Model object should implement, I don't think we need any control flow logic in the Action Controller.
I actually do this using Action Controllers. I almost always have a couple of Action Controllers that are used for many pages each. They infer what is wanted and combine any data or templates together in a way specific to the application. Also, I use the error controller that is dispatched when no controller is found to show static HTML content. I often customize that code so I can pass extra parameters to do little site specific things.
(#10850)
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: how should the model communicate its result?

Post by alex.barylski »

I actually do this using Action Controllers. I almost always have a couple of Action Controllers that are used for many pages each
I'm not sure if I misunderstand but incase I do...

You use the same controller(s) for many pages or are you saying you use many controllers per page?

In either case I am interested in hearing how this is done and more importantly why, what benefits does it offer? As it stands I almost always have a single controller per page but I'm thinking maybe it might be neat to reuse some controllers if possible.

I have in the past chained multiple controllers togather to form an processing chain...but it turned out to be a PITA to maintain so I scrapped the idea.

Basically one action uploaded a file, and forwarded that file onto an action processor. If it was XML it was handed off to XML processor if it was CSV it was handed off to CSV processor and INI was handed off to INI processor.

Once each of these processor actions finished they invoked the final action controller with the data from each file as a PHP native array which the last action controller would then use to import into a database.

This is the only time I found it "sorta" useful to chain controller actions. Eventually I opted for a strategy implementation in the model and had it simply process the files and return a native array.

But the idea of chaining controller actions still interests me...if I could think of a scneario where it might be a more interesting solution.

Cheers,
Alex
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: how should the model communicate its result?

Post by josh »

Technically what you referred to is a bridge not a strategy, but the same thing in essence, the context is just different. I think ( but may be wrong ) what is being discussed is an application layer within the domain layer. This could be considered a service layer or facade. Basically all that functionality thats in the controllers would be factored down into the domain model which would take care of the heavy lifting
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: how should the model communicate its result?

Post by Christopher »

PCSpectra wrote:You use the same controller(s) for many pages or are you saying you use many controllers per page?
Same Controller, many pages. As VladSun said, it often ends up that many "These "thin controllers" look too much similar to each other,". I was saying that I don't pull that functionality into the Front Controller. Instead, I create Controllers that are still thin but use parameters or other context to differentiate the content when the Controller functionality is identical. Static HTML pages are one such Controller. The content still need to be inserted into the the layout, so they are essentially just selecting a template file. Likewise things like showing a simple list of items from a database. It could be a company's employees on a contact us page, a list of press releases to download, etc.. The difference is just the names of the Model and View -- which are essentially polymorphic. Nothing really unusual about the idea.
(#10850)
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: how should the model communicate its result?

Post by alex.barylski »

Technically what you referred to is a bridge not a strategy, but the same thing in essence, the context is just different.
Funny, cause I would say you are confusing the two patterns, not me. :)
http://www.codeproject.com/KB/architecture/bridge.aspx wrote:Often, the Strategy Pattern is confused with the Bridge Pattern. Even though, these two patterns are similar in structure, they are trying to solve two different design problems. Strategy is mainly concerned in encapsulating algorithms, whereas Bridge decouples the abstraction from the implementation, to provide different implementation for the same abstraction.
A bridge is not what I needed, nor is it what I implemented.

1. The user uploads a file
2. The user selects a file type from a list of radio options (XML, INI, CSV)
3. The strategy is detemrined by the end user and executed to process the file

No where in those steps do I see a need for a separating the abstraction from implementation, however I do see a need to simply swap implementations or algorithms dynamically (as it's unknown how many sources data will come from -- could SQL file in the future or myabe a binary format) while leaving the interface alone.

Cheers,
Alex
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: how should the model communicate its result?

Post by josh »

PCSpectra wrote: If it was XML it was handed off to XML processor if it was CSV it was handed off to CSV processor and INI was handed off to INI processor.
These are implementations of a filesystem abstraction. Like I said the terms are almost interchangeable though ( bridge & strategy ).
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: how should the model communicate its result?

Post by alex.barylski »

Oh yea...hmmmm....no comment right I'm...to tired...and I don't think there is much more to say...

Back to work :)
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: how should the model communicate its result?

Post by josh »

Upon re-reading the definitions of the patterns and your post you are right, and I should not have spoken for your code :lol: The confusion was I figured your abstraction ( your uploader do-hicky or whatever ) had it's own subclasses

This is what threw me off:
PCSpectra wrote:Basically one action uploaded a file, and forwarded that file onto an action processor.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: how should the model communicate its result?

Post by alex.barylski »

No worries man...the code was complex which is why I was confused which is why I refactored...

It's first implementation was more akin to something of a Chain of Responsibility pattern with the exception being each controller knew what controllers it was to forward to next (whereas other chains in my system are completely ignorant of that they just do what they know to do and return).

In anycase...I don't think there was any concrete pattern in the design...not that there ever is but still it was confusing for me write so understandably it would be confusing others to comprehend, especially without the benefit of the source code right in front of you.

Cheers,
Alex
Post Reply