Lukas Renggli wrote:
>>> In the Pier-Jetsam-Environment package, I have moved the
>>> settings" group of definitions out of PRStructure, since the
>>> itself doesn't need to know anything about how it is to be
>> Why not? I have websites where every top level structure has its own
> 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.
Yes I understood entirely.
The same scheme is preserved with my approach, if you use the
PRPierFrameStandardBP then it specifies the policy that structures have
#localEnvironment and #localStyleSheet properties, and it alone controls
how they are used.
However if you display with, PRPierFrameAdmin then the fixed (non BP)
layout is defined in the class, no pages in the kernel are used in the
display, so #localEnvironment doesn't mean anything, however
#headerColor is used in order to offer an example of a themeable
If you display with PRPierFrameCWS then the layout is defined as one
standard layout. But with 7 css controlled display choices, again
#localEnvironment is not needed.
If you display with PRPierFrameSwitching then the layout is defined at
any level, by a choice of any one of the above. This allows me to
specify my "Admin" pages to be displayed with the Admin frame, but my
main site pages to be displayed with the standard frame.
> So in my model, structures have their properties, which the
> frame may make use of. However Structures have no knowledge of their
> as to how they are to be used. Its the same "children" shouldnt know
> much about their "parents" use-cases issue.
I don't see the relation.
PRStructure is a model class. Yet it defines view related behavior.
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
Exactly, so I am just saying that the "Seaside View" could define
property descriptions. Change the seaside view and the property
descriptions may also change.
The OmniBrowser view has a different engine to display structure.
>>> I am now attempting and failing to put a link to the
>>> 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
I already do this when I am in control of the layout, but I want to
simplify so that the user can specify the bare layout that they want,
without knowing about complex things such as privileges. I dont really
need security loaded for some of my future sites.
for the config application, that is sometimes handy to have.