Hi Jörn,
Joern Nettingsmeier schrieb:
> Andreas Hartmann wrote:
[...]
>>> introduced generic editors.insertLink usecase implementation.
>>> the view is created by a cocoon pipeline, not a jxtemplate, because the
>>> necessary data is more readily available as input modules than via the
>>> java api.
>>
>> that's an issue that should definitely be addressed immediately.
>> We can't declare JX templates the recommended way of implementing
>> usecase views if they don't provide access to information which
>> is necessary for rendering.
>
> 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)
>>> + <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)
>>> + <map:parameter name="tab" value="en"/>
IMO this shouldn't be hard-coded, but rather set to the default
language ...
>>> + <map:parameter name="chosenLanguage"
>>> value="{page-envelope:document-language}"/>
${document.getLanguage()}
>>> + <map:parameter name="path"
>>> value="{page-envelope:document-path}"/>
${document.getPath()}
>>> + <map:parameter name="documentId"
>>> value="{page-envelope:document-uuid}"/>
${document.getUUID()}
>>> + <map:parameter name="documentExtension"
>>> value="{page-envelope:document-extension}"/>
${document.getSourceExtension()}
>>> + <map:parameter name="defaultLanguage"
>>> value="{page-envelope:default-language}"/>
${document.getPublication().getDefaultLanguage()}
>>> + <map:parameter name="languages"
>>> value="{page-envelope:publication-languages-csv}"/>
${document.getPublication().getLanguages()}
>>> + <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?
> 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.
> do you still think we had better use jxtemplate?
IMO yes :)
-- Andreas
> comments are appreciated.
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
