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 2007/05/14 10:47:51 UTC
[1.4] Generic handling of revisions for included documents
Hi Lenya devs,
the problem with the blocker bug 42394 [1] is the following:
- Specific revisions are addressed using ...?lenya.revision=xy
- The revision parameter is passed from the sitemap to the
RepositorySourceFactory
- The homepage includes a news overview (IMO a normal situation)
- The news module sitemap evaluates the lenya.revision parameter
- It tries to load revision xy of the news page, even if it
doesn't exist
How should we handle this situation? Some options:
- Pass UUID and language alongside the lenya.revision parameter
to specify which document is affected by the revision selection.
The problem with this approach is that an inconsistent view is
generated because document versions from different times are
assembled to a page.
- Whenever a repository source is generated, compare its path
with the path of the HTTP request. If it is the same, use the
revision parameter, if not, don't use it. Well, if we want to
emphasize convention over configuration, this might be the
easiest solution. But the same problem occurs as with the
first option.
- Use global revision numbers (like SVN) and apply them to all
documents. If a document didn't exist at the given time, the
inclusion either returns a placeholder, or an error message
is shown.
IMO option 2 is preferrable, but will probably require massive
changes to the revision control mechanism (maybe something for
1.4.1).
A quick fix would be to hard-code if the lenya.revision parameter
should be evaluated. For instance, the "include" and "header"
formats of the news resource type wouldn't use it. But this can't
be a long-term solution for various reasons - for instance, you'd
always have to know if you can omit the parameter when you access
a lenyadocument: source.
Maybe there are more ideas?
-- Andreas
[1] http://issues.apache.org/bugzilla/show_bug.cgi?id=42394
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] Generic handling of revisions for included documents
Posted by Andreas Hartmann <an...@apache.org>.
Thorsten Scherler schrieb:
[...]
> With this as base on could as well implement easy a diff output like we
> have in svn revision (e.g. colored diff between two version).
>
> AKA
> Document doc = rcml.getBackupEntryDiff(version,otherVersion);
>
> Where we could make the generator configurable like
> <map:generate type="revision">
> <map:parameter name="diff" value="true|false"/>
> </map:generate>
Hmm, why should we mix diff functionality with presentation pipelines?
I'd rather add a specific usecase for this.
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] Generic handling of revisions for included documents
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Mon, 2007-05-14 at 13:07 +0200, Thorsten Scherler wrote:
> On Mon, 2007-05-14 at 11:38 +0200, Andreas Hartmann wrote:
> ...
> > > Meaning another option is to limit the revision to the main document,
> > > which is as well producing the overview in
> > > http://localhost:8888/default/authoring/index.html?lenya.usecase=tab.revisions
> > >
> > > The revision link would open only the document (no nav, no menu, no
> > > nothing else but the result of
> > > {resource-type:format-xhtml}?rendertype={1}.
> > >
> > > wdyt?
> >
> > That would certainly be an option, but it would require hard-coding
> > the revision handling in sitemaps. We'd have to introduce a generic
> > concept of "page" vs. "revision" rendering.
>
> Requesting
> http://localhost:8888/default/authoring/index.html?lenya.revision=2
> is triggering which code?
>
> I just was looking were lenya.revision=2 get resolved. Can you point me
> to the code?
>
> I thought that I could find something like:
>
> RCML rcml = getSourceDocument().getRepositoryNode().getRcml();
> int version= getParameter("lenya.revision");
> Document doc = rcml.getBackupEntry(version);
>
> We would need to write rcml.getBackupEntry(int version){} and above goes
> in a generator that returns the sax out of the doc.
>
> That would not make it necessary to hard code the revision handling.
>
> Having a match like
> <map:match type="request-parameter" pattern="lenya.revision">
> <map:generate type="revision"/>
> <map:serialize type="xml"/>
> </map:match>
With this as base on could as well implement easy a diff output like we
have in svn revision (e.g. colored diff between two version).
AKA
Document doc = rcml.getBackupEntryDiff(version,otherVersion);
Where we could make the generator configurable like
<map:generate type="revision">
<map:parameter name="diff" value="true|false"/>
</map:generate>
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] Generic handling of revisions for included documents
Posted by Andreas Hartmann <an...@apache.org>.
Thorsten Scherler schrieb:
> On Mon, 2007-05-14 at 11:38 +0200, Andreas Hartmann wrote:
> ...
>>> Meaning another option is to limit the revision to the main document,
>>> which is as well producing the overview in
>>> http://localhost:8888/default/authoring/index.html?lenya.usecase=tab.revisions
>>>
>>> The revision link would open only the document (no nav, no menu, no
>>> nothing else but the result of
>>> {resource-type:format-xhtml}?rendertype={1}.
>>>
>>> wdyt?
>> That would certainly be an option, but it would require hard-coding
>> the revision handling in sitemaps. We'd have to introduce a generic
>> concept of "page" vs. "revision" rendering.
>
> Requesting
> http://localhost:8888/default/authoring/index.html?lenya.revision=2
> is triggering which code?
The resource type module sitemaps pass the lenya.revision parameter to
the DocumentSource, from there it goes to the RepositorySource. The
actual evaluation happens in the RepositorySource.
> I just was looking were lenya.revision=2 get resolved. Can you point me
> to the code?
>
> I thought that I could find something like:
>
> RCML rcml = getSourceDocument().getRepositoryNode().getRcml();
> int version= getParameter("lenya.revision");
> Document doc = rcml.getBackupEntry(version);
That's in RepositorySource:
if (revisionNumber == -1) {
this.content = (ContentHolder) session.getRepositoryItem(
factory, sourceUri);
}
else {
Node node = (Node) session.getRepositoryItem(factory, sourceUri);
this.content = node.getHistory().getRevision(revisionNumber);
}
> We would need to write rcml.getBackupEntry(int version){} and above goes
> in a generator that returns the sax out of the doc.
>
> That would not make it necessary to hard code the revision handling.
>
> Having a match like
> <map:match type="request-parameter" pattern="lenya.revision">
> <map:generate type="revision"/>
> <map:serialize type="xml"/>
> </map:match>
>
> Not sure whether I explained myself very well.
IMO revision handling should be completely orthogonal to pipeline
processing. Otherwise, the danger of forgetting something is too big,
and the code becomes harder to maintain.
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] Generic handling of revisions for included documents
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Mon, 2007-05-14 at 11:38 +0200, Andreas Hartmann wrote:
...
> > Meaning another option is to limit the revision to the main document,
> > which is as well producing the overview in
> > http://localhost:8888/default/authoring/index.html?lenya.usecase=tab.revisions
> >
> > The revision link would open only the document (no nav, no menu, no
> > nothing else but the result of
> > {resource-type:format-xhtml}?rendertype={1}.
> >
> > wdyt?
>
> That would certainly be an option, but it would require hard-coding
> the revision handling in sitemaps. We'd have to introduce a generic
> concept of "page" vs. "revision" rendering.
Requesting
http://localhost:8888/default/authoring/index.html?lenya.revision=2
is triggering which code?
I just was looking were lenya.revision=2 get resolved. Can you point me
to the code?
I thought that I could find something like:
RCML rcml = getSourceDocument().getRepositoryNode().getRcml();
int version= getParameter("lenya.revision");
Document doc = rcml.getBackupEntry(version);
We would need to write rcml.getBackupEntry(int version){} and above goes
in a generator that returns the sax out of the doc.
That would not make it necessary to hard code the revision handling.
Having a match like
<map:match type="request-parameter" pattern="lenya.revision">
<map:generate type="revision"/>
<map:serialize type="xml"/>
</map:match>
Not sure whether I explained myself very well.
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] Generic handling of revisions for included documents
Posted by Andreas Hartmann <an...@apache.org>.
Thorsten Scherler schrieb:
[...]
> Actually if we assume that we have on document as main entrance and the
> news is just an addon to this page, which will be rendered in some
> formats (like html) and in others not (like pdf), we can make the
> revision only depended on the main document. Where the main document can
> be perfectly an aggregation of different documents.
>
> Let us see the aggregation that we had the other day:
> <map:aggregate element="cmsbody">
> <map:part
> src="cocoon:/navigation-element/breadcrumb/{2}/{3}/{5}/{6}/{7}"/>
> <map:part
> src="cocoon:/navigation-element/tabs/{2}/{3}/{5}/{6}/{7}"/>
> <map:part
> src="cocoon:/navigation-element/menu/{2}/{3}/{5}/{6}/{7}"/>
> <map:part
> src="cocoon:/navigation-element/search/{2}/{3}/{5}/{6}/{7}"/>
> <map:part
> src="cocoon://modules/languageselector/text-none/flagsize-13"/>
> <map:part src="{resource-type:format-xhtml}?rendertype={1}"/>
> </map:aggregate>
>
> IMO the only interested part for the revision is
> <map:part src="{resource-type:format-xhtml}?rendertype={1}"/>
>
> The rest is presentational and not part of the document.
This would work only if we do the aggregation in the sitemap, and it
wouldn't be generic but require hard-coding the revision handling in
all sitemaps. When you use templates, you'd have to add revision control
specific control statements in XSLTs ...
> Meaning another option is to limit the revision to the main document,
> which is as well producing the overview in
> http://localhost:8888/default/authoring/index.html?lenya.usecase=tab.revisions
>
> The revision link would open only the document (no nav, no menu, no
> nothing else but the result of
> {resource-type:format-xhtml}?rendertype={1}.
>
> wdyt?
That would certainly be an option, but it would require hard-coding
the revision handling in sitemaps. We'd have to introduce a generic
concept of "page" vs. "revision" rendering.
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] Generic handling of revisions for included documents
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Mon, 2007-05-14 at 10:47 +0200, Andreas Hartmann wrote:
> Hi Lenya devs,
>
> the problem with the blocker bug 42394 [1] is the following:
>
> - Specific revisions are addressed using ...?lenya.revision=xy
>
> - The revision parameter is passed from the sitemap to the
> RepositorySourceFactory
>
> - The homepage includes a news overview (IMO a normal situation)
>
> - The news module sitemap evaluates the lenya.revision parameter
>
> - It tries to load revision xy of the news page, even if it
> doesn't exist
>
>
> How should we handle this situation? Some options:
>
> - Pass UUID and language alongside the lenya.revision parameter
> to specify which document is affected by the revision selection.
> The problem with this approach is that an inconsistent view is
> generated because document versions from different times are
> assembled to a page.
>
> - Whenever a repository source is generated, compare its path
> with the path of the HTTP request. If it is the same, use the
> revision parameter, if not, don't use it. Well, if we want to
> emphasize convention over configuration, this might be the
> easiest solution. But the same problem occurs as with the
> first option.
>
> - Use global revision numbers (like SVN) and apply them to all
> documents. If a document didn't exist at the given time, the
> inclusion either returns a placeholder, or an error message
> is shown.
>
> IMO option 2 is preferrable, but will probably require massive
> changes to the revision control mechanism (maybe something for
> 1.4.1).
>
> A quick fix would be to hard-code if the lenya.revision parameter
> should be evaluated. For instance, the "include" and "header"
> formats of the news resource type wouldn't use it. But this can't
> be a long-term solution for various reasons - for instance, you'd
> always have to know if you can omit the parameter when you access
> a lenyadocument: source.
>
>
> Maybe there are more ideas?
Actually if we assume that we have on document as main entrance and the
news is just an addon to this page, which will be rendered in some
formats (like html) and in others not (like pdf), we can make the
revision only depended on the main document. Where the main document can
be perfectly an aggregation of different documents.
Let us see the aggregation that we had the other day:
<map:aggregate element="cmsbody">
<map:part
src="cocoon:/navigation-element/breadcrumb/{2}/{3}/{5}/{6}/{7}"/>
<map:part
src="cocoon:/navigation-element/tabs/{2}/{3}/{5}/{6}/{7}"/>
<map:part
src="cocoon:/navigation-element/menu/{2}/{3}/{5}/{6}/{7}"/>
<map:part
src="cocoon:/navigation-element/search/{2}/{3}/{5}/{6}/{7}"/>
<map:part
src="cocoon://modules/languageselector/text-none/flagsize-13"/>
<map:part src="{resource-type:format-xhtml}?rendertype={1}"/>
</map:aggregate>
IMO the only interested part for the revision is
<map:part src="{resource-type:format-xhtml}?rendertype={1}"/>
The rest is presentational and not part of the document.
Meaning another option is to limit the revision to the main document,
which is as well producing the overview in
http://localhost:8888/default/authoring/index.html?lenya.usecase=tab.revisions
The revision link would open only the document (no nav, no menu, no
nothing else but the result of
{resource-type:format-xhtml}?rendertype={1}.
wdyt?
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] Generic handling of revisions for included documents
Posted by Andreas Hartmann <an...@apache.org>.
Andreas Hartmann schrieb:
> - Whenever a repository source is generated, compare its path
> with the path of the HTTP request. If it is the same, use the
> revision parameter, if not, don't use it.
I guess this is the most straightforward and least invasive approach
ATM.
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org