Page 2 of 2
Re: how should the model communicate its result?
Posted: Fri Nov 21, 2008 2:24 pm
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
Re: how should the model communicate its result?
Posted: Fri Nov 21, 2008 5:38 pm
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.
Re: how should the model communicate its result?
Posted: Fri Nov 21, 2008 9:22 pm
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
Re: how should the model communicate its result?
Posted: Sat Nov 22, 2008 4:31 am
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
Re: how should the model communicate its result?
Posted: Sat Nov 22, 2008 7:06 am
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.
Re: how should the model communicate its result?
Posted: Sat Nov 22, 2008 10:47 am
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
Re: how should the model communicate its result?
Posted: Sat Nov 22, 2008 5:11 pm
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 ).
Re: how should the model communicate its result?
Posted: Sat Nov 22, 2008 5:20 pm
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

Re: how should the model communicate its result?
Posted: Sat Nov 22, 2008 9:46 pm
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

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.
Re: how should the model communicate its result?
Posted: Sun Nov 23, 2008 4:10 pm
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