Pier Refactorings

Hi,

the latest version of Pier includes a few experimental features. I  
would like to hear your opinion on these:

1. Environments

Before environments were a reference to a different page anywhere on  
your page. One idea was to replace this reference with a document  
(like the page has one). This allows then to edit the meta-page using  
the settings and have it close to the page it is applied to. As  
before, keeping it empty would inherit the environment from the  
parent. Do you think that improves the usability?

2. Custom Documents

Another idea was that an environment (that is independent of the  
proposal above) can add any number of document (formerly called  
content widget) widgets. These widgets could then be put for example  
into a side-bar or the heading to allow customization of these parts  
of the page as part of the edit process of a structure. Again these  
'extra' documents can have default documents and/or be inherited from  
parent structures. Do you think that would be useful?

Do you think 1 is still useful if we have 2?

I appreciate any thoughts on this. Of course I already made my own  
opinion (that you might read between the lines) ...

Cheers,
Lukas

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


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

It sounds interesting.  Is there a code example anywhere to help me
visualize some good use cases for this?  I understand what you're
saying about the side bar, but my pier site already had it in the old
design, so I'm interested to see how this improves it.

On 11/1/07, Lukas Renggli <[hidden email]> wrote:
_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

> It sounds interesting.  Is there a code example anywhere to help me
> visualize some good use cases for this?

Ahh, indeed I didn't commit point 2 yet, because it is not quite  
working yet :-/

> I understand what you're saying about the side bar, but my pier site  
> already had it in the old
> design, so I'm interested to see how this improves it.

How did you do it? The problem I am facing right now is that I want to  
change the side-bar independent of the currently used environment?  
Similar to the way I am changing the contents area.

Cheers,
Lukas

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


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

On 11/1/07, Lukas Renggli <[hidden email]> wrote:
>
> How did you do it? The problem I am facing right now is that I want to
> change the side-bar independent of the currently used environment?
> Similar to the way I am changing the contents area.

I haven't looked at it for a while, but I believe I just had it in the
main contents area like the default Pier.  I just switched out that
default side bar with a custom one that had specific navigations and a
login button.  If you log in as administrator you finally see the Pier
buttons (comment, environment etc.).  And CSS was used to move it
around.

I'll try to have a look when I get a chance.

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

Lukas Renggli wrote:
> Hi,
>
> the latest version of Pier includes a few experimental features. I  
> would like to hear your opinion on these:
>
> 1. Environments
>
> Before environments were a reference to a different page anywhere on  
> your page.
I didn't like this at first, but I find it to be quite flexible.
> One idea was to replace this reference with a document  
> (like the page has one). This allows then to edit the meta-page using  
> the settings and have it close to the page it is applied to. As  
> before, keeping it empty would inherit the environment from the  
> parent. Do you think that improves the usability?
>  
Currently the the process is not that explicit, any page can be the
environment. The designer of the site can/has to establish their own
conventions as to where the environments are stored in the hierarchy and
who has permissions to edit them.

It is easier in the sense that you are making the environment a special
document in a special place and so providing a special button with which
to edit it. This makes the process explicit and perhaps clearer.

However I prefer the flexibility to establish my own conventions, but I
need the space/a place in which to explain these conventions to my users.

So if I am forced to have the environment in the vicinity of the root
page, where is the space for me to put the explanation? I don't want to
put it on my home page. The existing model allows me to set up a "site
editing help and advice" area and have the environment local to the
instructions, without cluttering up the main site. The root page can
nominate the environment which itself resides in the context of the user
instructions which explain to how to use it.

This also makes it easier to manage permissions. If I want my site to be
globally editable, except for the environments, I can set my permissions
recursively from the root to give open access. But then each environment
becomes an exception to this rule and I have to go and fix the
permissions for each environment.

Putting the environments in a separate branch, means that changing the
permissions recursively for the main public site branch  does not effect
the environments which have admin-only privileges.

Another problem I foresee here is that I would want this
document-in-settings document to have contents. How would I manage the
contents of this document in a document-setting in terms of moving
copying and setting permissions of its component parts?
> 2. Custom Documents
>
> Another idea was that an environment (that is independent of the  
> proposal above) can add any number of document (formerly called  
> content widget) widgets. These widgets could then be put for example
>  
To me the environment represents the "management interface" for a
portion of the site. I do not think that the environment should be
limited to the layout. I got around this restriction using the scheme
above and having the "site editing and advice" area where I can put my
management interfaces, the environment layout being only one part of the
administration.

My site is a shop so the administration includes user account
management, product data management, product grouping definitions and
shop pages generation and front page generation, amongst other things.

If your site is only a website or a wiki then there may not be much else
to manage. However if you want to build a complex site whose main focus
is not changing the look, then you need somewhere to put all of your
management interfaces. For me the environment is "a" the logical place
to put it, together with contextual instructions as to how to use all of
these things.

