[yast-devel] use-activeresource: continuation
Hi, I've been continuing with the work, which Martin Vidner and Karel started 2 weeks ago - trying to use ActiveResource without service_resource.rb . This is currently the "use-activeresource" branch. I've added support for discovering controller paths from interface name. So currently there are no hard coded controller paths. Previously resources were used like this: *** Example from network_controller.rb *** hn = load_proxy "org.opensuse.yast.modules.yapi.network.hostname" *** Now they can be used like this: *** plugins/network/app/model/hostname.rb *** class Hostname < YastResource uses_interface "org.opensuse.yast.modules.yapi.network.hostname" end *** Example from network_controller.rb *** Hostname.initialize_from_interface hn = Hostname.find :one *** I think, that: - this newer approach better follows the MVC philosophy (with service_resource.rb, no model class is possible) - the YastResource < ActiveResource class is much shorter and more readable - individual model classes can be enriched by resource-specific methods - YastResource and individual models are not created dynamically - and so are easier to test (in contrast with service_resource.rb) - test can be made for the model. Currently we depend on tests in controller. - it is Black Magic Free (TM) :-) Please note, that "use-activeresource" branch depends on "resource-restful" branch, because it needs to discover individual resources (which is not possible with current "/resources" on web-service). This work was done to show, that there are other (and many think better) approaches to the problem than dynamic creation of classes in service_resource.rb. So I especially ask Duncan and Klaas, what other problems service_resource solves and YastResource does not. Please let me know what you think. Martin Kudlvasr -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Martin Kudlvasr write:
Hi,
I've been continuing with the work, which Martin Vidner and Karel started 2 weeks ago - trying to use ActiveResource without service_resource.rb . This is currently the "use-activeresource" branch.
I've added support for discovering controller paths from interface name. So currently there are no hard coded controller paths.
Previously resources were used like this:
*** Example from network_controller.rb *** hn = load_proxy "org.opensuse.yast.modules.yapi.network.hostname" ***
Now they can be used like this:
*** plugins/network/app/model/hostname.rb *** class Hostname < YastResource uses_interface "org.opensuse.yast.modules.yapi.network.hostname" end *** Example from network_controller.rb *** Hostname.initialize_from_interface
^^^^ Hi, why you need this line??? I think that have it in before_filter is good solution. What could be problem is that we should add some caching service as resource_loader store link for already created module.
hn = Hostname.find :one ***
I think, that: - this newer approach better follows the MVC philosophy (with service_resource.rb, no model class is possible) - the YastResource < ActiveResource class is much shorter and more readable - individual model classes can be enriched by resource-specific methods - YastResource and individual models are not created dynamically - and so are easier to test (in contrast with service_resource.rb) - test can be made for the model. Currently we depend on tests in controller. - it is Black Magic Free (TM) :-)
Please note, that "use-activeresource" branch depends on "resource-restful" branch, because it needs to discover individual resources (which is not possible with current "/resources" on web-service).
This work was done to show, that there are other (and many think better) approaches to the problem than dynamic creation of classes in service_resource.rb. So I especially ask Duncan and Klaas, what other problems service_resource solves and YastResource does not.
Please let me know what you think.
Martin Kudlvasr
-- Josef Reidinger YaST team maintainer of perl-Bootloader, YaST2-Repair, webyast modules language and time -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Tuesday 22 September 2009 15:06:53 Josef Reidinger wrote:
Martin Kudlvasr write:
Now they can be used like this:
*** plugins/network/app/model/hostname.rb *** class Hostname < YastResource uses_interface "org.opensuse.yast.modules.yapi.network.hostname" end *** Example from network_controller.rb *** Hostname.initialize_from_interface
^^^^ Hi, why you need this line??? I think that have it in before_filter is good solution. What could be problem is that we should add some caching service as resource_loader store link for already created module.
Yes, these should probably be moved to before filter, but that depends on each plugin programmer's attitude. To the caching thing ... in use-activeresource, the classes are statically created so there is no motivation to cache them. We can cache the data using a database, or cache the http traffic on "any.domain/resources/any.interface.name.xml". Both will IMHO have the same effect. The http proxy will be more transparent, OTOH caching in database will not introduce any new dependency. Martin
hn = Hostname.find :one ***
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Tuesday 22 September 2009 14:41:43 Martin Kudlvasr wrote:
This work was done to show, that there are other (and many think better) approaches to the problem than dynamic creation of classes in service_resource.rb. So I especially ask Duncan and Klaas, what other problems service_resource solves and YastResource does not.
Please let me know what you think.
I think this is a great step forward. The argument of being able to add code to the client proxy that otherwise would go in the model is enough to convince for the benefits. Only the name of the class does not convince me, may be the name YaST:ServiceResource::Base can be reused (there is already such class there) Also the initialization that needs to be done looks weird, but I can't think on something to avoid it. -- Duncan Mac-Vicar P. - Engineering Manager, YaST SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Wednesday 23 September 2009 15:13:47 Duncan Mac-Vicar Prett wrote:
On Tuesday 22 September 2009 14:41:43 Martin Kudlvasr wrote:
This work was done to show, that there are other (and many think better) approaches to the problem than dynamic creation of classes in service_resource.rb. So I especially ask Duncan and Klaas, what other problems service_resource solves and YastResource does not.
Please let me know what you think.
I think this is a great step forward.
Let's not forget kudos to Martin Vidner and Karel.
The argument of being able to add code to the client proxy that otherwise would go in the model is enough to convince for the benefits.
Only the name of the class does not convince me, may be the name YaST:ServiceResource::Base can be reused (there is already such class there)
The YastResource name was chosen quickly as we knew it was going to be only temporary. I personally have no preferred name. If we are going to plan a transition, we should keep 2 names for some time. Both service_resource.rb and YastResource can be used by plugins at the same time. This way we can achieve a fluent transition.
Also the initialization that needs to be done looks weird, but I can't think on something to avoid it.
Well, I combined the 2 steps in "init_interface_and_find" method which combines the 2 lines and does exactly what "load_proxy" does - init the class and call find. As Josef has pointed out the initialization part can be placed in a before filter, which would have to be different for each plugin/model. -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Wednesday 23 September 2009 16:00:11 Martin Kudlvasr wrote:
Only the name of the class does not convince me, may be the name YaST:ServiceResource::Base can be reused (there is already such class there)
The YastResource name was chosen quickly as we knew it was going to be only temporary. I personally have no preferred name. If we are going to plan a transition, we should keep 2 names for some time. Both service_resource.rb and YastResource can be used by plugins at the same time. This way we can achieve a fluent transition.
What I mean, ServiceResource is a module, not a class. And there is already a empty class YaST:ServiceResource::Base there Duncan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Thu, Sep 24, 2009 at 09:49:32AM +0200, Duncan Mac-Vicar Prett wrote:
On Wednesday 23 September 2009 16:00:11 Martin Kudlvasr wrote:
Only the name of the class does not convince me, may be the name YaST:ServiceResource::Base can be reused (there is already such class there)
The YastResource name was chosen quickly as we knew it was going to be only temporary. I personally have no preferred name. If we are going to plan a transition, we should keep 2 names for some time. Both service_resource.rb and YastResource can be used by plugins at the same time. This way we can achieve a fluent transition.
What I mean, ServiceResource is a module, not a class. And there is already a empty class YaST:ServiceResource::Base there
I have moved the code to assume the place of YaST::ServiceResource::Base - see the branch: http://git.opensuse.org/?p=projects/yast/web-client.git;a=shortlog;h=refs/he... I think it is in a working shape so I am considering to merge it to master and use it for yast2-webclient-network. -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
participants (4)
-
Duncan Mac-Vicar Prett -
Josef Reidinger -
Martin Kudlvasr -
Martin Vidner