Marc,
yep, this is surely one way of going about it, but I personally was
looking more into either
- overloading the call to the actual write() by adding an optional map of
parameters to be applied on the transformer just before the transformation
is started...
Again, this is the constraints of having the Transformer be lazy initialized
I think. The write method should be resetting the transformer, setting
parameters, resetting the source, but not recompiling the stylesheet. If
you want a different stylesheet, that's where the line is drawn on creating
a
new TransformRepresentation instance I think.
(that and setting output-parameters seems like a useful thing to have)
Sure.
- having some convention on upgrading URI-request-parameters to be applied
as xslt parameters
Bordering on genius.
Good point. Looking at the available JAXP input-sources I think it would
end at having support for streams, sax and dom, no?
Yea, this class should really just be a light wrapper to JAXP with some
restlet
sugar.
I think the goal should be to expose as few operations as possible that
still cover the bulk of common use cases. I rarely use SAX so I have
yeah, but of course this depends on the scope you are taking: the "bulk of
common use cases" of restlet (scoping all restlet based projects out
there) might very well not include xslt whatsoever
Sorry, I did not imply restlet use cases but transformation use cases.
applying your rule to the extreme would suggest removing what we already
have and maybe just list it as a sample?
little exposure to this particular case. As I mentioned before, if we
can keep the user from having to pull out JAXP code for anything but
fringe scenarios AND still not bloat the class with JAXP wrapper code,
that is best.
IMHO the restlet user is a programmer. If such person thinks he needs
xslt in his system, it probably is because he already knows xslt, or at
least will benefit from learning it anyway, no?
I agree the user is the developer. This is an API after all and I think this
concept is critical to good API design. It certainly helps adoption if you
make it easy for the developer. When I mean easy I mean we here as people
working on the API have spent enough time to know the existing JAXP model,
existing uses of that model, and quite frankly a knowledge of xslt, xpath
and maybe even xquery would help. I know xslt. I know JAXP too. Other apis
that say they do transformations will not then force you to whip out the
JAXP javadocs to create some bridge code everytime. I'm not saying wrap the
entire JAXP library, just facillitate common transformation use scenarios.
From that angle, I'm really fundamentally reconsidering how xslt
transformations are currently added into restlet. So maybe we really
should do an effort of listing the use cases?
This ties in with above. I'll see if I can make a list from the pure xslt
and DOM standpoint.
Maybe someone could explain the backward compatability issues of this
class, because frankly, it was broken, badly, so who has been using it?
I assume documentation could help us out here quite a bit.
On the other hand: I think the current patch in issue 377 (have you tested
it?) is fixing the include/import/document issues without changing the
public interface: so I think that accounts for proper backwards
compatibility (unless you want to _keep_ support for the broken way of
working?)
As for the more fundamental approach and rethinking of xslt (and sax
pipelining in my case) I would suggest to put this in a new package all
together, how the one fades in and the other fades out (period of
deprecation) is then just a matter of being considerate enough.
I haven't had time to look at aspects of the recent changes. It's a fairly
complex arena so I think the first agenda is to list use cases then right
the test cases for those use cases. I think using real data from a file and
not inline test data is appropriate. Then examine what can be salvaged, what
is not intuitive, and what works with the existing class. This is bad timing
on my part though as I have no time to fiddle with this until late next week
sometime, I guess I'm just wanting to get my two cents in before more
changes happen.
As far as the TwoStep View Pattern, I essentially am doing the same thing.
If you look at my sample code for how I would use TransformRepresentation in
the Resource.getRepresentation method. I create a generic xml wrapper tag
(I'm not conforming to any schema), and then I turn any domain POJOs I might
need to compose my view into xml (via XStream), attach the wrapper tag's
closing tag, and send it off to the transformer. No need to see JAXP code.
The stylesheet I give to the TransformRep has xsl templates that match on
the POJOs, it also imports a skeleton framework of html. There is a skeleton
xslt stylesheet that gets xsl:imported that handles the basic html
structure, and the skeleton of course does half a dozen xsl:includes which
refer to page design stuff like headers, footers, navbars,etc.
XSLT2.0 with the Saxon engine is so powerful, it's hard to argue other
templating libraries once you break the learning curve barrier on xslt. It
will even handle POJOs directly if you just pass them as parameters. This
is probably the reason I don't look to restlets to get involved too much in
my view. For the MVC aspect, I leave the controller part to the appropriate
Resource subclass because regardless of the Representation I will give (xml
or html), I am usually going to generate the same POJOs that identify the
Resource for what it is. This I didn't show in my code example, simply for
verbosity sake.
Joe.
