On 5/26/06, Elvelind Grandin <[EMAIL PROTECTED]> wrote:
>
> On 5/26/06, Charlie Moad <[EMAIL PROTECTED]> wrote:
> >
> > On 5/26/06, Jorge Godoy <[EMAIL PROTECTED]> wrote:
> > >
> > > > So I am basically looking for some detailed suggestions on how to
> > > > approach this problem. I can provide more samples if needed, but
> > > > would just like to get some interaction to decide on a good approach.
> > >
> > > I've read about ZSI a long time ago, and I don't remember much about it,
> > > but my suggestion would be for you to try to work with the expose
> > > decorator. By using it you can offer multiple output formats.
> > >
> > > For example, today you can output (x)html + json by doing this:
> > >
> > > @turbogears.expose(format = 'html')
> > > @turbogears.expose(format = 'json', allow_json = True)
> > > def some_method(self, *args, **kwords):
> > > # method implementation
> > >
> > >
> > > If you could add your implementation to it, then we'd end up with:
> > >
> > > @turbogears.expose(format = 'html')
> > > @turbogears.expose(format = 'json', allow_json = True)
> > > @turbogears.expose(format = 'wsdl', other_parameters = here)
> > > def some_method(self, *args, **kwords):
> > > # method implementation
> > >
> > > I believe this is a great thing because you don't need separate methods to
> > > handle different output formats and you also don't need to worry about the
> > > dispatchers that are there. TG takes care of that for you and it "simply
> > > works". Also, using this approach, you can convert existing applications
> > > to use your new implementation with very little work.
> > >
> > > So... Think about using the expose decorator.
> >
> > Thanks for the tip. I have never thought about stacking decorators.
> > That could come in useful for having one method serve the soap logic
> > and generating doc pages. I looked at this somewhat though and the
> > expose method only seemed customizable through the template plugins,
> > but I didn't see a way to pass "other_parameters" to the template.
>
> you can't at this point. What parameters are you in need of passing?
It would be nice to have two possibilities.
1. @expose(format='soap', requestTC=???, responseTC=???)
This would serve well for soap proxies in which there is no wsdl. It
'might' even be possible to auto-generate wsdl's given this approach.
2. @expose(template='zsi:mymodule.wsdl')
This would would use some standard naming scheme to determine which
method of the wsdl this method is implementing. Then is would set the
request and response typecodes that were resolved for that method of
the wsdl.
Both these are paths to possibly setting a func.requestTC and
func.responseTC attribute on the exposed methods. Then each call to
the method would use those typecode to marshall between soap and
python. It is important to remember that a soap client will point to
the class and not the methods, so TG would have to redirect the
request to the correct method.
This would be sufficient for a first approach. You could quickly want
to perform additional pre/post processing on the soap messages to
support features like ws-addressing.
Would it be considered bad form to have a 'turbozsi.expose' function
to handle all this?
Thanks,
Charlie
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~----------~----~----~----~------~----~------~--~---
