[Ann] Pier-Jetsam-Environment with Themeable classic Pier 1.0.0 ui

> Hello All,
>
> Pier-Jetsam-Environment moves all configuration and initialization of a
> pier kernel to subclasses of PRPierFrame.
>
> 1. Just switch your seaside application's PRPierFrame component to
> switch to a different style and layout (even switch to a different style
> framework).
>
> 2. Set up a second entry point to your Pier instance with a different
> style. e.g. http://admin.mypier.example
> this allows a simple way to support admin users without needing
> Pier-Security.
>
> 3. Embed your pier instance in another seaside app, with a specialised
> style for that app as provided by the root frame component that you
> choose to embed.
>
> 4. The standard scheme of user editable environments still works as
> before except that new environments get auto initialized.
>
> enjoy
>
> Keith
>
> p.s. feedback invited
>
> ===========
>
>
> PRPierFrameStandardBP
> ==================
> The same policies and layout as the current pier release, except that no
> 'environment' is initially needed. If you provide 'environment' with
> empty contents it will be initialized automatically.
>
> PRPierFrameNewBP
> ================
> As above except that the layout is obtained/initialized in
> $environment/layout
>
>
> PRPierFrameCWS and subclasses
> ========================
>
> As above except that the style framework is based upon "Content With
> Style" css framework.
> The framework uses a single layout definition, but provides a number of
> common layouts via CSS variants.
>
> The options are
>
>     "#layout1colCss
>     " #layoutnavtopsubrightCss
>     "#layoutnavtop3colCss
>     "" #layoutnavtop1colCss
>     "" #layoutnavleft1colCss
>     "" #layoutnavleft2colCss
>     "" #layoutnavtoplocalleftCss
>     "
> see: http://www.contentwithstyle.co.uk/Articles/17/a-css-framework
>
> PRPierFrameAdminBP - Themeable classic pier 1.0.0 ui
> ========================================
> The old classic pier admin UI (including the tree navigation widget)
>
> All colors in css are referenced to method selectors for easy theming.
> (Subclass and override #colorMethods)
> Updated to use "Nifty Corners" so that rounded corners show in Internet
> Explorer.
> Updated to use transparent png, so that the color of the banner and the
> logo can be changed in a single method.
>
> There is still a little bit of work to get the css working cross browser
>
> feedback as always appreciated
>
> Keith
>
>
> _______________________________________________
> SmallWiki, Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>
>  

>>> In the Pier-Jetsam-Environment package, I have moved the "layout
>>> settings" group of definitions out of PRStructure, since the  
>>> structure
>>> itself doesn't need to know anything about how it is to be  
>>> displayed.
>>>
>>
>> Why not? I have websites where every top level structure has its own
>> look.
>>
> Sure that's what I do too.
>
> But the structure itself has nothing to do with determining its  
> usage or
> look. It does keep hold of arbitrary properties, but those properties
> are specified by the "frame" that is going to be displaying the
> structure, not by the structure itself.

>>> I am now attempting and failing to put a link to the  
>>> PRSettingsCommand
>>> in the seaside toolbar,  is this possible?
>>>
>>
>> Ouch, Seaside Toolbar? I usually keep that disabled.
>>
> I agree it would be simpler if it was factored out... I have  
> factored it
> out into a decoration-helper. I am still hoping that you will see your
> way to support Session/Decoration helpers in 2.9. For me the Toolbar
> decoration becomes enabled via the ToolbarHelper when a suitably
> qualified user logs in.

>>>> In the Pier-Jetsam-Environment package, I have moved the "layout
>>>> settings" group of definitions out of PRStructure, since the  
>>>> structure
>>>> itself doesn't need to know anything about how it is to be  
>>>> displayed.
>>>>
>>>>        
>>> Why not? I have websites where every top level structure has its own
>>> look.
>>>
>>>      
>> Sure that's what I do too.
>>
>> But the structure itself has nothing to do with determining its  
>> usage or
>> look. It does keep hold of arbitrary properties, but those properties
>> are specified by the "frame" that is going to be displaying the
>> structure, not by the structure itself.
>>    
>
> Sorry, I didn't express myself clearly.
>
> What I ment is that the look (or environment) changes on different  
> structures. For example the Seaside web-site has a different look in  
> the root than on all other pages. Or my blog has a different look as  
> all the other pages.
>  

>> So in my model, structures have their properties, which the display
>> frame may make use of. However Structures have no knowledge of their  
>> own
>> as to how they are to be used. Its the same "children" shouldnt know  
>> too
>> much about their "parents" use-cases issue.
>>    
>
> I don't see the relation.
>  

> The OmniBrowser view has a different engine to display structure.
>
>  
>>>> I am now attempting and failing to put a link to the  
>>>> PRSettingsCommand
>>>> in the seaside toolbar,  is this possible?
>>>>
>>>>        
>>> Ouch, Seaside Toolbar? I usually keep that disabled.
>>>
>>>      
>> I agree it would be simpler if it was factored out... I have  
>> factored it
>> out into a decoration-helper. I am still hoping that you will see your
>> way to support Session/Decoration helpers in 2.9. For me the Toolbar
>> decoration becomes enabled via the ToolbarHelper when a suitably
>> qualified user logs in.
>>    
>
> In Seaside 2.9 the toolbar is a decoration on the root component. I  
> wonder why you don't just embed the components that make up the  
> toolbar as pages in Pier that have admin privileges. This is what I do  
>