August 2009 - YaST Development - openSUSE Mailing Lists

[yast-devel] WebYaST daily status, 10-Aug-2009
by Ladislav Slezak 10 Aug '09

10 Aug '09

WebYaST 10-Aug-2009 kkaempf, dmacvicar, schubi, mschidkunz, jsrain, lslezak, mvidner, mzugec Status update - dmacvicar: testcase fixes, features - mschidkunz: navigation and workflow in WebYaST - lslezak, jsuchome: proposals for reboot and vendor service module - mzugec: L3 - kkaempf: ITO AI: all: effort estimation, test cases, packages should be ready for Suse Studio appliance -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

1 0

[yast-devel] browser detection
by Duncan Mac-Vicar Prett 10 Aug '09

10 Aug '09

I have committed ebe8692d4bfa38b1e9e741ead8690c10511c5e05 which adds support to "Warn for unsupported browsers (fate #306686)" Designers can check/clean the style then :-) Idea from http://think2loud.com/build-an-unsupported-browser-warning-with- jquery/ plus enhanced browser detection from this plugin: http://davecardwell.co.uk/javascript/jquery/plugins/jquery-browserdetect/ which gives us more granularity. You can try opening the client in Konqueror to see how it looks. To control when the warning is shown, see jquery.badbrowser.js badBrowser() function. -- 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(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

1 0

[yast-devel] WebYaST daily status, 7-Aug-2009
by Klaus Kaempf 07 Aug '09

07 Aug '09

WebYaST 7-Aug-2009 kkaempf, dmacvicar, jsrain, lslezak, mzugec Status update - jsrain: checked with Coolo on how to distribute webyast with 11.2 - lslezak: planning - mzugec: L3 - dmacvicar: added Wiki page on testing - kkaempf: worked on Fate looked at modeling AI: think about effort estimates for your modules --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

1 0

[yast-devel] WebYaST: how to model reboot/shutdown actions
by Ladislav Slezak 06 Aug '09

06 Aug '09

Hi all, I'm workign on fate#306694 ([webyast] Shutdown Module), I checked the CIM model how system shutdown/reboot is modeled there - it's defined in CIM_OperatingSystem class which also provides information about memory size, free swap etc.. According to this the reboot/shutdown actions could be part of the status plugin. The question is should we follow the CIM model? Or should we include it in the service API? Any opinion? Thanks in advance -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak(a)suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

2 1

[yast-devel] WebYaST daily status, 6-Aug-2009
by Klaus Kaempf 06 Aug '09

06 Aug '09

WebYaST 6-Aug-2009 kkaempf, dmacvicar, mschmidkunz, jsrain, lslezak, mkudlvasr, mzugec Status update - dmacvicar: still working on coverage tests in Hudson assigned tasks to developers (together with jsrain) Goal: get image build - mschmidkunz: - working on navigation - jsrain: - assigned tasks to developers - working on contract with local Rails consultant - lslezak: - worked with jsuchome on users module - now focusing on shutdown/reboot looked at CIM model, some questions left AI: ask questions on yast-devel - mkudlvasr: - worked with jreidinger on modules - mzugec: - planning network module - kkaempf: - met with mschmidkunz on UI priorities - VirtualBox 11.2 setup revealed problems with check-setup, fixing AI: all, adapt your tests, refactor regularly ! --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

1 0

[yast-devel] WebYaST daily status, 5-Aug-2009
by Klaus Kaempf 06 Aug '09

06 Aug '09

