Cool Idea!

Dear Lukas,

I think I am getting there...

One thing Pier has been lacking is a simple means of packaging up a 
configuration of Pier as a simple module.

Important methods for setting things up, such as #defaultEnvironment are 
on PRStructure of all places! Styles are here, layouts are there, and 
content is yet somewhere else (PRKernel class defaultRoot).

I have tried out a solution! Route everything through the PRPierFrame, 
then you can pick a PRFrame subclass in seaside/config, or embed it in 
another Seaside application.

1. Style Libraries (currently manually added in seaside/config)
2. Script Libraries (currently manually added in seaside/config)
3. Policy for finding Layout from the structure. (currently in PRStructure)
4. Policy for finding StyleSheets (currently in PRStructure)
5. Default Environment (currently in PRStructure)
6. Default Layout (currently in PRStructure)
7. Default Kernel Content (currently in PRKernel class)
8. Not Found Handler (currently in PRMain)
9. Forbidden Handler (currently in PRMain)
10. XHTML Doctype/Strict etc. (already in PRFrame)
11. Ability to override the body cssClass (currently obtained from the 
structure)
12. Option to adapt the #settingsDescription for components being 
editted. (can add/remove fields)

I have been able to provide my own preferred policies for all of the 
above, and now I feel able to deliver a "Pier for Something" module.

regards

Keith

p.s. some code is in Pier-Jetsam-Environment

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki