Hey Torsten, I was able to get your initial setup working fine, but then i tried to install the ruotekit modifications into my other existing rails app and now i keep getting this sinatra error:
=> Booting Mongrel => Rails 2.3.4 application starting on http://0.0.0.0:3000 => Call with -d to detach => Ctrl-C to shutdown server Fri Feb 19 13:06:04 -0500 2010: Read error: #<MissingSourceFile: no such file to load -- sinatra/respond_to> /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require' /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require' /opt/local/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/ active_support/dependencies.rb:156:in `require' /opt/local/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/ active_support/dependencies.rb:521:in `new_constants_in' ... any ideas? Thanks, Dave BTW ruote-on-rails works fine with your initial set of instructions. On Feb 9, 10:02 am, Torsten Schoenebaum <[email protected]> wrote: > Hi list! > > A little follow up to my lines on using Ruote from within Rails. I > mentionend "put rk into your Rack app's middleware stack" as possibility > for that without giving further details. > > Kenneth did some fine work on that and I added a few more lines so that > now I would propagate to use RuoteKit when there's a need for Ruote on > Rails. > > If you need a quickstart, have a look at my example Rails app > athttp://github.com/tosch/ruote-on-rails > > The only files changed are: > * config/environment.rb > * config/initializers/ruote_kit.rb > * lib/tasks/ruote_kit.rake > > You get all the power of the changes done in my previously mentioned > gist plus the possibility to peep into running processes by surfing to > /_ruote. > > There's just one drawback at the moment: RuoteKit's views and methods > aren't protected in any way, they are accessible to the world if you > don't protect them by yourself in some way. > > So let's dig a little deeper: Where to put your own Ruote stuff? > > First of all, you should register your participants in the ruote_kit.rb > initializer file (before the RuoteKit.configure_catchall! call). Note > that you should only use non-instanciated participants as the Ruote > engine when running Rails has no access to a worker instance by default > (instanciated participants will only work if a worker is bound to the > engine). That means: Don't use BlockParticipants! Don't use > ParticipantClass.new. Those will most probably not work. > > Some words on the catchall participant: The call to > RuoteKit.configure_catchall! > is a shortcut for the following: > RuoteKit.engine.register_participant('.*', Ruote::StorageParticipant) > So you'll get a storage participant for every participant name you may > think of. If you didn't register your own participants beforehand, every > time a participant expression is entered in your processes, a workitem > will be put in the storage participant. You may access all storaged > workitems by calling RuoteKit.storage_participant.all. See > Ruote::StorageParticipant's inline docu for all methods you may or may > not need ;-) > > Note that there is no need to run RuoteKit.configure_catchall! ! The > storage participant will be there anyway, but you'll have to register it > by yourself if you want to use it in your process definitions. You could > register a not so greedy (name-wise) variant: > RuoteKit.engine.register_participant 'storage_+*', Ruote::StorageParticipant > In your process definitions, each participant expression refering to > storage_a or storage_b etc would be handled by the storage participant. > > Apropos process definitions: Where to put them? You may keep it simple > and put them in the initializer (writing to some global constant for > example). John likes them to be referenced by urls, so you could put > them as files in some subdirectory of public [1]. You can even put the > process definition to the place where you launch processes. In short > words: It's totally up to you. > > Now you have your participants registered and your process definitions > (f)lying around somewhere. Where to launch them? The possibilities are > nearly endless. You could call RuoteKit.engine.launch in your > controllers. I would suggest to use one or more methods in your models > for that, combined with callbacks and/or observers. The best way depends > on your models, so YMMV. > > For human participant integration, the storage participant is built. It > holds the workitems until they are explicitely replied to the engine > (you can do this via > RuoteKit.storage_participant.reply(workitem) > ). There could be a controller wrapping all this up, but for a start, > there always is /_ruote/workitems ... > > That's all for now. I hope this helps and am waiting for questions, > Torsten > > [1] Note that you have to set the remote_definition_allowed option of > the engine to true to get that going. -- you received this message because you are subscribed to the "ruote users" group. to post : send email to [email protected] to unsubscribe : send email to [email protected] more options : http://groups.google.com/group/openwferu-users?hl=en
