hi andreas!
Andreas Hartmann wrote:
Hi Jörn,
Joern Nettingsmeier schrieb:
well, it's a matter of taste, actually. i like to implement usecase
views as cocoon pipelines, because i know how to get at stuff using
input modules, and i find jxtemplates nasty...
I understand that it's a matter of taste, but if we continue using
both approaches we'll probably confuse our users. I prefer JX templates
mainly because I can access Java objects directly, and I have to change
just one place because the pipeline structures are already provided by
the usecase module.
WDTOT?
Would you mind giving a short description of what kind of information
you were missing?
here is the information i needed to make the existing tree code work:
Some examples how to obtain this information in a JX template:
+ <!-- this is a usecase view (see
config/cocoon-xconf/usecase-insertLink.xconf) -->
+ <map:match pattern="editors.insertLink">
+ <map:generate src="context://lenya/content/util/empty.xml"/>
+ <map:transform
src="fallback://lenya/modules/editors/xslt/insertLink.xsl">
<jx:set var="doc" value="${usecase.getParameter('document')}"/>
(provided the handler belongs to a DocumentUsecase subclass)
ok, this was obstacle no. 1: i figured since i was not accessing
documents at all, i should be subclassing AbstractUsecase, which does
not provide all those neat functions. point taken.
+ <map:parameter name="publicationId"
value="{page-envelope:publication-id}"/>
${document.getPublication().getId()}
+ <map:parameter name="area" value="authoring"/>
${document.getArea()}
+ <map:parameter name="areaBasePath"
+
value="{proxy:/{page-envelope:publication-id}/{page-envelope:area}}"/>
AREA_BASE_PATH = '<proxy:url href="/${publicationId}/${area}"/>';
(see modules/sitemanagement/usecases/tab/sitetree.jx, I'll add the
corresponding documentation to the usecase framework docs asap)
deep and utter magic. where did you pull this one from?
i looked into sitetree.jx, but i still haven't figured what's going on.
are those tags being replaced by a transformation before the
jxtransformer kicks in?
anyway, it's quite atrocious :-D
+ <map:parameter name="tab" value="en"/>
IMO this shouldn't be hard-coded, but rather set to the default
language ...
sorry, yes. that's a leftover from the old code... will fix.
+ <map:parameter name="languages"
value="{page-envelope:publication-languages-csv}"/>
${document.getPublication().getLanguages()}
ok, that's probably nicer than to dissect a csv. i'm assuming i can
jx:forEach over the return value directly...
+ <map:parameter name="editorModule"
value="{request-param:lenya.editorModule}"/>
${usecase.getParameter('lenya.editorModule')}
+ </map:transform>
+ <map:call resource="style-cms-page"/>
+ <map:serialize />
+ </map:match>
i did not mean to imply it's not obtainable via java, just that i could
not figure out how in a reasonable timeframe.
I understand this for the areaBasePath, but for the other information -
is it a matter of re-structuring the documentation? Or would a page on
JX templates in Lenya help?
as i said, i started from AbstractUsecase... that was a very bad idea
indeed.
plus in this case, we don't really cause server-side effects, hence it
seems overkill to implement a special usecase handler just to obtain
some view-related data. my approach uses the dummy handler instead.
You can just use the DocumentUsecase to get the information described
above.
ah well :)
do you still think we had better use jxtemplate?
IMO yes :)
point taken. i'll try and re-implement the stuff as a (shudder!)
jxtemplate....
--
Jörn Nettingsmeier
Kurt is up in heaven now.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
