On 8/7/06, ByteDoc wrote: >I see the view on a lower level than the layout. The view as > such uses helpers/elements to create its content, but I don't like the > idea of letting the view set something above/outside of it. > > I'd rather create some logic to set layout parameters from the > view-calling controller instead of making the layout view-dependent, > which it would be if it accepted data set by a view.
I would like to politely ask anyone to reconsider this opinion. To think of the view as architecturally "smaller" or beneath the layout is an obvious and easy model to build in one's head - for the simple reason of its physical size when drawn on screen. However, just because it is physically smaller, does that mean that it is architectually so? Contrary to first appearances, I think that this is actually a complex question. Two of the primary goals of frameworks and methodologies like those imposed by cakephp are - DRY (don't repeat yourself) - MVC - separation of data-handling, business logic and page design Sometimes a design decision that a certain page makes, will affect more than the "rectangle" that the view is currently allowed to control. We break our MVC separation by forcing the designer to come and see the php-engineer just because he wants to change the background color without repeating himself. Alternativley we break DRY by making him repeat his layout with one bg-color change. Why do we mandate that the engineer really shouldn't repeat himself, but force the poor html guy to do things many times ?? I'd love to write more, but have to concentrate on my day job at the moment... --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~----------~----~----~----~------~----~------~--~---
