The pattern list also recommends serializer. arkin
Scott Boag/CAM/Lotus wrote: > > > 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 -- ____________________________________________________________ Assaf Arkin [EMAIL PROTECTED] CTO http://www.exoffice.com Exoffice, The ExoLab Company tel: (650) 259-9796
