26 May
2008
26 May
'08
2:01 p.m.
Hello All,
Pier-Jetsam-Environment moves all configuration and initialization of a
pier kernel to subclasses of PRPierFrame.
1. Just switch your seaside application's PRPierFrame component to
switch to a different style and layout (even switch to a different style
framework).
2. Set up a second entry point to your Pier instance with a different
style. e.g. http://admin.mypier.example
this allows a simple way to support admin users without needing
Pier-Security.
3. Embed your pier instance in another seaside app, with a specialised
style for that app as provided by the root frame component that you
choose to embed.
4. The standard scheme of user editable environments still works as
before except that new environments get auto initialized.
enjoy
Keith
p.s. feedback invited
===========
PRPierFrameStandardBP
==================
The same policies and layout as the current pier release, except that no
'environment' is initially needed. If you provide 'environment' with
empty contents it will be initialized automatically.
PRPierFrameNewBP
================
As above except that the layout is obtained/initialized in
$environment/layout
PRPierFrameCWS and subclasses
========================
As above except that the style framework is based upon "Content With
Style" css framework.
The framework uses a single layout definition, but provides a number of
common layouts via CSS variants.
The options are
"#layout1colCss
" #layoutnavtopsubrightCss
"#layoutnavtop3colCss
"" #layoutnavtop1colCss
"" #layoutnavleft1colCss
"" #layoutnavleft2colCss
"" #layoutnavtoplocalleftCss
"
see: http://www.contentwithstyle.co.uk/Articles/17/a-css-framework
PRPierFrameAdminBP - Themeable classic pier 1.0.0 ui
========================================
The old classic pier admin UI (including the tree navigation widget)
All colors in css are referenced to method selectors for easy theming.
(Subclass and override #colorMethods)
Updated to use "Nifty Corners" so that rounded corners show in Internet
Explorer.
Updated to use transparent png, so that the color of the banner and the
logo can be changed in a single method.
There is still a little bit of work to get the css working cross browser
feedback as always appreciated
Keith
26 May
26 May
5:12 p.m.
New subject: [Ann] Pier-Jetsam-Environment with Themeable classic Pier 1.0.0 ui
PRPierFrameAdminBP - Themeable classic pier 1.0.0 ui
========================================
The old classic pier admin UI (including the tree navigation widget)
I just abandoned the idea of using the Blueprint grid to layout the
classic ui.
The table based layout is much more fluid all round, and the arguments
used for css in favour of tables do not really apply to us with Pier.
The argument is usually something along the lines of the content markup
being too layout-specific. However in Pier, the semantic markup is not
HTML, but instead it is the object model.
Secondly it is trivial to write an alternative table layout to go with a
new css style sheet.
basically we can have the best of all worlds.
best regards
Keith
12 Jun
12 Jun
4:22 a.m.
In the Pier-Jetsam-Environment package, I have moved the "layout
settings" group of definitions out of PRStructure, since the structure
itself doesn't need to know anything about how it is to be displayed.
Instead the chosen parent frame can add its own "layout settings"
descriptions to structures. As an example of how this works, the "admin"
frame adds a "Theme Color" setting, other frames add settings according
to their own needs.
I am now attempting and failing to put a link to the PRSettingsCommand
in the seaside toolbar, is this possible?
cheers
Keith
Hello All,
Pier-Jetsam-Environment moves all configuration and initialization of a
pier kernel to subclasses of PRPierFrame.
1. Just switch your seaside application's PRPierFrame component to
switch to a different style and layout (even switch to a different style
framework).
2. Set up a second entry point to your Pier instance with a different
style. e.g. http://admin.mypier.example
this allows a simple way to support admin users without needing
Pier-Security.
3. Embed your pier instance in another seaside app, with a specialised
style for that app as provided by the root frame component that you
choose to embed.
4. The standard scheme of user editable environments still works as
before except that new environments get auto initialized.
enjoy
Keith
p.s. feedback invited
===========
PRPierFrameStandardBP
==================
The same policies and layout as the current pier release, except that no
'environment' is initially needed. If you provide 'environment' with
empty contents it will be initialized automatically.
PRPierFrameNewBP
================
As above except that the layout is obtained/initialized in
$environment/layout
PRPierFrameCWS and subclasses
========================
As above except that the style framework is based upon "Content With
Style" css framework.
The framework uses a single layout definition, but provides a number of
common layouts via CSS variants.
The options are
"#layout1colCss
" #layoutnavtopsubrightCss
"#layoutnavtop3colCss
"" #layoutnavtop1colCss
"" #layoutnavleft1colCss
"" #layoutnavleft2colCss
"" #layoutnavtoplocalleftCss
"
see: http://www.contentwithstyle.co.uk/Articles/17/a-css-framework
PRPierFrameAdminBP - Themeable classic pier 1.0.0 ui
========================================
The old classic pier admin UI (including the tree navigation widget)
All colors in css are referenced to method selectors for easy theming.
(Subclass and override #colorMethods)
Updated to use "Nifty Corners" so that rounded corners show in Internet
Explorer.
Updated to use transparent png, so that the color of the banner and the
logo can be changed in a single method.
There is still a little bit of work to get the css working cross browser
feedback as always appreciated
Keith
_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
11:08 a.m.
In the Pier-Jetsam-Environment package, I have moved
the "layout
settings" group of definitions out of PRStructure, since the structure
itself doesn't need to know anything about how it is to be displayed.
Why not? I have websites where every top level structure has its own
look.
I am now attempting and failing to put a link to the
PRSettingsCommand
in the seaside toolbar, is this possible?
Ouch, Seaside Toolbar? I usually keep that disabled.
Sure, you can render a link to a specific Pier page from any Seaside
component. Assuming that "self context" is the current context you can
write:
html anchor
goto: (self context command: PRSettingsCommand);
with: 'Settings'
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
3:44 p.m.
Lukas Renggli wrote:
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.
As an example the "AdminFrame" stores the current theme colour in the
structure's properties. Since the "AdminFrame" has a fixed layout
determined by the class, there is no need for structures to have an
#environment or #stylesheet setting wen displayed with the "AdminFrame"
The "ContentWithStyle" frame stores the current layout selection in the
structures properties, there are 7 choices.
1 col, 2 col, 3 col etc etc.
So in my model, structures have their properties, which the display
frame may make use of. However Structures have no knowledge of their own
as to how they are to be used. Its the same "children" shouldnt know too
much about their "parents" use-cases issue.
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 the
Pier-Jetsam-Environment package, I have moved the "layout
settings" group of definitions out of PRStructure, since the structure
itself doesn't need to know anything about how it is to be displayed.
Why not? I have websites where every top level structure has its own
look.
I am now
attempting and failing to put a link to the PRSettingsCommand
in the seaside toolbar, is this possible?
Ouch, Seaside Toolbar? I usually keep that disabled.
Sure, you can render a link to a specific Pier page
from any Seaside
component. Assuming that "self context" is the current context you can
write:
html anchor
goto: (self context command: PRSettingsCommand);
with: 'Settings'
Unfortunately the WAToolbar frame is outside of withContextDo: So I dont
think that this will work.
Keith
4:15 p.m.
In the Pier-Jetsam-Environment package, I have moved
the "layout
settings" group of definitions out of PRStructure, since the
structure
itself doesn't need to know anything about how it is to be
displayed.
Why not? I have websites where every top level structure has its own
look.
So in my model, structures have their properties,
which the display
frame may make use of. However Structures have no knowledge of their
own
as to how they are to be used. Its the same "children" shouldnt know
too
much about their "parents" use-cases issue.
I don't see the relation.
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
this. The OmniBrowser view has a different engine to display structure.
I am now attempting and failing to put a link to the
PRSettingsCommand
in the seaside toolbar, is this possible?
Ouch, Seaside Toolbar? I usually keep that disabled.
5:50 p.m.
Lukas Renggli wrote:
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
environment.
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.
PRStructure is a model class. Yet it defines view related behavior.
In the
Pier-Jetsam-Environment package, I have moved the "layout
settings" group of definitions out of PRStructure, since the
structure
itself doesn't need to know anything about how it is to be
displayed.
Why not? I have websites where every top level structure has its own
look.
So in my
model, structures have their properties, which the display
frame may make use of. However Structures have no knowledge of their
own
as to how they are to be used. Its the same "children" shouldnt know
too
much about their "parents" use-cases issue.
I don't see the relation.
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
this.
Exactly, so I am just saying that the "Seaside View" could define
these
property descriptions. Change the seaside view and the property
descriptions may also change.
The OmniBrowser view has a different engine to display
structure.
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.
I am now attempting and failing to put a link to the
PRSettingsCommand
in the seaside toolbar, is this possible?
Ouch, Seaside Toolbar? I usually keep that disabled.
for the config application, that is sometimes handy to
have.
Lukas
cheers
Keith
6045
days inactive
6062
days old
6 comments
2 participants
participants (2)
-
Keith Hodges -
Lukas Renggli