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 <renggli(a)iam.unibe.ch> wrote:
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.
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.
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.
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.
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?
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