This is a significant limitation of the current model, the page
"environment" exists but when you go in there there is no contextual
help to tell you what it is you are looking at and what you can do in there.

So... a long time ago I implemented environment as a hierarchy in which
you could put contextual "here is how you use this " documentation. The
layout itself is in /environment/layout. This allows you to pick a
layout by making its contents +layoutA+ or +layoutB+  . The same
approach worked for picking css options.

environment
    layout
       layoutA
       layoutB
    scripts
    css
       cssA
       cssB
    color-schemes

The current scheme allows me to do this because I just point my root
page's environment to /environment/layout.

If I was doing a side bar I would add environment/side-bar to this list
and the layout includes +../sidebar+

I already do this so I am really not sure what the extra functionality
you are providing. Do you want a sidebar with an edit button in it?

If you want the sidebar to contain user editable content, then you could
introduce the idea of a component who finds its content via a search
strategy... e.g.

PRContents-findPage: aPagePath

^ (self context structure / aPagePath) ifNil: [ context structure parent
findPage: aPagePath ]

This would enable your side-bar documents to be managed in the existing
tree.
> into a side-bar or the heading to allow customization of these parts  
> of the page as part of the edit process of a structure. Again these  
> 'extra' documents can have default documents and/or be inherited from  
> parent structures. Do you think that would be useful?
>
>  
So you put extra contents widgets in the layout.... where is the content
obtained from/stored in your model?

Is the existing model preserved or do we have an extra document(s)
attribute in a PRPage, and each contents widget edits a different one?
> Do you think 1 is still useful if we have 2?
>
> I appreciate any thoughts on this. Of course I already made my own  
> opinion (that you might read between the lines) ...
>
> Cheers,
> Lukas
I am sure that you know what you are doing, I am not convinced that I am
fully understanding your intentions in order to make a valued judgement

best regards

Keith

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

Indeed, I use the same approach. Maybe it would help, if we had such a  
setup by default, with some explanatory text. Like this we would get a  
decent default configuration, but you would be still free to  
reorganize it however you like.

One problem I see with having the environment in the structure itself  
(as opposed to having it on a separate page) is that it is virtually  
impossible to use relative links. And you need those links because you  
don't want your components in the same hierarchy as the page.

> If I was doing a side bar I would add environment/side-bar to this  
> list
> and the layout includes +../sidebar+

The problem I face is that I need a different side-bar text for every  
page. And having a new layout for every page is not what I want.

> I already do this so I am really not sure what the extra functionality
> you are providing. Do you want a sidebar with an edit button in it?

The thing with the Sidebar is just an example. When I edit a page I  
would not only like to be able to edit the document in the contents  
(as it is now) but also in some other areas, that are not necessarily  
connected to the main contents, e.g. the side-bar, some small printed  
text, some additional links in a box somewhere, etc.

Well that was my idea (sort of). However I want it to be editable as  
part of the normal editing process. And keep the contents close to its  
page, as they closely belong together.

The existing model with the default document is preserved, this is  
also where the Magritte editor (login, permissions, etc) are managed.  
Additionally we would get other parts that can be edited the same way.  
All structures would get an extra document for every PRDocumentWidget  
defined in its environment. These documents (depending on the  
settings) can then be inherited (if left blank) from the parent or  
include a default text.

> I am sure that you know what you are doing, I am not convinced that  
> I am
> fully understanding your intentions in order to make a valued  
> judgement

Thank you for sharing your thoughts. I hope I could make it clearer now.

Regards,
Lukas

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


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

I just loaded and tried the PRDocumentWidget in my own Pier image.

At first I had tried to add "relative links" (like +./sidebar+) in the
environment, hoping they would be relative to the current structure,
not the environment:

foo
  sidebar  (displayed besides foo)
bar
  sidebar  (displayed besides bar)
environment (contains +./sidebar+)

Indeed this didn't work and the PRDocumentWidget is more practical :)

There is an annoying behavior though: when I edit the document
widget's contents, it's only saved if I click in another textarea (the
one for the structure's contents) before hitting ctrl-s or clicking
the Save button. (this is in Safari, in Firefox it works as expected)


On 02/11/2007, Lukas Renggli <[hidden email]> wrote:

--
Damien Pollet
type less, do more [ | ] http://typo.cdlm.fasmz.org

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

> There is an annoying behavior though: when I edit the document
> widget's contents, it's only saved if I click in another textarea (the
> one for the structure's contents) before hitting ctrl-s or clicking
> the Save button. (this is in Safari, in Firefox it works as expected)

Yes, the issue is a nasty bug in Safari. I only observed it when  
hitting Ctrl-S, not when hitting the save button, though. I don't have  
a solution ready for that bug right now.

Cheers,
Lukas

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


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