[Framework-Team] Re: Body class
Hi, 2010/1/17 Hanno Schlichting ha...@hannosch.eu: On Sun, Jan 17, 2010 at 4:24 PM, Martin Aspeli optil...@gmail.com wrote: Any chance we could put this in a separate view utility instead of the @@plone one, so that it's more sane to override? Yeah. With bodyClass already being on that view, it felt ok-ish. But I guess there's a couple of visual policy methods in there which should go into their own view somewhere in plone.app.layout. +1 Just looking at the methods, I'd move the following to a new view (leaving BBB support in the old place): mark_view have_portlets hide_columns renderBase bodyClass These all feel like things that influence CSS classes or UI policy in some way. I think mark_view should probably stay, or at least be separate. It's both fundamental to other functionality and easy to screw up. +1 for the others, though. Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Body class
On Sun, Jan 17, 2010 at 9:19 PM, Wichert Akkerman wich...@wiggy.net wrote: On 2010-1-17 16:52, Hanno Schlichting wrote: mark_view have_portlets hide_columns renderBase bodyClass is_view_template or whatever it is that manages IViewView. We've found it to be very painful to manage IViewView now. In particular it appears to be impossible to set when you render a template from a browser view. mark_view actually sets the IViewView interface. The main_template does: view nocall:view | nocall: plone_view; dummy python: plone_view.mark_view(view); which you should be able to do in any template that doesn't use main_template. Otherwise it should work just fine to add implements(IViewView) to your browser view class. But maybe I'm missing what exactly you want to do. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Body class
On 2010-1-17 21:36, Hanno Schlichting wrote: On Sun, Jan 17, 2010 at 9:19 PM, Wichert Akkermanwich...@wiggy.net wrote: On 2010-1-17 16:52, Hanno Schlichting wrote: mark_view have_portlets hide_columns renderBase bodyClass is_view_template or whatever it is that manages IViewView. We've found it to be very painful to manage IViewView now. In particular it appears to be impossible to set when you render a template from a browser view. mark_view actually sets the IViewView interface. The main_template does: view nocall:view | nocall: plone_view; dummy python: plone_view.mark_view(view); which you should be able to do in any template that doesn't use main_template. Otherwise it should work just fine to add implements(IViewView) to your browser view class. But maybe I'm missing what exactly you want to do. This: class MyView(BrowserView): def __call__(self): return aq_inner(self.context).some_template() and make sure that IViewView is set when some_template is rendered. Currently that is impossible since mark_view does checks that are impossible to influence from the outside, and there is nothing MyView could set IViewView on itself. Wichert. -- Wichert Akkerman wich...@wiggy.net It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Body class
On Sun, Jan 17, 2010 at 9:38 PM, Wichert Akkerman wich...@wiggy.net wrote: class MyView(BrowserView): def __call__(self): return aq_inner(self.context).some_template() and make sure that IViewView is set when some_template is rendered. Currently that is impossible since mark_view does checks that are impossible to influence from the outside, and there is nothing MyView could set IViewView on itself. Right. I have to admit that I don't fully understand IViewView. It currently suggests that for any published url, there's one view representing this url and it can be marked as the view of an object. But our pages are composed of many views, with skins there aren't any underlying views, though we somehow try to treat the ploneview as a surrogate. Once you turn main_template into a browser page it becomes even less clear what the view object is. And as you noticed it's impossible to get to that one mysterious view from somewhere in the layout stack. The only things you can access from all places are context and request. I think we might want to add a marker to the request instead or in addition to the current approach, similar to how disable editable border and hide columns work. I had a similar use-case recently, where I needed to make some of the content menus conditional on whether or not you are on the folder contents page. In the end I had to go down to something like alsoProvides(request, IContentsPage) and check that in code in the menus. The view just isn't accessible anywhere outside the one template it is driving. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
