Marnen, You are fast...
Class variables... got it! ;-) I intend to spin off worker threads(or fork if need be) after the initial 'submit' button is pushed. Those workers will tend to the jobs at hand. Yes I meant library.rb (not perl)... I really do not want to use a yaml file. Some of the config data will include passwords to other systems that the worker threads will need to perform their duties. Also, the admins will get cranky if I make them modify a yaml file. If I use a 'singleton' active record I do need to figure out how to encrypt the password in the database. If I use a static, err class variable, I am more than willing to roll the dice and assume no one will dump mongrel's memory and hunt for it. I am very willing to use the class variable approach, but I am highly curious how to build a 'singleton' model to make use of the various active record goodies (assuming I can delete it upon startup). Thanks, Cris Marnen Laibow-Koser wrote: > Cris Shupp wrote: >> Hi Marnen. >> >> Thanks for your reply. Here is what I am trying to do... >> >> We are trying to use mongrel as a job execution engine and use rails for >> the front end GUI. > > I'm not sure I understand. Mongrel is just a Web server. Are you > saying you have a Rails app that calls other processes? > >> We intend to have an initial configuration screen >> where the administrator will populate various properties in form for use >> in determine how the various jobs will run. Whenever the 'system' (and >> system will consist of more than, but include, mongrel) is brought down >> for maintenance we want the admins to reexamine these properties so we >> want them 'forgotten' between maintenance windows. Scalability is not >> an issue here as only a handful of admins will use the tool, (thus no >> clustering will be involved) and I expect statics, I mean class variables, >> will work. > > Again: they're not called that in Ruby. This isn't Java. :) > >> In fact, >> when I moved the TransientData class to a file called library.pl > > Did you mean library.rb ? (Anyway, it should be in a file called > transient_data.rb for clarity.) > >> in the >> lib directory and required it in the controller it did (finally) work. > > That makes some sense, I suppose... > >> >> If the right approach is to use an active record, despite the lack of >> need for persistence, can one create an active record and declare it to >> be a singleton (i.e. never more than one row in the database)? Can one >> do the equivalent of a j2ee startup bean and have a mongrel run a job >> upon startup of the server so I could delete that singleton? The idea >> of being able to use an active record and have all of the validation >> goodies does appeal to me. > > You could do this (although there are a variety of reasons that > singletons are probably a bad idea), but if it's just a question of > configuration parameters, it's probably easier to read them from a YAML > file. There's a Railscast on this topic. > > If you really want them transient, though, there's no need to store them > anywhere at all! Just call TransientData.new in the show action, not in > the constructor. Your controllers don't need -- and should not have -- > constructor methods. Remember, this isn't Java -- instance variables > spring into existence whenever you mention them. > >> >> Thanks, >> >> Cris >> > > Best, > -- > Marnen Laibow-Koser > http://www.marnen.org > [email protected] -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
