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.

> 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.

Sure, you can render a link to a specific Pier page from any Seaside component. Assuming that "self context" is the current context you can write: html anchor goto: (self context command: PRSettingsCommand); with: 'Settings'

>>> 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 environment is just a pointer from one structure to another one. That's it. It is only the Seaside view that knows how to interpret this.

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

for the config application, that is sometimes handy to have. Lukas