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 03:42:15 GMT
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:

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


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

View raw message