Ovidiu,
Sounds Great!!!!! Since no one objected.....Please go ahead and submit patches against
C2.1. I
will try to get them in. Please post zip files (with diff's and new files) directly to
cocoon-dev
as usual.
Thanks,
dims
PS: If there are problems with zip files, then you can upload them to BugZilla and
post the Bug ID
to the list.
--- Sylvain Wallez <[EMAIL PROTECTED]> wrote:
>
>
> Ovidiu Predescu wrote:
> >
> > Hi Carsten,
> >
> > On Tue, 14 Aug 2001 13:07:08 +0200, "Carsten Ziegeler" <[EMAIL PROTECTED]> wrote:
> >
> > > > Ovidiu Predescu wrote:
> > > >
> > > > I was looking at how the current Source interface is defined, and I
> > > > believe we need to separate things a little bit more. I badly need
> > > > this separation in one of the extensions to Cocoon I'm working on
> > > > (which I hope to present sometime early next month).
> > > >
> > > Sounds interesting. Tell us more about your extensions !
> >
> > The team I work on at HP is making use of Cocoon2 as a framework to
> > build and access Web Services. We are actively supporting and
> > promoting Cocoon2 within HP as the framework to be used for any XML
> > processing. We just had a beta release of our middleware product,
> > which among other things includes Cocoon2, which is based on 2.1-dev
> > as of June 18, 2001. We intend to integrate all the changes we make
> > back to the Cocoon2 main trunk.
> >
> > As part of the changes we've done, we had a SOAP and UDDI
> > logicsheet. The logicsheets were built on top of an abstraction we
> > called XStream, which is an object that holds an XML content, very
> > similar with the Source abstraction. In fact XStream was built on top
> > of a re-factored Source interface, which at the time I started the
> > branch, was only a class.
> >
> > XStream is a logicsheet, together with the supporting code, that
> > defines all sorts of operations, creation from an inline XML fragment,
> > transforming an XStream through a stylesheet (which is nothing else
> > than another XStream), etc. The SOAP logicsheet is implemented
> > directly using XStream objects, without having to use any client
> > library. It just collects the XML fragment specified in the XSP page,
> > creates an XStream object and invokes the SOAP server directly. The
> > XML response is packaged in an XStream object.
> >
> > The XStream objects are accessible by name, just like variables in
> > programming languages. The scope of a variable can be global, session
> > or XSP page. You can refer to them anywhere in an XSP page and you can
> > obtain their representation either as a Java object, or as an XML
> > fragment which gets embedded in the generated document.
> >
> > Here is how one uses this stuff, in a fictive SOAP piece of code:
> >
> > <xstream:create name="message"/>
> > <add>
> > <arg1><xsp-request:get-parameter name="a"/></arg1>
> > <arg2><xsp-request:get-parameter name="b"/></arg2>
> > </add>
> > </xstream:create>
> >
> > <xstream:create name="response">
> > <soap:call href="some url">
> > <request>
> > <xstream:get name="message" as="xml"/>
> > </request>
> > </soap:call>
> > </xstream:create>
> >
> > <xstream:create name="a transformation" href="context://some stylesheet"/>
> >
> > <para>The result of adding the two numbers is
> > <xstream:transform source="response" stylesheet="a transformation"/>
> > </para>
> >
> > The soap:call above simply creates another XStream object that
> > collects the XML fragment specified as a child. It then posts the
> > message to the specified URL, and places the resulting XML in an
> > XStream named "response". The above example shows how one can create
> > an XStream given an URL, and make use of it to transform another
> > XStream.
> >
> > XStream is only one type of objects that can be created. We are
> > working on having arrays, and special objects to hold content which is
> > not XML. This is needed for having the ability to process SOAP with
> > attachments, but can also be used to write Web applications that deal
> > with POST data which contains files and other non-XML data.
> >
> > I call this generic framework XScript; it is a framework for
> > manipulating arbitrary objects, but mostly with XML content, from
> > within XSP pages. We plan to make use of it to implement things like
> > ebXML, BizTalk and RNIF processors. These will transform Cocoon2 in a
> > framework to build Web Services, not only to access them.
> >
> > > > There are three distinct things the Source interface deals with right
> > > > now:
> > > >
> > > > a) the real input source, its last modified date, and content length
> > > >
> > > > b) determining whether the source is a file, and obtaining the file
> > > >
> > > > c) streaming the content of the source to a ContentHandler
> > > >
> > > > d) the ability to refresh a Source
> > > >
> > > > IMO the Source interface should deal only with a). Source should be an
> > > > abstraction for content, with no regard whether is a file or whether
> > > > it contains XML data.
> > > Yes, this is right. That was actually the intension of the source
> > > object. But by the time if was introduced the cocoon code used different
> > > ways of getting information from sources and it was very hard to unify
> > > them into a single Source object without redesigning some major parts.
> > > So this led actually to the current implementation.
> >
> > Yes, and I think you did a great job of unifying all the approaches in
> > a single one.
> >
> > > > By greping the sources really quick, I found that the only place that
> > > > uses the file characteristics of Source is in
> > > > DirectoryGenerator. However a simple workaround can be implemented, by
> > > > asking the Source for its system id, and determining from there the
> > > > type of the Source.
> > > Again correct, but I think that a isFile() method on the Source object
> > > is more convenient than testing the system id if it starts with the
> > > "file" protocol (and more performant).
> >
> > XStream is actually implemented as a Source. I modified the 2.1-dev
> > (unfortunatelly in a way that's a bit incompatible with today's main
> > trunk) so that Source is just a simple interface, as described in the
> > original message.
> >
> > If you look above, for an XStream object that's built from an inline
> > XML fragment, there isn't any File associated with it. The file
> > abstraction in fact makes no sense for it.
> >
> > Another example where the file abstraction doesn't make much sense is
> > with data coming from the POST request. There isn't any file
> > associated with this data, yet that data can be considered a Source.
> >
> > As you point out, the file abstraction may provide some performance
> > improvements over checking the system id. In this case we can
> > implement FileSource as another interface, that inherits from Source,
> > which provides the file abstraction:
> >
> > interface FileSource extends Source
> > {
> > public File getFile();
> > }
> >
> > > > The functionality defined in c) is already provided by XMLFragment,
> > > > and I see no reason why we shouldn't use this instead. Also we should
> > > > make a separation between Sources that contain XML data, and those
> > > > that don't.
> > > Yes and no, it would be good to separate between XML and not XML, the
> > > reason for the stream() method in the Source object was the idea that
> > > a source object is able to "generate" xml, even if the data is not XML,
> > > but e.g. html.
> >
> > I agree, but this type of sources that could be represented as XML
> > should really implement the XMLSource interface.
> >
> > > We could use the XMLFragment interface here as well, also we have to
> > > add a toSAX(XMLConsumer consumer) method.
> >
> > Should we then have toSAX(XMLConsumer) part of XMLFragment?
> >
> > > > As for point d), I'm not sure is good to assume that all the Sources
> > > > are mutable. I have actually come up with Source objects which are
> > > > imutable, and for them the refresh operation has no meaning.
> > > The refresh() method is currently very important for the reloading of
> > > the sitemap and the cocoon.xconf to detect changes. On the other hand
> > > the refresh() method is also meant as a reset() method, which means
> > > that you can call e.g. getInputStream() more than once. With e.g.
> > > an url connection this is only possible if you open a new connection
> > > before you can get an input stream for the second time, so refresh()
> > > is usefull here.
> > > I agree that refresh() might not be the right name for it.
> >
> > I understand your point, and as you point out, in the general case a
> > Source cannot be modified. An XStream created from an inline XML
> > fragment, or a Source created from the POST data, are immutable
> > objects, once created cannot be modified. The refresh/reset interface
> > makes sense to objects whose actual data store modifies, like the case
> > of the configuration files.
> >
> > I believe we should create a ModifiableSource interface for this kind
> > of objects, and remove the methods from the Source interface.
> >
> > > > As a result, I propose to have Source be following interface:
> > > >
> > > > public interface Source {
> > > > /*** BTW, why use long and not Date? ***/
> > > > long getLastModified();
> > > >
> > > > long getContentLength();
> > > >
> > > > public InputSource getInputSource() throws IOException;
> > > >
> > > > String getSystemId();
> > > >
> > > > /*** getInputStream() can be easily implemented as
> > > > getInputSource().getByteStream(). ***/
> > > > }
> > > >
> > > > Based on this, we can define XMLSource as:
> > > >
>
=== message truncated ===
=====
Davanum Srinivas, JNI-FAQ Manager
http://www.jGuru.com/faq/JNI
__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
