Re: [Springframework-developer] XMLC Support

[Juergen H. <ju...@in...>]

Rod, everybody,

Please have another look at the code example I gave: It is really simple and
straightforward, with 5 lines of rendering code - and no setup hassle,
because XMLCContext.getContext(servletContext) does the job. I believe that
we don't need to ship dedicated integration code for this. AbstractView is
essentially all that is needed for a pretty convenient XMLC-based view
implementation...

To reiterate: All that would be left of the XMLC support is a single
AbstractXmlcView class with about 20 lines of code. No separate startup
classes or anything else needed, so a single thin abstract base class is all
we could provide. And that base class doesn't really do a lot; a direct
subclass of AbstractView is perfectly feasible too. Effectively, if an
AbstractXmlcView subclass sets custom output options and builds the
XMLObject, it isn't really simpler than a direct AbstractView subclass that
would look as follows:

public abstract class MyXmlcView extends AbstractView {

  protected void renderMergedOutputModel(
      Map model, HttpServletRequest request, HttpServletResponse response)
      throws Exception {

    XMLCContext xmlcContext = XMLCContext.getContext(getServletContext());

    OutputOptions oo = new OutputOptions();
    // configure XMLC output options

    XMLObject xo = ...;  // create the XMLObject from the model

    response.setContentType(...);
    this.xmlcContext.writeDOM(request, response, oo, xo);
  }
}

Furthermore, XMLC is not really a mainstream technology. This is arguably
not even a candidate for a separate Spring core module (and a "module" with
a single 20-line abstract class would look a bit odd anyway). Of course,
people use a lot of third-party tools with Spring out there: but we don't
need to provide explicit integration code if direct usage of a tool is
simple and straightforward anyway. I believe that a simple recipe should be
sufficient in such a case.

Furthermore, I'm still convinced that our
spring-framework-1.2-with-dependencies download should be self-contained and
fully buildable. I've even put extra effort in to make sure that rebuilding
on JDK 1.4 still works, despite our new JDK 1.5 annotation support. If we
include an AbstractXmlcView class but don't include the XMLC jars, this is
not gonna work anymore. I strongly feel that this isn't worth it.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rod Johnson
Sent: Saturday, March 19, 2005 11:57 AM
To: spr...@li...
Subject: Re: [Springframework-developer] XMLC Support


Colin Sampaleanu wrote:
> I agree. Personally, I think XMLC is somewhat of a dying or dead
> technology... I would rather not add it to the core now, and perhaps for
> 1.3 when we move to more modular structure, we might revisit it as an
> optional download...
There have been numerous requests for support. (Mainly to me offline.)

I'm not 100% convinced that a recipe is adequate replacement. What if we
keep the code, but don't ship the (ridiculously large) XMLC JARs in a
download? So Spring builds (and the XMLC JARs are in CVS) but can't be
used with XMLC without the separate download from the XMLC site.



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer