commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew C. Oliver" <a...@superlinksoftware.com>
Subject Re: [Morphos] Proposal for new interface
Date Fri, 06 Sep 2002 12:37:21 GMT
>
> I'd say, let's ditch Locator and have simply URLS up front for 
> Morphos.java.
> And remember that Morphers must Morph stuff, not identify and locate 
> stuff.
>
> URL = UR*Locator*   ;-)


Let someone else LOCATE.  Just take the *stream* and assume someone 
located whatever
in advance.

>>
>> I'm not sure its a good idea to do in the first place.  Or rather 
>> you're trading one complexity for another.   Look at some of the 
>> existing elementprocessor stuff.  There are times when to fit to the 
>> model a call to the parent and sometimes grandparent is necessary. 
>
>
> Ok, but this has nothing to do with the first part of the "stateless" 
> thing, ie atomic morph method.
> So we are looking at the other thing, ok.

Explain what you mean by it.

>
>> I'm not sure this can be solved in a completely stateless manner. You 
>> can borrow an AWT event model idea and combine it with the builder 
>> pattern and build a model but you must be imminently predictive. 
>> Meaning you'd need to stuff the upstream data into the "buildee" in 
>> advance.  Meaning you must "know". 
>
>
> Ah, ok, I get it.
> You mean that in the "vertical" example, you must retain the internal 
> state between SAX events. Hmmm, you are right.
>
> Which means that only in the first case I can be stateless (inside 
> each Morpher) between calls.

Oh okay I think I get it.  Thats fine.

>
>> Thats kinda icky.  So ensure the tradeoff here between object 
>> instantiations is worth the tradeoff. 
>
>
> Ok, you are right.
> SAX basically "verticalizes" the processing and combines stages in a 
> single stage with many phases that all need to keep their internal 
> state between invocations :-/
>
> So ok, it really seems that SAX pipelines must have stateful Morphers, 
> because they do not perform it all in a method but have multiple 
> method invocations.
>
> So I guess that SAX pipelines will always have to be treated atomically.

eh?

>
>> (example kinda sorta:
>> http://jakarta.apache.org/poi/javadocs/javasrc/org/apache/poi/hssf/dev/EFHSSF_java.html#EFHSSF

>> -
>> Imagine SAX as the source instead of a binary file and you see what I 
>> mean.  But its a tradeoff as you can see.  I MUST know in advance.  
>> This example is a flattened version but easy to read.)
>
>
> Yes, you are right.
>
> Ok, so here is the new possibility:
>
>    *'''Object''': the information
>    *'''Morpher''': it acts on the information
>    *'''MorpherPipeline''': the manager of the flow of the morph of the 
> Object to an Object via Morphers.
>
>    interface Morpher
>    {
>        morph(Object input,
>              Object output,
>              Notifier notifier
>              Context context)
>    }
>
> The notifier is an "ErrorHandler".
> We can use ErrorHandler from other packages if you prefer.
>
> Context is about runtime configuration info.
> We can use Properties or Map instead.
>
>    interface Morpher
>    {
>        morph(Object input,
>              Object output,
>              ErrorHandler eh
>              Map parameters)
>
>        setConfigutarion(Map conf){
>        }
>    }
>
> and
>
>   abstract class SimpleMorpher
>   {
>        morph(Object input,
>              Object output){
>
>           morph(input,
>                 output,
>                 new nullErrorHandler,
>                 new HashMap();
>        }
>
>        setConfigutarion(Map conf){
>        }
>
>   }
>
With this we also need:

boolean validate(Object input, Object output) {
   boolean retval=false;
   if (input instanceof InputStream && Output instanceof OutputStream) {
       retval = true;
   }
   return retval;
}

and perhaps

Class getInputType()

Class getOutputType()

or some way of figuring out "what does this thing do".  

-Andy


--
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