Re: views controlling layouts
I also found a need for the view to set variables that can be used by the layout. I think even things like setting the page title, or including special CSS for that page should be done in that specific page view and not the layout or the controller. The method I used was this: // mypage.thtml variable = 'Something';?> // layout.thtml variable?> It's not the most elegant solution, but seems to work fine. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
Re: views controlling layouts
Thx for these answers. I have to admit I was caught too much in my day job application (developed in ABAP), where I use different level views that make up the complete _view_. And on the other side I tried to not give in too early, to feed a lively discussion and get detailed opinions from others - to help keep myself flexible by rethinking the "models built in my head" (Mark), whether they are wrong or right (or somewhere in between). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
Re: views controlling layouts
whoops, looks like we repeated each other, How Ironic. :-) Sorry for repeating yourself, Nate; i was composing my as yours came in. Mark On 8/7/06, Mark Quinn wrote: > 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 cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
Re: views controlling layouts
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 cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
Re: views controlling layouts
@ByteDoc: Mark is correct. The chief concern of MVC is separating view and controller logic, and secondarily, separating controller and model logic. This says nothing of preventing templates and layouts (view and view) from sharing data. In fact, I would argue that embedding view data in the controller violates DRY and tier separation almost as much as does putting business logic in the view. @Mark: We'll be adding a set() method in the View class to allow this. If you check out http://api.cakephp.org/class_view.html#9b395079675c6a66ff23ea9c6c4a668e you can see that there are a few properties of the View class which are available in templates, elements, and layouts (i.e. $pageTitle [when rendering templates, elements or layouts, View is available as $this). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
Re: views controlling layouts
Mark Quinn wrote: > To me, this is where your argument breaks down. A view is only part of > the picture. > > A view *and a layout* *and perhaps some elements* is the _view_ > > To say a view cannot set data is shortsighted. Perhaps a better way to > think of this is to think of "passing" data instead of setting data. Agreed, a "view" is more than a _view_ :) But in the concept meaning of view it does not set any data. Of course it uses/passes the data on to create itself so to say. But combining that with layouts (which I kinda lost focus on when writing the first reply) I would like to go back to the "only viewing view", emphasizing the hierarchical relation of layout and view. And in that sense 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. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
Re: views controlling layouts
On 8/7/06, ByteDoc <[EMAIL PROTECTED]> wrote: > > The line that has to be drawn here is not easy to see, I hope I can > make my opinion clear without using too much words (long explanations > are more confusing than helpful). > > A view should not be able to set any kind of data whatsoever - because > it is a _view_. To me, this is where your argument breaks down. A view is only part of the picture. A view *and a layout* *and perhaps some elements* is the _view_ To say a view cannot set data is shortsighted. Perhaps a better way to think of this is to think of "passing" data instead of setting data. A view passes data into its helpers which in turn generate html on behalf of the view. A view passes data into its elements for the same reason. Why should a view not be able to pass data to its layout, which in turn generates html on behalf of the view. - it strikes me as odd that people would want to seperate this case. I wholely agree that views should not be allowed to set any data other than in these circumstances. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
Re: views controlling layouts
The line that has to be drawn here is not easy to see, I hope I can make my opinion clear without using too much words (long explanations are more confusing than helpful). A view should not be able to set any kind of data whatsoever - because it is a _view_. I would tackle your described problem in a way that the controller has to make sure that the called view gets access to all the required data. The controller knows/determines which view to use, as such it also has to ensure the availability of the required data. If you have two layouts, with just one element replaced, than why do you have to pass two different sets of data to the view? Controller serves all the data (or access to it), view uses the data as required. To conclude - of course the view should dictate what element it needs - it already does by using it. But for expanding that do not look from the view side and what the view can set - look at how the data source can grow to satisfy different views. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
views controlling layouts
On 8/3/06, lorenzo wrote:
>
> Mark Quinn ha scritto:
>
> My current problem is how to get a view to set a variable that is
> available in the layout. From everything i've read. this should be
> easy, but i'm just not getting any loving.
>
> I baked a trivial example:
>
> my layout contains
> my favourite cheese is
>
> > my view contains
> > > $this->controller->set( 'cheese', 'cheddar' );
> > $cheese = 'brie';
> > ?>
> put this in your controller:
> $this->set('cheese','padano');
>
I understand that variables are _usually_ set in the controller. As an
experienced RoR developer, I am used to being able to have a VIEW set
a variable that is used by the LAYOUT. This makes complete sense to
seperate code logic and presentation. A trivial example is that the
controller programmer doesn't care what the title of a page is - that
is the call of the page designer/html person (yes, localisation etc,
may change this - but this is just a simple example).
A better example may be when the designer/html person wants the layout
to include a different element for certain pages/views. Why have two
layouts, solely in order to replace one element with a different one?
Wouldn't it be nice if the view could dictate which element it needed?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Cake
PHP" group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/cake-php
-~--~~~~--~~--~--~---
