cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: JXTG limitations
Date Tue, 27 Sep 2005 08:42:38 GMT
Daniel Fagerstrom wrote:

> Sylvain Wallez wrote:
>
>> Hi all,
>>
>> While working on some new CForms stuff (Ajax suggest lists and 
>> fi:styling as attributes), I felt more and more limited by the 
>> reduced enviromnent that JXTG offers to macros.
>>
>> Put it clearly, here's what I need to be accessible in macros:
>> - the service manager: I need to get a continuations knowing its ID
>
>
> Don't like it, would prefer the accessor stuff that we discussed (and 
> I started to implement). But as my focus will be on blocks for the 
> near future I shouldn't block other peoples work, so go ahead.


Accessors are about an extended objet model, right? In this regard, I 
don't think giving access to the ServiceManager there is a good thing as 
it will make it generally accessible, although of course Accessors can 
be serviceable and use the manager to provide some data.

JXTG extensions, on the other hand, may want to access additional 
components providing access to information that is to be used by the 
template. I make here a distinction between extensions (macros, taglibs, 
etc) and the template itself, even if I agree that the distinction is 
subtle.

>> - knowing and changing the XMLConsumer to which the template is 
>> sending SAX events. I need this to cleanly implement fi:styling as 
>> attributes and ensure no fi:styling element exists if attributes are 
>> used.
>
>
> Like it even less, it breaks SoC and I have some optimiztion ideas 
> that I would to work on in the future that not would work together 
> direct access to the XMLConsumer.
>
> Could you give some example of what you need to do, so that we can see 
> if there could be some more dclarative solution of it that we could 
> add to JXTG?


Sure. Let's consider the <ft:widget> macro:
    <jx:macro name="widget" 
targetNamespace="http://apache.org/cocoon/forms/1.0#template">
      <jx:parameter name="id"/>
     
      <jx:if test="${cformsHelper.pushWidget(id)}">
        <jx:set var="widget" value="${cformsHelper.peekWidget()}"/>
        <jx:set var="cformsDummy" 
value="${cformsHelper.generateWidget(widget, macro.arguments)}"/>
        <jx:evalBody/>
        <jx:set var="cformsDummy" 
value="${cformsHelper.flushRootAndPop()}"/>
      </jx:if>
    </jx:macro>

generateWidget() will use macro.arguments to automatically generate a 
<fi:styling> element. Now we would like also to ensure that the macro's 
body doesn't itself contain a <fi:styling>.

What that means is that the macro must be able to filter the SAX events 
produced by <jx:evalBody/>

Actually, having an optional content-handler argument to <jx:evalBody> 
may do the trick:

        <jx:set var="cformsDummy" 
value="${cformsHelper.generateWidget(widget, macro.arguments)}"/>
        <jx:evalBody handler="${cformsHelper.getStylingChecker()}"/>
        <jx:set var="cformsDummy" 
value="${cformsHelper.flushRootAndPop()}"/>

Does it sound better?

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://people.apache.org/~sylvain     http://www.anyware-tech.com
Apache Software Foundation Member     Research & Technology Director


Mime
View raw message