You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Andreas Hartmann <an...@apache.org> on 2006/06/07 17:36:37 UTC

Request for comments: Redirect after document is deleted

Hi Lenya devs,

please comment on this bug if you're interested in this issue.
We should either fix or close it.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39077

-- Andreas

-- 
Andreas Hartmann
Wyona Inc.  -   Open Source Content Management   -   Apache Lenya
http://www.wyona.com                      http://lenya.apache.org
andreas.hartmann@wyona.com                     andreas@apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org


Re: should we introduce an immutable "root" document ?

Posted by Joern Nettingsmeier <po...@uni-due.de>.
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: pol-admin@uni-due.de, Telefon: 0203/379-2736


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org


Re: should we introduce an immutable "root" document ? [was: Re: Request for comments: Redirect after document is deleted]

Posted by Andreas Hartmann <an...@apache.org>.
Jörn Nettingsmeier wrote:

[...]

> root document in this case means "the page that is displayed by default 
> in the live area". note that i'm talking about this mystical immutable 
> root page only for authoring.

That sounds very useful and would probably answer quite a lot of questions.


> there is no conceivable reason to ever 
> want to delete the that, because it has no meaning in live.
> 
> 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.


> 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?

Should this issue be addressed before 1.4 is released?

-- Andreas


-- 
Andreas Hartmann
Wyona Inc.  -   Open Source Content Management   -   Apache Lenya
http://www.wyona.com                      http://lenya.apache.org
andreas.hartmann@wyona.com                     andreas@apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org


Re: should we introduce an immutable "root" document ? [was: Re: Request for comments: Redirect after document is deleted]

Posted by Jörn Nettingsmeier <po...@uni-duisburg.de>.
Bob Harner wrote:
> On 6/7/06, Joern Nettingsmeier <po...@uni-due.de> wrote:
>> Andreas Hartmann wrote:
>> > Hi Lenya devs,
>> >
>> > please comment on this bug if you're interested in this issue.
>> > We should either fix or close it.
>> >
>> > http://issues.apache.org/bugzilla/show_bug.cgi?id=39077
>>
>> i would very much like to see bob's suggestion implemented, i.e. to jump
>> to the parent document if a document is deleted.
>>
>> that reminds me of an issue i wanted to bring up a while ago:
>> the document with the id "/index" has an implicit special meaning. if
>> you delete it (which is easily done), all of the lenya authoring
>> interface will explode in your face unless you recreate it. bad.
>>
>> i was wondering whether it might simplify things if we had an immutable
>> root page that is only displayed in the authoring area and cannot be
>> deleted. the issue becomes obvious in the site tree overview: there is
>> no root, and you cannot for example paste a document under root. you can
>> only paste it as a child of some existing document, never as a
>> first-level sibling.
>> so it would be really nice if the "authoring" entry in that overview
>> would have an actual page associated to it, and you could click on it.
>>
>> this root page could become the default backlink for any error messages,
>> (in fact for every piece of code that currently assumes that an /index
>> node exists).
>> it would enable users to paste stuff like they are used to, and there
>> would be a parent element for every document, which means we can have a
>> generic solution to this deletion problem without conditionals.
>>
>>
>> comments?
>>
>> jörn
> 
> There may be times when one *does* want to delete the root document,
> perhaps to recreate it as another doc type or because one wants to
> wipe the root document's history.  So, as one (harder-to-implement)
> alternative it might be better to fix the bad Lenya behavior when
> there is no root document.  But Jörn's suggestion seems like a good
> interrim measure.

root document in this case means "the page that is displayed by default 
in the live area". note that i'm talking about this mystical immutable 
root page only for authoring. there is no conceivable reason to ever 
want to delete the that, because it has no meaning in live.

perhaps the root document should have different characteristics per 
area: in authoring, it should display some informational text similar to 
publication.xml, 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.








-- 
"Open source takes the bullshit out of software."
	- Charles Ferguson on TechnologyReview.com

--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: pol-admin@uni-due.de, Telefon: 0203/379-2736

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org


Re: should we introduce an immutable "root" document ? [was: Re: Request for comments: Redirect after document is deleted]

Posted by Bob Harner <bo...@gmail.com>.
On 6/7/06, Joern Nettingsmeier <po...@uni-due.de> wrote:
> Andreas Hartmann wrote:
> > Hi Lenya devs,
> >
> > please comment on this bug if you're interested in this issue.
> > We should either fix or close it.
> >
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=39077
>
> i would very much like to see bob's suggestion implemented, i.e. to jump
> to the parent document if a document is deleted.
>
> that reminds me of an issue i wanted to bring up a while ago:
> the document with the id "/index" has an implicit special meaning. if
> you delete it (which is easily done), all of the lenya authoring
> interface will explode in your face unless you recreate it. bad.
>
> i was wondering whether it might simplify things if we had an immutable
> root page that is only displayed in the authoring area and cannot be
> deleted. the issue becomes obvious in the site tree overview: there is
> no root, and you cannot for example paste a document under root. you can
> only paste it as a child of some existing document, never as a
> first-level sibling.
> so it would be really nice if the "authoring" entry in that overview
> would have an actual page associated to it, and you could click on it.
>
> this root page could become the default backlink for any error messages,
> (in fact for every piece of code that currently assumes that an /index
> node exists).
> it would enable users to paste stuff like they are used to, and there
> would be a parent element for every document, which means we can have a
> generic solution to this deletion problem without conditionals.
>
>
> comments?
>
> jörn

There may be times when one *does* want to delete the root document,
perhaps to recreate it as another doc type or because one wants to
wipe the root document's history.  So, as one (harder-to-implement)
alternative it might be better to fix the bad Lenya behavior when
there is no root document.  But Jörn's suggestion seems like a good
interrim measure.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org


should we introduce an immutable "root" document ? [was: Re: Request for comments: Redirect after document is deleted]

Posted by Joern Nettingsmeier <po...@uni-due.de>.
Andreas Hartmann wrote:
> Hi Lenya devs,
> 
> please comment on this bug if you're interested in this issue.
> We should either fix or close it.
> 
> http://issues.apache.org/bugzilla/show_bug.cgi?id=39077

i would very much like to see bob's suggestion implemented, i.e. to jump
to the parent document if a document is deleted.

that reminds me of an issue i wanted to bring up a while ago:
the document with the id "/index" has an implicit special meaning. if
you delete it (which is easily done), all of the lenya authoring
interface will explode in your face unless you recreate it. bad.

i was wondering whether it might simplify things if we had an immutable
root page that is only displayed in the authoring area and cannot be
deleted. the issue becomes obvious in the site tree overview: there is
no root, and you cannot for example paste a document under root. you can
only paste it as a child of some existing document, never as a
first-level sibling.
so it would be really nice if the "authoring" entry in that overview
would have an actual page associated to it, and you could click on it.

this root page could become the default backlink for any error messages,
(in fact for every piece of code that currently assumes that an /index
node exists).
it would enable users to paste stuff like they are used to, and there
would be a parent element for every document, which means we can have a
generic solution to this deletion problem without conditionals.


comments?

jörn





-- 
"Á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: pol-admin@uni-due.de, Telefon: 0203/379-2736


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org