You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Frank W. Zammetti" <fz...@omnytex.com> on 2005/11/25 16:58:07 UTC
Client-side Digester?
Hope everyone (in the states at least!) is having a good Thanksgiving
weekend (and I hope, like me, that most of you have a 4-day extended
weekend!)
Has any thought been given to, or has any work been done already, to
creating a Javascript-based client-side version of Digester? I'm
starting on a new project soon where I'll potentially have to be doing a
fair amount of client-side XML parsing, and it occurs to me that using
Digester would make my life A LOT easier.
Even if only a subset of functionality was available, I think it would
be a nice thing to have. If this idea HASN'T been explored yet, would
there be any interest in it besides me? I could possibly roll it into
my project as a to-do and get it done.
Thanks!
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Client-side Digester?
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Martin Cooper wrote:
> I was referring more to dojo.xml.Parse than to domUtil. I didn't mean to
> suggest that this would supplant a Digester in JavaScript, but it could
> provide a foundation for such a thing.
Ah, I see. Yep, I can definitely see where it would make things easier.
> By the way, is there more documentation online than the API outline
> ( http://dojotoolkit.org/docs/apis/index.shtml)? That's not telling
> me a
> whole lot, and I'd hate to miss something cool just because I was
> looking in the wrong place :)
>
>
> There are quite a few .rest files in SVN, including two on the XML
> parsing system here:
>
> http://dojotoolkit.org/svn/dojo/trunk/documents/manual/rest/xml
>
> I don't believe these docs are up on the web site yet, so you may have
> to make do with the .rest files for now (which isn't so bad - they're
> even readable without processing). The docs are the focus of the
> upcoming 0.2 drop.
>
> There's also a description on the wiki, here:
>
> http://dojo.jot.com/Parser
Ah, gotta go do some reading :)
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Client-side Digester?
Posted by Martin Cooper <ma...@apache.org>.
On 11/25/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
>
> I can see where the Dojo parsing methods *will* make life easier... but
> in just quickly glancing at the dojo.xml.domUtil methods, it only looks
> like slightly more convenience than doing it myself.
I was referring more to dojo.xml.Parse than to domUtil. I didn't mean to
suggest that this would supplant a Digester in JavaScript, but it could
provide a foundation for such a thing.
By the way, is there more documentation online than the API outline
> (http://dojotoolkit.org/docs/apis/index.shtml)? That's not telling me a
> whole lot, and I'd hate to miss something cool just because I was
> looking in the wrong place :)
There are quite a few .rest files in SVN, including two on the XML parsing
system here:
http://dojotoolkit.org/svn/dojo/trunk/documents/manual/rest/xml
I don't believe these docs are up on the web site yet, so you may have to
make do with the .rest files for now (which isn't so bad - they're even
readable without processing). The docs are the focus of the upcoming 0.2drop.
There's also a description on the wiki, here:
http://dojo.jot.com/Parser
--
Martin Cooper
I've always felt that the Digester rules model, even though I have to
> fight it sometimes to do what I want, is a very powerful approach that
> really does save a great deal of time and effort, and I haven't seen
> anything as truly useful anywhere else. I think duplicating even a
> small subset of that functionality in Javascript is different enough
> from existing options that it might be worth some effort.
>
> Martin Cooper wrote:
> >
> >
> > On 11/25/05, *Frank W. Zammetti* <fzlists@omnytex.com
> > <ma...@omnytex.com>> wrote:
> >
> > Hope everyone (in the states at least!) is having a good
> Thanksgiving
> > weekend (and I hope, like me, that most of you have a 4-day extended
> > weekend!)
> >
> > Has any thought been given to, or has any work been done already, to
> > creating a Javascript-based client-side version of Digester? I'm
> > starting on a new project soon where I'll potentially have to be
> doing a
> > fair amount of client-side XML parsing, and it occurs to me that
> using
> > Digester would make my life A LOT easier.
> >
> >
> > It's not Digester, but you might want to take a look at dojo.xml.Parse
> > at http://dojotoolkit.org. They have robust XML parsing support in
> > there, and I'd hate to see us duplicate all that.
> >
> > --
> > Martin Cooper
> >
> >
> > Even if only a subset of functionality was available, I think it
> would
> > be a nice thing to have. If this idea HASN'T been explored yet,
> would
> > there be any interest in it besides me? I could possibly roll it
> into
> > my project as a to-do and get it done.
> >
> > Thanks!
> >
> > --
> > Frank W. Zammetti
> > Founder and Chief Software Architect
> > Omnytex Technologies
> > http://www.omnytex.com
> > AIM: fzammetti
> > Yahoo: fzammetti
> > MSN: fzammetti@hotmail.com <ma...@hotmail.com>
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > <ma...@jakarta.apache.org>
> >
> >
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> AIM: fzammetti
> Yahoo: fzammetti
> MSN: fzammetti@hotmail.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: Client-side Digester?
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
I can see where the Dojo parsing methods *will* make life easier... but
in just quickly glancing at the dojo.xml.domUtil methods, it only looks
like slightly more convenience than doing it myself.
By the way, is there more documentation online than the API outline
(http://dojotoolkit.org/docs/apis/index.shtml)? That's not telling me a
whole lot, and I'd hate to miss something cool just because I was
looking in the wrong place :)
I've always felt that the Digester rules model, even though I have to
fight it sometimes to do what I want, is a very powerful approach that
really does save a great deal of time and effort, and I haven't seen
anything as truly useful anywhere else. I think duplicating even a
small subset of that functionality in Javascript is different enough
from existing options that it might be worth some effort.
Martin Cooper wrote:
>
>
> On 11/25/05, *Frank W. Zammetti* <fzlists@omnytex.com
> <ma...@omnytex.com>> wrote:
>
> Hope everyone (in the states at least!) is having a good Thanksgiving
> weekend (and I hope, like me, that most of you have a 4-day extended
> weekend!)
>
> Has any thought been given to, or has any work been done already, to
> creating a Javascript-based client-side version of Digester? I'm
> starting on a new project soon where I'll potentially have to be doing a
> fair amount of client-side XML parsing, and it occurs to me that using
> Digester would make my life A LOT easier.
>
>
> It's not Digester, but you might want to take a look at dojo.xml.Parse
> at http://dojotoolkit.org. They have robust XML parsing support in
> there, and I'd hate to see us duplicate all that.
>
> --
> Martin Cooper
>
>
> Even if only a subset of functionality was available, I think it would
> be a nice thing to have. If this idea HASN'T been explored yet, would
> there be any interest in it besides me? I could possibly roll it into
> my project as a to-do and get it done.
>
> Thanks!
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> AIM: fzammetti
> Yahoo: fzammetti
> MSN: fzammetti@hotmail.com <ma...@hotmail.com>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> <ma...@jakarta.apache.org>
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> <ma...@jakarta.apache.org>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Client-side Digester?
Posted by Martin Cooper <ma...@apache.org>.
On 11/25/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
>
> Hope everyone (in the states at least!) is having a good Thanksgiving
> weekend (and I hope, like me, that most of you have a 4-day extended
> weekend!)
>
> Has any thought been given to, or has any work been done already, to
> creating a Javascript-based client-side version of Digester? I'm
> starting on a new project soon where I'll potentially have to be doing a
> fair amount of client-side XML parsing, and it occurs to me that using
> Digester would make my life A LOT easier.
It's not Digester, but you might want to take a look at dojo.xml.Parse at
http://dojotoolkit.org. They have robust XML parsing support in there, and
I'd hate to see us duplicate all that.
--
Martin Cooper
Even if only a subset of functionality was available, I think it would
> be a nice thing to have. If this idea HASN'T been explored yet, would
> there be any interest in it besides me? I could possibly roll it into
> my project as a to-do and get it done.
>
> Thanks!
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> AIM: fzammetti
> Yahoo: fzammetti
> MSN: fzammetti@hotmail.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: Client-side Digester?
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Just a quick update, I've actually had some time yesterday and today to
work on this idea, and I'm happy to say I've gotten a decent amount of
work done.
At present I have JSDigester (as I've taken to calling it) with three
rules implemented (ObjectCreate, SetProperties and BeanPropertySetter).
I need to complete one or two more rules to complete my first-pass
test harness, which is an object graph representing a movie collection.
Once I get that done, as soon as tomorrow I'm hoping, I was thinking of
posting it for folks to have a look at and see if anyone thinks its
worth continuing on. I know I'm going to be using it either way in an
upcoming project, but frankly once its at the point I need it to be at,
my only incentive to take it further would be if there was any interest
in possibly bringing it into Commons in some fashion, so I'm fishing to
see if there is any interest in that :)
Incidentally, I also threw together what looks a bit like a Javascript
implementation of JCL for this :)
Frank
Frank W. Zammetti wrote:
> Martin Cooper wrote:
>
>>
>>
>> On 11/26/05, *Frank W. Zammetti* <fzlists@omnytex.com
>> <ma...@omnytex.com>> 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. ;-)
>
>
> Haha, in a way, yeah :)
>
> It's more the event-oriented model of Digester though that I don't think
> there's an analogy for yet in Javascript... not without knowing
> something about the DOM structure before-hand anyway.
>
>> 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.
>
>
> I would agree if we were talking about a 1:1 conversion of Digester...
> but as Craig previously pointed out, it's probably not possible, or even
> desireable, to try to do a 1:1 conversion. One could make the argument
> with normal Digester that things would be a lot simpler if all you ever
> had was setXXX(Object), and the object itself took care of type
> conversions as it probably knows what it needs better than Digester
> does... in Javascript you almost have no choice but to think of it that
> way :)
>
>> 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.
>
>
> Excellent point. It might be enough to simply state that any class to
> be instantiated by Digester has to be available in page-scope before the
> parse() method is called, and leave it at that. The developer will have
> to include the correct import or include or whatever they do. But this
> is clearly something that needs to be thought through.
>
> > 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. ;)
>
>
> Yep, that's one answer, and seeing what Dojo offers would be a good idea
> in that case.
>
> > 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.
>
>
> But, IIRC, that is a requirement of the spec, right? So, if there is a
> basic assumption that any class Digester will work with follows the
> spec, that should take care of it.
>
>> Just a couple of thoughts off the top of my head.
>
>
> Yeah, it'll definitely be an interesting road :) I probably won't try
> and start until Monday, but I'm actually looking forward to seeing what
> I can put together next week.
>
> Frank
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Client-side Digester?
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Martin Cooper wrote:
>
>
> On 11/26/05, *Frank W. Zammetti* <fzlists@omnytex.com
> <ma...@omnytex.com>> 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. ;-)
Haha, in a way, yeah :)
It's more the event-oriented model of Digester though that I don't think
there's an analogy for yet in Javascript... not without knowing
something about the DOM structure before-hand anyway.
> 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.
I would agree if we were talking about a 1:1 conversion of Digester...
but as Craig previously pointed out, it's probably not possible, or even
desireable, to try to do a 1:1 conversion. One could make the argument
with normal Digester that things would be a lot simpler if all you ever
had was setXXX(Object), and the object itself took care of type
conversions as it probably knows what it needs better than Digester
does... in Javascript you almost have no choice but to think of it that
way :)
> 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.
Excellent point. It might be enough to simply state that any class to
be instantiated by Digester has to be available in page-scope before the
parse() method is called, and leave it at that. The developer will have
to include the correct import or include or whatever they do. But this
is clearly something that needs to be thought through.
> 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. ;)
Yep, that's one answer, and seeing what Dojo offers would be a good idea
in that case.
> 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.
But, IIRC, that is a requirement of the spec, right? So, if there is a
basic assumption that any class Digester will work with follows the
spec, that should take care of it.
> Just a couple of thoughts off the top of my head.
Yeah, it'll definitely be an interesting road :) I probably won't try
and start until Monday, but I'm actually looking forward to seeing what
I can put together next week.
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Client-side Digester?
Posted by Martin Cooper <ma...@apache.org>.
On 11/26/05, Frank W. Zammetti <fz...@omnytex.com> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: Client-side Digester?
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Client-side Digester?
Posted by Craig McClanahan <cr...@apache.org>.
On 11/25/05, Frank W. Zammetti <fz...@omnytex.com> 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
Re: Client-side Digester?
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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
Re: Client-side Digester?
Posted by Simon Kitching <sk...@apache.org>.
Hi Frank,
On Fri, 2005-11-25 at 10:58 -0500, Frank W. Zammetti wrote:
> Has any thought been given to, or has any work been done already, to
> creating a Javascript-based client-side version of Digester? I'm
> starting on a new project soon where I'll potentially have to be doing a
> fair amount of client-side XML parsing, and it occurs to me that using
> Digester would make my life A LOT easier.
>
> Even if only a subset of functionality was available, I think it would
> be a nice thing to have. If this idea HASN'T been explored yet, would
> there be any interest in it besides me? I could possibly roll it into
> my project as a to-do and get it done.
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.
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.
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/
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Client-side Digester?
Posted by Martin Cooper <ma...@apache.org>.
On 11/25/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
>
> Martin Cooper wrote:
> > Yes and no. I do see a place for JavaScript at the ASF, and I do believe
> > we should have a forum - and a community - around that.
>
> Kind of a tangent from my original post, but is there any chance of
> setting up a simple Javascript mailing list under the ASF? Or does it
> need to be tied to a particular project? Such a list I think would get
> quite a bit of traffic, certainly it would be a more on-topic place to
> post many of the questions we currently see on the Struts and Tomcat
> mailing lists (and I'm sure others). And this might serve as a good
> meeting place to discuss further ideas, as you alluded to later on in
> your reply.
This is one of the topics I'd like to discuss at an ApacheCon BOF. AFAIK,
language-specific lists (as opposed to project-specific ones) have been
discouraged in the past, so we need to think through what it is that we want
to accomplish.
> However, when it comes to the fundamentals, IMHO, the Dojo toolkit has
> > an existing and thriving community; they are pulling together the best
> > parts of existing toolkits; and they have a quorum of some of the very
> > smartest JavaScript developers anywhere. I really, really don't want to
> > see the ASF go off and (try to) duplicate all of the awesome work
> > they've done just so that it's under the ASF umbrella.
>
> I for one would agree, if it's duplication of effort simply for the goal
> of having something comperable under the ASF umbrella, I wouldn't think
> that a good idea. But I do think a client-side Digester, even if only a
> small subset of the current Digester, is significantly different enough
> from Dojo (as far as I can see at the moment) and other things that I am
> aware of, that it might be worth doing.
>
> I just noticed your a Dojo committer Martin... I wasn't aware of that.
Technically, yes, but that's more history than reality. To date, I haven't
actually committed anything. ;-) Mostly, I've just helped them with some of
the behind-the-scenes stuff.
--
Martin Cooper
Frank
>
Re: Client-side Digester?
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Martin Cooper wrote:
> Yes and no. I do see a place for JavaScript at the ASF, and I do believe
> we should have a forum - and a community - around that.
Kind of a tangent from my original post, but is there any chance of
setting up a simple Javascript mailing list under the ASF? Or does it
need to be tied to a particular project? Such a list I think would get
quite a bit of traffic, certainly it would be a more on-topic place to
post many of the questions we currently see on the Struts and Tomcat
mailing lists (and I'm sure others). And this might serve as a good
meeting place to discuss further ideas, as you alluded to later on in
your reply.
> However, when it comes to the fundamentals, IMHO, the Dojo toolkit has
> an existing and thriving community; they are pulling together the best
> parts of existing toolkits; and they have a quorum of some of the very
> smartest JavaScript developers anywhere. I really, really don't want to
> see the ASF go off and (try to) duplicate all of the awesome work
> they've done just so that it's under the ASF umbrella.
I for one would agree, if it's duplication of effort simply for the goal
of having something comperable under the ASF umbrella, I wouldn't think
that a good idea. But I do think a client-side Digester, even if only a
small subset of the current Digester, is significantly different enough
from Dojo (as far as I can see at the moment) and other things that I am
aware of, that it might be worth doing.
I just noticed your a Dojo committer Martin... I wasn't aware of that.
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Client-side Digester?
Posted by Martin Cooper <ma...@apache.org>.
On 11/25/05, Noel J. Bergman <no...@devtech.com> wrote:
>
> Frank W. Zammetti wrote:
>
> > Has any thought been given to, or has any work been done already, to
> > creating a Javascript-based client-side version of Digester? I'm
> > starting on a new project soon where I'll potentially have to be doing a
> > fair amount of client-side XML parsing, and it occurs to me that using
> > Digester would make my life A LOT easier.
>
> And a month or so ago, someone asked the same about logging. Seems to me
> that with the burgeoning popularity of AJAX technology, there will be a
> number of such thoughts.
>
> Now we just need to build a community that wants to collaborate on it.
Yes and no. I do see a place for JavaScript at the ASF, and I do believe we
should have a forum - and a community - around that.
However, when it comes to the fundamentals, IMHO, the Dojo toolkit has an
existing and thriving community; they are pulling together the best parts of
existing toolkits; and they have a quorum of some of the very smartest
JavaScript developers anywhere. I really, really don't want to see the ASF
go off and (try to) duplicate all of the awesome work they've done just so
that it's under the ASF umbrella.
I'm hoping that we can have a BOF at ApacheCon next month to talk about
JavaScript at the ASF. There are a number of people from a number of
different projects who I know are interested in collaborating on JavaScript
activities within the ASF, and I think this would be a great way to kick off
the discussions.
--
Martin Cooper
--- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
RE: Client-side Digester?
Posted by "Noel J. Bergman" <no...@devtech.com>.
Frank W. Zammetti wrote:
> Has any thought been given to, or has any work been done already, to
> creating a Javascript-based client-side version of Digester? I'm
> starting on a new project soon where I'll potentially have to be doing a
> fair amount of client-side XML parsing, and it occurs to me that using
> Digester would make my life A LOT easier.
And a month or so ago, someone asked the same about logging. Seems to me
that with the burgeoning popularity of AJAX technology, there will be a
number of such thoughts.
Now we just need to build a community that wants to collaborate on it.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org