> b) If XML serialization support for beans comes along, and I know many
> have requested it, this will create a confusion in names
I'm not sure why. It's the same basic process.
> I think printer and parser match, but how about just output? I guess
> formatter is not descriptive enough either. What would be the opposite
> of parse, by the way?
Output is almost OK. I kind of like "formatter" (which is why I named my
classes FormatterListeners).
Stefano, myself, and James Tauber tried to come up with some design
patterns a while ago:
Abstract patterns:
Producer ................... whatever -> memory
Transformer ................ memory -> memory
Pipe ....................... (Transformer)+
Consumer ................... memory -> whatever
Chain ...................... Producer -> Pipe -> Consumer
Pattern implementations:
Parser ..................... stream -> API
Processor .................. API -> API
Formatter .................. API -> areas
Renderer ................... areas -> screen
Serializer ................. memory -> stream
where
API := [SAX | DOM]
areas := memory representation of formatting areas
memory := [API | areas]
so that
A parser is a producer
A processor is a transformer
A formatter is a transformer
A serializer is a consumer
A renderer is a consumer
and name equivalences are
processor = filter
serializer = output-handler = emitter
Notice that "Formatter" is used for the process of formatting to some sort
of area. emitter?
I *really* like the idea of coming up with some sort of design patterns
list that we can all stick to (doing this is Stefano's original idea... so
all credit goes to him). I don't know if the above is it, but I think a
proper vocabulary will help a lot in having clean overall designs that work
with each other and that are understandable.
-scott
Assaf Arkin
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
e.com> cc: (bcc: Scott Boag/CAM/Lotus)
Sent by: Subject: Re: [Proposal] Printer
package
[EMAIL PROTECTED]
office.com
11/15/99 05:11
PM
Please respond
to xerces-dev
> Serialization doesn't have to have anything to do with beans. The fact
> that they used 'serializable' is just an artifact of their
implementation.
a) For me serialization does have to do with beans
b) If XML serialization support for beans comes along, and I know many
have requested it, this will create a confusion in names
> > xmloutput seems redundant, unless we should
> > consider xminput.
>
> I was only using xmloutput because it was similar to xsl:output. I'm not
> in love with either of my suggestions. I just find 'printer' to be
> confusing and not very descriptive.
I think printer and parser match, but how about just output? I guess
formatter is not descriptive enough either. What would be the opposite
of parse, by the way?
arkin
>
> -scott
>
>
> Assaf Arkin
> <[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
> e.com> cc:
[email protected], (bcc: Scott Boag/CAM/Lotus)
> Sent by: Subject: Re: [Proposal]
Printer package
> [EMAIL PROTECTED]
> office.com
>
>
> 11/15/99 03:34
> PM
> Please respond
> to xerces-dev
>
>
>
> > I don't think this is a good assumption. In my view we are making
> > components, which should be standalone. For instance, Xalan is useable
> > without any parser at all, though this tends to be an unlikely
scenario.
> > It is certainly designed not to have tight coupling with Xerces.
>
> I took that into account, I can certainly imagine someone using Xalan
> without Xerces and then the dependency becomes a problem. The design
> right now is that you can download the printers separately of any given
> DOM and use them.
>
> Possibly:
>
> * Xerces only distribution + printers/utility classes
>
> * Xalaon only distribution + printers/utility classes
>
> * Combined distribution
>
> (Yes, I don't like this approach, am looking for better solutions)
>
> > > or can obtain the
> > > printer/utility packages separately.
> >
> > Not sure what you mean by this.
>
> Download a separate package containing just the code under
> org.apache.xerces.printer and use it. You need DOM and SAX in the path,
> but you don't need the parser.
>
> > What do you think about changing the package name from .printer to
> > .serializer or .xmloutput or the like?
>
> I like printer better ;-) xmloutput seems redundant, unless we should
> consider xminput. serializer is out of the question. If you want to
> really serialize documents that would probably fall under the scope of a
> different product (e.g. how to serialize Beans and not just DOM?)
>
> > We'll also need a raw text output. I can adapt my FormatterToDOM to
use
> > straight SAX, so this won't be a problem.
>
> That's a boring printer, so I left it for last ;-)
>
> arkin
>
> >
> > -scott
>
> --
> ____________________________________________________________
> Assaf Arkin [EMAIL PROTECTED]
> CTO http://www.exoffice.com
> Exoffice, The ExoLab Company tel: (650) 259-9796
--
____________________________________________________________
Assaf Arkin [EMAIL PROTECTED]
CTO http://www.exoffice.com
Exoffice, The ExoLab Company tel: (650) 259-9796
