hmm i sudo gem installed sinatra-respond_to and it seems to be working now. i think there's something wrong with my gem repo or something. anyways, this works great thanks!
On Feb 19, 1:11 pm, "Dave @ UPENN" <[email protected]> wrote: > 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 onhttp://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
