Cool Idea!

Hello Lukas,

The hierarchy of choices available as swappable replacements for
PRPierFrame, is starting to mature.

The first, PRPierFrameCentral, implements the wiring in order for it to
be the centre of attention as I suggested yesterday. It aims to preserve
the existing behaviour, however it has a nice innovation:

If your site has no environment at all, it caches one for you. i.e. your
layout can be provided as part of your PRPierFrame subclass, and does
not need to be user visible or editable. If you edit the code that
generates your layout directly, it will get used for the next session.

And that's not all. If you add an empty page, and set that as an
environment in a structure's settings, it will automatically populate.

==
The second class PRPierBasicBP moves the layout to:

/environment/layout
/environment/style

Again it will be cached for you "off-site" until an environment is added.

==
A third class PRPierBasicCWS is a first attempt at an alternative to
blueprint.
==
A fourth class is PRPierAdmin provides a non edittable environment for
admin purposes.

cheers

Keith


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

> The hierarchy of choices available as swappable replacements for
> PRPierFrame, is starting to mature.

I don't really know if changing PRPierFrame is the right way to go?  
After all this is a rather low-level Seaside component. Maybe it would  
be better to have some property in the kernel?

> The second class PRPierBasicBP moves the layout to:
>
> /environment/layout
> /environment/style
>
> Again it will be cached for you "off-site" until an environment is  
> added.

I guess I'll have to look at the source code. I don't understand how  
different are supposed to work then? For example seaside.st uses 4  
different environments, my personal site uses 2.

Cheers,
Lukas

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


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

  No different... perhaps I should have written:

The path that a page uses to find its layout is:

*<one of my parent's local environment>*/environment/layout
*<one of my parent's local environment>*/environment/style

So I can have

/site/environment-1/layout
/site/environment-1/style

/site/environment-2/layout
/site/environment-3/style
/site/environment-4/layout

If my content looks like..

/home/intro/mine/cv

If /home/intro's local environment is set to environment-1, it and all
of its children get the layout and style from environment-1.

But /home has no environment so it will use the one cached and supplied
by the PRFrameSubclass component.

If cv is set to environment-3 , it will use the style from
environment-3, and the layout from environment-1
...

Adding this configuration as a PRKernel setting, isnt quite the right
place. PRKernel is part of the Model, and should not include any seaside
elements to do with rendering of the model. You could argue that the
environment is part of the "data", but it isnt really, its "the
configuration of the rendering". If seaside was not loaded then you
wouldnt need it.

I think PRPierFrame is the right place:

Scenario: I have written a Seaside application and I want to write some
user documentation. I put a link in my application to "Help", Help calls
a component which renders the pier documents in response to
#openOnTopic: , with a nice "Return" button at the bottom. That
component would be a variant of PRPierFrame, called
PRPierFrameReadOnlyReference.

For authoring the help documents I can use a full normal installation of
pier, but in place in another application, it would be nice to be able
to have the whole of pier as a component.

best regards

Keith

 


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