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:[EMAIL PROTECTED]]
> Sent: Tuesday, June 04, 2002 4:19 PM
> To: Jakarta Commons Developers List
> Cc: [EMAIL PROTECTED];
> [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; 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 [EMAIL PROTECTED]
>
>
> 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 [EMAIL PROTECTED]
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:commons-dev-> [EMAIL PROTECTED]>
> For
> additional commands,
> e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