WebYaST 5-Aug-2009 kkaempf, dmacvicar, mzugec, mschmidkunz Status update - dmacvicar: fixing rcov (ongoing) - fixing Hudson build server - if the build breaks, mails will be sent (to last committer and yast-commit) - mzugec: - next: network modeling - mschmidkunz: - workflow for login - kkaempf: - met with web designers - more work on features in Fate - moved PRD to innerweb wiki - got pointed to HAML (http://en.wikipedia.org/wiki/Haml) --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

2 1

[yast-devel] users controller refactoring
by Duncan Mac-Vicar Prett 05 Aug '09

05 Aug '09

Trying to get the coverage running for all directories, I got stuck at the user's one was failing because the testcase is still Scr based, when the module is actually using the YaPI. Once I tried to make the test pass I realized the code was not structured in a way that makes it easy to test. Mainly, I found the following flaws: - The controller did direct calls to YaPI I pointed at this pattern in a previous email. If you want to test this, you will need to stub the YaPI, which is a lot of noise for a controller - The controller called instance modifier methods This is a very confusing way of writing code. Basically, you are in a method, lets say index. And from it you call another method, lets say fill_users, which modifies an instance variable, which is later used in the code. def index # this method modifies/creates @var fill_vars # and from now, the code relies on what fill_vars did @var.do_something It is very hard to figure out that fill_users does something with @users if you don't look at the implementation. As fill_users does not require anything from the controller, why does it need instance variables? either move the code to a module, or where it belongs, In this case, it makes sense to actually put it into the class where it belongs: User The only reason why in rails you have @variables is because the view accesses them. But 1) if it is not passed to the view, there is no reason for member variables 2) member variables is not a way to pass data across functions, it is the state of the object! Refactorings done: - all the instance modifier methods where removed. Similar methods are now in the User class: users = User.find_all user = User.find(id) user = User.create(id) user.save user.destroy The API imitates the ActiveRecord/ActiveResource one. Why not, that is what people is used to see in controllers. This also allows to separate testing in 2 parts: - the User class test, for which mocha stubs YaPI calls - the controller class, for which mocha stubs User class class This makes the controller test much simpler, you need to stub User class to return arrays of User, and not deal with stubing the complicated YaPI calls, why should the controller know about those anyway. It is the User class the class that is hiding that complexity. I haven't enabled the User class tests because I get this when calling YaPI calls in my machine: TypeError: can't convert Array into String /usr/lib64/ruby/vendor_ruby/1.8/dbus/type.rb:108:in `+' /usr/lib64/ruby/vendor_ruby/1.8/dbus/type.rb:108:in `to_s' /usr/lib64/ruby/vendor_ruby/1.8/dbus/marshall.rb:352:in `append' However I wanted to post the patch for review (and I guess I still need to see if it works, once the tests are done) Another pattern is where to use static methods or not. Consider the destroy method. If you implement it in the class User def destroy # do something with yapi and @id end You can define it as a class method: def self.destroy(id) # do something with yapi and id end And then define the previous one just as: def destroy self.class.destroy(@id) end Then you can use either as User.destroy("schubi") or as user.destroy (assuming user is an User object) -- Duncan Mac-Vicar P. - Engineering Manager, YaST SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)

1 1

[yast-devel] Re: [yast-commit] <rest-service> master : Use static methods where it is useful
by Klaus Kaempf 04 Aug '09

04 Aug '09

* Josef Reidinger <jreidinger(a)suse.cz> [Aug 04. 2009 18:01]: > + # Creates argument for dbus call which specify what data is requested. > + # Available timezones is cached so request it only if it is necessary. > + # return:: hash with requested keys > + def Systemtime.create_read_question #:doc: > + ret = { > + "timezone" => "true", > + "utcstatus" => "true", > + "currenttime" => "true" > + } > + ret["zones"]= @@timezones.empty? ? "true" : "false" > + return ret Whats wrong with using true and false boolean constants ? Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

1 0

[yast-devel] Re: [yast-commit] <web-client> master : use lambdas instead loops
by Klaus Kaempf 04 Aug '09

04 Aug '09

* Josef Reidinger <jreidinger(a)suse.cz> [Aug 04. 2009 10:00]: > + region = timezones.find { |reg| reg.name == params[:region] } > + region = {} unless region This can be further shortened by writing region = (timezones.find { |reg| reg.name == params[:region] }) || {} Where I prefer region = (timezones.find { |reg| reg.name == params[:region] }) || Hash.new to make it less cryptic ;-) Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

3 4

[yast-devel] Links: Caching in Rails
by Ladislav Slezak 04 Aug '09

04 Aug '09

Hi all, I have implemented caching in the patches controller (in the REST service), the index method result is cached now. This speeds up reloading the main page (control panel) and clicking "Updates" shows the available patches faster. The first run takes more than 4 seconds on my machine, the following calls take about 70ms so this is a huge improvement... (The cache is valid for 5 minutes or until RPM DB or repo metadata are updated.) If you are interested in caching in Rails here are some links: http://guides.rubyonrails.org/caching_with_rails.html http://railsenvy.com/2007/2/28/rails-caching-tutorial http://railsenvy.com/2007/3/20/ruby-on-rails-caching-tutorial-part-2 http://thewebfellas.com/blog/2008/6/9/rails-2-1-now-with-better-integrated-… -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak(a)suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

2 1