launchpad-dev team mailing list archive

[Manish Sinha <mail@xxxxxxxxxxxxxxx>]

Hi Gary,

So this mens I need to have a look at wadllib and lazr.restt projects.
Let me summerize what I understoo.

wadllib is a parser for wadl files. It takes in a wadl string and
creates the corrospoding tree to corrospond with the schema so that
you can acess any method like application.resource_type.method

The parsed object from wadllib is passed to lazr.rest which traverses
the wadl tree reoresentation and creates the client side proxy.

Hope I got it correct.

--
Manish Sinha

On 5/13/10, Gary Poster <gary.poster@xxxxxxxxxxxxx> wrote:
> Manish and I spoke on IRC today.  We made progress on the two topics he
> raised there.  I'll summarize here for clarity, history, and community (IOW,
> please correct me!).
>
> The first issue Manish described in this email, so I'll respond below.
>
> On Apr 25, 2010, at 4:18 AM, Manish Sinha wrote:
>
>> Hi,
>>
>> I am working on a WADL-->C# converter and taking Launchpad WADL file as
>> the example. This project is mainly targeted at generating client proxy
>> code for Launchpad.
>> I ran into a few issues:
>>
>> in the request section of WADL, it can contain param[] and
>> representation_type[] both together
>> I can understand that param[] can be used for generating a method which
>> has all the parameters given in param[]
>> For representation_type[] I understood that the method is overloaded and
>> each there are as many overloaded methods as the number of
>> representation_type
>>
>> My doubt comes that, when both param[] and representation_type[] are
>> present in a single request.
>> Let's take we have m param and n representation_type
>> In this case, does all the methods look like?
>>
>> foo(param1, param2,.....,paramm, representation_type1)
>> foo(param1, param2,.....,paramm, representation_type2)
>> ...
>> ..
>> foo(param1, param2,.....,paramm, representation_typen)
>>
>> Or in most situations param[] and representation_type[] wont occur
>> together? Can I safely assume this?
>>
>>
>> I know many people on this list don't deal with development and not many
>> use WADL since they are comfortable with launchpadlib.
>>
>> It would be kind if some launchpad hacker answers this question. If anyone
>> is familiar with WADL, your suggestions are appreciated. If the hacker who
>> wrote Launchpad WADL can answer this, it would be a cherry on the ice.
>
> I believe this question is about porting the behavior of lazr.restfulclient,
> rather than wadllib.
>
> I like the way that lazr.restfulclient and wadllib handle this, and, as I
> said on IRC, I'd suggest considering porting these libraries, if possible,
> rather than making your own architecture.
>
> In that context, the libraries handle the situation you raise in this way.
>
> wadllib simply parses the wadl and gives a nice way of getting the data from
> it, like a specialized XML DOM object.  You can get the parameters of a
> given method for a given representation type.  For instance, if you have a
> wadllib object representation of a method named WADL_RESOURCE, you can ask
> it questions like WADL_RESOURCE.parameter_names('application/json') to get a
> list of the parameter names for that call and resource type.
>
> lazr.restfulclient then explicitly exposes all of the JSON methods.  The
> methods then only have parameters in them, and *never* (AFAICT) let the
> caller specify the representation type (since JSON is always used).
>
> The second question you raised was that the getByUrls method of branches in
> our WADL doesn't specify a return type.  I asked you to file a bug, which
> you did: https://bugs.launchpad.net/bugs/579516 .
>
> Gary

-- 
Sent from my mobile device