2010/7/26 Gaetano Giunta <[email protected]> > André Rømcke <[email protected]> wrote on 26/07/2010 10:51: > > > Remember that sections only works on content, earlier ezp used session to >> remember it, but that caused issues if you had several tabs open to same >> install. >> So as of 4.4 it will not persist in session anymore, meaning non content >> related pages will not have override condition for sections. >> >> > Interesting. > > How could then this requirement be satisfied in future versions? > > 1. using separate siteaccesses - this would surely work, and is imho the > cleanest solution, but it has some implications on the urls used to access > the site and also on the development time (more time spent setting up > configurations) > > 2. adding a /(section)/green parameter to all links that point from content > pages to non-content-related ones, then using that view parameter in the > pagelayout to switch color. > Pros: it whould work > Cons: an awful lot of templates to be patched. Wiew parameters are > available in pagelayout but not in view templates, so the value must be > passed down the chain by hand if the design has to be switched within the > view template too... > > 3. variation on the above idea, but using a cookie instead, maybe via > javascript (ie. set a 'section' cookie even when there's no session) > Pros: easier to deploy than the fix-all-urls solution; does not make your > urls ugly > Cons: does not work well with bookmarks; does not work well with tabs > > 4. adding some logic in the pagelayout that, when not showing a node, > checks the referral url to see what section the user is coming from (eg. via > a custom template op. in the pagelayout) > Pros: you only need to alter the pagelayout template > Cons: can slow down the site quite a bit; does not work well with bookmarks > > Ideas and comments are welcome. > > If a robust solution was found for setting multiple per-tab-values for a > cookie, I think solution 3 could in fact be good enough to be incorporated > into eZ... >
Not sure what your referring to here, but my guess is admin2 use of cookies. That is purely client side, and we wouldn't want to have a set-cookie statement on every request from server side as it would cause issues for reverse proxies(not important for admin, but for front end). The simplest solution seems to be siteaccess, put common settings in a extension (using ActiveAccessExtension) and use designs to serve different menu css / template. > > bye > Gaetano > > On Thu, Jul 15, 2010 at 2:34 PM, Carlos Revillo < >> [email protected] <mailto:[email protected]>> wrote: >> >> i would add two sections and will add override conditions for each >> one... >> >> 2010/7/15 Kévin Surrault <[email protected] <mailto: >> [email protected]>> >> >> >> Hello ! >> >> I am integrating a site which has two main parts. There are red >> pages >> and green pages that have only a few differences (background color >> and >> menus). There is a page that belongs to the two parts of the site, >> so >> it must have a red design and a green design, depending on the link >> that call it. >> >> My problem is : in the pagelayout template, how should I proceed to >> automatically set the appropriate design (red or green) to the page >> ? >> >> I've thought of fetching the node parent so I can know which part >> of >> the site is currently viewed, and then setting menus and divs like >> this (as in ezwebin templates) : >> >> {if eq($site_design, 'red')} >> {include uri='design:page_redmenu.tpl'} >> <div id='red'> >> {else} >> {include uri='design:page_greenmenu.tpl'} >> <div id='green'> >> {/if} >> >> ... </div> >> >> Is that a proper solution ? Do you have any better way to know the >> current part of the site, and to display the page in consequence ? >> >> Thank you ! >> >> ___ >> Kévin >> -- >> Sdk-public mailing list >> [email protected] <mailto:[email protected]> >> >> http://lists.ez.no/mailman/listinfo/sdk-public >> >> >> >> -- >> Sdk-public mailing list >> [email protected] <mailto:[email protected]> >> >> http://lists.ez.no/mailman/listinfo/sdk-public >> >> >> >
-- Sdk-public mailing list [email protected] http://lists.ez.no/mailman/listinfo/sdk-public
