cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <d...@yahoo.com>
Subject Re: [C2 proposal] Alternative to XSP
Date Wed, 29 Aug 2001 10:39:45 GMT
Joerg,

Sorry for the delay in replying to your e-mail. I really like the mapping between OO space
and XML
space. For obvious reasons we cannot get rid of XSP....But we can adopt your approach to some
extent. Have you thought about XSPlets to implement LogicSheets? This is more like the Tag
Library
approach in JSP (http://www.onjava.com/pub/a/onjava/2000/12/15/jsp_custom_tags.html)

Thanks,
dims

--- Joerg Henne <j.henne@levigo.de> wrote:
> Hi,
> 
> we all know and like XSP. However, we also know quite a few of its problems.
> Therefore I'd like to propose an alternative to XSP which may be, in many
> cases, a viable and much easier to use option.
> The basic idea has come up at least once on this list: perform a mapping
> between XML space and OO space like this:
> 
> - map an XML namespace onto a class which implements certain interfaces
> - map XML element names within the namespace onto method names
> - pass attributes and children of the mapped element to the method.
> 
> This mapping can either be performed in a generator or a transformer. Although
> the current implementation only supports the generator option, it already
> features a separation of the processing functionality into a separate class
> which makes the implementation of the transformer quite trivial.
> 
> --- The implementation in detail:
> 
> As the classes onto which the XML namespaces are mapped act as delegates in
> the production of XML fragments, they have been called "SAXLets".
> Consequently, the generator is called "SAXLetGenerator". The SAXLetGenerator
> uses a SAXLetProcessor as a delegate for the processing.
> 
> The SAXLets must be implementations of avalon Components with an additional
> interface SAXLet. The SAXLet interface is currently only a marker-interface
> and it has to be seen, if it makes sense to get rid of it in the future.
> 
> SAXLets may implement any of the Avalon lifestyle and life-cycle interfaces to
> control their management and two more interfaces to control their
> configuration:
> - SAXLets implementing XMLProducer will be passed a reference to an
> XMLConsumer
> - SAXLets implementing SitemapModelComponent will be set up like other
> SitemapModelComponents
> During one processing session, only on instance of each SAXLet will be created
> (i.e. retrieved from the ComponentSelector).
> 
> The mapping of element names to method names is subject to the following
> rules:
> - some-element becomes someElement
> - ELEMENT becomes eLEMENT
> The mapping is currently far from being fool-proof and probably has to be
> improved. Methody may be declared without parameters, or as takin an Avalon
> Configuration. In the latter case, the SAXLet processor will pass attributes
> and children of the mapped element to the method in the form of the
> Configuration.
> 
> It's quite obvoius that the SAXLetProcessor uses reflection to lookup and
> invoke the SAXLet methods. Now, I know your qualms about reflection, however,
> I've come to the comclusion that reflection is quite "fast enough":
> - It's the lookup of the method which takes a huge about of time. The
> invocation using Method.invoke() is much faster. Therefore the implementation
> caches the looked-up methods.
> - Benchmarks show, that dynamic invocation is (sxcluding the lookup) still
> about 30 times slower (on JDK 1.3) than static invocation. However, to put
> this into perspective, I've found my machine (900MHz, intel) to take roughly
> 1us per dynamic invocation. Or, in other words, if a page contains 10 SAXLet
> elements, the machine will spend about 10s for 1M-hits on the dynamic
> invocation. I think that's a reasonable figure.
> 
> Methods may produce output three ways:
> - A method may return an scalar Object. In this case the Object will be
> converted to String and, wrapped in an element of the same name as the
> invoking element, and sent down the pipeline.
> - A method may return an array of Objects. This is the same as the scalar
> case, just that ther will be an element with content for each array element.
> - A method may produce SAX events on it's own. In this case the SAXLet must
> implement XMLProducer, so that the reference to the consumer is available. The
> XML events will be filtered through a XMLFragmentCompleter (a new utility
> class) which makes sure that the XML is well-formed even in the case of
> premature returns.
> 
> Excetions thrown by the SAXLet methods are caught, logged, and re-trown
> wrapped in SAXExceptions.
> 
> The implementation comes with a very simple example, the RequestSAXLet, which
> re-implements the functionality of the request logicsheet as a SAXLet. The
> sample has ist's own sub-sitemap, the mounting of the sub-sitemap is up to
> you.
> 
> --- Future stuff and RT
> 
> Obviously, XSP can do a few things that SAXLets can't do, e.g. iteration and
> conditional processing of the input. However, one could argue that the need
> for iteration or conditional processing is an indication for a possible mixing
> of concerns. On the other hand, at least iteration and conditionals could be
> implemented, albeit in a less natural way than the simple delegation of the
> XML production.
> 
> Currently, the generator does not support caching. However, SAXLets could very
> well implement Cacheable so that the cacheable descision could be delegated to
> the SAXLets. We intend to add this RSN.
> 
> An additional performance improvement for the Generator can be achieved by
> caching the input events together with the references to the SAXLets and their
> methods, in order to get rid of the parsing of the input and lookup of the
> namespaces that is currently necessary.
> 
> --- 
> 
> I suppose that some of you will hate the SAXLet approach as it is quite
> incompatible with XSP and breaks all the current value-added functionality
> (logicsheets). But please let your comments roll in. 
> 
> Joerg Henne

> ATTACHMENT part 2 application/x-zip-compressed name=saxlet.zip
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org


=====
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message