Personally, I think it makes more sense to have it as a static method,
as the XMLEncoder is not a state-bearing object.. I think having to
construct an object implies something about its lifecycle - which in
this case would be misleading.
Using a static does make it a little more difficult to swap out the
encoder implementation, though... maybe we could use a singleton
pattern for the encoder? Split XMLEncoder into an interface and
implementation.. something like this could be used to override the
pattern:
Configuration.setAlternateXMLEncoder(new MyXMLEncoder());
Then...
XMLEncoder.getXMLEncoder().encodeList(), etc...
Of course, once you start talking about providing alternate
implementations, you start to wonder why the word "XML" is in there :)
So, maybe there's an Encoder interface with an XMLEncoder
implementation. Either way, it would be a fairly quick patch and
balances the concerns nicely I think.
Cris
On 12/3/05, Kevin Menard <kmenar..ervprise.com> wrote:
> On Mon, 28 Nov 2005 06:30:26 -0500, Andrus Adamchik
> <andru..bjectstyle.org> wrote:
>
> >
> > On Nov 26, 2005, at 1:02 AM, Cris Daniluk wrote:
> >
> >> Is XMLEncoder.encodeList() correctly marked as deprecated? If so, what
> >> should be used in its place?
> >
> > Yes, this static method is redundant. You can use this instead:
> >
> > new XMLEncoder().encode(rootXmlTag, objects);
>
> Sorry, I've been extremely busy trying to get thesis work done. Anyway,
> time for me to chime in.
>
> The original static method was indeed "redundant", but it was provided
> because it was intuitively named and represented a very common action.
> John and I had worked through the API a bit and decided it really was a
> nice thing to have.
>
> I really would like to see it undeprecated. There are some other API
> changes that I'm not sure really make sense either (e.g., having a public
> nodeToString() method). Or rather, they may make sense at some level, but
> I don't really find them to user-friendly. It may just be that I'm
> attached to the original API, having come up with it, so any rationale for
> the changes would be greatly appreciated.
>
> --
> Kevin
>
>
This archive was generated by hypermail 2.0.0 : Sun Dec 04 2005 - 18:28:55 EST