Mailinglist Archive: yast-devel (163 mails)

< Previous Next >
Re: [yast-devel] use-activeresource
  • From: Josef Reidinger <jreidinger@xxxxxxx>
  • Date: Thu, 10 Sep 2009 11:19:17 +0200
  • Message-id: <4AA8C495.40306@xxxxxxx>
On 09/10/2009 11:02 AM, Duncan Mac-Vicar Prett wrote:
On Thursday 10 September 2009 10:37:17 Klaus Kaempf wrote:
* Duncan Mac-Vicar Prett <dmacvicar@xxxxxxx> [Sep 10. 2009 10:19]:
I think Martin approach is saner and easier for Rails developers. I am
not sure how he expects to un-hardcode the remote path prefix by using
the interface, but I like the design of declaring the options in the
model class itself, in the same style of has_many and so on, one could
get something like with_interface "org.yast..." as an option to the path
derived from the class.

Can you point us to a Wiki page explaining your approach and some
example code showing the improvements over the current implementation ?

Please don't pollute the wiki with stuff that nobody will remember to cleanup
later ;-). IMO the place for an example is the final module tutorial and
unless the final approach is defined, the place for documentation is the
comments above the class in Martin's branch. Mailing lists are fine for
discussions and showing "examples".

the main difference is, current solution:

(client side)

client = YaST::ServiceReource.proxy_for('org.opensuse.yast.network.interface')
cards = client.find(:all)
...
if not client.permissions.write?
.. disable ui
end

Martin's solution

(client side)

class Interface < YastResource::Base
has_prefix '/network'
end

then in the controller:

cards = Interface.find(:all)
Interface.permissions...

And what we describe as missing features is the ability to do:

class Interface < YastResource::Base
any_that_implements 'org.opensuse.yast.network.interface'
end

instead of using has_prefix


I think that the most important difference is that we don't use any dark
magic as now in resource_loader so it is easier to maintain. It is much
cleaner to understand how it work.
Second the most important improvement is that developer could add
handling of resource to model, not to controller (excellent example is
status controller, which contain many model functionality).
Third one is that we use common rails convention, we have normal model
without any magic and we add only few defined additions to that model in
ancestor. That is idea, which any vendor developer know and can see.
With resource_loader is hard even to find, that model is based on
ActiveResource::Base so it has its methods, then find method for
permissions (and find that permissions is not cached!) and find how it
works is hard in current implementation.

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

< Previous Next >