commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank W. Zammetti" <fzli...@omnytex.com>
Subject Re: Client-side Digester?
Date Sat, 26 Nov 2005 18:39:24 GMT
Martin Cooper wrote:
> 
> 
> On 11/26/05, *Frank W. Zammetti* <fzlists@omnytex.com 
> <mailto:fzlists@omnytex.com>> 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

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message