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 at http://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
