Re: Pier Refactorings

Lukas Renggli wrote: I didn't like this at first, but I find it to be quite flexible. 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? 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. 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? 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