> hi Jeremy,
> in the histories controller, I could find no example to nicely obtain the PUT
> and POST content payload. Am I missing it?
> So I think a bad answer to my question is the following code. But I really
> don't like my _get_payload() hack reaching into the trans.environ object.
> Is there a better way to do this?
The short answer is that Galaxy has middleware that unpacks API request content
and puts them into parameters. For example, the URL
/api/histories/2f3f601bb97a6a89 calls histories/index with id=2f3f601bb97a6a89
The data from a POST or PUT appears as payload for create/update methods.
> in buildapp.py // I also don't like the fact that it needs five separate
> calls. this is the sort of design pattern that should be very easy.
>
> webapp.mapper.connect("/api/assets/", controller="medbook",
> action="assets_create", conditions=dict(method=["POST"]))
> webapp.mapper.connect("/api/assets/", controller="medbook",
> action="assets_read", conditions=dict(method=["GET"]))
> webapp.mapper.connect("/api/assets/*url", controller="medbook",
> action="assets_read", conditions=dict(method=["GET"]))
> webapp.mapper.connect("/api/assets/*url", controller="medbook",
> action="assets_update", conditions=dict(method=["PUT"]))
> webapp.mapper.connect("/api/assets/*url", controller="medbook",
> action="assets_delete", conditions=dict(method=["DELETE"]))
Something like this should work for all five:
webapp.mapper.resource( 'asset', 'assets', path_prefix='/api' )
In general, your best bet is to replicate an existing API controller as closely
as you can.
J.
___________________________________________________________
Please keep all replies on the list by using "reply all"
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at:
http://galaxyproject.org/search/mailinglists/
