On 11/26/05, Frank W. Zammetti <[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. ;-) 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. It would also eliminate the possibility of invoking constructors, or in fact using anything other than the built in types (scarce as they are), as the target of a Digester parse. 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. 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. > 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 :) 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. 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. ;) 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. Just a couple of thoughts off the top of my head. -- Martin Cooper > Craig > > Frank > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
