Hi all, Matthew scriobh: >I've been following Padraic's blog (heck, I've been commenting and >pointing out functionality of ZF to him), and what I see him doing is >something that only a fraction of sites are going to need to do. Not >every site needs to have composite views; his does, and he's trying to >figure out how to do so with ZF. If there's enough demand for the >functionality he describes and the solution he creates, we'll evealuate >if it's something ZF should support natively.
You know I did poll a number of programmers before starting that series, and composite views tended to crop up quite regularly. I think it's more popular a strategy than you think. Stating only a fraction of websites need it is a very broad stroke to make. As a matter of opinion I find the fascination with making controllers running the show almost as alien as you probably find composite View objects ;). I just don't see why Views should sit around and act helpless when they need some data from the Model. There's nothing in the MVC approach forbidding them from running off to get the Model themselves rather than relying on the Controllers (and all the processes that inevitably involves) to hand feed them. The widget view helper proposal Matthew pointing me to for example is one step forward. My own approach is an alternative - but hardly exclusive. Both have valid uses in their own way. For example, the controller layer is needed the moment the View needs more than a Model (e.g. ACL, external logging, etc.). The point being it's not a one fits all approach - alteratives of differing degress are called for. I don't think mine requires all that much change either - the main change is adding View multiplicity to aid compositing. Chances are the multiplicity isn't strictly required - haven't bothered checking yet if a single View can handle the same workflow - another day, another set of unit tests... If it has some unknown performance impact perhaps. >i was thinking: then why we need Actions, Controllers and Views the way >are now on ZF if we need to basically ignore them.. Just to clarify - I do not advocate that Controllers/Actions are unnecessary. My tack of implementing Composite View (common J2EE pattern) was to avoid unnecessary controller usage, usually where a Controller is being used as a proxy (nothing else) to read data from a Model. In fact that's pretty close to the definition of a View Helper - so boiling it down to a single class (not a whole layer) makes sense - well to this mad Irishman at least :). This is going to be a matter of opinion obviously - both approaches have the same net result. I just prefer (the opinion bit!) the simplicity of View Helpers and building a Composite View structure. Personally, I don't see the point of Controller usage if all the View needs is a Model. J2EE and, as Matthew noted on my blog, POEAA both say as much taking V->M interaction for granted - POEAA just doesn't identify this as a formal pattern alongside Template View/Transform View. And actually I quite like the ZF's level of design. The clear benefit of a loosely coupled framework is that I can do this level of tinkering with a handful of subclasses. It would merely be convenient for it to be built in for those not wishing to tinker so much. I can do even more complex stuff (which is way off the beaten track) the same way with a little tinkering. Some other frameworks would require a lot more trouble on my part. I don't believe I'd found any real need so far to rip apart a core class. Pádraic Pádraic Brady http://blog.astrumfutura.com http://www.patternsforphp.com ----- Original Message ---- From: Andries Seutens <[EMAIL PROTECTED]> To: [email protected] Sent: Tuesday, May 1, 2007 11:20:30 AM Subject: Re: [fw-general] Implementing complex Views with ZF Hey, Although we aren't using the ZF at work yet, we have similar needs with our "home made" framework. Our framework is based on Smarty, so we have developed a custom plugin, which allows us to dispatch a controller/action from within a template. Eg in the foo/bar.phtml template we could have something like: {dispatch controller=customers action=lookup username=andries template=customer/lookup.phtml} this would dispatch the Customers controller with the lookup action, and pass a parameter "username" to it. After the controller action has been dispatched the output will be fetched into the template customer/lookup.phtml. This works pretty nice, at least for our needs :). I'm not a big fan of using _forward too much, as I have experienced that this approach makes it very hard to track what's actually happening in the code (this is certainly the case when you haven't written the code yourself). Best, Andries Seutens http://andries.systray.be Matthew Weier O'Phinney schreef: > -- Cristian Bichis <[EMAIL PROTECTED]> wrote > (on Monday, 30 April 2007, 08:24 PM +0200): >>> The big question is this: how many OTHER people need what you say you >>> need or is what you are trying to do a big edge case? I'm a firm >>> believer that in 99.999% of all cases a problem fitting an application >>> to a framework is due to the architecture of the application, not the >>> framework. This is the point where egos get bruised because people >>> want to blame tools, not themselves. >> I am not complaining, but after rewriting lot of stuffs i feel ZF is >> very usefull on some sides and not very usefull on other sides :) >> >> I mean if for some standard cases (as you saw Padraic Brady posts on >> http://blog.astrumfutura.com/archives/281-Complex-Web-Pages-with-the-Zend-Framework.html), >> >> nothing fancy, are needed lot workarounds... > > I've been following Padraic's blog (heck, I've been commenting and > pointing out functionality of ZF to him), and what I see him doing is > something that only a fraction of sites are going to need to do. Not > every site needs to have composite views; his does, and he's trying to > figure out how to do so with ZF. If there's enough demand for the > functionality he describes and the solution he creates, we'll evealuate > if it's something ZF should support natively. > > I completely agree with Chris H.: most of the "issues" about supposed > bad architecture I've seen debated, both on the ZF lists as well as > those of other projects, are due to users trying to do something for > which the framework was not designed, or being unwilling to change their > application to work within the bounds of the framework. It very well may > be the case that Christian's approach does not fit with ZF; if so, that > doesn't necessarily mean ZF isn't useful for "complex" projects -- just > not for his project. > > I'm doing plenty of complex stuff with ZF lately; any time I get stuck > and think I need to turn to other tools or code something myself, I stop > and think if there might be another approach I can take that would let > me use existing components. Usually the answer is yes. > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
