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
Locked
