cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cziege...@s-und-n.de
Subject Re: [RT] Using pipeline as sitemap components (long)
Date Sun, 24 Nov 2002 15:49:04 GMT
<P>Sorry, if this mail is not properly formatted - I have to use a mail frontend which</P><P>absolutely
sucks. But it seems that I'm stuck to it for the next week.</P><P>&nbsp;</P><P>Sylvain
Wallez wrote:</P><P><FONT FACE="Monospace,Courier">&gt; &gt;You
can totally confuse new cocoon users by telling them<BR>&gt; &gt;that the serializer
does not have to be the xml serializer.<BR>&gt; &gt;Because they don't know
the internal things of Cocoon which<BR>&gt; &gt;we know. And it's not obvious
for them.<BR>&gt; &gt;<BR></FONT>&gt;<BR><FONT FACE="Monospace,Courier">&gt;
I don't agree with the above : the first thing that a Cocoon user has to<BR>&gt;
know are the concepts of generator, transformer and serializer. And all<BR>&gt;
documents explaining these concepts explain the usage of SAX events (or<BR>&gt;
at least XML documents) to communicate between components and the fact<BR>&gt; that
the serializer translates SAX events to a byte stream.<BR></FONT>&gt;<BR><FONT
FACE="Monospace,Courier">&gt; The concept of SAX-event pipeline is *the* fundamental
concept of<BR>&gt; Cocoon. A such, a user not knowing this concept will understand
about<BR>&gt; nothing to what Cocoon is and what it can do.<BR></FONT>&gt;<BR><FONT
FACE="Monospace,Courier">&gt; But let's not argue about this, which isn't the real
problem here.<BR></FONT>Ok ;) - you missunderstood me above because I didn't give
a good and clear explanation,</P><P>but you're right that we should not argue
about this...so...let's continue</P><P><FONT FACE="Monospace,Courier"><BR>&gt;
&gt;Let's be honest - do you know any framework etc. where you<BR>&gt; &gt;have
to specify things which are not used to define this<BR>&gt; &gt;service? It's
like implementing a method where you have to<BR>&gt; &gt;add some statement
at the beginning and at the end and then<BR>&gt; &gt;later on they are ignored.<BR>&gt;<BR></FONT>&gt;<BR><FONT
FACE="Monospace,Courier">&gt;Mmmh... what about languages like Eiffel where each method
can have<BR>&gt;preconditions and postconditions (or the new &quot;assert&quot;
in JDK 1.4) ?<BR>&gt;Depending on the runtime environment, these blocks may or may
not be called.</FONT></P><P><FONT FACE="Monospace,Courier">This is
a little bit different, as you can write pre- and post-</FONT></P><P><FONT
FACE="Monospace,Courier">conditions in Eiffel but you don't have to. They're optional.<BR></FONT><BR><FONT
FACE="Monospace,Courier">&gt; &gt;And I think if we have a special syntax for calling
a service<BR>&gt; &gt;it's nearly natural to have a special concept for defining<BR>&gt;
&gt;the service as well.<BR>&gt; &gt;<BR></FONT>&gt;<BR><FONT
FACE="Monospace,Courier">&gt; Yep. But once again, there is no new concept on the caller
part. I admit<BR>&gt; the syntax is somewhat stretched on the callee and that we
may want a<BR>&gt; particular syntax there, but certainly not on the caller part.<BR>Ok,
that's exactly where we different opinions - I really tend to</FONT></P><P><FONT
FACE="Monospace,Courier">have a new syntax for the caller part as well - but if the overall</FONT></P><P><FONT
FACE="Monospace,Courier">consensus is, that we don't need it - I will not block it - but</FONT></P><P><FONT
FACE="Monospace,Courier">come up from time to time if users complain about it :)</FONT></P><P><BR><FONT
FACE="Monospace,Courier">&gt; So what if we introduce some new statements to define
incomplete<BR>&gt; pipelines to be used as pipeline services ? For example, a serialization<BR>&gt;
service could be defined using :<BR></FONT>&gt;<BR><FONT FACE="Monospace,Courier">&gt;
&lt;map:begin-service/&gt;<BR>&gt; &lt;map:transform src=&quot;xdoc2fo.xsl&quot;/&gt;<BR>&gt;
&lt;map:serialize type=&quot;fo2pdf&quot;/&gt;<BR></FONT>&gt;<BR><FONT
FACE="Monospace,Courier">&gt; and a transformation service could be defined using :<BR></FONT>&gt;<BR><FONT
FACE="Monospace,Courier">&gt; &lt;map:begin-service/&gt;<BR>&gt;
&lt;map:transform src=&quot;foo.xsl&quot;/&gt;<BR>&gt; &lt;map:end-service/&gt;<BR></FONT>&gt;
<BR><FONT FACE="Monospace,Courier">&gt; That is &lt;map:begin-service&gt;
replaces a &lt;map:generator&gt; that would be<BR>&gt; ignored and has to
be used for transformation or serialization services.<BR>&gt; Similarily, &lt;map:end-service&gt;
replaces a &lt;map:serialize&gt; that would be<BR>&gt; ignored and has to
be used for generation or transformation services.</FONT></P><P><FONT
FACE="Monospace,Courier">Roughly yes! I think this is more intuitiv und understandable.<BR></FONT><BR><FONT
FACE="Monospace,Courier">&gt; &gt;And one interesting thought: I could imagine
that as soon<BR>&gt; &gt;as people can call a cocoon pipeline as a transformation<BR>&gt;
&gt;service they will want to call a web services doing the same<BR>&gt; &gt;as
well, so something like this comes into mind:<BR>&gt; &gt;&lt;generate src=&quot;hallo.xml&quot;/&gt;<BR>&gt;
&gt;&lt;call-pipeline src=&quot;<A HREF=http://server/transformation>http://server/transformation</A>&quot;/&gt;<BR>&gt;
&gt;&lt;serialize&gt;<BR>&gt;<BR></FONT>&gt;<BR><FONT
FACE="Monospace,Courier">&gt; Why should a remote web service be called with a &quot;call-pipeline&quot;,
which<BR>&gt; is a Cocoon concept ? Here again, we just want transformation. So
this<BR>&gt; can be written :<BR></FONT>&gt;<BR><FONT FACE="Monospace,Courier">&gt;
&lt;generate src=&quot;hallo.xml&quot;/&gt;<BR>&gt; &lt;transform
type=&quot;soap&quot; src=&quot;<A HREF=http://server/transformation>http://server/transformation</A>&quot;/&gt;<BR>&gt;
&lt;serialize/&gt;<BR></FONT>:) - you got me...</P><P>&nbsp;</P><P><FONT
FACE="Monospace,Courier">Carsten</FONT></P><P></P>
Mime
View raw message