On 11/25/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > Simon Kitching wrote: > > You may find difficulties trying to duplicate the general concept of > > Digester in javascript. I tried to do it in Ruby, and found that it > > doesn't fit terribly well with dynamically-typed languages. Quite a lot > > of Digester depends upon the ability to perform reflection upon the > > object on the top of the stack to determine what its properties are, and > > what types they have. This information just isn't available in Ruby, nor > > in Javascript. Some kind of "type declaration" framework (eg something > > like java's BeanInfo descriptors) is really needed, I think, to provide > > the info that Java classes give by default. I got stuck on this with the > > Ruby port, and then got distracted by other stuff. > > Hmm... interesting thought, but I actually would expect the > loosely-typed nature of Javascript to make it *easier*... > > I mean, let's say we have an object in Javascript, and we want to do the > equivalent of a setProperties() Digester rule... we'll have the same > requirement as with usual Digester in terms of it following the javabean > spec, so we know there's going to be a setXXX method for a given > attribute.
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. 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. But, there's no concern about whether the called setter accepts a > compatible type because there really are no types to worry about, so > setting a string is the same as setting an int. > > Well, that is, it's the same *as far as digester goes*... Obviously, if > a Javascript function is expecting an object reference of a particular > type and it gets a number instead, just as an example, I'd expect code > to be blowing up left anr right. But, I'm not going to try and enforce > any kind of type safety on Javascript, so I would leave such concerns to > the app developer. Your suggestion about something like BeanInfo is an > interesting one, and might actually provide some degree of type safety, > in a sense. I'll keep that in mind for sure. > > > I don't mean to discourage you from attempting this, just give warning > > that a 1:1 translation of Digester to a dynamically-typed language may > > not be possible. > > Oh, it may not be possible for any number of reasons :) I don't take it > as discouragement at all because I'm *sure* there will be problems that > I'll face as I try to do it that I can't even imagine now (I'm all but > sure I'm going to at least try to get the basics to work). > > > And of course if Digester is being reimplemented then that's a good > > chance to clean things up quite a bit. Digester2 may be a good starting > > point, or the ruby stuff at rubyforge: > > http://rubyforge.org/projects/xmldigester/ > > I think I'd be more inclined to try and get the current Digester > converted, or maybe more precisely I should say emulate what it does to > some limited degree, if for no other reason than it's a more known > quantity for me. I'm no expert at Digester by any stretch, but I think > I know it well enough to try. We'll see ;) 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. > Regards, > > > > Simon > > Frank Craig
