xml-xsp-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tagunov Anthony" <atagu...@nnt.ru>
Subject Re: taglib application order (was: Re-purposing XSP)
Date Sun, 11 Mar 2001 08:04:42 GMT
On Sun, 11 Mar 2001 00:18:50 -0500 (EST), Donald Ball wrote:

>On Sat, 10 Mar 2001, Tagunov Anthony wrote:
>
>> I clearly under there are some easy cases when the order of
>> taglib application is insignificant
>> (<esql:parameter><mytaglib:get-value/></esql:parameter>),
>> still the problem exists.
>
>does it? i think logicsheet application order is irrelevant, actually. can
>you demonstrate a case in which it is important?

in this example there's no problem :-)))
let us call this type of interaction between taglibs
(generate code that is executed from top to bottom)
interaction of type (A).

                             - o -
the problem is if we want the following:
do we allow our taglibs to interact in other ways?
I see intaraction imaginable of two more types,
let us call them types (B) and (C)

                             - o -
type (B) interaction:

-  Matt in AxKit writes taglibs that INVOKE tag handling
    code from other taglibs (that's how i understand his mails)
in C1 an equivalent approach would be to allow
the xsl that implements taglibA to emit tags <B:b/> that are
transformed later by taglibB. The only way to do that with
C1 is to chain the XSLT transformations. Then ther order
_is_ imortant.

                            - o -

type (C) interaction:
- the XSLT approach has got a _wide_ flexibility, maybe too
wide. What we can do with this approach is to allow
taglibA output something like (3) or (4) see bellow
and taglibB implemented as XSLT transform chained after
taglibA may react to both (3) and (4):

(3) taglibA can do the transform 
from
<xsp:page>
  <xsp:structure><xsp:include>classA</xsp:include></xsp:structure>
</xsp:page>
to
<xsp:page>
  <xsp:structure><xsp:include>classA</xsp:include></xsp:structure>
  <xsp:structure><xsp:variable name="z"/></xsp:structure>
</xsp:page>
(4) taglib A can do the transform
from
<xsp:page>
  <A:foo/>
</xsp:page>
to
<xsp:page>
 <B:foo>
   <a>1</a><b>2</b>
 </B:foo>
</xsp:page>
                               - o -
Interaction of type (A) already runs smothly evrywhere, it order insensetive
and nice :-))
Should interaction of type (B) be allowed? Looks very nice maybe yes.
Should interaction of type (C) be allowed? Donno.
-----------------------------------

>> Even if this problem is solved in C2 still, is there/should there be a way
>> for taglib A specify that it wants taglib B to be run after it?
>> Maybe it would be enough to warn in the documentation for A:
>> "please make sure to run B after A, or it won't work"
>
>logicsheets aren't "run" before or after one another - the code which they
>generate is run top-down through a mix of instructions they all generate.
>they're applied in a certain order by the c1 xsp engine, but i think it
>could just as easily work by merging all of the logicsheets into one big
>stylesheet and re-applying it that until no nodes in any of the logicsheet
>namespace uris are left. hmm, i wonder, is that true?

Great and nice! :-)) interaction of type (A) can be served this way
(at least we can IMAGINE all the stylesheets combined to operate
as one hyper-stylesheet :-)
Not for type (B) though.

Best regards, Tagunov Anthony



Mime
View raw message