Just a quick update, I've actually had some time yesterday and today to
work on this idea, and I'm happy to say I've gotten a decent amount of
work done.
At present I have JSDigester (as I've taken to calling it) with three
rules implemented (ObjectCreate, SetProperties and BeanPropertySetter).
I need to complete one or two more rules to complete my first-pass
test harness, which is an object graph representing a movie collection.
Once I get that done, as soon as tomorrow I'm hoping, I was thinking of
posting it for folks to have a look at and see if anyone thinks its
worth continuing on. I know I'm going to be using it either way in an
upcoming project, but frankly once its at the point I need it to be at,
my only incentive to take it further would be if there was any interest
in possibly bringing it into Commons in some fashion, so I'm fishing to
see if there is any interest in that :)
Incidentally, I also threw together what looks a bit like a Javascript
implementation of JCL for this :)
Frank
Frank W. Zammetti wrote:
Martin Cooper wrote:
On 11/26/05, *Frank W. Zammetti* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Craig McClanahan wrote:
> If you're using JavaScript, why would you restrict yourself to
that
> (even if you *could* figure it out)? You can dynamically
add fields to
> a JavaScript object, so an analog of the set properties rule
would just
> define a field on the object for every attribute in the XML
element.
That's a good point... that thinking leads to a path where instead of
populating pre-made objects from a parsed XML document, the objects
themselves are created on-the-fly. Or more precisely, you
wouldn't have
to deal in pre-defefined objects.
At that point, you've just reduced the problem to parsing XML in
JavaScript, which is a solved problem. ;-)
Haha, in a way, yeah :)
It's more the event-oriented model of Digester though that I don't think
there's an analogy for yet in Javascript... not without knowing
something about the DOM structure before-hand anyway.
Putting the conversion in the setter would be unfortunate, since
you've then embedded knowledge in that setter that would have
otherwise been confined to the Digester rules.
I would agree if we were talking about a 1:1 conversion of Digester...
but as Craig previously pointed out, it's probably not possible, or even
desireable, to try to do a 1:1 conversion. One could make the argument
with normal Digester that things would be a lot simpler if all you ever
had was setXXX(Object), and the object itself took care of type
conversions as it probably knows what it needs better than Digester
does... in Javascript you almost have no choice but to think of it that
way :)
Note that ObjectCreateRule is going to be, um, "interesting", for a
couple of reasons. Probably the trickiest thing is going to be finding
the class that you need to instantiate, since you won't have Java's
class loading mechanisms to help you out.
Excellent point. It might be enough to simply state that any class to
be instantiated by Digester has to be available in page-scope before the
parse() method is called, and leave it at that. The developer will have
to include the correct import or include or whatever they do. But this
is clearly something that needs to be thought through.
> You're going to need to
implement some kind of dynamic loading scheme, and the classes you
instantiate are going to have to play by the rules you define for
that. (BTW, Dojo has one you could use. ;)
Yep, that's one answer, and seeing what Dojo offers would be a good idea
in that case.
> Also, many uses of (Java) Digester
take advantage of zero-arg constructors, a la JavaBeans, but most
classes in JavaScript don't have such things, so you'll need to be
passing in parameters to those constructors.
But, IIRC, that is a requirement of the spec, right? So, if there is a
basic assumption that any class Digester will work with follows the
spec, that should take care of it.
Just a couple of thoughts off the top of my head.
Yeah, it'll definitely be an interesting road :) I probably won't try
and start until Monday, but I'm actually looking forward to seeing what
I can put together next week.
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
