Mailinglist Archive: yast-devel (246 mails)

< Previous Next >
Re: [yast-devel] Webyast session with consultant
  • From: josef reidinger <jreidinger@xxxxxxx>
  • Date: Wed, 26 Aug 2009 13:46:26 +0200
  • Message-id: <4A952092.5070708@xxxxxxx>
Duncan Mac-Vicar Prett napsal(a):
On Tuesday 25 August 2009 15:18:42 Josef Reidinger wrote:
another hints how to change our dynamic creating ActiveResource to
normal classes and have in each plugin usual model, which should contain
a lot of functionality and can be easily tested. (So we should have
something like YaSTController as ancestor and YaSTResource as model
ancestor).
Welcome any another ideas which I forget mention.

That is possible, the only reason why we ask for the proxy object instead of
having a model is because the path is variable, so proxy_for makes first a
request to resources.xml and then sets the right path for the resource.

In a more RESTful model like making GET /:host/time go to TimeController#show
and pass host as a parameter, one would still need to set the host all the
time. Any idea how to make less repetitive?


Yes, we discuss it and possibility is use YaSTController ancestor and
YaSTModel ancestor where in YaSTController is beforefilter which set
site in YaSTController. This also set this var to its childs so it works
good (acts same as usual ActiveResource). Also YaSTModel should contain
permissions and other YaST rest related stuff. What is still unclear for
me is specific path for interface. I think that it is not so hard use
common ActiveResource mapping modelname -> path on site. I think that
sollution in
http://kkaempf.blogspot.com/2009/05/designing-restful-api-for-yast.html
is not good, we should prefer using namespaces for routes -
http://api.rubyonrails.org/classes/ActionController/Routing/RouteSet/Mapper.html#M000556
. Then we need no magic with interface and have common ActiveResource
code. So we should remove interface and only have permissions key (as
now interface is identic with permissions path)


Another think which Karel demonstrate on cloudkit is usage of request
type OPTIONS which get description of provided REST api and which we
should include to document our REST api.

Josef
--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups