Regarding the concern for too many changes or compatibility issues, I have 
two comments:

1.  The install base of Mav users seems small at this time which talks to 
the size of the impact.

2.  All you're suggesting is a slightly revised mav.xml file -- All this 
means to me is a few minutes typing and it'll be behind me.

So, I wouldn't worry about these issues.  Full stream ahead!  (If you want 
to do something nice, I would limit it to forcing an error if the new 
version reads an old-style xml file.)

Dan

PS.  Does it make sense to consider the capability of transforming xml with 
dvsl to html, then through velocity in this step?


At 01:19 AM 4/26/02 -0700, Jeff Schnitzer wrote:
>I really like the fop view, but I think it makes more sense as a
>transform... and of course, this screams out the need for being able to
>hook up multiple transform types.  I'd love to run my model through a
>couple XSLs to produce formatting objects and then finally through a fop
>transform to produce PDF.
>
>I've been giving a lot of thought to this, and I no longer think it
>would be very hard to do.  However, it would require changing the
>View/ViewFactory and Transform/TransformFactory interfaces in a
>not-backwards-compatible way.
>
>We would probably also want to change the syntax of transform
>definitions from:
>
><view name="blah">
>   <transform>
>     <path value="foo.xsl"/>
>     <path value="bar.xsl"/>
>   </transform>
></view>
>
>..to:
>
><view name="blah">
>   <transform path="foo.xsl"/>
>   <transform path="bar.xsl"/>
></view>
>
>Fortunately, with the Maverick 2.0 ability to define an XSL to transform
>the config file at load time, it would be trivial to automatically adapt
>existing config files.
>
>This would be kind of a lot of API changes in a relatively short period
>of time.  What do you guys think?
>
>Jeff Schnitzer
>[EMAIL PROTECTED]
>
> > -----Original Message-----
> > From: jim moore [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, April 25, 2002 7:21 AM
> > To: [EMAIL PROTECTED]
> > Subject: [Mav-user] fop view for maverick
> >
> > Thought I would let everyone know that I've made a custom view that
>uses
> > fop
> > (http://xml.apache.org/fop/) to
> > generate a pdf.
> >
> > I'm not completely convinced that a view is the approproate choice for
> > this
> > functionality, though, so I'd like to get some feedback. This is
>slightly
> > different than a standard mav view in that its output is inherently
> > non-transformable (the output is binary pdf data).
> >
> > A command using this view currently looks like:
> >
> >     <command name="fop">
> >         <view name="SUCCESS" type="fop" path="foptest.jsp"/>
> >     </command>
> >
> > One nice thing is that path can be any url within this webapp that
> > produces
> > a valid fo file, so it should be able point to another maverick
>command
> > and
> > get its transforms that way (haven't tried this):
> >
> >     <command name="fop" class="someController">
> >         <view name="pdf" type="fop" path="foptest.m"/>
> >         <view name="html">
> >             <transform>
> >                 <path value="raw.xsl"/>
> >                 <path value="to-html.xsl"/>
> >             </transform>
> >         </view>
> >     </command>
> >
> >     <command name="foptest">
> >         <view name="SUCCESS">
> >             <transform>
> >                 <path value="raw.xsl"/>
> >                 <path value="to-pdf.xsl"/>
> >             </transform>
> >         </view>
> >     </command>
> >
> > Its working nicely. I've attached the relevant source files, but the
>war
> > file is 4.5mb (needs fop.jar, batik.jar, etc), so I decided I'd just
> > sending
> > a link to it instead of clogging your inboxes:
> >
> > http://www.scolamoore.com/opt-fop.war
> >
> > Anyway, do you think a custom view is the way to go with this or do
>you
> > think another type is more appropriate? I thought about using a custom
> > command and it seems to make more sense in some ways, but I wasn't
>sure
> > how
> > to go about it--unlike ViewFactory, CommandFactory is a concrete
>class,
> > not
> > an interface.
> >
> > I think the functionality is nice--easy way to get mav to take the
>same
> > data
> > and generate html or a pdf (as in the second example). Using batik,
>svg
> > view
> > should be pretty straightforward to create as well. Just not sure if
>I'm
> > bending the architecture too much.
> >
> > --jim
>
>
>_______________________________________________
>Mav-user mailing list
>[EMAIL PROTECTED]
>https://lists.sourceforge.net/lists/listinfo/mav-user


_______________________________________________
Mav-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mav-user

Reply via email to