environmentStructure | environment layout stylesheet |
self flag:
#pierconfig. "structure then contents" environment := (PRPage
named: 'environment') addDecoration: PRHider new; addChild:
(layout := (PRPage named: 'layout') addChild: ((PRComponent
named: 'header') [...]
If you log-in (latest version, I suggest to always use this one) or
what do you mean? I have not seen any access to the environment
offered when I log in. It took me three days to even find that the
environment existed! Now I am actually using the latest version,
though it took me more than a week to learn how to load and run this.
I don't know if this functionality also works with ACL Security,
probably not. In the Unix Security you need to log-in as a super-user
and then the environment (that is hidden trough a hider-decoration)
magically appears. The code doing this is the following:
PRContext>>setUser: aUser
self propertyAt: #user put: aUser.
self enumerator hidden: (aUser notNil
and: [ aUser isSuperuser ])
The enumerator in the context is a default visitor that knows how to
traverse Pier. If you set #hidden: to true it also visits hidden
structures, else they are simply ignored. Menus are rendered using
this default enumerator.
if you
directly type the path to the environment (older versions)
you are able to simply edit those things from within your Web
browser. Lukas
I do understand that you are able to do this. Thats what I did in
order to reverse engineer the code to put into
environmentStructure. Although pier is very tightly and cleanly
architected, I think that am at a different stage in the process. I
feel that my contribution is part of the process of making things
more usable for the uninitiated. I have the benefit of not knowing
anything about pier and having to learn it all from scratch.
Even though you can't see the environment, everybody is able to see
the environment by directly typing the URL. Of course this can also
be prevented using one of the security frameworks. As an example and
to prove that this works, try to go to the environment of my homepage
by browsing to <http://www.lukas-renggli.ch/environment>.
So I am taking a look at the raw features that pier
has and putting
them into a context for the new users, specifically power users,
who need meta-tools. The old environment is simply a tool for
editing one thing, the layout. My implementation of environment has/
will become a development space for new layouts, styles and
everything else which I dont think really had a place before. You
are correct you can directly edit a sub-component by entering the
direct url. But I ask the question, how do you learn how to do this
if no one has told you, it has to be really obvious. I also think
that it is best to get things to a point where the out of the box
experience as easy to learn as possible, but we dont want to
clutter up the main user wiki content with this stuff, which is
what wiki's always used to do.
Yes, I completely agree. That's why I tried to make hidden structures
visible for super-users, I don't know why it didn't work in your
case. Maybe the default Pier setup should include a better
introduction and a how-to for the most common functionalities. Right
now a non-programmer is simply lost.
You may not see the need to mark the hard wired
things. But for me
they are a useful hook for learning things, particularly if you
want to tweak things, which is where learning things often starts
for me.
Sure, the problem is I don't like flags in the code ;-)
Some of things you labelled as hard wired are not hard wired, these
are just default values that can be changed trough the web-interface.
Something totally unrelated, just to write it down: it would be cool
to have sort of a tagging system in Smalltalk, so that one could
associate tags with classes, methods, instance variables, etc. Then
we could get rid of the categories and all the flags and one could
simply open a browser on all entities tagged as "hard wired", or on
all classes tagged as "document" and "visitor" displaying the
PRDocumentVisitor class ...
On reflection it looks like the direction this is
leading to is to
refactor all of the environment stuff, and some of the pierconfig
stuff out of PRStructure into a separate extension module. For want
of a better name "PREnvironment" and sons.
This would allow Environments (i.e. the out of the box style and
configuration) to be selected in the seaside configuration panel,
and offer a creative outlet for users to produce a range of pre-
configured environments. This becomes the natural starting point
for new 'power' users to begin creating bespoke environments, while
allowing the core of pier to remain lean and fit.
For #icon and #label this would be a good idea, else I don't really
see the point. The environment is instantiated once when you set up
the server, after that it doesn't need that code anymore. This is
just a template to get users started from.
To have the choice between different ready-made templates I created a
small command with less than 30 lines of code. See Pier-Environment-
lr.1 in the Pier repository. It has 3 slightly different templates
defined on the class-side, that can be applied from the web-interface
anywhere inside Pier. Does this help? Do you think that should go
into the core?
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch