commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Moore" <tmo...@blackboard.com>
Subject RE: [Morphos] Java data morphing package
Date Tue, 04 Jun 2002 21:44:44 GMT
I've been thinking about this kind of thing myself lately.  One thing I
realized early on is that you need at least two different interfaces,
because sometimes you'll need to transform to a new instance of an
immutable object, and other times you'll need to transform to an
existing object.  In other words, some Morphers need to have this:

     void morph(Object input, Object output) throws MorphException.
IOException;

for reasons that you state, but others need to have this:

     Object morph(Object input) throws MorphException. IOException;

for example, a Morpher that translates some object to a String.

Most of the time, you probably won't be able to do both types, so you
need two different interfaces. :-\

-- 
Tim Moore / Blackboard Inc. / Software Engineer
1899 L Street, NW / 5th Floor / Washington, DC 20036
Phone 202-463-4860 ext. 258 / Fax 202-463-4863


> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org] 
> Sent: Tuesday, June 04, 2002 4:19 PM
> To: Jakarta Commons Developers List
> Cc: fop-dev@xml.apache.org; 
> krysalis-developers@lists.sourceforge.net; 
> cocoon-dev@xml.apache.org; poi-dev@jakarta.apache.org; Avalon 
> Developers List
> Subject: [Morphos] Java data morphing package
> 
> 
> *CROSSPOST * PROPOSAL OF PARTICIPATION *
> 
> Welcome to the first public discussion about project Morphos.
> 
> This message is being posted to many lists because it has the 
> aim of solving a common need.
> 
> The discussion will continue, for those interested, on the 
> jakarta commons mailing list. To subscribe, send an empty 
> mail to commons-dev-subscribe@jakarta.apache.org
> 
> 
> What is Morphos?
> -----------------------------
> Morphos will be a Java Api and implementation for 
> transforming data, in any form it may be: xml, streams, objects.
> 
> It focuses on the API and framework, and demands 
> implementation to other projects-modules wherever possible.
> 
> 
> Why Morphos?
> -----------------------------
> Morphos starts from a need around a community of developers, 
> with an initial charter committed in Jakarta Commons Sandbox. 
> Before anything got committed, it has slightly evolved from 
> being tied initially to XML. Here is the old charter 
> (http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/morphos
> /PROPOSAL.txt?
> rev=HEAD&content-type=text/vnd.viewcvs-markup).
> 
> This mail illustrates the latest status of the private 
> discussions, and a is the start of the public one.
> 
> Currently there are many projects that need or would benefit 
> from a generic transformation API:
> 
>   - Jakarta POI -
> 
>       OLE<->XML transformations
> 
>   - Cocoon -
> 
>         using a single api and a contrib section for the
>         loads of components it now hosts in the core
> 
>   - FOP -
> 
>         redesigning the main interface for FO<->PDF,MIF,...etc
> 
>    - Krysalis Wings -
> 
>          transforming chart XML format to SVG or image formats
> 
> Other projects that can be wrapped round this api are numerous:
>   - Batik (image transcoders)
>   - Xerces-Xalan
>   - Avalon Excalibur Converter
>   - Commons Digester
>   - Jakarta-commons-sandbox Jelly
>   -  etc...
> 
> A componentization of the transformation process can help 
> reuse and minimize code duplication.
> 
> 
> What does it do?
> -----------------------------
>  Morphos should simply do:
> 
>  data  --> morphos ---> data
> 
>  Data can be:
>    - stream
>    - events
>    - objects
> 
> I don't see other basic generic "data" types, since files and 
> such can become streams and viceversa without any format or 
> form conversion. I want a *very* simple api, with no 
> duplicated methods. IE having get(Stream) and get(File) is 
> not necessary IMO, since they do the same thing. The main API 
> must be very simple. We can always add helper classes.
> 
>  I took look at these APIs:
>  - Jaxp
>  - Batik Transcoder
> 
> Jaxp:
> Baised towards xml (more in package names than in fact). 
> Already has a bad track on version using (the infamious 
> "endorsed" dir and param). Uses static method for getting the 
> transformer.
> 
> Batik Transcoder:
> Good API but it's source can contain a Reader, InputStream, 
> Contenthandler, etc, so it's tied to these. No support for 
> pipelining of transcodes.
> 
> Ok, but in Concrete?
> ------------------------------
> 
> Here is the proposed API, all in package org.apache.commons.morphos:
> 
> /**
>  * The interface that is implemented by classes that morph.
>  * It uses two params and not a return value to make it usable with
>  * event based Objects (contenthandlers).
>  * Parameters are key pairs, used to configure the Morpher.
>  * Events in the Morpher are notified by registering a 
> listener.  */ public interface Morpher {
> 
>     void morph(Object input, Object output) throws 
> MorphException. IOException;
> 
>     void addParameter(String paramName, String paramValue);
>     String getParameter(String paramName);
>     void remove Parameter(String paramName);
>     String[] getParameterNames();
>     String[] getParameterValues();
> 
>     void addNotificationListener(NotificationListener nl);
>     void removeNotificationListener(NotificationListener nl);
>     void clearNotificationListeners();
> 
> }
> 
> /**
>  * A Morpher made out of a sequence of morphers.
>  */
> 
> public interface MorpherPipeline extends Morpher {
> 
>     void addStage(Morpher nextMorpher);
> 
> }
> 
> 
> 
> /**
>  * The Factory for Morphers.
>  * There is a getDefaultFactory method for easy use.
>  * Used in frameworks it's better not to use it and rely on
>  * services that give the proper MorpherFactory.
>  */
> public abstract MorpherFactory  {
> 
>     Morpher getMorpher(DataType inputType, DataType outputType);
>     Morpher getMorpher(name);
> 
>     Morpher getPreparedMorpher(DataType inputType, DataType 
> outputType);
>     Morpher getPreparedMorpher(name);
> 
>     static MorpherFactory getDefaultFactory();
> }
> 
> 
> /**
>  * Describes what the format of the data is.
>  * It consists of a mimetype (format) and a dataForm (representation).
>  * For example a gif image file and a jped image file have a 
> different mimetype but same dataform (file).
>  * An SVG file and an SVG DOM in memory have same mimetype 
> but different dataform.  */ public interface DataType {
> 
>     void setMimeType(String mimetype);
>     void setDataForm(String format);
> 
>     String getMimeType();
>     String getDataForm();
> 
> }
> 
> 
> --
> Nicola Ken Barozzi                   nicolaken@apache.org
>             - verba volant, scripta manent -
>    (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> For 
> additional commands, 
> e-mail: <mailto:commons-dev-help@jakarta.apache.org>
> 
> 

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message