cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: XInclude Transformer vs CInlude Transformer
Date Thu, 13 Jun 2002 11:16:49 GMT
Stefano Mazzocchi wrote:
>
> Mattam wrote:
> >
> > Ivelin Ivanov [Sun, 09 Jun 2002 11:22:07 -0500]:
> >
> > |
> > | Two almost identical transformers are confusing me.
> > | What is the difference between the two?
> > | Should one be deprecated?
> > |
> > | I'd vote for the one which implements the W3C XInclude spec closest.
> > | Maybe it should take the best of the other one.
> > |
> >
> > CInclude allows cocoon:/ protocol, and XInclude tends to be a
> strict implementation of the standard. Maybe keeping only
> XInclude while allowing the cocoon:/ protocol (with a switch?)
> would be the better.
>
> I agree, having both is highly confusing. Moreover, I think that we
> should *not* be using the XInclude namespace on the server side because
> we could get collisions in the future for browsers implementing XInclude
> on the client side.
>
In some cases this is true, but not in all. Imagine, fetching a distant
XML document containing xinclude commands. For processing it you need these
extra pieces of information, so you have to include the referenced documents
and therefore you need a xinclude transformer in some cases.

> For example, suppose you have something like this
>
>  <blah>
>   <include xmlns="http://www.w3.org/xinclude/2000" src="blah.inc"/>
>   <include xmlns="http://apache.org/cocoon/include" src="blah.inc"/>
>  </blah>
>
> the first tag should *not* be processed by Cocoon, even by an
> 'including' transformer.
>
> So, IMO, the best long term solution would be:
>
>  1) deprecate both XIncludeTransformer and CIncludeTransformer
>  2) change CIncludeTransformer to IncludeTransformer
>  3) make IncludeTransformer work just on a cocoon-specific namespace
>
> what do you think?
>
Again, I think XIncludeTransformer makes sense.

And we still have the third include transformer, the session transformer
which use is more verbose but therefore more flexible. Example:

	<session:include xmlns:session="http://cocoon.apache.org/session/1.0">
		<session:connection>
			<session:target>http://www.xml.com/cocoon.xml</session:target>
			<session:config>
				<session:param>
				  <session:name>METHOD</session:name>
				  <session:value>POST</session:value>
				</session:param>
			</session:config>
			<session:params>
				<session:param>
				  <session:name>user</session:name>
				  <session:value>xyz</session:value>
				</session:param>
			</session:params>
		</session:connection>
	</session:include>

As you can see by this example, you can parameterize the connection (for
example
setting the HTTP method to POST) and you can simply add parameters (for
example
the user=xyz).

I admit that this is rather verbose, but it is very usefull, especially
setting
the method and the simple handling of additional parameters is a *must
have*.

So I would suggest that we deprecate the cincludetransforer and use the
above
functionality for a new include transformer (not necessarily the syntax and
names, but the functionality).

What do you think?

Carsten


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


Mime
View raw message