I agree that a Transform seems to make sense. If we do go the route of
multiple transforms, I think one thing to try to accomplish is full
interoperability between them. Imagine a case where my model is basically a
csv that I am getting from some legacy system:
name, phone, email
jim, 555-555-5555, [EMAIL PROTECTED]
tom, 555-555-5656, [EMAIL PROTECTED]
bill, 555-555-5657, [EMAIL PROTECTED]
I want to transform that to an xml file with jsp, run the resulting xml
through an xsl to convert it to an fo, and then pipe that through fop to
produce a pdf:
<view name="blah">
<transform path="csv.jsp"/>
<transform type="xsl" path="fo.xsl"/>
<transform type="fop"/>
</view>
or maybe this is more appropriate:
<view name="blah" path="csv.jsp">
<transform type="xsl" path="fo.xsl"/>
<transform type="fop"/>
</view>
----- Original Message -----
From: "jim moore" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, April 26, 2002 9:30 AM
Subject: FW: [Mav-user] Heterogenous transforms (and fop)
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] On Behalf Of Jeff
> Schnitzer
> Sent: Friday, April 26, 2002 4:19 AM
> To: [EMAIL PROTECTED]
> Subject: [Mav-user] Heterogenous transforms (and fop)
>
>
> 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
