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 <[email protected]> [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: [email protected] For additional commands, e-mail: [email protected]
