commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank W. Zammetti" <>
Subject Re: Client-side Digester?
Date Sat, 26 Nov 2005 15:26:44 GMT
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.

But, then that would seem to eliminate the possibility of parent-child 
relationships since that depends on a setter in a bean adding another 
bean to an internal collection, and I don't think that's the kind of 
thing one would want to happen automagically, assuming it could.

There may well be the opportunity for new rules in a dynamically-typed 
language that only make sense there.

> Note that there's no type safety issue (at least at this point) either 
> ... JavaScript fields don't have an innate type, so there is nothing you 
> can do that corresponds to Java's reflection to say "what should I 
> convert this string attribute value to before I save it."  Instead, 
> conversion happens on usage of the corresponding field value.

Yep, that was exactly my point too :)  Although, the conversion could be 
built-in to the setter by the prototype designer, but that's outside the 
scope of what Digester would do.

> Personally, I think trying to do a literal conversion would be 
> artificially limiting in the world of a dynamic language.  Something 
> that emulated the spirit, but not the detailed semantics, might be more 
> what you are after.

Yes, I agree.  To me, there are a few Digester rules that are pretty 
much must-haves... ObjectCreateRule, SetPropertiesRule, SetTopRule and 
CallMethodRule immediately come to mind... there may be some others, but 
I think the rest are somewhat less important (day 2-type things anyway). 
  It doesn't have to (and maybe shouldn't, and in some cases probably 
can't) be an exact replica of Digester, but the underlying model of "set 
some processing rules, hand it an XML document and fire those rules when 
appropriate" is the key point I think.  There rest is just details :)

> Craig


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message