Cool Idea!

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Cool Idea!

keith1y
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
Reply | Threaded
Open this post in threaded view
|

Re: Cool Idea!

Lukas Renggli-2
> 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 agree, this is not ideal.

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

Sounds interesting.

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

I will have a look, thanks.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch


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