Re: Ultimate Dynamicity

[Ryan Hoegg <rh...@isisnetworks.net>]

Hello,

I am not absolutely sure I understand your architecture, but I will give 
this a go:

> * If I merge all the XSL stylesheets via xsl:include or xsl:import into a
> master.xsl that is in the system, it can't work!! Because, AFAIK, I can't
> get XSL transformation to do "template match" on nodes of a particular
> namespace (or can I?).

Yes, XSLT is namespace aware.  You can define namespaces prefixes for your namespaces in your stylesheet and match that way.  However, I think you can also do this:
<xsl:template xmlns:fooBar="http://www.foo.com/bar/1.0" match="fooBar:baz"><xsl:apply-templates/></xsl:template>
Would someone else more steeped in XSLT knowledge than I verify this?

> * For any request, I don't know what type it is until the response from
> the real-time server, and can't direct Cocoon to use the correct
> stylesheet.

Sounds like a custom Transformer to me.  I think you could set a 
pipeline parameter in your Generator denoting which Block this document 
is from and then have a lookup facility in your Transformer that applies 
the correct stylesheet for that Block.

Hope this helps,
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net

Niclas Hedhman wrote:

>Hi, everyone.
>
>Not sure if this belongs on the users or dev list, but I post it here first.
>
>
>Problem is a bit hard to explain, but here we go;
>
>I have a system where N people creates Avalon Blocks for Real-time
>applications (process control).
>Each Block has a real-time part and a UI part.
>Each Block re-utilizes a lot of standard JavaBeans, and the collection of
>JavaBeans used are growing from various 3rd party developers.
>The system has a Block that can introspect other Blocks, and provide
>connectivity to the network.
>It is possibly to retrieve arbitrary objects from the system, by using a
>simple "name-dot-name" syntax, as in Jakarta Commons BeanUtils.
>If the JavaBean has a "toXML()" method, that is called when the JavaBean
>is requested and returned to the client.
>
>Cocoon is used for the UI, and a custom generator takes part of the
>request URL as the "requested object" in the remote real-time system. It
>will hence be returned an text/xml document from the real-time system.
>
>Cocoon will transform the XML into HTML via XSL.
>
>Now!!
>Since there are many independent developers of "real-time content", I have
>prescribed the use of XML namespaces.
>Each Block developer is responsible to create the standard/default set of
>XSL stylesheets, for the new JavaBeans he/she defines.
>
>BUT, I know have an aggregation problem of the Stylesheets that comprises
>the UI side of things.
>
>* If I merge all the XSL stylesheets via xsl:include or xsl:import into a
>master.xsl that is in the system, it can't work!! Beacuse, AFAIK, I can't
>get XSL transformation to do "template match" on nodes of a particular
>namespace (or can I?).
>
>* For any request, I don't know what type it is until the response from
>the real-time server, and can't direct Cocoon to use the correct
>stylesheet.
>
>Does anyone have any idea on this?
>
>Thanks
>Niclas
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>For additional commands, e-mail: users-help@cocoon.apache.org
>
>  
>



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

Re: Ultimate Dynamicity

[Bertrand Delacretaz <bd...@codeconsult.ch>]

Le Samedi, 9 aoû 2003, à 14:38 Europe/Zurich, Niclas Hedhman a écrit :
> ...Wow... Is this so??  I assume I could have the xmlns declaration at 
> the
> root node as well, right? I also assume then, that the document node
>
> <foo:mynode xmlns:foo="http://www.mycompany.com/mytype" >
> </foo:mynode>
>
> would be matched by the template
>
> <xsl:template xmlns:bar="http://www.mycompany.com/mytype"
>   match="bar:mynode" />

Looks correct, although usually (by convention) you'd put the xmlns:bar 
definition on the xml:stylesheet node (and mabye use 
exclude-result-prefixes as well).

I also find the self:: axis useful for stuff like (for example)

   <xsl:apply-templates select="*[some 
condition...][self::foo:elementA|self::bar:element2]"/>

-Bertrand

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

Re: Ultimate Dynamicity

[Niclas Hedhman <ni...@hedhman.org>]

<quote who="Ryan Hoegg">
> Hello,
>
> I am not absolutely sure I understand your architecture.

It is harder to explain than it is in real life ;o)
Think; Independent networked XML resources where the type of each resource
is unknown until the response document is returned. BUT that each document
type has an installed set of XSL stylesheet for transformations in Cocoon.


> Yes, XSLT is namespace aware.  You can define namespaces prefixes for
> your namespaces in your stylesheet and match that way.  However, I think
> you can also do this: <xsl:template
> xmlns:fooBar="http://www.foo.com/bar/1.0"
> match="fooBar:baz"><xsl:apply-templates/></xsl:template> Would someone
> else more steeped in XSLT knowledge than I verify this?

Wow... Is this so??  I assume I could have the xmlns declaration at the
root node as well, right? I also assume then, that the document node

<foo:mynode xmlns:foo="http://www.mycompany.com/mytype" >
</foo:mynode>

would be matched by the template

<xsl:template xmlns:bar="http://www.mycompany.com/mytype"
  match="bar:mynode" />

Really good stuff if this works. Will try later!


> Sounds like a custom Transformer to me.  I think you could set a
> pipeline parameter in your Generator denoting which Block this document
> is from and then have a lookup facility in your Transformer that applies
>  the correct stylesheet for that Block.

If was thinking of the generator creating a PI with the "type" for the
transformer to use. The sheer size of the TraxTransformer gave me a creepy
feeling and I didn't want to extend it.

> Hope this helps,

YES, it really does.

Thanks a lot!

Niclas



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org