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.
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 ;)
> Regards,
>
> Simon
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
|