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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
