21 Apr
2008
21 Apr
'08
8:43 p.m.
I am a bit stuck in a pre-Blueprint world. So I was having a look at it.
I loaded up the current, release of pier, and it is very clean and ready
to be styled. I miss the tree view, has it gone because it doesnt fit in
the layout?
Blueprint looks cool for some applications. I have one site which has a
fairly fixed layout, so blueprint appears to me to be an ideal solution
for that, but not, I fear for pier in general.
This appears to me to be a better fit, for general blogish/corporate sites.
http://www.contentwithstyle.co.uk/Articles/17/a-css-framework/
best regards
Keith
22 Apr
22 Apr
12:10 a.m.
Hello Lukas,
I am looking at the latest Pier,
There is a fair bit of stuff I am not understanding... but I am getting
there.
Could you explain how the PRDocumentsWidget is supposed to work.
I dont really like the settings for environment and css in every
page/structure. I think its untidy.
I would prefer that a page looks up the heirarchy for...
one_of_my_ancestors/environment/layout
one_of_my_ancestors/environment/css
and there are other settings that could be set this way... e.g.
the page that is shown to a user when he hits a forbidden page.
one_of_my_ancestors/environment/forbidden
thanks
Keith
4:16 a.m.
I would prefer that a page looks up the heirarchy for...
one_of_my_ancestors/environment/layout
one_of_my_ancestors/environment/css
I have implemented this scheme in
pieraddons/Pier-Jetsam-Environment
It was much easier to do with the current code, than when I last looked
at it a couple of years back.
I think that there are some advantages to doing it this way, so I hope
you will take a look.
One being that it is possible to put administrators instructions in the
"environment page". So having created a layout, there is a place to put
"design intent" information and to coach your users as to how to use the
design you have made. A notable feature of existing successful CMS is
that they have lots of docs to coach the users and admins through using
the system. Pier is somewhat bare in this regard.
Secondly this establishes a pattern, that "settings" is not the only
place to put setting/parameters. I can write a plugin which can have
heirarchically inherited settings, scoped to my part of the tree,
without having to put a new setting field into every page. The plugin
can look to an environment/settingsforplugin page.
Thirdly, environments can have environments, so that when you are
editing an environment layout and you mess it up, you can continue to
work, because you will not have broken the environments/environment.
(this was possible under the old scheme too and worked well)
btw great work
Keith
4:35 a.m.
But.... I have just hit a snag...
Having an environment for administrators to edit, with an environment
within it with higher level permissions that the admins arent supposed
to see, makes it really easy to accidentally set the permissions
recursively down the tree so that administrators can see everything.
I find it difficult to keep track of permissions in my sites so..
I solved this by having separate trees for each level of permissions,
and cross linking between them.
Having the #environment settings preference facilitates this approach...
so I think a compromise might be keep just the #environment setting.
Keith
9 a.m.
Having an environment for administrators to edit, with
an environment
within it with higher level permissions that the admins arent supposed
to see, makes it really easy to accidentally set the permissions
recursively down the tree so that administrators can see everything.
Yes, that's another reason why I put my environments at a different
place.
My layout always looks somehow like this:
root (owner: editor)
system (owner: admin)
user
groups
system
environment (owner: designer)
parts
components
templates
template1
template2
...
page1
page2
I usually don't put the CSS into Pier itself.
Of course Pier should be open to allow a different layout.
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
10:09 a.m.
Just to give a further example as to how this can be used...
PRFrameAdmin class comment explains:
====
This frame displays the site using the layout in /environment/admin,
rather than the default.
This allows a second seaside application to be set up which shows an
admin interface to the whole site.
This application can be configured to need authorization before viewing,
while the main site is public.
Thus, two (or potentially more) levels of security can be configured
without using Pier-Security.
===
Keith
1:07 p.m.
That's interesting. So you essentially have two entry points to your
site. For example
www.seaside.st
for the normal visitors and
admin.seaside.st
for an administrative interface to the same site?
Lukas
On Apr 22, 2008, at 10:09 , Keith Hodges wrote:
Just to give a further example as to how this can be
used...
PRFrameAdmin class comment explains:
====
This frame displays the site using the layout in /environment/admin,
rather than the default.
This allows a second seaside application to be set up which shows an
admin interface to the whole site.
This application can be configured to need authorization before
viewing,
while the main site is public.
Thus, two (or potentially more) levels of security can be configured
without using Pier-Security.
===
Keith
_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
--
Lukas Renggli
http://www.lukas-renggli.ch
4:27 p.m.
Lukas Renggli wrote:
That's interesting. So you essentially have two
entry points to your
site. For example
www.seaside.st
for the normal visitors and
admin.seaside.st
for an administrative interface to the same site?
Lukas
Exactly! A whole additional dimension. It was a eureka moment for me I
think this could be very useful.
Keith
8 Nov
8 Nov
7:40 p.m.
I know this is pretty old, but I have been thinking along these lines
myself, since I didn't really want to have a login button on the
normal site.
On Tue, Apr 22, 2008 at 3:27 PM, Keith Hodges <keith_hodges(a)yahoo.co.uk> wrote:
Lukas Renggli wrote:
That's interesting. So you essentially have
two entry points to your
site. For example
www.seaside.st
for the normal visitors and
admin.seaside.st
for an administrative interface to the same site?
Lukas
Exactly! A whole additional dimension. It was a eureka moment for me I
think this could be very useful.
Keith
_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
22 Apr
22 Apr
8:55 a.m.
Could you explain how the PRDocumentsWidget is
supposed to work.
This is for multiple editing areas, so for example you have a sidebar
with news or additional links. The PRDocumentsWidget is added to the
environment, where you can also set the default content. On the page
you can then edit the extra documents as part of the normal edit
operation.
I dont really like the settings for environment and
css in every
page/structure. I think its untidy.
It is not 100% necessarily, but it avoids a great deal of duplication.
Like this I can easily have all the design at a different place and
reuse it from everywhere.
I would prefer that a page looks up the heirarchy
for...
one_of_my_ancestors/environment/layout
one_of_my_ancestors/environment/css
You can still do this, if you want.
and there are other settings that could be set this
way... e.g.
the page that is shown to a user when he hits a forbidden page.
one_of_my_ancestors/environment/forbidden
If you use PUMain you get a longin window.
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
8:51 a.m.
I loaded up the current, release of pier, and it is
very clean and
ready
to be styled.
You can either build on top of blueprint (I know of many Pier pages
that have done exactly this) or remove it an use your own things
(there are quite a couple of pages here as well).
I miss the tree view, has it gone because it doesnt
fit in
the layout?
The tree is still there as a widget. So you can just add it. I removed
it from the default layout, as its usability is very limited and I
think it should be generally avoided. In my opinion the tree is only
good to manage and organize the site, therefor I often add it for
admins only.
Blueprint looks cool for some applications. I have one
site which
has a
fairly fixed layout, so blueprint appears to me to be an ideal
solution
for that, but not, I fear for pier in general.
This appears to me to be a better fit, for general blogish/corporate
sites.
http://www.contentwithstyle.co.uk/Articles/17/a-css-framework/
I don't see much difference, except that this CSS framework is a bit
at a different leven. It provides 6 different layouts and seems to me
a bit limited. However there is nothing that prevents you from using
it in Pier: remove blueprintcss, add contentwithstyle, done.
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
5964
days inactive
6165
days old
10 comments
3 participants
participants (3)
-
Jason Johnson -
Keith Hodges -
Lukas Renggli