On Tue, Feb 25, 2014 at 3:47 PM, Sylvain Bauza <sylvain.ba...@gmail.com>wrote:
> 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 ? > Yes, that's correct. > 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. > Why don't you know what the data is going to look like before you receive it? One last important point, this API endpoint (Host) is admin-only in case of > you mention the potential security issues it could lead. > My issue with this sort of API isn't security, it's that describing how to use it for an end user is more difficult than having a clearly defined static set of inputs and outputs. Doug > > Thanks for your help, > -Sylvain > > > 2014-02-25 18:55 GMT+01:00 Doug Hellmann <doug.hellm...@dreamhost.com>: > > 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 >> <sylvain.ba...@gmail.com>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 <doug.hellm...@dreamhost.com>: >>> >>> >>>> >>>> >>>> On Tue, Feb 25, 2014 at 6:55 AM, Sylvain Bauza <sylvain.ba...@gmail.com >>>> > 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 >>>>> OpenStack-dev@lists.openstack.org >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> OpenStack-dev mailing list >>>> OpenStack-dev@lists.openstack.org >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev