commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rich Coco <rac...@starbak.com>
Subject Re: [Digester] basic usage problem. Help me understand the stack.
Date Tue, 27 Jul 2004 02:06:30 GMT
unfortunately, for me, i *do* have to keep the containment hierarchy
intact. the incoming xmlrpc msg is a method call and its
incoming arguments - which can have arbitrarily nested structures
within structures, arrays of structures as structure elements, etc... -
have to be presented to a java class that handles that particular method
call in such a way that the java objects built from the xmlrpc method
args  maintain the original 'containment' relationship.

so for example, suppose xmlrpc method Foo has these three arguments:
Struct_1, Struct_2, Array(Struct_3) > I am trying to avoid using xml here.
Struct_1 is some strucuture definition, as is Struct_2,
and then the 3rd arg is an array of structures (each memeber being of
type Struct_2, some other know structure definition).

then the result of parsing such xml code would have to be, say, a hashtable
something like this:

Arg_1_name  ==>  new Struct_1( ... )  // args are known member/values
Arg_2_name ==> new Struct_2(...)
Arg_3_Name ==>  new Vector<Struct_3>

any of the above structures could conceivably contain another structure
as an element. the Arg names are knwon from the original XML spec defining
the API. this spec specifies all Structure definitions and all Method
signatures.

it is relatively straight-forward (using digester) to parse such xml definitions to generated:
  * java classes for each structure definition

  * java classes for each method that takes one or more of the strucutre
     definitions as an argument (or Vectors thereof).

  * each Structure class has its custom (generated) toXML() method so that
    an instantiated such class can output its xmlrpc fragment. Such fragments
    can be concatentated together - together with a methodName - to form
    a well-fromed xmlrpc message which can be *sent* over the wire.

What I am finding much more difficult to do is the reverse:
take an *incoming* xmlrpc request (with a specified methodRequest name
already known from the XML input spec file from which everything is generated)
and turn its xmlrpc arguments (which are the nested structure definitions
for which we have well defined java class definitions) into a container
(hashtable?) of java classes that can be handed to the java class
(not generated) that handles this specific request.

I'd like to do this with *one* Digester servlet,
not one specialized Digester servlet per xmlrpc method.
(the latter would not be hard to do. why am i making htis hard on myself?
Hmmmmm...)




Simon Kitching wrote:
> On Tue, 2004-07-27 at 13:17, Rich Coco wrote:
> 
> 
> If you need to treat Part objects differently depending upon their
> parent element, then you can use these patterns:
>   */struct_1/part
>   */struct_2/part
>   */part/part
> 
> Here, I presume that when processing a part nested within a part, it
> doesn't matter what the parent of the top-level part is. I can't imagine
> a scenario where this would not be the desired behaviour.
> 
> Regards,
> 
> Simon
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message