Andreas Hartmann wrote:
> Jörn Nettingsmeier wrote:
>> perhaps the root document should have different characteristics per
>> area: in authoring, it should display some informational text similar
>> to publication.xml,
>
> We could even merge it with the publication.xml (introduction.html) page.
i had thought about that, but then this page would have to be
<visit>able for <world>, and not only for users who have access to
authoring. might be hairy, or maybe not.
>> but in live, it should contain a redirect to the first node in the
>> sitetree. this could be easily done with some pipeline magic in cocoon.
>>
>> and my suggestion is not only to fix the "missing /index" problem. it
>> also ensures that *every* page has a parent, which cleans up the tree
>> semantics and makes the sitetree overview nicer to use when moving
>> pages around. right now, iiuc you *cannot* cut a document and paste it
>> as a first-level document. it will always become a child of your
>> current doc, because you can't click on "[+]authoring" , where you
>> want the page to be.
>
> That was possible in 1.2, but the implementation was not very clean
> because the page you're proposing was missing. Maybe we can really
> solve the problem by introducing this "root page".
>
> Do you think you could implement this, or give an estimation
> what needs to be done?
not realistically. i'm not into that part of the code too well, and i'd
rather solve some of the many other open issues i recently whined about.
it would be really neat to have it for 1.4.0 though. maybe solprovider
can estimate the size of the task, since iiuc he's been working on his
own sitetree implementation recently?
here's a plaintext documentation of what i think should happen:
1. introduce a new, immutable page at the root of the site tree ("root
page"). the id for this page is "/".
2. this implies that every sitetree.xml has to be wrapped in a <node
id="/"> element. this might also be implicit to avoid changes to
existing sitetrees, but i had rather we spell it out.
3. the root page gets an ac entry that allows "visit" for "world", and
nothing else. or alternatively, the root page does not get resolved to
something that lives in "content", but rather to some non-editable
asset, like under resources/. this can be done in the sitemap.xmap.
[
side issue: are admins currently all-powerful (like root on unix), or
can they just give themselves the rights to do anything (like admins on
windows)? the latter would be nicer, because then we don't have to use
nasty conditionals all over the place to keep admin users from deleting
this page. they could still give themselves sufficient rights to destroy
it, but that would be mindless vandalism...
]
4. the currently existing redirects from "/" to "/index" in the
sitemap.xmap can be removed.
5. for the live area, the "root page" must be a redirect to the first
node in the live sitetree. i.e. the cocoon pipeline must match "/" and
call a mechanism that can write http headers *and* parse the
sitetree.xml. is this possible with an xsp page?
6. test cutting and pasting of pages in the "site" tab of authoring,
look for code that used to handle the special case of "pages with no
parent", and get rid of it.
wdyt?
--
"Án nýrra verka, án nútimans, hættir fortíðin að vekja áhuga."
"Without new works, without the present the past will cease to be of
interest."
- Ásmundur Sveinsson (1893-1982)
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: [EMAIL PROTECTED], Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
