Well, I agreed with the fact I switched some way the use of this feature to match my needs, but then let me ask you a quick question : how can handle WSME variable request body ?
The first glance I have is that WSME is requiring a static API in terms of inputs, could you then confirm ? Do you have any idea on how I could get my goal, ie. having a static input plus some extra variable inputs ? I was also thinking about playing with __getattr__ and __setattr__ but I'm not sure the Registry could handle that. One last important point, this API endpoint (Host) is admin-only in case of you mention the potential security issues it could lead. Thanks for your help, -Sylvain 2014-02-25 18:55 GMT+01:00 Doug Hellmann <[email protected]>: > OK, that's not how that feature is meant to be used. > > The idea is that on application startup plugins or extensions will be > loaded that configure the extra attributes for the class. That happens one > time, and the configuration does not depend on data that appears in the > request itself. > > Doug > > > On Tue, Feb 25, 2014 at 9:07 AM, Sylvain Bauza <[email protected]>wrote: > >> Let me give you a bit of code then, that's currently WIP with heavy >> rewrites planned on the Controller side thanks to Pecan hooks [1] >> >> So, L102 (GET request) the convert() method is passing the result dict as >> kwargs, where the Host.__init__() method is adding dynamic attributes. >> That does work :-) >> >> L108, I'm specifying that my body string is basically an Host object. >> Unfortunately, I can provide extra keys to that where I expect to be extra >> attributes. WSME will then convert the body into an Host [2], but as the >> Host class doesn't yet know which extra attributes are allowed, none of my >> extra keys are taken. >> As a result, the 'host' (instance of Host) argument of the post() method >> is not containing the extra attributes and thus, not passed for creation to >> my Manager. >> >> As said, I can still get the request body using Pecan directly within the >> post() method, but I then would have to manage the mimetype, and do the >> adding of the extra attributes there. That's pretty ugly IMHO. >> >> Thanks, >> -Sylvain >> >> [1] http://paste.openstack.org/show/69418/ >> >> [2] https://github.com/stackforge/wsme/blob/master/wsmeext/pecan.py#L71 >> >> >> 2014-02-25 14:39 GMT+01:00 Doug Hellmann <[email protected]>: >> >> >>> >>> >>> On Tue, Feb 25, 2014 at 6:55 AM, Sylvain Bauza >>> <[email protected]>wrote: >>> >>>> Hi, >>>> >>>> Thanks to WSME 0.6, there is now possibility to add extra attributes to >>>> a Dynamic basetype. >>>> I successfully ended up showing my extra attributes from a dict to a >>>> DynamicType using add_attributes() but I'm now stuck with POST requests >>>> having dynamic body data. >>>> >>>> Although I'm declaring in wsexpose() my DynamicType, I can't say to >>>> WSME to map the pecan.request.body dict with my wsattrs and create new >>>> attributes if none matched. >>>> >>>> Any idea on how to do this ? I looked at WSME and the type is >>>> registered at API startup, not when being called, so the get_arg() method >>>> fails to fill in the gaps. >>>> >>>> I can possibly do a workaround within my post function, where I could >>>> introspect pecan.request.body and add extra attributes, so it sounds a bit >>>> crappy as I have to handle the mimetype already managed by WSME. >>>> >>> >>> I'm not sure I understand the question. Are you saying that the dynamic >>> type feature works for GET arguments but not POST body content? >>> >>> Doug >>> >>> >>> >>>> >>>> >>>> Thanks, >>>> -Sylvain >>>> >>>> _______________________________________________ >>>> OpenStack-dev mailing list >>>> [email protected] >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
