From B.Candler at pobox.com Sat Sep 1 07:46:07 2007 From: B.Candler at pobox.com (Brian Candler) Date: Sat, 1 Sep 2007 12:46:07 +0100 Subject: Bootstrapping from SVN In-Reply-To: References: <20070831205150.GA28101@uk.tiscali.com> Message-ID: <20070901114607.GA10005@uk.tiscali.com> On Fri, Aug 31, 2007 at 04:47:16PM -0600, Duane Johnson wrote: > The way I've seen it done is to run "rake install" in a checked out > version of merb. Then it just installs a new gem over top of > whatever gem your system has. Sure - but it takes a while for it to rebuild ri and rdoc etc. I was just checking to see if I'd missed a trick. If not, I'll stick with this way. Thanks, Brian. From canadaduane at gmail.com Sat Sep 1 09:29:21 2007 From: canadaduane at gmail.com (Duane Johnson) Date: Sat, 1 Sep 2007 07:29:21 -0600 Subject: Bootstrapping from SVN In-Reply-To: <20070901114607.GA10005@uk.tiscali.com> References: <20070831205150.GA28101@uk.tiscali.com> <20070901114607.GA10005@uk.tiscali.com> Message-ID: <238E3BC5-87D6-44B7-BFFA-2141E6AE9FED@gmail.com> I do this: rake gem; sudo gem install pkg/merb-0.4.0.gem --no-ri --no-rdoc -- Duane (Sorry, Brian for that previously unexplained shortcut command, gemi) On Sep 1, 2007, at 5:46 AM, Brian Candler wrote: > On Fri, Aug 31, 2007 at 04:47:16PM -0600, Duane Johnson wrote: >> The way I've seen it done is to run "rake install" in a checked out >> version of merb. Then it just installs a new gem over top of >> whatever gem your system has. > > Sure - but it takes a while for it to rebuild ri and rdoc etc. > > I was just checking to see if I'd missed a trick. If not, I'll > stick with > this way. > > Thanks, > > Brian. From ry at tinyclouds.org Sun Sep 2 07:17:01 2007 From: ry at tinyclouds.org (ry dahl) Date: Sun, 2 Sep 2007 13:17:01 +0200 Subject: A Proposal To Magically Remove 'params' Message-ID: <21ee31950709020417o6207b537w8cf7d5f1222a5baa@mail.gmail.com> I have a magical proposal for the anti-magic web framework. Controller methods do not use arguments and yet expect arguments. This is handled through this params hash because we don't know in advance what parameters a client could pass to Merb. But in almost every instance, it is too much to know all the query parameters - one doesn't care if the user threw in an extraneous variable - one only cares about the variables we need to process the action. Instead of using params we could make actions more functional by taking advantage of this cool programming concept called 'arguments'. An example class ProductController def show(id) # GET /products/show?id=12 @product = Product.find(id) render end def index(page = 1) # GET /products?page=2 @products = Product.paginate_all(page) render end end Getting a parameter list for a method is rather difficult, but using zenspider's ParseTree, it is possible. (Attached is a proof of concept. It is also viewable at http://pastie.caboo.se/93218 ) ParseTree is slow, but it only needs to be run once at load - we can cache the argument lists for each method. It is extremely magical, but the magic is limited in scope - we are not going to be using this all around the the source tree. Only for controller actions. It does not increase the frame stack and should have zero effect on performance. Advantages: - Less to type. No more params[:username], just username - Cleaner API. At a glance it is visible what parameters actions take. - params in its current state is slightly dangerous. Clients can pass to it whatever (key, value) pairs they want and Merb will blindly symbolizes the keys. These symbols are never garbage collected. - We can automatically raise a BadRequest if the user does not supply all of the arguments needed. I would happily implement this if Ezra and the list thinks that this would be a welcome feature. ry -------------- next part -------------- A non-text attachment was scrubbed... Name: method_args.rb Type: text/x-ruby-script Size: 831 bytes Desc: not available Url : http://rubyforge.org/pipermail/merb-devel/attachments/20070902/d8fed299/attachment.bin From canadaduane at gmail.com Sun Sep 2 10:24:41 2007 From: canadaduane at gmail.com (Duane Johnson) Date: Sun, 2 Sep 2007 08:24:41 -0600 Subject: A Proposal To Magically Remove 'params' In-Reply-To: <21ee31950709020417o6207b537w8cf7d5f1222a5baa@mail.gmail.com> References: <21ee31950709020417o6207b537w8cf7d5f1222a5baa@mail.gmail.com> Message-ID: <862BF7D5-3096-41E7-BC5C-3AAA9BE4D909@gmail.com> On Sep 2, 2007, at 5:17 AM, ry dahl wrote: > I have a magical proposal for the anti-magic web framework. > Personally, I appreciate magic when it's scientifically reasonable :) > Controller methods do not use arguments and yet expect arguments. This > is handled through this params hash because we don't know in advance > what parameters a client could pass to Merb. But in almost every > instance, it is too much to know all the query parameters - one > doesn't care if the user threw in an extraneous variable - one only > cares about the variables we need to process the action. > > Instead of using params we could make actions more functional by > taking advantage of this cool programming concept called 'arguments'. > An example > > class ProductController > def show(id) # GET /products/show?id=12 > @product = Product.find(id) > render > end > > def index(page = 1) # GET /products?page=2 > @products = Product.paginate_all(page) > render > end > end > I would like this a lot. One side effect might be, however, that the 'params' hash currently in use in the views will no longer be available. We could, of course, just leave the params hash in as well, but let's assume we remove it completely. Does this mean that controllers would have to wrap arguments in instance variables if it's necessary to pass them along to the view? e.g.: def index(page = 1, show_extra = true) @show_extra = show_extra # ... end Perhaps these arguments should become "locals" in the view as well? > Getting a parameter list for a method is rather difficult, but using > zenspider's ParseTree, it is possible. (Attached is a proof of > concept. It is also viewable at http://pastie.caboo.se/93218 ) > > ParseTree is slow, but it only needs to be run once at load - we can > cache the argument lists for each method. > Would this make Merb a *nix-only framework? > It is extremely magical, but the magic is limited in scope - we are > not going to be using this all around the the source tree. Only for > controller actions. > > It does not increase the frame stack and should have zero effect on > performance. > > Advantages: > - Less to type. No more params[:username], just username > - Cleaner API. At a glance it is visible what parameters actions take. The cleaner API is what makes my preference tip towards magic in this case. Controllers become very readable with this addition. > - params in its current state is slightly dangerous. Clients can pass > to it whatever (key, value) pairs they want and Merb will blindly > symbolizes the keys. These symbols are never garbage collected. Hmm. I didn't know that. > - We can automatically raise a BadRequest if the user does not supply > all of the arguments needed. > Nice. > I would happily implement this if Ezra and the list thinks that this > would be a welcome feature. > Just to throw it out there for discussion, is it possible to prepare the framework in such a way that we could turn a ParseTree controller implementation into a plugin? Regards, Duane Johnson (canadaduane) From ry at tinyclouds.org Sun Sep 2 10:49:48 2007 From: ry at tinyclouds.org (ry dahl) Date: Sun, 2 Sep 2007 16:49:48 +0200 Subject: A Proposal To Magically Remove 'params' In-Reply-To: <862BF7D5-3096-41E7-BC5C-3AAA9BE4D909@gmail.com> References: <21ee31950709020417o6207b537w8cf7d5f1222a5baa@mail.gmail.com> <862BF7D5-3096-41E7-BC5C-3AAA9BE4D909@gmail.com> Message-ID: <21ee31950709020749t1fde1576p3f98ea94da5b467@mail.gmail.com> > I would like this a lot. Thanks :) > One side effect might be, however, that the > 'params' hash currently in use in the views will no longer be > available. We could, of course, just leave the params hash in as > well, but let's assume we remove it completely. Does this mean that > controllers would have to wrap arguments in instance variables if > it's necessary to pass them along to the view? e.g.: > > def index(page = 1, show_extra = true) > @show_extra = show_extra > # ... > end > > Perhaps these arguments should become "locals" in the view as well? I would recommend keeping the params hash around for backwards compatibility but with a depreciation warning. I don't think query params should automatically become locals of the view. it's not so often that you pass query params directly to the view > Would this make Merb a *nix-only framework? I don't know if ParseTree compiles on windows, but if it doesn't, there isn't any reason why it shouldn't be able to. It only uses pure ruby stuff. > Just to throw it out there for discussion, is it possible to prepare > the framework in such a way that we could turn a ParseTree controller > implementation into a plugin? Probably (maybe with the help of some new hooks in the dispatcher). However, I would really like to have this considered for the core controller since it's a fairly fundamental API issue and doesn't effect performance/memory footprint (I think!). I guess the real tough question is: do people mind having ParseTree as a dependency? ry From ry at tinyclouds.org Sun Sep 2 11:16:28 2007 From: ry at tinyclouds.org (ry dahl) Date: Sun, 2 Sep 2007 17:16:28 +0200 Subject: A Proposal To Magically Remove 'params' In-Reply-To: <21ee31950709020749t1fde1576p3f98ea94da5b467@mail.gmail.com> References: <21ee31950709020417o6207b537w8cf7d5f1222a5baa@mail.gmail.com> <862BF7D5-3096-41E7-BC5C-3AAA9BE4D909@gmail.com> <21ee31950709020749t1fde1576p3f98ea94da5b467@mail.gmail.com> Message-ID: <21ee31950709020816o4a0cc493ld0c649db398d09d4@mail.gmail.com> > I don't know if ParseTree compiles on windows, but if it doesn't, > there isn't any reason why it shouldn't be able to. It only uses pure > ruby stuff. This came out wrong. I meant that its written in C but the only C library it uses is ruby. ry From ez at engineyard.com Sun Sep 2 13:00:17 2007 From: ez at engineyard.com (Ezra Zygmuntowicz) Date: Sun, 2 Sep 2007 10:00:17 -0700 Subject: A Proposal To Magically Remove 'params' In-Reply-To: <21ee31950709020816o4a0cc493ld0c649db398d09d4@mail.gmail.com> References: <21ee31950709020417o6207b537w8cf7d5f1222a5baa@mail.gmail.com> <862BF7D5-3096-41E7-BC5C-3AAA9BE4D909@gmail.com> <21ee31950709020749t1fde1576p3f98ea94da5b467@mail.gmail.com> <21ee31950709020816o4a0cc493ld0c649db398d09d4@mail.gmail.com> Message-ID: <4BE79063-B201-440E-A963-8CEED014E728@engineyard.com> On Sep 2, 2007, at 8:16 AM, ry dahl wrote: >> I don't know if ParseTree compiles on windows, but if it doesn't, >> there isn't any reason why it shouldn't be able to. It only uses pure >> ruby stuff. > > This came out wrong. I meant that its written in C but the only C > library it uses is ruby. > > ry Ry- We already implemented this exact thing in a bit more robust way: http://pastie.caboo.se/93260 But I decided that ParseTree is too heavy of a dependency. Partree will never work on windows with the one click installer. Since it uses rubyinline it needs a C compiler every time it's run :( So adding this as a dependency would not only make it not work on windows anymore, it would also make it not work on production servers that don't have a C compiler installed which is a lot of production *nix servers. I do like the idea of it and it does not affect performance because parsetree is only ran once on server boot. But it's not going to happen because of the heavy dependency that would limit where merb can run. Most shared hosts don't let you use a C compiler and windows definitely doesn't work with parsetree unless you use cygwin which is not really a solution. Cheers- -- Ezra Zygmuntowicz -- Founder & Ruby Hacker -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) From ry at tinyclouds.org Sun Sep 2 13:10:40 2007 From: ry at tinyclouds.org (ry dahl) Date: Sun, 2 Sep 2007 19:10:40 +0200 Subject: A Proposal To Magically Remove 'params' In-Reply-To: <4BE79063-B201-440E-A963-8CEED014E728@engineyard.com> References: <21ee31950709020417o6207b537w8cf7d5f1222a5baa@mail.gmail.com> <862BF7D5-3096-41E7-BC5C-3AAA9BE4D909@gmail.com> <21ee31950709020749t1fde1576p3f98ea94da5b467@mail.gmail.com> <21ee31950709020816o4a0cc493ld0c649db398d09d4@mail.gmail.com> <4BE79063-B201-440E-A963-8CEED014E728@engineyard.com> Message-ID: <21ee31950709021010i355e68ecsad3e6aca2be793b7@mail.gmail.com> > We already implemented this exact thing in a bit more robust way: > > http://pastie.caboo.se/93260 Wow! Hot! > But I decided that ParseTree is too heavy of a dependency. Partree > will never work on windows with the one click installer. Since it > uses rubyinline it needs a C compiler every time it's run :( So > adding this as a dependency would not only make it not work on > windows anymore, it would also make it not work on production servers > that don't have a C compiler installed which is a lot of production > *nix servers. > > I do like the idea of it and it does not affect performance because > parsetree is only ran once on server boot. But it's not going to > happen because of the heavy dependency that would limit where merb > can run. Most shared hosts don't let you use a C compiler and windows > definitely doesn't work with parsetree unless you use cygwin which is > not really a solution. I could (probably) extract/repackage the code from ParseTree to do just the parameter extraction (and without RubyInline). If we had that extension, would it change your opinion? ry From B.Candler at pobox.com Mon Sep 3 05:30:16 2007 From: B.Candler at pobox.com (Brian Candler) Date: Mon, 3 Sep 2007 10:30:16 +0100 Subject: A Proposal To Magically Remove 'params' In-Reply-To: <21ee31950709020417o6207b537w8cf7d5f1222a5baa@mail.gmail.com> References: <21ee31950709020417o6207b537w8cf7d5f1222a5baa@mail.gmail.com> Message-ID: <20070903093015.GA14613@uk.tiscali.com> On Sun, Sep 02, 2007 at 01:17:01PM +0200, ry dahl wrote: > I have a magical proposal for the anti-magic web framework. ... > Instead of using params we could make actions more functional by > taking advantage of this cool programming concept called 'arguments'. > An example > > class ProductController > def show(id) # GET /products/show?id=12 > @product = Product.find(id) > render > end > > def index(page = 1) # GET /products?page=2 > @products = Product.paginate_all(page) > render > end > end Just to add a dissenting voice - I very much dislike this idea. I consider Merb to be a simple framework, "what you would end up with if you started writing a Mongrel custom handler" was I think how someone described it. I don't like the idea of my code having to be *parsed* to add magic, and I wouldn't be confident that it would work in all cases (e.g. what about if I put controller actions in a module and mix them in? What if I define controller actions dynamically at runtime, e.g. based on reflecting the database?) I would prefer, if this is done, that it be made as a plugin, so I don't have to have it. However I have a couple of observations to add: (1) Bog-standard rdoc is able to parse method definitions, so it probably doesn't need a heavyweight parsing library. Perhaps even rdoc itself could be used. (2) I can think of a much simpler way to get a similar effect: use method_missing to define an accessor method the first time a parameter is accessed. Outline: def method_missing(arg, *rest) if params.has_key(arg) and rest.size == 0 eval("def #{arg}; params[#{arg.inspect}]; end") # FIXME!! return params[arg] end raise NoMethodError end As long as the method is defined in the controller class, not the controller instance, then the eval is run only the first time it is used. Of course, when you write Product.paginate_all(page) then 'page' still has the overhead of a method call, rather than dereferencing a local variable, but I believe that would be very small in the majority of cases. It would also be offset against the overhead of preparing the correct argument list in the "magic" design. Also, 'id' would need to be a special case given that it's a (deprecated) existing method. def id params[:id] end > - params in its current state is slightly dangerous. Clients can pass > to it whatever (key, value) pairs they want and Merb will blindly > symbolizes the keys. These symbols are never garbage collected. This is a separate problem. I think the solution is to leave the keys as strings in the params hash; I guess they start out as strings initially (e.g. from regexp matching or XML parsing). So no extra garbage is created up-front, and indeed less work will be done up-front in converting parameters to symbols which may not actually be used. Of course, params['id'] still generates garbage unfortunately, as will params[:id] if it is converted to a string internally, as I believe HashWithIndifferentAccess from ActiveSupport does. The solution I propose is something like Symbol#to_s which returns the *same* frozen string object each time it is called. That's easily implemented: class Symbol @@_stringreps = Hash.new { |h,k| h[k] = k.to_s.freeze } def to_fring @@_stringreps[self] end end irb(main):008:0> :foo.to_fring => "foo" irb(main):009:0> :foo.to_fring.object_id => -605563374 irb(main):010:0> :foo.to_fring.object_id => -605563374 irb(main):011:0> :foo.to_fring.object_id => -605563374 irb(main):012:0> :bar.to_fring.object_id => -605617824 irb(main):013:0> :bar.to_fring.object_id => -605617824 irb(main):014:0> :bar.to_fring.object_id => -605617824 Regards, Brian. From ry at tinyclouds.org Mon Sep 3 07:39:59 2007 From: ry at tinyclouds.org (ry dahl) Date: Mon, 3 Sep 2007 13:39:59 +0200 Subject: A Proposal To Magically Remove 'params' In-Reply-To: <20070903093015.GA14613@uk.tiscali.com> References: <21ee31950709020417o6207b537w8cf7d5f1222a5baa@mail.gmail.com> <20070903093015.GA14613@uk.tiscali.com> Message-ID: <21ee31950709030439t554a4f2dv40a3b84509676405@mail.gmail.com> > I don't like the idea of my code having to be *parsed* to add magic 'parsed' isn't the right verb here. ParseTree isn't opening up the file, reading in a string, and parsing it. It just traverses the internal node structure that Ruby has already built up. ParseTree tree does not have a method to simply return the parameters of a method (a constant time operation) - it traverses the structure of the entire method (linear in the size of the method - I guess). A custom extension to return the parameters would take a method object, and follow two node pointers before coming to a linked list of the parameter symbols (more or less - I think - I haven't done it yet). > and I > wouldn't be confident that it would work in all cases (e.g. what about if I > put controller actions in a module and mix them in? What if I define > controller actions dynamically at runtime, e.g. based on reflecting the > database?) All of these cases can be handled correctly. It's not as complex as you're thinking :) I will write the extension this week and then you can evaluate it. ry From B.Candler at pobox.com Mon Sep 3 08:30:14 2007 From: B.Candler at pobox.com (Brian Candler) Date: Mon, 3 Sep 2007 13:30:14 +0100 Subject: A Proposal To Magically Remove 'params' In-Reply-To: <21ee31950709030439t554a4f2dv40a3b84509676405@mail.gmail.com> References: <21ee31950709020417o6207b537w8cf7d5f1222a5baa@mail.gmail.com> <20070903093015.GA14613@uk.tiscali.com> <21ee31950709030439t554a4f2dv40a3b84509676405@mail.gmail.com> Message-ID: <20070903123014.GA24666@uk.tiscali.com> On Mon, Sep 03, 2007 at 01:39:59PM +0200, ry dahl wrote: > > I don't like the idea of my code having to be *parsed* to add magic > > 'parsed' isn't the right verb here. ParseTree isn't opening up the > file, reading in a string, and parsing it. It just traverses the > internal node structure that Ruby has already built up. OK, I understand. I'd be happier if Ruby had named parameter passing as a _standard_ feature of the language. It's been talked about for years :-) Since controller methods never take parameters normally, I guess that handling the case of controller(foo,bar) differently from controller() is fine. However I think the params hash should be kept exposed for those who want to use it. Regards, Brian. From hutch at recursive.ca Tue Sep 4 08:26:14 2007 From: hutch at recursive.ca (Bob Hutchison) Date: Tue, 4 Sep 2007 08:26:14 -0400 Subject: A Proposal To Magically Remove 'params' In-Reply-To: <21ee31950709020749t1fde1576p3f98ea94da5b467@mail.gmail.com> References: <21ee31950709020417o6207b537w8cf7d5f1222a5baa@mail.gmail.com> <862BF7D5-3096-41E7-BC5C-3AAA9BE4D909@gmail.com> <21ee31950709020749t1fde1576p3f98ea94da5b467@mail.gmail.com> Message-ID: Hi, On 2-Sep-07, at 10:49 AM, ry dahl wrote: > I would recommend keeping the params hash around for backwards > compatibility but with a depreciation warning. Another dissenting voice... I will not/cannot avoid the use of the params object in some of my applications. So, please, no deprecation. I don't care if Merb supported controller parameters or not, in principle. I doubt I'd ever use them, I prefer to look at the params object as an input data thing that needs to be inspected rather carefully. On the other hand, Merb is still mostly light and easy to understand, and starts very quickly -- it would be sad to see this end. Cheers, Bob ---- Bob Hutchison -- tumblelog at http:// www.recursive.ca/so/ Recursive Design Inc. -- weblog at http://www.recursive.ca/ hutch http://www.recursive.ca/ -- works on http://www.raconteur.info/ cms-for-static-content/home/ From james.herdman at gmail.com Tue Sep 4 13:22:33 2007 From: james.herdman at gmail.com (James Herdman) Date: Tue, 4 Sep 2007 13:22:33 -0400 Subject: Scripts and Rake Message-ID: <546b89120709041022g66aef998j643df35584c0e3fb@mail.gmail.com> I was wondering why both Rails and Merb opt for command-line scripts for generating components, such as models and controllers, and migrations versus using Rake scripts? Thank you, James H. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/merb-devel/attachments/20070904/d379bf6e/attachment.html From fernand.galiana at gmail.com Tue Sep 4 13:49:33 2007 From: fernand.galiana at gmail.com (Fernand Galiana) Date: Tue, 4 Sep 2007 11:49:33 -0600 Subject: Couple of questions for Merb 0.4 Message-ID: <8EBF3D44-E9C5-40AD-A968-B31F0CDF14AA@gmail.com> All, I have just updated to the latest release of merb 0.4 and I am wondering how I can get my controller changes to reload without bouncing the server ? I am running in dev mode but my changes to my merb controller don't seem to get picked up on new requests. Also say I have a controller that needs to render an alternate xml format ie something like: respond_to do |fmt| fmt.xml => { render :xml => true, :action => 'fred' } end where in fred.xerb I have xml.blee do xml.fred some_val ... end When I tried to run the following code I am getting a merb error on engine.transform where engine is nil ? undefined method `transform' for nil:NilClass - (NoMethodError) /usr/local/lib/ruby/gems/1.8/gems/merb-0.4.0/lib/merb/mixins/ render.rb:155:in `render' What am I missing ? -Fernand From fernand.galiana at gmail.com Tue Sep 4 16:32:28 2007 From: fernand.galiana at gmail.com (Fernand Galiana) Date: Tue, 4 Sep 2007 14:32:28 -0600 Subject: Xml templates... Message-ID: <30ab479c0709041332k2a4a7819k8eb054712b7a3864@mail.gmail.com> I was looking in using an xml_builder template to do something like: blee.xerb xml.blees do <% for blee in @blees %> xml.blee = blee.name <% end %> end It looks like the xml_builder template can't expand the erb tag. It this not the correct way to expand and xml template ? Thanks ! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/merb-devel/attachments/20070904/34e19fc5/attachment.html From B.Candler at pobox.com Tue Sep 4 16:46:07 2007 From: B.Candler at pobox.com (Brian Candler) Date: Tue, 4 Sep 2007 21:46:07 +0100 Subject: returning(...) ? Message-ID: <20070904204606.GA22162@uk.tiscali.com> The following construct is an ActiveSupport-ism: returning(Foo.new) do |foo| ... end I don't especially like it, since it's both more verbose and less efficient than the direct alternative: foo = Foo.new ... foo It doesn't occur many times in Merb, so does anyone agree with me that it should be removed? I tried doing this (patch attached) and I find the code more readable without. For example, in lib/merb/mixins/responder.rb Before: def <=>(entry) returning((entry.quality <=> quality).to_s) do |c| c.replace((index <=> entry.index).to_s) if c == '0' end.to_i end After: def <=>(entry) c = (entry.quality <=> quality).to_s c.replace((index <=> entry.index).to_s) if c == '0' c.to_i end This second form also more clearly begs the question, why is the result from <=> being converted to string and then back to integer? I don't know the answer to that :-) I believe the attached patch is OK - it doesn't break any specs. It doesn't remove the definition of Object#returning itself, or its spec. Regards, Brian. -------------- next part -------------- Index: lib/merb/gems.rb =================================================================== --- lib/merb/gems.rb (revision 508) +++ lib/merb/gems.rb (working copy) @@ -27,16 +27,16 @@ end def list_required(timing = :all) - returning({}) do |required| - with_manifest do |manifest| - manifest.each do |gem,options| - gem_when = (options["when"] || :after).to_sym - if timing == :all || gem_when == timing - required[gem] = options["version"] - end + required = {} + with_manifest do |manifest| + manifest.each do |gem,options| + gem_when = (options["when"] || :after).to_sym + if timing == :all || gem_when == timing + required[gem] = options["version"] end end end + required end def load_required(timing = :after) Index: lib/merb/mixins/responder.rb =================================================================== --- lib/merb/mixins/responder.rb (revision 508) +++ lib/merb/mixins/responder.rb (working copy) @@ -65,18 +65,18 @@ def self.parse(accept_header) # parse the raw accept header into a unique, sorted array of AcceptType objects - returning( accept_header.split(/,/).enum_for(:each_with_index).map do |entry,index| + list = accept_header.split(/,/).enum_for(:each_with_index).map do |entry,index| AcceptType.new(entry,index += 1) - end.sort.uniq ) do |list| - # firefox (and possibly other browsers) send broken default accept headers. - # fix them up by sorting alternate xml forms (namely application/xhtml+xml) - # ahead of pure xml types (application/xml,text/xml). - if app_xml = list.detect{|e| e.super_range == 'application/xml'} - list.select{|e| e.to_s =~ /\+xml/}.each { |acc_type| - list[list.index(acc_type)],list[list.index(app_xml)] = - list[list.index(app_xml)],list[list.index(acc_type)] } - end + end.sort.uniq + # firefox (and possibly other browsers) send broken default accept headers. + # fix them up by sorting alternate xml forms (namely application/xhtml+xml) + # ahead of pure xml types (application/xml,text/xml). + if app_xml = list.detect{|e| e.super_range == 'application/xml'} + list.select{|e| e.to_s =~ /\+xml/}.each { |acc_type| + list[list.index(acc_type)],list[list.index(app_xml)] = + list[list.index(app_xml)],list[list.index(acc_type)] } end + list end private @@ -128,9 +128,9 @@ end def <=>(entry) - returning((entry.quality <=> quality).to_s) do |c| - c.replace((index <=> entry.index).to_s) if c == '0' - end.to_i + c = (entry.quality <=> quality).to_s + c.replace((index <=> entry.index).to_s) if c == '0' + c.to_i end def eql?(entry) Index: lib/merb/template/erubis.rb =================================================================== --- lib/merb/template/erubis.rb (revision 508) +++ lib/merb/template/erubis.rb (working copy) @@ -40,12 +40,12 @@ return @@erbs[path] else begin - returning ::Erubis::MEruby.new(IO.read(path)) do |eruby| - eruby.init_evaluator :filename => path - if cache_template?(path) - @@erbs[path], @@mtimes[path] = eruby, Time.now - end - end + eruby = ::Erubis::MEruby.new(IO.read(path)) + eruby.init_evaluator :filename => path + if cache_template?(path) + @@erbs[path], @@mtimes[path] = eruby, Time.now + end + eruby rescue Errno::ENOENT raise "No template found at path: #{path}" end Index: lib/merb/mailer.rb =================================================================== --- lib/merb/mailer.rb (revision 508) +++ lib/merb/mailer.rb (working copy) @@ -52,9 +52,9 @@ def initialize(o={}) self.config = :sendmail if config.nil? o[:rawhtml] = o.delete(:html) - @mail = returning MailFactory.new() do |m| - o.each { |k,v| m.send "#{k}=", v } - end + m = MailFactory.new() + o.each { |k,v| m.send "#{k}=", v } + @mail = m end end From ivey at gweezlebur.com Tue Sep 4 16:47:59 2007 From: ivey at gweezlebur.com (Michael D. Ivey) Date: Tue, 4 Sep 2007 15:47:59 -0500 Subject: Xml templates... In-Reply-To: <30ab479c0709041332k2a4a7819k8eb054712b7a3864@mail.gmail.com> References: <30ab479c0709041332k2a4a7819k8eb054712b7a3864@mail.gmail.com> Message-ID: <7E5F5A57-3C3E-45C6-95EA-AC32D007223D@gweezlebur.com> On Sep 4, 2007, at 3:32 PM, Fernand Galiana wrote: > xml.blees do > <% for blee in @blees %> > xml.blee = blee.name > <% end %> > end Try xml.blees do @blees.each do |blee| xml.blee(blee.name) end end From B.Candler at pobox.com Tue Sep 4 16:49:14 2007 From: B.Candler at pobox.com (Brian Candler) Date: Tue, 4 Sep 2007 21:49:14 +0100 Subject: Xml templates... In-Reply-To: <30ab479c0709041332k2a4a7819k8eb054712b7a3864@mail.gmail.com> References: <30ab479c0709041332k2a4a7819k8eb054712b7a3864@mail.gmail.com> Message-ID: <20070904204914.GA22994@uk.tiscali.com> On Tue, Sep 04, 2007 at 02:32:28PM -0600, Fernand Galiana wrote: > I was looking in using an xml_builder template to do something like: > blee.xerb > xml.blees do > <% for blee in @blees %> > xml.blee = [1]blee.name > <% end %> > end > It looks like the xml_builder template can't expand the erb tag. > It this not the correct way to expand and xml template ? That's not xml_builder format, that's erb format. I think someone else came across the same issue, see http://merb.devjavu.com/projects/merb/ticket/162 From canadaduane at gmail.com Tue Sep 4 16:57:20 2007 From: canadaduane at gmail.com (Duane Johnson) Date: Tue, 4 Sep 2007 14:57:20 -0600 Subject: returning(...) ? In-Reply-To: <20070904204606.GA22162@uk.tiscali.com> References: <20070904204606.GA22162@uk.tiscali.com> Message-ID: On Sep 4, 2007, at 2:46 PM, Brian Candler wrote: > The following construct is an ActiveSupport-ism: > > returning(Foo.new) do |foo| > ... > end > > I don't especially like it, since it's both more verbose and less > efficient > than the direct alternative: > > foo = Foo.new > ... > foo > I think it should go too. It doesn't add much for readability (even though it removes one repeated noun) and seems quite a bit slower. Duane Johnson (canadaduane) From ez at engineyard.com Tue Sep 4 17:02:15 2007 From: ez at engineyard.com (Ezra Zygmuntowicz) Date: Tue, 4 Sep 2007 14:02:15 -0700 Subject: returning(...) ? In-Reply-To: References: <20070904204606.GA22162@uk.tiscali.com> Message-ID: <230E42DB-1439-4E2B-A2F0-EDE3E40DF178@engineyard.com> On Sep 4, 2007, at 1:57 PM, Duane Johnson wrote: > > On Sep 4, 2007, at 2:46 PM, Brian Candler wrote: > >> The following construct is an ActiveSupport-ism: >> >> returning(Foo.new) do |foo| >> ... >> end >> >> I don't especially like it, since it's both more verbose and less >> efficient >> than the direct alternative: >> >> foo = Foo.new >> ... >> foo >> > > I think it should go too. It doesn't add much for readability (even > though it removes one repeated noun) and seems quite a bit slower. > > Duane Johnson > (canadaduane) > I'm fine with axing it. Cheers -- Ezra Zygmuntowicz -- Founder & Ruby Hacker -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) From B.Candler at pobox.com Tue Sep 4 17:26:26 2007 From: B.Candler at pobox.com (Brian Candler) Date: Tue, 4 Sep 2007 22:26:26 +0100 Subject: returning(...) ? In-Reply-To: <230E42DB-1439-4E2B-A2F0-EDE3E40DF178@engineyard.com> References: <20070904204606.GA22162@uk.tiscali.com> <230E42DB-1439-4E2B-A2F0-EDE3E40DF178@engineyard.com> Message-ID: <20070904212626.GA24630@uk.tiscali.com> On Tue, Sep 04, 2007 at 02:02:15PM -0700, Ezra Zygmuntowicz wrote: > I'm fine with axing it. Should Merb's definition of Object#returning also go? Anybody who wants to use ActiveSupport can still require it themselves. Now that Merb is aiming to be ORM-neutral, perhaps extra care needs to be taken with core_ext. Some users won't have ActiveSupport loaded, but others will (e.g. because they are using ActiveRecord). There's a risk that Merb's core extensions may clash with or be incompatible with an ORM's extensions with the same method names. Hash#to_xml and Hash.from_xml are particular examples that spring to mind. Regards, Brian. From fernand.galiana at gmail.com Tue Sep 4 17:37:02 2007 From: fernand.galiana at gmail.com (Fernand Galiana) Date: Tue, 4 Sep 2007 15:37:02 -0600 Subject: Xml templates... In-Reply-To: <20070904204914.GA22994@uk.tiscali.com> References: <30ab479c0709041332k2a4a7819k8eb054712b7a3864@mail.gmail.com> <20070904204914.GA22994@uk.tiscali.com> Message-ID: <30ab479c0709041437j65cc1255j485f2dc811f57706@mail.gmail.com> Thanks Brian - Well erb sure but I still would like to get the xml builder object bound to the template. That's the essence of my question ie being able to embed erb tag within my xml template. -Fernand On 9/4/07, Brian Candler wrote: > > On Tue, Sep 04, 2007 at 02:32:28PM -0600, Fernand Galiana wrote: > > I was looking in using an xml_builder template to do something like: > > blee.xerb > > xml.blees do > > <% for blee in @blees %> > > xml.blee = [1]blee.name > > <% end %> > > end > > It looks like the xml_builder template can't expand the erb tag. > > It this not the correct way to expand and xml template ? > > That's not xml_builder format, that's erb format. > > I think someone else came across the same issue, see > http://merb.devjavu.com/projects/merb/ticket/162 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/merb-devel/attachments/20070904/48283d27/attachment.html From ry at tinyclouds.org Tue Sep 4 17:54:38 2007 From: ry at tinyclouds.org (ry dahl) Date: Tue, 4 Sep 2007 23:54:38 +0200 Subject: A Proposal To Magically Remove 'params' In-Reply-To: <21ee31950709030439t554a4f2dv40a3b84509676405@mail.gmail.com> References: <21ee31950709020417o6207b537w8cf7d5f1222a5baa@mail.gmail.com> <20070903093015.GA14613@uk.tiscali.com> <21ee31950709030439t554a4f2dv40a3b84509676405@mail.gmail.com> Message-ID: <21ee31950709041454q2927862u7774c2fb369326ac@mail.gmail.com> Here is an extension which allows one to inspect the arguments of a method. To use it do this: require 'method_args' m = my_object.method(:my_method) m.args http://s3.amazonaws.com/four.livejournal/20070904/method_args-0.0.1.zip http://s3.amazonaws.com/four.livejournal/20070904/method_args-0.0.1.gem So - now that we have a quick simple extension, what would people say about arguments to actions? ry From fernand.galiana at gmail.com Tue Sep 4 19:26:56 2007 From: fernand.galiana at gmail.com (Fernand Galiana) Date: Tue, 4 Sep 2007 17:26:56 -0600 Subject: Xml templates... Message-ID: <242936EA-B7DC-4C30-A1EA-C6AEEB145BEE@gmail.com> Doh ! Of course... Thanks Michael !! From scaudill at gmail.com Tue Sep 4 19:37:24 2007 From: scaudill at gmail.com (Stephen Caudill) Date: Tue, 4 Sep 2007 19:37:24 -0400 Subject: returning(...) ? In-Reply-To: <20070904204606.GA22162@uk.tiscali.com> References: <20070904204606.GA22162@uk.tiscali.com> Message-ID: On Sep 4, 2007, at 4:46 PM, Brian Candler wrote: > > Before: > > def <=>(entry) > returning((entry.quality <=> quality).to_s) do |c| > c.replace((index <=> entry.index).to_s) if c == '0' > end.to_i > end > > After: > > def <=>(entry) > c = (entry.quality <=> quality).to_s > c.replace((index <=> entry.index).to_s) if c == '0' > c.to_i > end Ah... That'd be me. I'm still fond of the k-combinator, but not so fond of it that I can't see a misuse these days :) The .to_s and then subsequent .to_i were merely facilitators to being able to use returning. That snippet would probably be best rewritten as: def <=>(entry) c = entry.quality <=> quality c = index <=> entry.index if c == 0 c end specs still pass with that change made. -- Stephen Caudill (voxdolo) From scaudill at gmail.com Tue Sep 4 19:46:58 2007 From: scaudill at gmail.com (Stephen Caudill) Date: Tue, 4 Sep 2007 19:46:58 -0400 Subject: returning(...) ? In-Reply-To: <20070904204606.GA22162@uk.tiscali.com> References: <20070904204606.GA22162@uk.tiscali.com> Message-ID: <28796A57-03E4-4366-AC50-50D8B8474879@gmail.com> Fixed this in r511. I still think there's a time and a place for that pattern. It's not magical and it follows a clear precedent in good OO design. It is decidedly *not* as performant as it's sometimes longer handed counterpart, but Ruby is a language in which the value of being succinct is frequently more important than being very fast. I'd rather not sacrifice a bit of beauty in my code for a few milliseconds parsing difference, since most of the overhead occurs in method dispatch. just my 2? -- Stephen Caudill (voxdolo) On Sep 4, 2007, at 4:46 PM, Brian Candler wrote: > The following construct is an ActiveSupport-ism: > > returning(Foo.new) do |foo| > ... > end > > I don't especially like it, since it's both more verbose and less > efficient > than the direct alternative: > > foo = Foo.new > ... > foo > > It doesn't occur many times in Merb, so does anyone agree with me > that it > should be removed? > > I tried doing this (patch attached) and I find the code more readable > without. For example, in lib/merb/mixins/responder.rb > > Before: > > def <=>(entry) > returning((entry.quality <=> quality).to_s) do |c| > c.replace((index <=> entry.index).to_s) if c == '0' > end.to_i > end > > After: > > def <=>(entry) > c = (entry.quality <=> quality).to_s > c.replace((index <=> entry.index).to_s) if c == '0' > c.to_i > end > > This second form also more clearly begs the question, why is the > result from > <=> being converted to string and then back to integer? I don't > know the > answer to that :-) > > I believe the attached patch is OK - it doesn't break any specs. It > doesn't > remove the definition of Object#returning itself, or its spec. > > Regards, > > Brian. > > _______________________________________________ > Merb-devel mailing list > Merb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/merb-devel From zackchandler at gmail.com Tue Sep 4 21:37:20 2007 From: zackchandler at gmail.com (Zack Chandler) Date: Tue, 4 Sep 2007 18:37:20 -0700 Subject: returning(...) ? In-Reply-To: <28796A57-03E4-4366-AC50-50D8B8474879@gmail.com> References: <20070904204606.GA22162@uk.tiscali.com> <28796A57-03E4-4366-AC50-50D8B8474879@gmail.com> Message-ID: <33841ac70709041837p5343083fwe6548dab2690cd7@mail.gmail.com> I like having the options of using the syntax sugar (when appropriate) of returning and with_options. I totally agree that the framework can do without due these idioms due to performance requirements but as an app developer I'd like the option where cleanliness/beauty is valued more than a small speedup. Zack On 9/4/07, Stephen Caudill wrote: > Fixed this in r511. > > I still think there's a time and a place for that pattern. It's not > magical and it follows a clear precedent in good OO design. It is > decidedly *not* as performant as it's sometimes longer handed > counterpart, but Ruby is a language in which the value of being > succinct is frequently more important than being very fast. I'd > rather not sacrifice a bit of beauty in my code for a few > milliseconds parsing difference, since most of the overhead occurs in > method dispatch. > > just my 2? > > -- > > Stephen Caudill (voxdolo) > > On Sep 4, 2007, at 4:46 PM, Brian Candler wrote: > > > The following construct is an ActiveSupport-ism: > > > > returning(Foo.new) do |foo| > > ... > > end > > > > I don't especially like it, since it's both more verbose and less > > efficient > > than the direct alternative: > > > > foo = Foo.new > > ... > > foo > > > > It doesn't occur many times in Merb, so does anyone agree with me > > that it > > should be removed? > > > > I tried doing this (patch attached) and I find the code more readable > > without. For example, in lib/merb/mixins/responder.rb > > > > Before: > > > > def <=>(entry) > > returning((entry.quality <=> quality).to_s) do |c| > > c.replace((index <=> entry.index).to_s) if c == '0' > > end.to_i > > end > > > > After: > > > > def <=>(entry) > > c = (entry.quality <=> quality).to_s > > c.replace((index <=> entry.index).to_s) if c == '0' > > c.to_i > > end > > > > This second form also more clearly begs the question, why is the > > result from > > <=> being converted to string and then back to integer? I don't > > know the > > answer to that :-) > > > > I believe the attached patch is OK - it doesn't break any specs. It > > doesn't > > remove the definition of Object#returning itself, or its spec. > > > > Regards, > > > > Brian. > > > > _______________________________________________ > > Merb-devel mailing list > > Merb-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/merb-devel > > _______________________________________________ > Merb-devel mailing list > Merb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/merb-devel > From has.sox at gmail.com Wed Sep 5 01:12:47 2007 From: has.sox at gmail.com (Daniel N) Date: Wed, 5 Sep 2007 15:12:47 +1000 Subject: Official Plugins - What should they be Message-ID: <2fff50390709042212k75b4d411vad4a2ada53f99b23@mail.gmail.com> There's been a lot of discussion on the #merb channel lately about official plugins. I'm starting this thread and hoping to get some discussion as to what these official plugins should be, at least in the lead-up to revision 1.0 So far as I have seen on the #merb these are: ORM's merb_active_record merb_sequel merb_datamapper and merb_form_controls - there is a ticket for this one on trac As I understand it, these would be hosted on the merb track so that only merb commiters can update them, hence they remain official. Also I think the idea of some kind of merb_autorization would not be out of place. Cheers Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/merb-devel/attachments/20070905/df620344/attachment-0001.html From B.Candler at pobox.com Wed Sep 5 01:35:25 2007 From: B.Candler at pobox.com (Brian Candler) Date: Wed, 5 Sep 2007 06:35:25 +0100 Subject: returning(...) ? In-Reply-To: <33841ac70709041837p5343083fwe6548dab2690cd7@mail.gmail.com> References: <20070904204606.GA22162@uk.tiscali.com> <28796A57-03E4-4366-AC50-50D8B8474879@gmail.com> <33841ac70709041837p5343083fwe6548dab2690cd7@mail.gmail.com> Message-ID: <20070905053525.GA15693@uk.tiscali.com> On Tue, Sep 04, 2007 at 06:37:20PM -0700, Zack Chandler wrote: > I like having the options of using the syntax sugar (when appropriate) > of returning and with_options. I totally agree that the framework can > do without due these idioms due to performance requirements but as an > app developer I'd like the option where cleanliness/beauty is valued > more than a small speedup. I think this should be considered as two aspects: (1) Merb providing these constructs for application writers to use (2) Merb using these constructs itself For case (1), I have no problem with Merb providing an ActiveSupport-like feature bundle for users. My concern is whether Merb's extensions to Object, Hash etc would clash with similar extensions, like ActiveSupport. For case (2), this problem becomes more acute, since (for example) Merb may rely on a particular behaviour of Hash.from_xml, but ActiveSupport may implement Hash.from_xml differently, and itself rely on this different behaviour. It gets even more acute with people running Merb and Rails side-by-side in the same process. To solve this, I am pondering along the following lines: * Merb implements all these extension methods in a distinct namespace, e.g. Hash.merb_from_xml (or perhaps, for class methods, Merb::Hash.from_xml) * Merb's internal use of these constructs uses these distinct names * If a user 'require's a specific library, then these get aliased to the expected names, e.g. Hash.from_xml This means that: - Merb and language extensions (e.g. ActiveSupport/Facets/other ORM/other extensions) can be loaded simultaneously - Merb won't affect the behaviour of the extension library, and vice versa - If a programmer wants to use Merb's implementation of these language extensions, they are available given a 'require' Thoughts? Brian. From B.Candler at pobox.com Wed Sep 5 01:43:16 2007 From: B.Candler at pobox.com (Brian Candler) Date: Wed, 5 Sep 2007 06:43:16 +0100 Subject: Couple of questions for Merb 0.4 In-Reply-To: <8EBF3D44-E9C5-40AD-A968-B31F0CDF14AA@gmail.com> References: <8EBF3D44-E9C5-40AD-A968-B31F0CDF14AA@gmail.com> Message-ID: <20070905054316.GB15693@uk.tiscali.com> On Tue, Sep 04, 2007 at 11:49:33AM -0600, Fernand Galiana wrote: > I have just updated to the latest release of merb 0.4 and I am > wondering how I can get my controller changes > to reload without bouncing the server ? I am running in dev mode > but my changes to my merb controller don't > seem to get picked up on new requests. > > Also say I have a controller that needs to render an alternate > xml format ie something like: > > respond_to do |fmt| > fmt.xml => { render :xml => true, :action => 'fred' } > end > > where in fred.xerb I have > > xml.blee do > xml.fred some_val > ... > end > > When I tried to run the following code I am getting a merb error on > engine.transform where engine is nil ? > > undefined method `transform' for nil:NilClass - (NoMethodError) > /usr/local/lib/ruby/gems/1.8/gems/merb-0.4.0/lib/merb/mixins/ > render.rb:155:in `render' I don't think there has been a "release" of merb 0.4. You need to report your subversion revision number, as shown by "svn info": $ svn info Path: . URL: http://svn.devjavu.com/merb/trunk Repository Root: http://svn.devjavu.com/merb Repository UUID: 47880103-7c1f-0410-8e14-d6dd2138f79d Revision: 516 <<<<<<<<<<<< this number Node Kind: directory Schedule: normal Last Changed Author: ez at brainspl.at Last Changed Rev: 516 I only say this because if you are running r422 or later, you should get a more helpful error message ("no template matching ") rather than "undefined method `transform' for nil" Regards, Brian. From B.Candler at pobox.com Wed Sep 5 03:36:26 2007 From: B.Candler at pobox.com (Brian Candler) Date: Wed, 5 Sep 2007 08:36:26 +0100 Subject: returning(...) ? In-Reply-To: <20070905053525.GA15693@uk.tiscali.com> References: <20070904204606.GA22162@uk.tiscali.com> <28796A57-03E4-4366-AC50-50D8B8474879@gmail.com> <33841ac70709041837p5343083fwe6548dab2690cd7@mail.gmail.com> <20070905053525.GA15693@uk.tiscali.com> Message-ID: <20070905073625.GA21819@uk.tiscali.com> On Wed, Sep 05, 2007 at 06:35:25AM +0100, Brian Candler wrote: > To solve this, I am pondering along the following lines: > > * Merb implements all these extension methods in a distinct namespace, > e.g. Hash.merb_from_xml (or perhaps, for class methods, Merb::Hash.from_xml) > > * Merb's internal use of these constructs uses these distinct names > > * If a user 'require's a specific library, then these get aliased to the > expected names, e.g. Hash.from_xml I just noticed another mail saying there are now "supported plugins" in the tree. So I propose: 1. Move core_ext into a supported plugin. Where Merb itself currently makes use of features within core_ext: 2. If it can be changed to use native Ruby instead, without making the code harder to maintain or significantly slower, then do that. 3. Otherwise, put the method in merb's own core_ext but with a private name, e.g. "merb_foo". The public core_ext will alias this to a more common name, e.g. "foo" The core_ext plugin needs to have its own separate specs, so that Merb's own specs prove that it works without the core_ext plugin. This gives users of Merb three options: - don't use core extensions - use Merb's core extensions plugin - use someone else's core extensions (e.g. ActiveSupport), which may be necessary in the case where an ORM depends on it (e.g. ActiveRecord) Comments? Brian. P.S. I think the plugins directory should have a trunk/tags/branches structure, so that when merb-x.x.x is released, a matching set of plugins can also be tagged. Users can always choose to install a more recent version of the plugin, but this is at their own risk. From B.Candler at pobox.com Wed Sep 5 03:39:40 2007 From: B.Candler at pobox.com (Brian Candler) Date: Wed, 5 Sep 2007 08:39:40 +0100 Subject: A Proposal To Magically Remove 'params' In-Reply-To: <21ee31950709041454q2927862u7774c2fb369326ac@mail.gmail.com> References: <21ee31950709020417o6207b537w8cf7d5f1222a5baa@mail.gmail.com> <20070903093015.GA14613@uk.tiscali.com> <21ee31950709030439t554a4f2dv40a3b84509676405@mail.gmail.com> <21ee31950709041454q2927862u7774c2fb369326ac@mail.gmail.com> Message-ID: <20070905073940.GB21819@uk.tiscali.com> On Tue, Sep 04, 2007 at 11:54:38PM +0200, ry dahl wrote: > Here is an extension which allows one to inspect the arguments of a > method. To use it do this: > require 'method_args' > m = my_object.method(:my_method) > m.args > > http://s3.amazonaws.com/four.livejournal/20070904/method_args-0.0.1.zip > http://s3.amazonaws.com/four.livejournal/20070904/method_args-0.0.1.gem > > So - now that we have a quick simple extension, what would people say > about arguments to actions? $ sudo gem install method_args-0.0.1.gem Password: ERROR: While executing gem ... (RuntimeError) Error instaling method_args-0.0.1.gem: method_args requires Ruby version >= 1.8.6 $ ruby -v ruby 1.8.4 (2005-12-24) [i486-linux] Most distros don't have 1.8.6 included as standard yet (this machine is Ubuntu-6.06.1). So if method_args really needs 1.8.6, I think its audience will be limited for the time being. Regards, Brian. From B.Candler at pobox.com Wed Sep 5 03:59:22 2007 From: B.Candler at pobox.com (Brian Candler) Date: Wed, 5 Sep 2007 08:59:22 +0100 Subject: Xml templates... In-Reply-To: <30ab479c0709041437j65cc1255j485f2dc811f57706@mail.gmail.com> References: <30ab479c0709041332k2a4a7819k8eb054712b7a3864@mail.gmail.com> <20070904204914.GA22994@uk.tiscali.com> <30ab479c0709041437j65cc1255j485f2dc811f57706@mail.gmail.com> Message-ID: <20070905075922.GC21819@uk.tiscali.com> On Tue, Sep 04, 2007 at 03:37:02PM -0600, Fernand Galiana wrote: > Thanks Brian - Well erb sure but I still would like to get the xml > builder object > bound to the template. That's the essence of my question ie being able > to embed > erb tag within my xml template. I think you need to choose one or the other. (1) Do you want to write your template in XmlBuilder style? In that case, you can't embed <% .. %>. However you don't need to, as a builder template is just Ruby code. If you want to write "for blee in @blees" you just write that; there's no need to encode it in Erb-style tags. http://builder.rubyforge.org/ (2) Do you want to write your template in Erb style? In that case the template would look something like <% for blee in @blees %> <%=h blee.name %> However if you do this, and your template is called blees.erb, then until recently Merb would send it as text/html rather than text/xml. That's what ticket 162 is about. Regards, Brian. From has.sox at gmail.com Wed Sep 5 05:09:43 2007 From: has.sox at gmail.com (Daniel N) Date: Wed, 5 Sep 2007 19:09:43 +1000 Subject: Fwd: Official Plugins - What should they be In-Reply-To: <8596653B-B61B-4B4F-A547-9AF7536640E3@gmail.com> References: <2fff50390709042212k75b4d411vad4a2ada53f99b23@mail.gmail.com> <8596653B-B61B-4B4F-A547-9AF7536640E3@gmail.com> Message-ID: <2fff50390709050209n26ab3faam4892687c87abb386@mail.gmail.com> Forwarded to list ---------- Forwarded message ---------- From: Luke Sutton Date: Sep 5, 2007 6:51 PM Subject: Re: Official Plugins - What should they be To: Daniel N > and > merb_form_controls - there is a ticket for this one on trac Aren't some of form controls ORM specific? Perhaps the form controls plugin could form some base that the ORM specific plugins then build on top of? > As I understand it, these would be hosted on the merb track so that > only merb commiters can update them, hence they remain official. > > Also I think the idea of some kind of merb_autorization would not > be out of place. I think that anything that generates HTML should go into a plugin as well. I've heard some people say they want to use merb as a REST server etc, in which case they don't need them. -- Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/merb-devel/attachments/20070905/e0742923/attachment.html From scaudill at gmail.com Wed Sep 5 09:56:36 2007 From: scaudill at gmail.com (Stephen Caudill) Date: Wed, 5 Sep 2007 09:56:36 -0400 Subject: returning(...) ? In-Reply-To: <20070905073625.GA21819@uk.tiscali.com> References: <20070904204606.GA22162@uk.tiscali.com> <28796A57-03E4-4366-AC50-50D8B8474879@gmail.com> <33841ac70709041837p5343083fwe6548dab2690cd7@mail.gmail.com> <20070905053525.GA15693@uk.tiscali.com> <20070905073625.GA21819@uk.tiscali.com> Message-ID: <966CF7D7-46D8-4610-8C37-948053814E33@gmail.com> On Sep 5, 2007, at 3:36 AM, Brian Candler wrote: > On Wed, Sep 05, 2007 at 06:35:25AM +0100, Brian Candler wrote: >> To solve this, I am pondering along the following lines: >> >> * Merb implements all these extension methods in a distinct >> namespace, >> e.g. Hash.merb_from_xml (or perhaps, for class methods, >> Merb::Hash.from_xml) >> >> * Merb's internal use of these constructs uses these distinct names >> >> * If a user 'require's a specific library, then these get aliased >> to the >> expected names, e.g. Hash.from_xml > > I just noticed another mail saying there are now "supported > plugins" in the > tree. > > So I propose: > > 1. Move core_ext into a supported plugin. > > Where Merb itself currently makes use of features within core_ext: > > 2. If it can be changed to use native Ruby instead, without making > the code > harder to maintain or significantly slower, then do that. > > 3. Otherwise, put the method in merb's own core_ext but with a > private name, > e.g. "merb_foo". The public core_ext will alias this to a more > common > name, e.g. "foo" > > The core_ext plugin needs to have its own separate specs, so that > Merb's own > specs prove that it works without the core_ext plugin. > > This gives users of Merb three options: > - don't use core extensions > - use Merb's core extensions plugin > - use someone else's core extensions (e.g. ActiveSupport), which > may be > necessary in the case where an ORM depends on it (e.g. ActiveRecord) > > Comments? I think this is extreme. I appreciate the sentiment, but as a committer, I'd still like to have a library at hand to provide conveniences. I'm not opposed to that library living in an insular namespace > P.S. I think the plugins directory should have a trunk/tags/branches > structure, so that when merb-x.x.x is released, a matching set of > plugins > can also be tagged. Users can always choose to install a more > recent version > of the plugin, but this is at their own risk. Sounds like a good idea. From scaudill at gmail.com Wed Sep 5 10:01:44 2007 From: scaudill at gmail.com (Stephen Caudill) Date: Wed, 5 Sep 2007 10:01:44 -0400 Subject: returning(...) ? In-Reply-To: <20070905073625.GA21819@uk.tiscali.com> References: <20070904204606.GA22162@uk.tiscali.com> <28796A57-03E4-4366-AC50-50D8B8474879@gmail.com> <33841ac70709041837p5343083fwe6548dab2690cd7@mail.gmail.com> <20070905053525.GA15693@uk.tiscali.com> <20070905073625.GA21819@uk.tiscali.com> Message-ID: <1EDF60B4-39D6-4B64-899F-2E409266BCEB@gmail.com> On Sep 5, 2007, at 3:36 AM, Brian Candler wrote: > This gives users of Merb three options: > - don't use core extensions > - use Merb's core extensions plugin > - use someone else's core extensions (e.g. ActiveSupport), which > may be > necessary in the case where an ORM depends on it (e.g. ActiveRecord) > > Comments? Bah.. got trigger happy with the send button. Just to complete my thought: I'm not opposed to that library living in an insular namespace for internal use so it wouldn't collide with ActiveSupport or Facets. But when it gets down to brass tacks, as a developer of merb, I'd still like to have our own internal lib of methods I can rely on to behave in a certain manner. -- Stephen Caudill (voxdolo) From ry at tinyclouds.org Wed Sep 5 10:13:20 2007 From: ry at tinyclouds.org (ry dahl) Date: Wed, 5 Sep 2007 16:13:20 +0200 Subject: A Proposal To Magically Remove 'params' In-Reply-To: <20070905073940.GB21819@uk.tiscali.com> References: <21ee31950709020417o6207b537w8cf7d5f1222a5baa@mail.gmail.com> <20070903093015.GA14613@uk.tiscali.com> <21ee31950709030439t554a4f2dv40a3b84509676405@mail.gmail.com> <21ee31950709041454q2927862u7774c2fb369326ac@mail.gmail.com> <20070905073940.GB21819@uk.tiscali.com> Message-ID: <21ee31950709050713g1c63eaf7l9a1fcffa96f1f457@mail.gmail.com> Hi Brian, Luis, Sorry for the confusion - it actually doesn't depend on 1.8.6, I just didn't test it on others. Seems to work down to 1.8.4 and it is almost working for 1.9. It also would conceivably work for lower versions (one just needs to test it out). Luis, I don't know anything about Visual C, but if Mongrel is compiling with it certainly this should. Look at the extconf.rb, there is nothing to it. I've updated a few things in the extension: lowered the required ruby version and added support for splat arguments. I won't be posting here anymore about this extension (it's getting its own RubyForge project) but please check out the revision: http://s3.amazonaws.com/four.livejournal/20070905/method_args-0.0.2.gem http://s3.amazonaws.com/four.livejournal/20070905/method_args-0.0.2.zip Try it out and then go sit outside in the cool grass, under the warm sun, and dream about how nice it would be to use arguments instead of params. We could even keep params around (at no extra speed cost and not depreciated) for those who enjoy typing. def show(id) @product = Product.find(id) render end The extension is a mere 160 lines of C code. It runs quickly and it seems to work rather well. Bob Hutchison wrote: > Another dissenting voice... I will not/cannot avoid the use of the > params object in some of my applications. So, please, no deprecation. > I don't care if Merb supported controller parameters or not, in > principle. I doubt I'd ever use them, I prefer to look at the params > object as an input data thing that needs to be inspected rather > carefully. On the other hand, Merb is still mostly light and easy to > understand, and starts very quickly -- it would be sad to see this end. Bob, in what way are you using params? Why can't you avoid it? I think you are not thinking about this correctly. ry From josh at hasmanythrough.com Wed Sep 5 10:28:19 2007 From: josh at hasmanythrough.com (Josh Susser) Date: Wed, 5 Sep 2007 07:28:19 -0700 Subject: returning(...) ? In-Reply-To: <33841ac70709041837p5343083fwe6548dab2690cd7@mail.gmail.com> References: <20070904204606.GA22162@uk.tiscali.com> <28796A57-03E4-4366-AC50-50D8B8474879@gmail.com> <33841ac70709041837p5343083fwe6548dab2690cd7@mail.gmail.com> Message-ID: returning() as the k-combinator is fairly cool, but I like the more object-oriented Object#tap better, and it's going to be standard in Ruby 1.9 too. See http://eigenclass.org/hiki.rb?Changes+in+Ruby+1.9#l25 I've read different things about the overhead of returning()/tap, ranging from mildly more overhead to significant, but haven't done any measurements myself. But either way, we can make it kick butt in Rubinius, so you should be able to use it guilt-free someday. --josh On Sep 4, 2007, at 6:37 PM, Zack Chandler wrote: > I like having the options of using the syntax sugar (when appropriate) > of returning and with_options. I totally agree that the framework can > do without due these idioms due to performance requirements but as an > app developer I'd like the option where cleanliness/beauty is valued > more than a small speedup. > > Zack > > On 9/4/07, Stephen Caudill wrote: >> Fixed this in r511. >> >> I still think there's a time and a place for that pattern. It's not >> magical and it follows a clear precedent in good OO design. It is >> decidedly *not* as performant as it's sometimes longer handed >> counterpart, but Ruby is a language in which the value of being >> succinct is frequently more important than being very fast. I'd >> rather not sacrifice a bit of beauty in my code for a few >> milliseconds parsing difference, since most of the overhead occurs in >> method dispatch. >> >> just my 2? >> >> -- >> >> Stephen Caudill (voxdolo) >> >> On Sep 4, 2007, at 4:46 PM, Brian Candler wrote: >> >>> The following construct is an ActiveSupport-ism: >>> >>> returning(Foo.new) do |foo| >>> ... >>> end >>> >>> I don't especially like it, since it's both more verbose and less >>> efficient >>> than the direct alternative: >>> >>> foo = Foo.new >>> ... >>> foo >>> >>> It doesn't occur many times in Merb, so does anyone agree with me >>> that it >>> should be removed? >>> >>> I tried doing this (patch attached) and I find the code more >>> readable >>> without. For example, in lib/merb/mixins/responder.rb >>> >>> Before: >>> >>> def <=>(entry) >>> returning((entry.quality <=> quality).to_s) do |c| >>> c.replace((index <=> entry.index).to_s) if c == '0' >>> end.to_i >>> end >>> >>> After: >>> >>> def <=>(entry) >>> c = (entry.quality <=> quality).to_s >>> c.replace((index <=> entry.index).to_s) if c == '0' >>> c.to_i >>> end >>> >>> This second form also more clearly begs the question, why is the >>> result from >>> <=> being converted to string and then back to integer? I don't >>> know the >>> answer to that :-) >>> >>> I believe the attached patch is OK - it doesn't break any specs. It >>> doesn't >>> remove the definition of Object#returning itself, or its spec. >>> >>> Regards, >>> >>> Brian. -- Josh Susser http://blog.hasmanythrough.com From fernand.galiana at gmail.com Wed Sep 5 13:48:38 2007 From: fernand.galiana at gmail.com (Fernand Galiana) Date: Wed, 5 Sep 2007 11:48:38 -0600 Subject: Reloading ?? Message-ID: <30ab479c0709051048i173c0e53n1cac00de1ddd1ef9@mail.gmail.com> All, So I got passed my initial hurdles with merb 0.4. And all seems to work very nicely. Thank you all for your help ! One thing though, why should I have to bounce the merb server when I change my controller or associated classes ? Am I missing something ? I am having flash back to my java days where I now have to reflect on what changed and bounce the server accordingly... -Fernand -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/merb-devel/attachments/20070905/6aaec4b9/attachment.html From ez at engineyard.com Wed Sep 5 13:52:07 2007 From: ez at engineyard.com (Ezra Zygmuntowicz) Date: Wed, 5 Sep 2007 10:52:07 -0700 Subject: Reloading ?? In-Reply-To: <30ab479c0709051048i173c0e53n1cac00de1ddd1ef9@mail.gmail.com> References: <30ab479c0709051048i173c0e53n1cac00de1ddd1ef9@mail.gmail.com> Message-ID: <18B0ED1E-6B20-4D97-90FE-9F5ED3E761AE@engineyard.com> On Sep 5, 2007, at 10:48 AM, Fernand Galiana wrote: > All, > > So I got passed my initial hurdles with merb 0.4. And all seems > to work very nicely. > Thank you all for your help ! > > One thing though, why should I have to bounce the merb server > when I change > my controller or associated classes ? Am I missing something ? > > I am having flash back to my java days where I now have to > reflect on what changed > and bounce the server accordingly... > > -Fernand > Wayne and Duane are working on the merb reloader pretty hard. It shoudl be done today or tomorrow so bear with us. Thanks -- Ezra Zygmuntowicz -- Founder & Ruby Hacker -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) From canadaduane at gmail.com Wed Sep 5 14:31:22 2007 From: canadaduane at gmail.com (Duane Johnson) Date: Wed, 5 Sep 2007 12:31:22 -0600 Subject: Reloading ?? In-Reply-To: <18B0ED1E-6B20-4D97-90FE-9F5ED3E761AE@engineyard.com> References: <30ab479c0709051048i173c0e53n1cac00de1ddd1ef9@mail.gmail.com> <18B0ED1E-6B20-4D97-90FE-9F5ED3E761AE@engineyard.com> Message-ID: <2014A697-8AE6-4951-94A7-E2827A5B207C@gmail.com> The latest code is checked in now, and it stands ready to use you as a guinea pig :) Duane Johnson (canadaduane) On Sep 5, 2007, at 11:52 AM, Ezra Zygmuntowicz wrote: > > On Sep 5, 2007, at 10:48 AM, Fernand Galiana wrote: > >> All, >> >> So I got passed my initial hurdles with merb 0.4. And all seems >> to work very nicely. >> Thank you all for your help ! >> >> One thing though, why should I have to bounce the merb server >> when I change >> my controller or associated classes ? Am I missing something ? >> >> I am having flash back to my java days where I now have to >> reflect on what changed >> and bounce the server accordingly... >> >> -Fernand >> > > > Wayne and Duane are working on the merb reloader pretty hard. It > shoudl be done today or tomorrow so bear with us. > > Thanks > -- Ezra Zygmuntowicz > -- Founder & Ruby Hacker > -- ez at engineyard.com > -- Engine Yard, Serious Rails Hosting > -- (866) 518-YARD (9273) > > > _______________________________________________ > Merb-devel mailing list > Merb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/merb-devel From fernand.galiana at gmail.com Wed Sep 5 15:03:12 2007 From: fernand.galiana at gmail.com (Fernand Galiana) Date: Wed, 5 Sep 2007 13:03:12 -0600 Subject: Reloading ?? In-Reply-To: <2014A697-8AE6-4951-94A7-E2827A5B207C@gmail.com> References: <30ab479c0709051048i173c0e53n1cac00de1ddd1ef9@mail.gmail.com> <18B0ED1E-6B20-4D97-90FE-9F5ED3E761AE@engineyard.com> <2014A697-8AE6-4951-94A7-E2827A5B207C@gmail.com> Message-ID: <30ab479c0709051203r4c4a375ay6d458e2fe39594ab@mail.gmail.com> Awsome !! I'll take her out for a rip. Thanks for addressing this issue... -Fernand On 9/5/07, Duane Johnson wrote: > > The latest code is checked in now, and it stands ready to use you as > a guinea pig :) > > Duane Johnson > (canadaduane) > > On Sep 5, 2007, at 11:52 AM, Ezra Zygmuntowicz wrote: > > > > > On Sep 5, 2007, at 10:48 AM, Fernand Galiana wrote: > > > >> All, > >> > >> So I got passed my initial hurdles with merb 0.4. And all seems > >> to work very nicely. > >> Thank you all for your help ! > >> > >> One thing though, why should I have to bounce the merb server > >> when I change > >> my controller or associated classes ? Am I missing something ? > >> > >> I am having flash back to my java days where I now have to > >> reflect on what changed > >> and bounce the server accordingly... > >> > >> -Fernand > >> > > > > > > Wayne and Duane are working on the merb reloader pretty hard. It > > shoudl be done today or tomorrow so bear with us. > > > > Thanks > > -- Ezra Zygmuntowicz > > -- Founder & Ruby Hacker > > -- ez at engineyard.com > > -- Engine Yard, Serious Rails Hosting > > -- (866) 518-YARD (9273) > > > > > > _______________________________________________ > > Merb-devel mailing list > > Merb-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/merb-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/merb-devel/attachments/20070905/1af740bb/attachment.html From fernand.galiana at gmail.com Wed Sep 5 17:41:47 2007 From: fernand.galiana at gmail.com (Fernand Galiana) Date: Wed, 5 Sep 2007 15:41:47 -0600 Subject: Reloading ?? In-Reply-To: <30ab479c0709051203r4c4a375ay6d458e2fe39594ab@mail.gmail.com> References: <30ab479c0709051048i173c0e53n1cac00de1ddd1ef9@mail.gmail.com> <18B0ED1E-6B20-4D97-90FE-9F5ED3E761AE@engineyard.com> <2014A697-8AE6-4951-94A7-E2827A5B207C@gmail.com> <30ab479c0709051203r4c4a375ay6d458e2fe39594ab@mail.gmail.com> Message-ID: <30ab479c0709051441i6405bb34xde8b45a0aa309a25@mail.gmail.com> Guys, Ok I have updated to the latest. Couple things 1) Should the configuration directory in a merb app be called conf or config ? I believe the latest patch references config vs conf. 2) On first load it look like @mtime is not being set as initialize_merb is not getting called, resulting in a npe. -Fernand On 9/5/07, Fernand Galiana wrote: > > Awsome !! I'll take her out for a rip. Thanks for addressing this issue... > > -Fernand > > On 9/5/07, Duane Johnson < canadaduane at gmail.com> wrote: > > > > The latest code is checked in now, and it stands ready to use you as > > a guinea pig :) > > > > Duane Johnson > > (canadaduane) > > > > On Sep 5, 2007, at 11:52 AM, Ezra Zygmuntowicz wrote: > > > > > > > > On Sep 5, 2007, at 10:48 AM, Fernand Galiana wrote: > > > > > >> All, > > >> > > >> So I got passed my initial hurdles with merb 0.4. And all seems > > >> to work very nicely. > > >> Thank you all for your help ! > > >> > > >> One thing though, why should I have to bounce the merb server > > >> when I change > > >> my controller or associated classes ? Am I missing something ? > > >> > > >> I am having flash back to my java days where I now have to > > >> reflect on what changed > > >> and bounce the server accordingly... > > >> > > >> -Fernand > > >> > > > > > > > > > Wayne and Duane are working on the merb reloader pretty hard. It > > > shoudl be done today or tomorrow so bear with us. > > > > > > Thanks > > > -- Ezra Zygmuntowicz > > > -- Founder & Ruby Hacker > > > -- ez at engineyard.com > > > -- Engine Yard, Serious Rails Hosting > > > -- (866) 518-YARD (9273) > > > > > > > > > _______________________________________________ > > > Merb-devel mailing list > > > Merb-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/merb-devel > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/merb-devel/attachments/20070905/2949f177/attachment.html From canadaduane at gmail.com Wed Sep 5 21:01:52 2007 From: canadaduane at gmail.com (Duane Johnson) Date: Wed, 5 Sep 2007 19:01:52 -0600 Subject: Reloading ?? In-Reply-To: <30ab479c0709051441i6405bb34xde8b45a0aa309a25@mail.gmail.com> References: <30ab479c0709051048i173c0e53n1cac00de1ddd1ef9@mail.gmail.com> <18B0ED1E-6B20-4D97-90FE-9F5ED3E761AE@engineyard.com> <2014A697-8AE6-4951-94A7-E2827A5B207C@gmail.com> <30ab479c0709051203r4c4a375ay6d458e2fe39594ab@mail.gmail.com> <30ab479c0709051441i6405bb34xde8b45a0aa309a25@mail.gmail.com> Message-ID: <3A8D4288-1115-407D-9796-1020AADAD81B@gmail.com> On Sep 5, 2007, at 3:41 PM, Fernand Galiana wrote: > Guys, > > Ok I have updated to the latest. Couple things > > 1) Should the configuration directory in a merb app be called > conf or config ? > I believe the latest patch references config vs conf. > It's been changed to 'config'. > 2) On first load it look like @mtime is not being set as > initialize_merb is not > getting called, resulting in a npe. > Yes, g00k caught this too. It should be fixed now. Let me know if it's otherwise :) Duane Johnson (canadaduane) From B.Candler at pobox.com Thu Sep 6 04:46:42 2007 From: B.Candler at pobox.com (Brian Candler) Date: Thu, 6 Sep 2007 09:46:42 +0100 Subject: A Proposal To Magically Remove 'params' In-Reply-To: <21ee31950709050713g1c63eaf7l9a1fcffa96f1f457@mail.gmail.com> References: <21ee31950709020417o6207b537w8cf7d5f1222a5baa@mail.gmail.com> <20070903093015.GA14613@uk.tiscali.com> <21ee31950709030439t554a4f2dv40a3b84509676405@mail.gmail.com> <21ee31950709041454q2927862u7774c2fb369326ac@mail.gmail.com> <20070905073940.GB21819@uk.tiscali.com> <21ee31950709050713g1c63eaf7l9a1fcffa96f1f457@mail.gmail.com> Message-ID: <20070906084642.GB28954@uk.tiscali.com> On Wed, Sep 05, 2007 at 04:13:20PM +0200, ry dahl wrote: > http://s3.amazonaws.com/four.livejournal/20070905/method_args-0.0.2.gem > http://s3.amazonaws.com/four.livejournal/20070905/method_args-0.0.2.zip > > Try it out and then go sit outside in the cool grass, under the warm > sun, and dream about how nice it would be to use arguments instead of > params. We could even keep params around (at no extra speed cost and > not depreciated) for those who enjoy typing. > > def show(id) > @product = Product.find(id) > render > end > > The extension is a mere 160 lines of C code. It runs quickly and it > seems to work rather well. Yes, this is very cool. I've just posted it to ruby-talk :-) A few comments/thoughts: (1) I don't see why Method#args should raise an exception for a method which takes no arguments. Why not just return an empty array? #args? can remain but would be equivalent to #args.size > 0 (2) Would it be better to use symbols rather than strings? Ruby-1.9 now does this for method names, see http://eigenclass.org/hiki.rb?Changes+in+Ruby+1.9#l32 However in practice what we're talking about is local_variables. Under 1.8 this returns an array of strings, and I see no suggestion that this will change. So on second thoughts, forget this. (3) Would it be worth reflecting whether each argument is optional individually, or should we just rely on existing Method#arity? irb(main):018:0> class X irb(main):019:1> def hello(foo, bar, baz=nil, *rest) irb(main):020:2> end irb(main):021:1> end => nil irb(main):022:0> meth = x.method(:hello) => # irb(main):023:0> meth.args => ["foo", "bar", "baz", "*rest"] irb(main):024:0> meth.arity => -3 # a bit awkward to interpret It seems that Ruby-1.9 makes life much more complicated here (ugh): http://eigenclass.org/hiki.rb?Changes+in+Ruby+1.9#l15 (4) For efficiency, maybe it's worth implementing the 'calling' side of this within the C extension as well. That is, take a hash, flatten the elements and send them to the receiver in the correct order. A question arises as to what happens if the hash contains keys which are not matched by the receiver. One option is to pass a hash of the left-over elements in the splat receiver, e.g. def foo(id, page=nil, *rest) puts "id=#{id.inspect}" puts "page=#{page.inspect}" puts "rest=#{rest.inspect}" end method(:foo).callvar( :id=>123, :foo=>1, :bar=>2 ) # more convenient? sendvar( :foo, :id=>123, :foo=>1, :bar=>2 ) # Result: # id=123 # page=nil # rest={:foo=>1, :bar=>2} Without a splat receiver perhaps an exception should be raised: def bar(id, page=nil) puts "id=#{id.inspect}" puts "page=#{page.inspect}" end method(:bar).callvar( :id=>123, :foo=>1, :bar=>2 ) # raises ArgumentError, no argument called :foo This _might_ be useful to application developers (i.e. if a page posts a value but you forgot to declare it in the controller method args). On the other hand it might be annoying, e.g. because you're not interested in the value of Submit buttons, hidden fields containing cookies etc. Regards, Brian. From hutch at recursive.ca Thu Sep 6 16:51:41 2007 From: hutch at recursive.ca (Bob Hutchison) Date: Thu, 6 Sep 2007 16:51:41 -0400 Subject: A Proposal To Magically Remove 'params' In-Reply-To: <21ee31950709050713g1c63eaf7l9a1fcffa96f1f457@mail.gmail.com> References: <21ee31950709020417o6207b537w8cf7d5f1222a5baa@mail.gmail.com> <20070903093015.GA14613@uk.tiscali.com> <21ee31950709030439t554a4f2dv40a3b84509676405@mail.gmail.com> <21ee31950709041454q2927862u7774c2fb369326ac@mail.gmail.com> <20070905073940.GB21819@uk.tiscali.com> <21ee31950709050713g1c63eaf7l9a1fcffa96f1f457@mail.gmail.com> Message-ID: Hi, On 5-Sep-07, at 10:13 AM, ry dahl wrote: > Bob Hutchison wrote: >> Another dissenting voice... I will not/cannot avoid the use of the >> params object in some of my applications. So, please, no deprecation. >> I don't care if Merb supported controller parameters or not, in >> principle. I doubt I'd ever use them, I prefer to look at the params >> object as an input data thing that needs to be inspected rather >> carefully. On the other hand, Merb is still mostly light and easy to >> understand, and starts very quickly -- it would be sad to see this >> end. > > Bob, in what way are you using params? Why can't you avoid it? I think > you are not thinking about this correctly. Well, I'll give you an example. One of my applications is a course management system that administers and marks quizzes. The quiz is supplied as data to the program and the program generates the form. There is a single action in the controller that handles the test marking and updates the student's 'transcript'. Cheers, Bob ---- Bob Hutchison -- tumblelog at http:// www.recursive.ca/so/ Recursive Design Inc. -- weblog at http://www.recursive.ca/ hutch http://www.recursive.ca/ -- works on http://www.raconteur.info/ cms-for-static-content/home/ From ry at tinyclouds.org Thu Sep 6 19:21:37 2007 From: ry at tinyclouds.org (ry dahl) Date: Fri, 7 Sep 2007 01:21:37 +0200 Subject: A Proposal To Magically Remove 'params' In-Reply-To: References: <21ee31950709020417o6207b537w8cf7d5f1222a5baa@mail.gmail.com> <20070903093015.GA14613@uk.tiscali.com> <21ee31950709030439t554a4f2dv40a3b84509676405@mail.gmail.com> <21ee31950709041454q2927862u7774c2fb369326ac@mail.gmail.com> <20070905073940.GB21819@uk.tiscali.com> <21ee31950709050713g1c63eaf7l9a1fcffa96f1f457@mail.gmail.com> Message-ID: <21ee31950709061621l14f63cbep4e6feb49ec13b505@mail.gmail.com> > > Bob Hutchison wrote: > >> Another dissenting voice... I will not/cannot avoid the use of the > >> params object in some of my applications. So, please, no deprecation. > >> I don't care if Merb supported controller parameters or not, in > >> principle. I doubt I'd ever use them, I prefer to look at the params > >> object as an input data thing that needs to be inspected rather > >> carefully. On the other hand, Merb is still mostly light and easy to > >> understand, and starts very quickly -- it would be sad to see this > >> end. > > > > Bob, in what way are you using params? Why can't you avoid it? I think > > you are not thinking about this correctly. > > Well, I'll give you an example. One of my applications is a course > management system that administers and marks quizzes. The quiz is > supplied as data to the program and the program generates the form. > There is a single action in the controller that handles the test > marking and updates the student's 'transcript'. With action arguments one is still able to pass hash structures. For example, if you have an unknown number of quiz questions, then perhaps you would send quiz_questions[sex]=radio(male,female)&quiz_questions[age]=intenger_select(0..50) (I'm inventing some syntax for form creation here. :) Then the action would look like def quiz_create(quiz_questions) ... end The point is that you can pass hashes still in as arguments. Because of this, there isn't anything you can't do with params that you cannot do with action args. ry From ez at engineyard.com Thu Sep 6 19:23:42 2007 From: ez at engineyard.com (Ezra Zygmuntowicz) Date: Thu, 6 Sep 2007 16:23:42 -0700 Subject: A Proposal To Magically Remove 'params' In-Reply-To: <21ee31950709061621l14f63cbep4e6feb49ec13b505@mail.gmail.com> References: <21ee31950709020417o6207b537w8cf7d5f1222a5baa@mail.gmail.com> <20070903093015.GA14613@uk.tiscali.com> <21ee31950709030439t554a4f2dv40a3b84509676405@mail.gmail.com> <21ee31950709041454q2927862u7774c2fb369326ac@mail.gmail.com> <20070905073940.GB21819@uk.tiscali.com> <21ee31950709050713g1c63eaf7l9a1fcffa96f1f457@mail.gmail.com> <21ee31950709061621l14f63cbep4e6feb49ec13b505@mail.gmail.com> Message-ID: <578308C1-33AC-4118-B472-4E8FDD3EAAD5@engineyard.com> On Sep 6, 2007, at 4:21 PM, ry dahl wrote: >>> Bob Hutchison wrote: >>>> Another dissenting voice... I will not/cannot avoid the use of the >>>> params object in some of my applications. So, please, no >>>> deprecation. >>>> I don't care if Merb supported controller parameters or not, in >>>> principle. I doubt I'd ever use them, I prefer to look at the >>>> params >>>> object as an input data thing that needs to be inspected rather >>>> carefully. On the other hand, Merb is still mostly light and >>>> easy to >>>> understand, and starts very quickly -- it would be sad to see this >>>> end. >>> >>> Bob, in what way are you using params? Why can't you avoid it? I >>> think >>> you are not thinking about this correctly. >> >> Well, I'll give you an example. One of my applications is a course >> management system that administers and marks quizzes. The quiz is >> supplied as data to the program and the program generates the form. >> There is a single action in the controller that handles the test >> marking and updates the student's 'transcript'. > > With action arguments one is still able to pass hash structures. For > example, if you have an unknown number of quiz questions, then perhaps > you would send > > quiz_questions[sex]=radio(male,female)&quiz_questions[age] > =intenger_select(0..50) > > (I'm inventing some syntax for form creation here. :) > > Then the action would look like > > def quiz_create(quiz_questions) > ... > end > > The point is that you can pass hashes still in as arguments. Because > of this, there isn't anything you can't do with params that you cannot > do with action args. > > ry Plus even if we did allow action args in, params would not go away and you could just not give your actions arguments and use the oparams hash just like normal. So this is an additive feature and does not change the way you use params at all. Cheers- -- Ezra Zygmuntowicz -- Founder & Ruby Hacker -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) From hutch at recursive.ca Fri Sep 7 00:16:30 2007 From: hutch at recursive.ca (Bob Hutchison) Date: Fri, 7 Sep 2007 00:16:30 -0400 Subject: A Proposal To Magically Remove 'params' In-Reply-To: <578308C1-33AC-4118-B472-4E8FDD3EAAD5@engineyard.com> References: <21ee31950709020417o6207b537w8cf7d5f1222a5baa@mail.gmail.com> <20070903093015.GA14613@uk.tiscali.com> <21ee31950709030439t554a4f2dv40a3b84509676405@mail.gmail.com> <21ee31950709041454q2927862u7774c2fb369326ac@mail.gmail.com> <20070905073940.GB21819@uk.tiscali.com> <21ee31950709050713g1c63eaf7l9a1fcffa96f1f457@mail.gmail.com> <21ee31950709061621l14f63cbep4e6feb49ec13b505@mail.gmail.com> <578308C1-33AC-4118-B472-4E8FDD3EAAD5@engineyard.com> Message-ID: <102E7527-B9EB-4985-BD0C-15E46C939EF8@recursive.ca> Hi, On 6-Sep-07, at 7:23 PM, Ezra Zygmuntowicz wrote: > > On Sep 6, 2007, at 4:21 PM, ry dahl wrote: > >>>> Bob Hutchison wrote: >>>>> Another dissenting voice... I will not/cannot avoid the use of the >>>>> params object in some of my applications. So, please, no >>>>> deprecation. >>>>> I don't care if Merb supported controller parameters or not, in >>>>> principle. I doubt I'd ever use them, I prefer to look at the >>>>> params >>>>> object as an input data thing that needs to be inspected rather >>>>> carefully. On the other hand, Merb is still mostly light and >>>>> easy to >>>>> understand, and starts very quickly -- it would be sad to see this >>>>> end. >>>> >>>> Bob, in what way are you using params? Why can't you avoid it? I >>>> think >>>> you are not thinking about this correctly. >>> >>> Well, I'll give you an example. One of my applications is a course >>> management system that administers and marks quizzes. The quiz is >>> supplied as data to the program and the program generates the form. >>> There is a single action in the controller that handles the test >>> marking and updates the student's 'transcript'. >> >> With action arguments one is still able to pass hash structures. For >> example, if you have an unknown number of quiz questions, then >> perhaps >> you would send >> >> quiz_questions[sex]=radio(male,female)&quiz_questions[age] >> =intenger_select(0..50) >> >> (I'm inventing some syntax for form creation here. :) >> >> Then the action would look like >> >> def quiz_create(quiz_questions) >> ... >> end >> >> The point is that you can pass hashes still in as arguments. Because >> of this, there isn't anything you can't do with params that you >> cannot >> do with action args. >> >> ry > > > Plus even if we did allow action args in, params would not go away > and you could just not give your actions arguments and use the > oparams hash just like normal. So this is an additive feature and > does not change the way you use params at all. That's fine. I was objecting to the deprecation of params that was suggested. Cheers, Bob > > Cheers- > -- Ezra Zygmuntowicz-- Founder & Ruby Hacker > -- ez at engineyard.com > -- Engine Yard, Serious Rails Hosting > -- (866) 518-YARD (9273) > > ---- Bob Hutchison -- tumblelog at http:// www.recursive.ca/so/ Recursive Design Inc. -- weblog at http://www.recursive.ca/ hutch http://www.recursive.ca/ -- works on http://www.raconteur.info/ cms-for-static-content/home/ From b.candler at pobox.com Tue Sep 11 08:48:56 2007 From: b.candler at pobox.com (b.candler at pobox.com) Date: Tue, 11 Sep 2007 13:48:56 +0100 Subject: Problem returning a Proc Message-ID: I'm just playing with a recent Merb trunk (-r590). All the specs pass, apart from 2 pending. Now, the README says: "if you return a Proc object from your action, it will be called and the return value sent to the client." However this doesn't seem to work with the following test controller: class Hello < Application def world res = "Hello world from #{$$} at #{Time.now}!\n" proc { sleep 5 res } end end I get the 5 second wait, but zero bytes of response. $ telnet localhost 4000 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. GET /hello/world HTTP/1.0 HTTP/1.1 200 OK Connection: close Date: Tue, 11 Sep 2007 12:43:51 GMT Content-Type: text/html Content-Length: 0 Connection closed by foreign host. It works if I remove the proc { ... } wrapper and just return the string directly. I'm pretty sure I'm doing the proc return correctly; if I write it as a standalone Ruby program then it behaves as I expect, i.e. def world res = "Hello world from #{$$} at #{Time.now}!\n" proc { sleep 5 res } end puts world.call # this works and shows the message Anybody got any idea why this doesn't work? I'm not submitting this as a ticket as I'm not sure if the behaviour is wrong, the README is wrong, or I'm doing something wrong :-) Thanks, Brian. From ry at tinyclouds.org Tue Sep 11 11:35:35 2007 From: ry at tinyclouds.org (ry dahl) Date: Tue, 11 Sep 2007 17:35:35 +0200 Subject: Problem returning a Proc In-Reply-To: References: Message-ID: <21ee31950709110835t28012bc4wb0a77901fdf9a77e@mail.gmail.com> It's because Merb doesn't write status or headers on procs. Presumably because Merb doesn't yet know the Content-Length of the response? I'm all for changing this: returning headers and status (without Content-Length) on proc return values before calling the proc. ry On 9/11/07, b.candler at pobox.com wrote: > I'm just playing with a recent Merb trunk (-r590). All the specs pass, apart > from 2 pending. > > Now, the README says: "if you return a Proc object from your action, it will > be called and the return value sent to the client." > > However this doesn't seem to work with the following test controller: > > class Hello < Application > def world > res = "Hello world from #{$$} at #{Time.now}!\n" > proc { > sleep 5 > res > } > end > end > > I get the 5 second wait, but zero bytes of response. > > $ telnet localhost 4000 > Trying 127.0.0.1... > Connected to localhost.localdomain (127.0.0.1). > Escape character is '^]'. > GET /hello/world HTTP/1.0 > > HTTP/1.1 200 OK > Connection: close > Date: Tue, 11 Sep 2007 12:43:51 GMT > Content-Type: text/html > Content-Length: 0 > > Connection closed by foreign host. > > It works if I remove the proc { ... } wrapper and just return the string > directly. > > I'm pretty sure I'm doing the proc return correctly; if I write it as a > standalone Ruby program then it behaves as I expect, i.e. > > def world > res = "Hello world from #{$$} at #{Time.now}!\n" > proc { > sleep 5 > res > } > end > puts world.call # this works and shows the message > > Anybody got any idea why this doesn't work? I'm not submitting this as a > ticket as I'm not sure if the behaviour is wrong, the README is wrong, or > I'm doing something wrong :-) > > Thanks, > > Brian. > _______________________________________________ > Merb-devel mailing list > Merb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/merb-devel > From ez at engineyard.com Tue Sep 11 14:43:58 2007 From: ez at engineyard.com (Ezra Zygmuntowicz) Date: Tue, 11 Sep 2007 11:43:58 -0700 Subject: Problem returning a Proc In-Reply-To: <21ee31950709110835t28012bc4wb0a77901fdf9a77e@mail.gmail.com> References: <21ee31950709110835t28012bc4wb0a77901fdf9a77e@mail.gmail.com> Message-ID: <0012111C-09FB-4B63-B110-652005F60805@engineyard.com> Hi~ On Sep 11, 2007, at 8:35 AM, ry dahl wrote: > It's because Merb doesn't write status or headers on procs. Presumably > because Merb doesn't yet know the Content-Length of the response? > > I'm all for changing this: returning headers and status (without > Content-Length) on proc return values before calling the proc. > > ry > > On 9/11/07, b.candler at pobox.com wrote: >> I'm just playing with a recent Merb trunk (-r590). All the specs >> pass, apart >> from 2 pending. >> >> Now, the README says: "if you return a Proc object from your >> action, it will >> be called and the return value sent to the client." >> >> However this doesn't seem to work with the following test controller: >> >> class Hello < Application >> def world >> res = "Hello world from #{$$} at #{Time.now}!\n" >> proc { >> sleep 5 >> res >> } >> end >> end >> >> I get the 5 second wait, but zero bytes of response. >> >> $ telnet localhost 4000 >> Trying 127.0.0.1... >> Connected to localhost.localdomain (127.0.0.1). >> Escape character is '^]'. >> GET /hello/world HTTP/1.0 >> >> HTTP/1.1 200 OK >> Connection: close >> Date: Tue, 11 Sep 2007 12:43:51 GMT >> Content-Type: text/html >> Content-Length: 0 >> >> Connection closed by foreign host. >> >> It works if I remove the proc { ... } wrapper and just return the >> string >> directly. >> >> I'm pretty sure I'm doing the proc return correctly; if I write it >> as a >> standalone Ruby program then it behaves as I expect, i.e. >> >> def world >> res = "Hello world from #{$$} at #{Time.now}!\n" >> proc { >> sleep 5 >> res >> } >> end >> puts world.call # this works and shows the message >> >> Anybody got any idea why this doesn't work? I'm not submitting >> this as a >> ticket as I'm not sure if the behaviour is wrong, the README is >> wrong, or >> I'm doing something wrong :-) >> >> Thanks, >> >> Brian. Brian- There is a helper method for this that sets all the proper headers and whatnot. Here is how to use it to do what your example does: def world res = "Hello world from #{$$} at #{Time.now}!\n" render_defered do sleep 5 res end end Cheers- -- Ezra Zygmuntowicz -- Founder & Ruby Hacker -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) From b.candler at pobox.com Tue Sep 11 15:53:37 2007 From: b.candler at pobox.com (b.candler at pobox.com) Date: Tue, 11 Sep 2007 20:53:37 +0100 Subject: Problem returning a Proc In-Reply-To: <0012111C-09FB-4B63-B110-652005F60805@engineyard.com> References: <21ee31950709110835t28012bc4wb0a77901fdf9a77e@mail.gmail.com> <0012111C-09FB-4B63-B110-652005F60805@engineyard.com> Message-ID: Ezra Zygmuntowicz writes: > There is a helper method for this that sets all the proper headers and > whatnot. Here is how to use it to do what your example does: > > def world > res = "Hello world from #{$$} at #{Time.now}!\n" > render_defered do > sleep 5 > res > end > end Thank you. It's "render_deferred", but when I change use that it works. Perhaps this example should go into the README. What I found surprising (and still do) is that a controller action can return a String directly, but a Proc cannot. Therefore, what exactly is it that a Proc is supposed to do to generate output, which a controller action doesn't have to do? Looking in abstract_controller.rb, I see: @_body = case caught when :filter_chain_completed call_action(action) when String caught when nil filters_halted when Symbol send(caught) when Proc caught.call(self) else raise MerbControllerError, "The before filter chain is broken dude. wtf?" end and this is also called from Controller#dispatch (via 'super') So at first glance, it looks like caught.call(self) ought to take the return value of the Proc and treat it just the same as a String returned directly from the controller method. But I'm clearly not understanding the flow of control, because that's not what's happening. Regards, Brian. From ez at engineyard.com Tue Sep 11 16:04:40 2007 From: ez at engineyard.com (Ezra Zygmuntowicz) Date: Tue, 11 Sep 2007 13:04:40 -0700 Subject: Problem returning a Proc In-Reply-To: References: <21ee31950709110835t28012bc4wb0a77901fdf9a77e@mail.gmail.com> <0012111C-09FB-4B63-B110-652005F60805@engineyard.com> Message-ID: <379EAA3E-8C32-4C9B-B6F5-CEB6F08E097A@engineyard.com> On Sep 11, 2007, at 12:53 PM, b.candler at pobox.com wrote: > Ezra Zygmuntowicz writes: >> There is a helper method for this that sets all the proper >> headers and whatnot. Here is how to use it to do what your >> example does: def world >> res = "Hello world from #{$$} at #{Time.now}!\n" >> render_defered do >> sleep 5 >> res >> end >> end > > Thank you. It's "render_deferred", but when I change use that it > works. Perhaps this example should go into the README. > What I found surprising (and still do) is that a controller action > can return a String directly, but a Proc cannot. Therefore, what > exactly is it that a Proc is supposed to do to generate output, > which a controller action doesn't have to do? > Looking in abstract_controller.rb, I see: > @_body = case caught > when :filter_chain_completed > call_action(action) > when String > caught > when nil > filters_halted > when Symbol > send(caught) > when Proc > caught.call(self) > else > raise MerbControllerError, "The before filter chain is broken > dude. wtf?" > end > and this is also called from Controller#dispatch (via 'super') > So at first glance, it looks like caught.call(self) ought to take > the return value of the Proc and treat it just the same as a String > returned directly from the controller method. But I'm clearly not > understanding the flow of control, because that's not what's > happening. > Regards, > Brian. Brian- That is only for a Proc returned from a before filter. class Foo greetings, i have been trying to get merb and monit to play well. but monit won't restart merb. neither will monit stop merb if it is still running but not responding. below is the monit config for the merb app. anyone know what i am doing wrong or have good strategies for using monit and merb? thank you - john weir check process manwith-4000 with pidfile /path_to_merb_app/log/merb. 4000.pid start program = " /usr/bin/merb -u nobody -G nogroup -e production -d -m /path_to_merb_app/ -f /path_to_merb_app/dist/conf/upload.conf -M /path_to_merb_app/dist/ conf/merb.yml" stop program = "/usr/bin/merb -k 4000" if totalmem is greater than 95.0 MB for 2 cycles then restart # eating up memory? #if cpu is greater than 50% for 2 cycles then alert # send an email to admin if cpu is greater than 80% for 3 cycles then restart # hung process? #if loadavg(5min) greater than 10 for 8 cycles then restart # bad, bad, bad if 3 restarts within 5 cycles then timeout # something is wrong, call the sys-admin if failed port 4000 protocol http # check for response with timeout 10 seconds then start group mongrel From b.candler at pobox.com Sun Sep 16 08:14:29 2007 From: b.candler at pobox.com (b.candler at pobox.com) Date: Sun, 16 Sep 2007 13:14:29 +0100 Subject: upload_progress example Message-ID: Since mrblog is now out of sync with trunk, I distilled out of it just the minimum parts for having upload progress display on file uploads. I also took the liberty of inverting the way the iframe was used: now the iframe contains the progress display, rather than being the target of the form post. This makes more sense to me, as you may wish to separate visually the progress display anyway, and it also means that completion of upload can render a completely new page. This works with Firefox, but I've not tested it with any other browsers. The short tarball is attached in case it's of use to anyone else. Regards, Brian. -------------- next part -------------- A non-text attachment was scrubbed... Name: upload_progress.tgz Type: application/octet-stream Size: 16738 bytes Desc: not available Url : http://rubyforge.org/pipermail/merb-devel/attachments/20070916/1c09054c/attachment.obj From canadaduane at gmail.com Mon Sep 17 10:08:49 2007 From: canadaduane at gmail.com (Duane Johnson) Date: Mon, 17 Sep 2007 08:08:49 -0600 Subject: Why do we check for the controller file? Message-ID: I remember having this discussion on IRC before, so Ezra if you could remind me that would be appreciated: Why do we check for the existence of the controller file in (what is now) Request#controller_class? The reason I ask is that I would like to implement some sort of "Rails engine" like features for gem plugins--in other words, drop in a gem that has controllers/views etc. and have it just work. In order to do this, I need the Request#controller_class to return my gem's controller class (which corresponding file does not exist inside the standard controller directory). Thanks, Duane Johnson (canadaduane) From ez at engineyard.com Mon Sep 17 10:41:41 2007 From: ez at engineyard.com (Ezra Zygmuntowicz) Date: Mon, 17 Sep 2007 07:41:41 -0700 Subject: Why do we check for the controller file? In-Reply-To: References: Message-ID: We do this because if we dont then people could get just about any class to load just by putting it in the URL. It was suggested that we check whether the class in question is a subclass of controller but by that time its too late since we would have to constantize the classname in order to check if its a subclass. So its a security issue to prevent urls from loading maliscious classes especially when active support is loaded. I suppose we could make a controller load paths array that your plugin could add to and check all the paths in said array. We just have to be careful about this stuff. On another note, to_const_string has a dos attack vuln in it. If you GET /404 or any URL that starts with a number it sends it into an infinite loop. Since it uses a until loop but only consumes chars if they dont start with a number. Can you add a gaurd to that method to raise an error if any of the string sections start with a digit? Thanks Ezra Zygmuntowicz ez at engineyard.com 1-530-917-7815 On Sep 17, 2007, at 7:08 AM, Duane Johnson wrote: > I remember having this discussion on IRC before, so Ezra if you could > remind me that would be appreciated: > > Why do we check for the existence of the controller file in (what is > now) Request#controller_class? > > The reason I ask is that I would like to implement some sort of > "Rails engine" like features for gem plugins--in other words, drop in > a gem that has controllers/views etc. and have it just work. In > order to do this, I need the Request#controller_class to return my > gem's controller class (which corresponding file does not exist > inside the standard controller directory). > > Thanks, > Duane Johnson > (canadaduane) > > _______________________________________________ > Merb-devel mailing list > Merb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/merb-devel From chris at oxdi.eu Mon Sep 17 10:57:17 2007 From: chris at oxdi.eu (Chris Farmiloe) Date: Mon, 17 Sep 2007 15:57:17 +0100 Subject: Why do we check for the controller file? In-Reply-To: References: Message-ID: > I suppose we could make a controller load paths array that your plugin > could add to and check all the paths in said array. We just have to be > careful about this stuff. Maybe a way to "register" valid controllers, so no potentially costly filesystem calls need to be made? Merb::Controller.register 'MyPluginController', '/path/to/ my_plugin_controller' Merb::Controller.registered?('MyPluginController') ==> true RE: GET /404 There is a patch on the ticket ;) Regards Farms. Design & Dev Oxygen. http://www.oxdi.eu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/merb-devel/attachments/20070917/dcc44ac4/attachment.html From ry at tinyclouds.org Mon Sep 17 21:14:14 2007 From: ry at tinyclouds.org (ry dahl) Date: Tue, 18 Sep 2007 03:14:14 +0200 Subject: Routes Message-ID: <21ee31950709171814j6f81571ai68c040b69a5ad386@mail.gmail.com> hi all, I want to move some routing tasks out of the router and into the controller. The goal is to make Merb feel less like mod_rewrite and give the user more control at the controller. The new Router is simple: it takes the path_info (not the whole request) then outputs a controller class and some parameters from the path matching. The rest of the routing would be done at the controller level. The controller is ultimately in charge of determining which action to call. In particular, only the controller gets to see the http method. Because resource controllers and normal controllers have very different routing rules, I think they should be different classes. I'd split them into two classes: Merb::Controllers::Standard and Merb::Controllers::Resource. These would both be subclasses of Controller, and would implement the method Controller#route Users would create controllers by subclassing one of these two. Some cute things can be done by letting the controller have control of action routing. For example, in the standard controller we could use punctuation to declare that an action receives a POST: def update! # POST controller/update def update # GET controller/update def index # GET controller/index The standard controller can safely ignore _method (for those of us who do not want emulated PUT and DELETE methods) We can put custom route rules nearer to the actions they effect instead of in a separate file. add_route 'test/:blah', :index # assigns params[:blah] and routes to test action def test end Duane's popular regular expression routing can be implemented in an add_route-like controller class method, say, match_route. In the end this will be a tighter, more readable, and more natural API than the current. Additionally this opportunity can be used to rid Merb of the increasingly complex @compiled_statement construction in route.rb and rely instead on a constructed data structure to match against. I suspect performance can be increased. This is a largish change and I would like to create it in an experimental branch to work on it. Thoughts? ry From ez at engineyard.com Mon Sep 17 22:13:26 2007 From: ez at engineyard.com (Ezra Zygmuntowicz) Date: Mon, 17 Sep 2007 19:13:26 -0700 Subject: Routes In-Reply-To: <21ee31950709171814j6f81571ai68c040b69a5ad386@mail.gmail.com> References: <21ee31950709171814j6f81571ai68c040b69a5ad386@mail.gmail.com> Message-ID: Hi~ On Sep 17, 2007, at 6:14 PM, ry dahl wrote: > hi all, > > I want to move some routing tasks out of the router and into the > controller. The goal is to make Merb feel less like mod_rewrite and > give the user more control at the controller. The new Router is > simple: it takes the path_info (not the whole request) then outputs a > controller class and some parameters from the path matching. The rest > of the routing would be done at the controller level. The controller > is ultimately in charge of determining which action to call. In > particular, only the controller gets to see the http method. > > Because resource controllers and normal controllers have very > different routing rules, I think they should be different classes. I'd > split them into two classes: Merb::Controllers::Standard and > Merb::Controllers::Resource. These would both be subclasses of > Controller, and would implement the method Controller#route > Users would create controllers by subclassing one of these two. > > Some cute things can be done by letting the controller have control of > action routing. > > For example, in the standard controller we could use punctuation to > declare that an action receives a POST: > def update! # POST controller/update > def update # GET controller/update > def index # GET controller/index > > The standard controller can safely ignore _method (for those of us who > do not want emulated PUT and DELETE methods) > > We can put custom route rules nearer to the actions they effect > instead of in a separate file. > add_route 'test/:blah', :index # assigns params[:blah] and routes > to test action > def test > end > Duane's popular regular expression routing can be implemented in an > add_route-like controller class method, say, match_route. > > In the end this will be a tighter, more readable, and more natural API > than the current. Additionally this opportunity can be used to rid > Merb of the increasingly complex @compiled_statement construction in > route.rb and rely instead on a constructed data structure to match > against. I suspect performance can be increased. > > This is a largish change and I would like to create it in an > experimental branch to work on it. > > Thoughts? > > ry I'm not convinced that this would make things better. You're welcome to work on a branch but I'm not going to merge it to trunk unless I think it's a big improvement and I'm not seeing why this way would be better. I also don't like the idea of two different types of controllers that are exactly the same and inherit from the same superclass but are different only in how they are routed to. I don't want to discourage you from trying this out in a branch so go for it, but I have to reserve judgement until I see it or you show me a more complete mockup API. Cheers- -- Ezra Zygmuntowicz -- Founder & Ruby Hacker -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) From ry at tinyclouds.org Mon Sep 17 23:15:17 2007 From: ry at tinyclouds.org (ry dahl) Date: Tue, 18 Sep 2007 05:15:17 +0200 Subject: Routes In-Reply-To: References: <21ee31950709171814j6f81571ai68c040b69a5ad386@mail.gmail.com> Message-ID: <21ee31950709172015n68e36bddk81cd0c00c3897fb0@mail.gmail.com> > I'm not going to merge it to trunk unless I > think it's a big improvement and I'm not seeing why this way would be > better. Noted :) New branch created at /branches/ry_routes > I also don't like the idea of two different types of > controllers that are exactly the same and inherit from the same > superclass but are different only in how they are routed to. Perhaps this distinction doesn't need to be implemented as split classes, however I think from a user perspective it makes sense to think of resource controllers as fundamentally different than standard controllers - even if they share 99% of the code. ry From B.Candler at pobox.com Tue Sep 18 07:01:07 2007 From: B.Candler at pobox.com (Brian Candler) Date: Tue, 18 Sep 2007 12:01:07 +0100 Subject: Routes In-Reply-To: <21ee31950709171814j6f81571ai68c040b69a5ad386@mail.gmail.com> References: <21ee31950709171814j6f81571ai68c040b69a5ad386@mail.gmail.com> Message-ID: <20070918110107.GA5221@uk.tiscali.com> On Tue, Sep 18, 2007 at 03:14:14AM +0200, ry dahl wrote: > Some cute things can be done by letting the controller have control of > action routing. > > For example, in the standard controller we could use punctuation to > declare that an action receives a POST: > def update! # POST controller/update > def update # GET controller/update > def index # GET controller/index I don't understand why this can't be done with "normal" routing, e.g. (untested) r.match(%r[/:controller(/::(/:id)?)?(\.:format)?], :method=>"post"). to(:action=>"[1]!") This is just a variant on default_routes > We can put custom route rules nearer to the actions they effect > instead of in a separate file. > add_route 'test/:blah', :index # assigns params[:blah] and routes > to test action > def test > end If the idea is to keep the route definition near to the controller, maybe it would be simpler just to allow the router to be re-opened in each controller source file (if it isn't already), e.g. Merb::Router.prepare do |r| r.match("/whatever/test/:blah").to(:test) end class Whatever < Application def test end end However, the benefit of putting all the routing logic in one place is it makes it clear the order in which testing is made, to resolve ambiguities between routes. > In the end this will be a tighter, more readable, and more natural API > than the current. Additionally this opportunity can be used to rid > Merb of the increasingly complex @compiled_statement construction in > route.rb and rely instead on a constructed data structure to match > against. I suspect performance can be increased. I agree that the current linear search, i.e. a big if / elsif tree, is far from optimal. However I think it can be improved without moving the logic out of centralised routing. If I understand you correctly, you're saying that all matches will be initially made against a fixed pattern /:controller/.*, and then the request is dispatched to the controller which performs its own sub-matching as required. By dispatching directly to a controller first, you avoid the linear search, which is a potentially a factor of N improvement when you have N controllers. Well, you could get the same benefit in the centralised routing model, by imposing an equivalent rule that all path regexps must start with /\w+. Bundle all the path routing rules into bins, perform a match on /(\w+), then perform a linear search under bins[$1]. That is, instead of having one @@compiled_statement, have multiple @@compiled_statements indexed by the first path component. (So it doesn't make the complexity any less, I'm afraid!) However I suspect this can be generalised. One way I'm thinking is to combine all the path regexps into one mega path matching regexp, and let the regexp engine take care of it. You would group together all routing rules which have the same path regexp, and perform a linear search afterwards for the non-path tests. e.g. r.match("/admin/:action").to(www) r.match("/:flurble/:action", :method=>"delete").to(xxx) r.match("/:controller/:action", :method=>"post").to(yyy) r.match("/:controller/:action").to(zzz) The last three rules all match path /([^\/.,;?]+)/([^\/.,;?]+), and so you would compile to something like %r{ \A (/admin/([^\/.,;?]+)) | (/([^\/.,;?]+)/([^\/.,;?]+)) \z }x In the case of the first branch matching you'd dispatch to www, and in the case of the second branch matching you'd run compiled (pseudocode) if params[:method] == 'delete' # set params[:flurble] = $1, params[:action] = $1 to(xxx) elsif params[:method] == 'post' # set params[:controller] = $1, params[:action] = $1 to(yyy) else # set params[:controller] = $1, params[:action] = $1 to(zzz) end However I'm not sure if there's a cheap way to identify which branch of a regexp has matched. If you have to do if $1 ... elsif $2 ... elsif $3 ... end then much of the benefit has been lost. And you also need to be sure of how ambiguous matching is resolved, e.g. in the above example /admin/foo matches the first regexp branch in preference to the second. Regards, Brian. From B.Candler at pobox.com Tue Sep 18 08:17:41 2007 From: B.Candler at pobox.com (Brian Candler) Date: Tue, 18 Sep 2007 13:17:41 +0100 Subject: Routes In-Reply-To: <20070918110107.GA5221@uk.tiscali.com> References: <21ee31950709171814j6f81571ai68c040b69a5ad386@mail.gmail.com> <20070918110107.GA5221@uk.tiscali.com> Message-ID: <20070918121741.GA10181@uk.tiscali.com> On Tue, Sep 18, 2007 at 12:01:07PM +0100, Brian Candler wrote: > However I suspect this can be generalised. One way I'm thinking is to > combine all the path regexps into one mega path matching regexp, and let the > regexp engine take care of it. ... > However I'm not sure if there's a cheap way to identify which branch of a > regexp has matched. Here's an outline of how I think it could be done. --- 8< --------------------------------------------------------------------- # Part one: show how it works manually RE = %r{\A(?: (?> ()/admin/(\w+)) | (?> ()/(\w+)/(\w+)) )\z}x puts RE.inspect ACTIONS = { 1 => proc { |m| puts "www: #{m.inspect}" }, 3 => proc { |m| puts "xxx/yyy/zzz: #{m.inspect}" }, } def test(patt) m = RE.match(patt).to_a puts m.inspect i = m.index("") ACTIONS[i].call(m[i+1..-1]) end test("/admin/wibble") test("/bibble/boing") puts "----" # Part two: proof of concept of automatic regexp construction class POC attr_reader :regexps, :re, :actions def initialize @regexps = [] # [[regexp,[action,action]], [regexp,[action,action], ...] end def match(regexp, action) regexp = Regexp.new(regexp) unless regexp.is_a? Regexp if entry = @regexps.find { |e| e[0] == regexp } entry[1] << action else @regexps << [regexp, [action]] end end def compile @re = %r{\A(?:#{@regexps.collect { |r| "(?>()#{r[0]})" }.join("|")})\z} @actions = {} i = 1 @regexps.each do |r,a| @actions[i] = a i += 1 + r.source.scan(%r{\((?!\?)}).size # ergh, count number of captures end end def run(patt, request={}) m = @re.match(patt).to_a i = m.index("") @actions[i].each { |a| res = a.call(request, m[i+1..-1]); return res if res } nil end end r = POC.new r.match(%r{/admin/(\w+)}, proc { |req,path| {:action=>"www"} }) r.match(%r{/(\w+)/(\w+)}, proc { |req,path| {:action=>"xxx"} if req[:method]=="delete" }) r.match(%r{/(\w+)/(\w+)}, proc { |req,path| {:action=>"yyy"} if req[:method]=="post" }) r.match(%r{/(\w+)/(\w+)}, proc { |req,path| {:action=>"zzz"} }) p r.regexps r.compile p r.re p r.actions p r.run("/admin/wibble", :method=>"get") p r.run("/bibble/boing", :method=>"delete") p r.run("/bibble/boing", :method=>"post") p r.run("/bibble/boing", :method=>"get") --- 8< --------------------------------------------------------------------- Seem feasible? Other things to do: - create procs automatically for the simple 'non-deferred' routing, which is easy since procs are first-class objects. No eval required :-) - map m[0], m[1], m[2]... into the named params fields like :controller, :action etc if the original regexp had :foo placeholders Regards, Brian. From B.Candler at pobox.com Tue Sep 18 09:55:58 2007 From: B.Candler at pobox.com (Brian Candler) Date: Tue, 18 Sep 2007 14:55:58 +0100 Subject: Routes In-Reply-To: <20070918121741.GA10181@uk.tiscali.com> References: <21ee31950709171814j6f81571ai68c040b69a5ad386@mail.gmail.com> <20070918110107.GA5221@uk.tiscali.com> <20070918121741.GA10181@uk.tiscali.com> Message-ID: <20070918135557.GA13662@uk.tiscali.com> On Tue, Sep 18, 2007 at 01:17:41PM +0100, Brian Candler wrote: > Here's an outline of how I think it could be done. Incidentally, there's some scope for further optimisation here. Given that the applications with large numbers of routes are likely to be resource-based, e.g. /foos /foos/:id /foos/new /foos/:id/edit /foos/:id/:action then it may be worth reflecting this in the structure of the composed regexp by matching the shared prefix only once. Trying to combine adjacent regexps automatically may be hard, but resource routing could explicitly build regexps this way. The speed gains may not be significant in the bigger picture: $ cat speed.rb require 'benchmark' include Benchmark re1 = "(?: () /)\n" re2 = "(?: () /)\n" ["things","bars","bazs","xyzs","abcs","foos","persons","admins"].each do |r| re1 << < References: <21ee31950709171814j6f81571ai68c040b69a5ad386@mail.gmail.com> <20070918110107.GA5221@uk.tiscali.com> <20070918121741.GA10181@uk.tiscali.com> Message-ID: <20070918203013.GA2775@uk.tiscali.com> On Tue, Sep 18, 2007 at 01:17:41PM +0100, Brian Candler wrote: > Here's an outline of how I think it could be done. This was broken as I was using (?> ...), which permanently eats characters and then won't allow the data to match a different branch. Fixed version attached, with some other cleanups. Incidentally, instead of writing (?: () ...branch1... ) | (?: () ...branch2... ) it would be simpler to write ( ...branch1... ) | ( ...branch2... ) since the outer brackets also capture the entire match, which gives a suitable non-nil sentinel to mark the start of the branch. However this way means I need a fast way to detect the first non-nil element in the match array (rather than the first empty string element) and I couldn't think of a way to do that faster than i = (0...m.size).find { |x| m[x] } Also, I decided to anchor the whole expression, which means the individual branch regexps don't need to be anchored, but instead we could insist that the branches need to have their own anchors (which I think is the current behaviour) Regards, Brian. -------------- next part -------------- class POCRouter class Path attr_reader :regexp, :num_captures, :blocks def initialize(regexp, blocks=[]) @regexp = regexp @num_captures = @regexp.source.scan(%r{\((?!\?)}).size # FIXME, e.g. \( or [(] @blocks = blocks end end attr_reader :paths, :re, :capindex def initialize @paths = [] end def match(regexp, &blk) regexp = Regexp.new(regexp) unless regexp.is_a? Regexp if path = @paths.find { |p| p.regexp == regexp } path.blocks << blk else @paths << Path.new(regexp, [blk]) end end def compile @re = %r{\A(?: #{@paths.collect { |p| "(?: () #{p.regexp})" }.join("|\n")} )\z}x # extended RE is easier to read for debugging @capindex = {} i = 0 @paths.each do |p| @capindex[i] = p i += p.num_captures + 1 end end def inspect (@re || @paths).inspect end def run(path, request={}) m = @re.match(path).captures i = m.index("") || (return nil) path = capindex[i] path.blocks.each do |blk| res = blk.call(request, m[i+1, path.num_captures]) return res if res end nil end end r = POCRouter.new r.match(%r{/admin/(\w+)}) { |req,m| p m; {:action=>"www"} } r.match(%r{/(\w+)/(\w+)}) { |req,m| p m; {:action=>"xxx"} if req[:method]=="delete" } r.match(%r{/(\w+)/(\w+)}) { |req,m| {:action=>"yyy"} if req[:method]=="post" } r.match(%r{/(\w+)/(\w+)}) { |req,m| {:action=>"zzz"} } p r r.compile p r p r.run("/admin/wibble", :method=>"get") p r.run("/bibble/boing", :method=>"delete") p r.run("/bibble/boing", :method=>"post") p r.run("/bibble/boing", :method=>"get") From ez at engineyard.com Tue Sep 18 16:45:58 2007 From: ez at engineyard.com (Ezra Zygmuntowicz) Date: Tue, 18 Sep 2007 13:45:58 -0700 Subject: Routes In-Reply-To: <20070918135557.GA13662@uk.tiscali.com> References: <21ee31950709171814j6f81571ai68c040b69a5ad386@mail.gmail.com> <20070918110107.GA5221@uk.tiscali.com> <20070918121741.GA10181@uk.tiscali.com> <20070918135557.GA13662@uk.tiscali.com> Message-ID: <83645E16-4843-4EB0-BB3D-B12076A596FB@engineyard.com> On Sep 18, 2007, at 6:55 AM, Brian Candler wrote: > On Tue, Sep 18, 2007 at 01:17:41PM +0100, Brian Candler wrote: >> Here's an outline of how I think it could be done. > > Incidentally, there's some scope for further optimisation here. > Given that > the applications with large numbers of routes are likely to be > resource-based, e.g. > > /foos > /foos/:id > /foos/new > /foos/:id/edit > /foos/:id/:action > > then it may be worth reflecting this in the structure of the > composed regexp > by matching the shared prefix only once. Trying to combine adjacent > regexps > automatically may be hard, but resource routing could explicitly build > regexps this way. > > The speed gains may not be significant in the bigger picture: > > $ cat speed.rb > require 'benchmark' > include Benchmark > > re1 = "(?: () /)\n" > re2 = "(?: () /)\n" > ["things","bars","bazs","xyzs","abcs","foos","persons","admins"].each > do |r| > re1 << < | (?: () /#{r}) > | (?: () /#{r}/(\\d+)) > | (?: () /#{r}/new) > | (?: () /#{r}/(\\d+)/edit) > | (?: () /#{r}/(\\d+)/(\\w+)) > EOS > re2 << < | (/#{r} ( > (?: () ) | > (?: () /new) | > (?: () (/\\d+) ( > (?: () ) | > (?: () /edit) | > (?: () /(\\w+)) > )) > )) > EOS > end > > # Naive regexp > RE1 = %r{^(?:#{re1})$}x > # Prefix-optimised regexp > RE2 = %r{^(?:#{re2})$}x > > N = 10_000 > > bm(6) do |test| > test.report("Match 1:") { N.times { raise unless RE1 =~ "/foos/ > 123/edit" } } > test.report("Match 2:") { N.times { raise unless RE2 =~ "/foos/ > 123/edit" } } > test.report("Mismatch 1:") { N.times { raise if RE1 =~ "/flurble/ > baz" } } > test.report("Mismatch 2:") { N.times { raise if RE2 =~ "/flurble/ > baz" } } > end > $ ruby speed.rb > user system total real > Match 1: 1.060000 0.000000 1.060000 ( 1.069919) > Match 2: 0.620000 0.000000 0.620000 ( 0.620281) > Mismatch 1: 0.640000 0.010000 0.650000 ( 0.636095) > Mismatch 2: 0.150000 0.000000 0.150000 ( 0.156758) > > This is on a small laptop (Pentium M 1.1GHz), and shows an > improvement of > about 44 microseconds per match when matching the sixth out of eight > resources. > > It would be interesting to see how this compares with current routing > strategy though. > > Regards, > > Brian. I definitely want to keep all the routes in the router.rb file, I just think having them in one place instead of spread out is much better and more explicit in ordering etc. In the big picture of a merb dispatch the current routers compiled_statement is not even close to being a significant slice of the time spent dispatching a request. I don't have any problems with trying to optimize it further but I don't think it will gain us that much in the overall picture. I'm always happy to be proven wrong though ;) Cheers- -- Ezra Zygmuntowicz -- Founder & Ruby Hacker -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) From kevwil at gmail.com Tue Sep 18 23:57:12 2007 From: kevwil at gmail.com (Kevin Williams) Date: Tue, 18 Sep 2007 21:57:12 -0600 Subject: patch and a few questions Message-ID: <683a886f0709182057l5c7d9cdfread01649439c6689@mail.gmail.com> I have a patch for merb_sequel to get migrations to work a bit better for PostgresQL. Could someone look at it and tell me how badly I screwed it up? In this patch I tried to handle encoding and logging as well. I've tried sqlite and postgres but I don't get any logging (still! after the patch). How do I get SQL logging to go to a file or the console? Actually, I'll put the other questions in other messages, to keep the thread (if any) on track. -- Cheers, Kevin Williams http://kevwil.com/ http://www.almostserio.us/ http://kevwil.jaiku.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: merb_sequel_connection.patch Type: application/octet-stream Size: 1629 bytes Desc: not available Url : http://rubyforge.org/pipermail/merb-devel/attachments/20070918/6e9687eb/attachment.obj From B.Candler at pobox.com Wed Sep 19 04:41:13 2007 From: B.Candler at pobox.com (Brian Candler) Date: Wed, 19 Sep 2007 09:41:13 +0100 Subject: Routes In-Reply-To: <83645E16-4843-4EB0-BB3D-B12076A596FB@engineyard.com> References: <21ee31950709171814j6f81571ai68c040b69a5ad386@mail.gmail.com> <20070918110107.GA5221@uk.tiscali.com> <20070918121741.GA10181@uk.tiscali.com> <20070918135557.GA13662@uk.tiscali.com> <83645E16-4843-4EB0-BB3D-B12076A596FB@engineyard.com> Message-ID: <20070919084113.GA4422@uk.tiscali.com> On Tue, Sep 18, 2007 at 01:45:58PM -0700, Ezra Zygmuntowicz wrote: > In the big picture of a > merb dispatch the current routers compiled_statement is not even > close to being a significant slice of the time spent dispatching a > request. Good point. I'm not sure what the current best way to profile merb is, so I hacked something very simple: --- /usr/lib/ruby/gems/1.8/gems/merb-0.4.0/lib/merb/server.rb.orig 2007-09-19 08:43:28.000000000 +0100 +++ /usr/lib/ruby/gems/1.8/gems/merb-0.4.0/lib/merb/server.rb 2007-09-19 08:47:03.000000000 +0100 @@ -439,6 +439,8 @@ start(@@merb_opts[:port]) else trap('TERM') { exit } + trap("USR1") { require 'profiler'; Profiler__::start_profile } + trap("USR2") { Profiler__::stop_profile; Profiler__::print_profile($stderr) } mongrel_start(@@merb_opts[:port]) end I tested with the following app, run in production mode (merb -e production): Merb::Router.prepare do |r| r.resources :foos r.resources :bars r.resources :bazs r.default_routes end class Hello < Application def world "Hello, world!" end end I then hit it 100 times on /hello/world, sent -USR1, hit it 100 times on /hello/world again, and sent -USR2. Here are the results: % cumulative self self total time seconds seconds calls ms/call ms/call name 5.41 0.84 0.84 1000 0.84 6.98 Logger#add 5.15 1.64 0.80 900 0.89 4.10 MonitorMixin.synchronize 3.41 2.17 0.53 900 0.59 0.79 Logger::Formatter#format_datetime 3.03 2.64 0.47 900 0.52 1.78 MonitorMixin.mon_exit 2.83 3.08 0.44 900 0.49 0.68 MonitorMixin.mon_release 2.25 3.43 0.35 900 0.39 0.43 Logger::Formatter#msg2str 2.12 3.76 0.33 900 0.37 0.40 Logger::LogDevice#check_shift_log 2.12 4.09 0.33 900 0.37 0.74 MonitorMixin.mon_enter 2.06 4.41 0.32 99 3.23 139.39 TCPServer#accept 2.00 4.72 0.31 100 3.10 4.80 Merb::Router#match 1.93 5.02 0.30 100 3.00 137.10 MerbHandler#process 1.93 5.32 0.30 3877 0.08 0.15 Hash#[] 1.93 5.62 0.30 900 0.33 1.77 Logger::Formatter#call 1.87 5.91 0.29 400 0.73 1.30 Hash#inspect 1.61 6.16 0.25 1900 0.13 0.14 Time#now 1.42 6.38 0.22 900 0.24 0.31 MonitorMixin.mon_check_owner 1.42 6.60 0.22 3600 0.06 0.06 Thread#critical= 1.35 6.81 0.21 900 0.23 2.02 Logger#format_message 1.35 7.02 0.21 400 0.52 0.52 String#split 1.29 7.22 0.20 100 2.00 148.80 Mongrel::HttpServer#process_client 1.29 7.42 0.20 700 0.29 0.33 Mash#convert_key 1.29 7.62 0.20 900 0.22 0.24 MonitorMixin.mon_acquire 1.22 7.81 0.19 300 0.63 1.37 Hash#each_pair 1.22 8.00 0.19 300 0.63 0.73 Mongrel::HeaderOut#[]= 1.16 8.18 0.18 2200 0.08 0.10 String#% 1.16 8.36 0.18 200 0.90 2.90 Mongrel::DirHandler#can_serve 1.09 8.53 0.17 1800 0.09 0.09 Array#shift 1.03 8.69 0.16 600 0.27 0.62 Class#read_inheritable_attribute 0.97 8.84 0.15 200 0.75 0.75 File#expand_path 0.97 8.99 0.15 1600 0.09 0.65 Class#new 0.97 9.14 0.15 100 1.50 2.70 Mongrel::HttpRequest#initialize 0.97 9.29 0.15 100 1.50 88.80 Merb::Dispatcher#handle 0.97 9.44 0.15 200 0.75 1.95 Merb::Request#query_parse 0.90 9.58 0.14 1800 0.08 0.08 Hash#default 0.90 9.72 0.14 78 1.79 19.87 Kernel.sleep 0.84 9.85 0.13 800 0.16 0.96 Merb::Request#route_params 0.77 9.97 0.12 200 0.60 0.80 Mash#default 0.77 10.09 0.12 800 0.15 0.78 Merb::Request#route_match 0.71 10.20 0.11 600 0.18 0.18 Class#inheritable_attributes 0.71 10.31 0.11 900 0.12 0.17 Logger#format_severity 0.64 10.41 0.10 1800 0.06 0.06 NilClass#nil? 0.64 10.51 0.10 1000 0.10 0.10 String#inspect 0.64 10.61 0.10 1300 0.08 0.08 Fixnum#== 0.64 10.71 0.10 900 0.11 0.11 Thread#pass 0.64 10.81 0.10 300 0.33 4.93 Merb::Request#params 0.64 10.91 0.10 106 0.94 1.60 Array#map 0.64 11.01 0.10 100 1.00 1.50 Merb::Request#path 0.64 11.11 0.10 200 0.50 0.70 Mongrel::HttpRequest#unescape 0.58 11.20 0.09 300 0.30 0.57 Merb::Request#controller_name 0.58 11.29 0.09 400 0.23 1.35 Merb::AbstractController#before_filters 0.58 11.38 0.09 100 0.90 4.00 Kernel.catch 0.58 11.47 0.09 753 0.12 18.46 Array#each 0.58 11.56 0.09 1200 0.08 0.08 Kernel.respond_to? 0.58 11.65 0.09 900 0.10 4.29 Logger::LogDevice#write 0.58 11.74 0.09 1300 0.07 0.07 IO#write 0.52 11.82 0.08 100 0.80 1.20 String#to_const_string 0.52 11.90 0.08 400 0.20 0.25 Mash#convert_value 0.52 11.98 0.08 100 0.80 0.80 Thread#initialize 0.52 12.06 0.08 400 0.20 0.28 Mongrel::HttpResponse#write 0.52 12.14 0.08 400 0.20 0.52 Merb::Controller#_session_id_key 0.52 12.22 0.08 100 0.80 5.60 Merb::Request#controller_class 0.52 12.30 0.08 1453 0.06 0.06 Kernel.nil? 0.45 12.37 0.07 400 0.18 0.88 Merb::AbstractController#after_filters 0.45 12.44 0.07 1800 0.04 0.04 Module#=== 0.45 12.51 0.07 100 0.70 0.70 Fixnum#>= 0.45 12.58 0.07 300 0.23 0.33 Array#include? 0.45 12.65 0.07 900 0.08 7.90 Logger#info 0.45 12.72 0.07 800 0.09 0.09 Symbol#inspect 0.45 12.79 0.07 200 0.35 1.00 Mongrel::HttpResponse#send_status 0.45 12.86 0.07 1000 0.07 0.07 Time#strftime 0.39 12.92 0.06 1000 0.06 0.06 String#<< 0.39 12.98 0.06 100 0.60 1.80 Hash#each 0.39 13.04 0.06 100 0.60 2.80 Mongrel::HttpResponse#initialize 0.39 13.10 0.06 200 0.30 0.35 Enumerable.inject 0.39 13.16 0.06 200 0.30 1.30 Merb::Request#body_and_query_params 0.39 13.22 0.06 300 0.20 0.20 Hash#key? 0.39 13.28 0.06 100 0.60 2.50 Object#full_const_get 0.39 13.34 0.06 1100 0.05 0.05 Fixnum#- 0.39 13.40 0.06 100 0.60 7.00 Merb::AbstractController#dispatch 0.39 13.46 0.06 1800 0.03 0.03 Thread#current 0.32 13.51 0.05 100 0.50 1.30 Merb::CookieStore#initialize 0.32 13.56 0.05 100 0.50 0.70 Mongrel::HttpParser#execute 0.32 13.61 0.05 100 0.50 2.80 Merb::Controller#set_dispatch_variables 0.32 13.66 0.05 200 0.25 0.80 Hash#to_mash 0.32 13.71 0.05 200 0.25 0.40 Mash#initialize 0.32 13.76 0.05 100 0.50 39.90 Merb::Controller#dispatch 0.26 13.80 0.04 400 0.10 0.20 Merb::Request#content_type 0.26 13.84 0.04 600 0.07 0.07 String#== 0.26 13.88 0.04 100 0.40 1.00 Time#httpdate 0.26 13.92 0.04 100 0.40 1.30 Merb::Request#query_params 0.26 13.96 0.04 200 0.20 0.20 String#tr 0.26 14.00 0.04 1100 0.04 0.04 Fixnum#< 0.26 14.04 0.04 100 0.40 0.40 Merb::AbstractController#default_thrown_content 0.26 14.08 0.04 1100 0.04 0.04 Array#[] ... snip everything below 0.25% 0.00 15.53 0.00 1 0.00 15530.00 #toplevel It looks like logging is the worst offender, with Logger#add and its mutex (MonitorMixin) accounting for the top 8 slots, 4.09 out of 15.53 seconds, or 26%. In fact, it looks like Logger#add and its children, at 6.98ms per call and called 1000 times, count for 6.98s in total. TCPAccept is next, and Merb::Router#match is third. However this only accounts for 2.00% Now, I've seen figures for Merb performance typically in the 400-600 requests per second range. Are these measured with logging turned off? If not, I think there is a strong argument for introducing a mutex-free logging system. (Simple idea: replace Logger#add with an append to a string buffer, which is atomic. Then once per second empty the buffer using String#slice! which should also be atomic, and write that to the log) Finally, I repeated the test using merb -e production -l WARN % cumulative self self total time seconds seconds calls ms/call ms/call name 4.62 0.42 0.42 1000 0.42 0.51 Logger#add 3.85 0.77 0.35 100 3.50 6.00 Merb::Router#match 3.74 1.11 0.34 100 3.40 10.30 IO#close 3.19 1.40 0.29 100 2.90 79.70 Mongrel::HttpServer#process_client 3.19 1.69 0.29 100 2.90 71.40 MerbHandler#process 2.75 1.94 0.25 900 0.28 0.81 Logger#info 2.42 2.16 0.22 1600 0.14 0.86 Class#new 2.31 2.37 0.21 600 0.35 0.50 Class#read_inheritable_attribute 2.09 2.56 0.19 400 0.48 0.73 Hash#inspect 2.09 2.75 0.19 400 0.47 0.47 String#split 2.09 2.94 0.19 3742 0.05 0.11 Hash#[] 1.98 3.12 0.18 738 0.24 10.15 Array#each 1.98 3.30 0.18 100 1.80 2.00 Time#httpdate 1.65 3.45 0.15 400 0.38 1.23 Merb::AbstractController#before_filters 1.65 3.60 0.15 300 0.50 5.93 Merb::Request#params 1.65 3.75 0.15 100 1.50 1.90 Merb::Request#json_params 1.54 3.89 0.14 100 1.40 2.10 Mongrel::HttpRequest#initialize 1.54 4.03 0.14 1000 0.14 0.17 Time#now 1.43 4.16 0.13 200 0.65 1.40 Hash#to_mash 1.43 4.29 0.13 100 1.30 55.30 Merb::Dispatcher#handle 1.32 4.41 0.12 100 1.20 17.30 Merb::Controller#dispatch 1.32 4.53 0.12 700 0.17 0.24 Mash#convert_key 1.32 4.65 0.12 300 0.40 0.80 Mongrel::HeaderOut#[]= 1.21 4.76 0.11 100 1.10 3.90 Merb::Controller#build 1.10 4.86 0.10 800 0.13 1.03 Merb::Request#route_params 1.10 4.96 0.10 200 0.50 0.55 Mongrel::HttpResponse#send_header 0.99 5.05 0.09 300 0.30 1.00 Hash#each_pair 0.99 5.14 0.09 100 0.90 1.10 Merb::Request#method 0.99 5.23 0.09 55 1.64 24.73 Kernel.sleep 0.88 5.31 0.08 200 0.40 0.40 File#expand_path 0.88 5.39 0.08 400 0.20 0.20 String#% 0.88 5.47 0.08 200 0.40 0.70 Mash#initialize 0.88 5.55 0.08 200 0.40 0.55 Mash#include? 0.77 5.62 0.07 100 0.70 6.10 Merb::AbstractController#dispatch 0.77 5.69 0.07 100 0.70 4.90 Mongrel::HttpResponse#initialize 0.77 5.76 0.07 200 0.35 1.20 Mongrel::DirHandler#can_serve 0.77 5.83 0.07 1800 0.04 0.04 Hash#default 0.77 5.90 0.07 800 0.09 0.85 Merb::Request#route_match 0.77 5.97 0.07 100 0.70 1.60 Merb::Controller#set_dispatch_variables 0.66 6.03 0.06 400 0.15 0.62 Merb::AbstractController#after_filters 0.66 6.09 0.06 100 0.60 0.60 StringScanner#scan 0.66 6.15 0.06 100 0.60 0.70 Object#blank? 0.66 6.21 0.06 200 0.30 2.25 Merb::Request#query_parse 0.66 6.27 0.06 200 0.30 0.30 String#gsub 0.66 6.33 0.06 400 0.15 0.68 Merb::Controller#_session_id_key 0.66 6.39 0.06 1438 0.04 0.04 Kernel.nil? 0.66 6.45 0.06 1000 0.06 0.06 Hash#[]= 0.55 6.50 0.05 99 0.51 52.63 TCPServer#accept 0.55 6.55 0.05 200 0.25 1.40 Merb::Request#cookies 0.55 6.60 0.05 900 0.06 0.06 Array#last 0.55 6.65 0.05 100 0.50 1.20 Mongrel::HttpResponse#finished 0.55 6.70 0.05 100 0.50 5.70 Merb::SessionMixin.setup_session 0.55 6.75 0.05 76 0.66 1.18 Array#map 0.55 6.80 0.05 400 0.13 0.22 Mash#convert_value 0.55 6.85 0.05 300 0.17 0.23 StringIO#initialize 0.55 6.90 0.05 400 0.13 0.22 Mongrel::HttpResponse#write 0.55 6.95 0.05 400 0.13 0.27 Merb::Request#content_type 0.55 7.00 0.05 100 0.50 4.70 Merb::Request#controller_class 0.55 7.05 0.05 100 0.50 2.60 Object#full_const_get 0.55 7.10 0.05 200 0.25 0.25 String#to_s 0.55 7.15 0.05 100 0.50 1.00 Thread#new 0.55 7.20 0.05 100 0.50 0.50 Merb::Controller#status ... snip everything below 0.5% 0.00 9.09 0.00 1 0.00 9090.00 #toplevel This is more interesting: even though nothing is actually logged, because of the large number of calls to Logger#add it still accounts for 4.62%, with another 2.75% for Logger#info and 1.54% for Time#now (the fact it has been called 1000 times suggests that timestamps are being made for log entries which are never written!) Merb::Router#match is now the number two offender at 3.85%, but this is probably still not enough by itself to warrant a rewrite. Regards, Brian. From B.Candler at pobox.com Wed Sep 19 05:36:03 2007 From: B.Candler at pobox.com (Brian Candler) Date: Wed, 19 Sep 2007 10:36:03 +0100 Subject: Routes In-Reply-To: <20070919084113.GA4422@uk.tiscali.com> References: <21ee31950709171814j6f81571ai68c040b69a5ad386@mail.gmail.com> <20070918110107.GA5221@uk.tiscali.com> <20070918121741.GA10181@uk.tiscali.com> <20070918135557.GA13662@uk.tiscali.com> <83645E16-4843-4EB0-BB3D-B12076A596FB@engineyard.com> <20070919084113.GA4422@uk.tiscali.com> Message-ID: <20070919093603.GA8465@uk.tiscali.com> OK, I hacked together a simple replacement logger, and this is what I get with logging *enabled* (merb -e production) % cumulative self self total time seconds seconds calls ms/call ms/call name 3.69 0.34 0.34 100 3.40 76.60 MerbHandler#process 3.25 0.64 0.30 800 0.38 0.73 Merb::Logger#info 3.15 0.93 0.29 3724 0.08 0.20 Hash#[] 3.04 1.21 0.28 400 0.70 1.47 Hash#inspect 2.93 1.48 0.27 300 0.90 2.10 Hash#each_pair 2.60 1.72 0.24 52 4.62 43.27 Kernel.sleep 2.60 1.96 0.24 200 1.20 1.75 Mongrel::HttpResponse#send_status 2.49 2.19 0.23 400 0.58 1.02 Merb::AbstractController#after_filters 2.17 2.39 0.20 100 2.00 2.60 Mongrel::HttpRequest#initialize 2.17 2.59 0.20 100 2.00 25.80 IO#close 2.06 2.78 0.19 1600 0.12 0.73 Class#new 2.06 2.97 0.19 100 1.90 4.60 Merb::Request#query_params 1.95 3.15 0.18 200 0.90 1.60 Mash#include? 1.95 3.33 0.18 400 0.45 0.45 String#split 1.84 3.50 0.17 100 1.70 8.50 Merb::AbstractController#dispatch 1.63 3.65 0.15 700 0.21 0.29 Mash#convert_key 1.52 3.79 0.14 100 1.40 19.90 Merb::Controller#dispatch 1.52 3.93 0.14 100 1.40 70.10 Mongrel::HttpServer#process_client 1.41 4.06 0.13 100 1.30 2.80 Merb::Router#match 1.41 4.19 0.13 800 0.16 0.59 Merb::Request#route_params 1.41 4.32 0.13 300 0.43 0.67 Mongrel::HeaderOut#[]= 1.30 4.44 0.12 300 0.40 0.40 Hash#key? 1.30 4.56 0.12 400 0.30 0.30 NilClass#inspect 1.19 4.67 0.11 400 0.28 0.28 Mash#convert_value 1.19 4.78 0.11 1300 0.08 0.08 Kernel.class 1.19 4.89 0.11 900 0.12 0.12 String#[] 1.19 5.00 0.11 100 1.10 56.20 Merb::Dispatcher#handle 1.08 5.10 0.10 400 0.25 0.70 Merb::AbstractController#before_filters 1.08 5.20 0.10 200 0.50 2.10 Mash#default ... snip less than 1% 0.00 9.22 0.00 1 0.00 9220.00 #toplevel Performance test using ab -n 1000 http://localhost:4000/hello/world [Before patch] Requests per second: 276.78 [#/sec] (mean) Time per request: 3.613 [ms] (mean) [After patch] Requests per second: 401.49 [#/sec] (mean) Time per request: 2.491 [ms] (mean) This is on a 1.1GHz Pentium M. It would be interesting to see what people with higher-performance servers achieve. Cheers, Brian. P.S. In this code, a single write is done at the end of each request. I've not protected it with a mutex, because I think that IO#write is atomic, but I may be wrong. More performance could perhaps be achieved by not flushing after every request, but by doing this in a background thread. However I think it might make more sense if we're going this route to give each request its own log buffer, so that logs don't get interspersed from overlapping requests in a multi-threaded application. Also, I notice that the logger class and initialisation is currently hard-coded into merb.rb; perhaps it would be better to make this configurable. -------------- next part -------------- --- lib/merb.rb.orig 2007-09-19 09:55:24.000000000 +0100 +++ lib/merb.rb 2007-09-19 09:56:37.000000000 +0100 @@ -10,7 +10,7 @@ end require 'fileutils' require 'merb/erubis_ext' -require 'logger' +require 'merb/logger' require 'json' require 'set' autoload :MerbUploadHandler, 'merb/upload_handler' @@ -67,8 +67,8 @@ MERB_VIEW_ROOT = MERB_ROOT / "app/views" MERB_SKELETON_DIR = File.join(MERB_FRAMEWORK_ROOT, '../app_generators/merb/templates') logpath = $TESTING ? "#{MERB_ROOT}/merb_test.log" : "#{MERB_ROOT}/log/merb.#{Merb::Server.config[:port]}.log" -MERB_LOGGER = Logger.new(logpath) -MERB_LOGGER.level = Logger.const_get(Merb::Server.config[:log_level].upcase) rescue Logger::INFO +MERB_LOGGER = Merb::Logger.new(logpath) +MERB_LOGGER.level = Merb::Logger.const_get(Merb::Server.config[:log_level].upcase) rescue Merb::Logger::INFO MERB_PATHS = [ "/app/models/**/*.rb", "/app/controllers/application.rb", @@ -82,4 +82,4 @@ if $TESTING test_files = File.join(lib, 'test', '*.rb') Dir[test_files].each { |file| require file } -end \ No newline at end of file +end --- lib/merb/mongrel_handler.rb.orig 2007-09-16 19:32:04.000000000 +0100 +++ lib/merb/mongrel_handler.rb 2007-09-19 10:10:39.000000000 +0100 @@ -145,8 +145,8 @@ total_request_time = Time.now - start benchmarks[:total_request_time] = total_request_time - MERB_LOGGER.info("Request Times: #{benchmarks.inspect}") - MERB_LOGGER.info("Response status: #{response.status}\nComplete Request took: #{total_request_time} seconds, #{1.0/total_request_time} Requests/Second\n\n") + MERB_LOGGER.info("Request Times: #{benchmarks.inspect}\nResponse status: #{response.status}\nComplete Request took: #{total_request_time} seconds, #{1.0/total_request_time} Requests/Second\n\n") + MERB_LOGGER.flush end rescue Object => e # if an exception is raised here then something is --- lib/merb/logger.rb.orig 2007-09-19 10:14:33.000000000 +0100 +++ lib/merb/logger.rb 2007-09-19 10:06:37.000000000 +0100 @@ -0,0 +1,70 @@ +module Merb + # Logging is called several times for each request, so keep it short and + # sweet. Use << for atomic add to buffer, and slice! for atomic removal. + + class Logger + module Severity + DEBUG = 0 + INFO = 1 + WARN = 2 + ERROR = 3 + FATAL = 4 + UNKNOWN = 5 + end + include Severity + + attr_accessor :level + attr_reader :buf + def initialize(log) + @level = level + @buf = "" + if log.respond_to?(:write) + @log = log + elsif File.exist?(log) + @log = open(log, (File::WRONLY | File::APPEND)) + @log.sync = true + else + @log = open(log, (File::WRONLY | File::APPEND | File::CREAT)) + @log.sync = true + @log.write("# Logfile created on %s" % [Time.now.to_s]) + end + end + + def flush + return if @buf.size == 0 + @log.write @buf.slice!(0..-1) + end + + def close + flush + @log.close if @log.respond_to? :close + @log = nil + end + + def debug(msg) + return if @level > DEBUG + msg << "\n" unless msg[-1] == ?\n + @buf << msg + end + def info(msg) + return if @level > INFO + msg << "\n" unless msg[-1] == ?\n + @buf << msg + end + def warn(msg) + return if @level > WARN + msg << "\n" unless msg[-1] == ?\n + @buf << msg + end + def error(msg) + return if @level > ERROR + msg << "\n" unless msg[-1] == ?\n + @buf << msg + end + def error(msg) + return if @level > FATAL + msg << "\n" unless msg[-1] == ?\n + @buf << msg + end + end +end From ez at engineyard.com Wed Sep 19 13:33:13 2007 From: ez at engineyard.com (Ezra Zygmuntowicz) Date: Wed, 19 Sep 2007 10:33:13 -0700 Subject: Routes In-Reply-To: <20070919093603.GA8465@uk.tiscali.com> References: <21ee31950709171814j6f81571ai68c040b69a5ad386@mail.gmail.com> <20070918110107.GA5221@uk.tiscali.com> <20070918121741.GA10181@uk.tiscali.com> <20070918135557.GA13662@uk.tiscali.com> <83645E16-4843-4EB0-BB3D-B12076A596FB@engineyard.com> <20070919084113.GA4422@uk.tiscali.com> <20070919093603.GA8465@uk.tiscali.com> Message-ID: Hi~ On Sep 19, 2007, at 2:36 AM, Brian Candler wrote: > OK, I hacked together a simple replacement logger, and this is what > I get > with logging *enabled* (merb -e production) > > % cumulative self self total > time seconds seconds calls ms/call ms/call name > 3.69 0.34 0.34 100 3.40 76.60 > MerbHandler#process > 3.25 0.64 0.30 800 0.38 0.73 > Merb::Logger#info > 3.15 0.93 0.29 3724 0.08 0.20 Hash#[] > 3.04 1.21 0.28 400 0.70 1.47 Hash#inspect > 2.93 1.48 0.27 300 0.90 2.10 Hash#each_pair > 2.60 1.72 0.24 52 4.62 43.27 Kernel.sleep > 2.60 1.96 0.24 200 1.20 1.75 > Mongrel::HttpResponse#send_status > 2.49 2.19 0.23 400 0.58 1.02 > Merb::AbstractController#after_filters > 2.17 2.39 0.20 100 2.00 2.60 > Mongrel::HttpRequest#initialize > 2.17 2.59 0.20 100 2.00 25.80 IO#close > 2.06 2.78 0.19 1600 0.12 0.73 Class#new > 2.06 2.97 0.19 100 1.90 4.60 > Merb::Request#query_params 1.95 3.15 0.18 200 > 0.90 1.60 Mash#include? > 1.95 3.33 0.18 400 0.45 0.45 String#split > 1.84 3.50 0.17 100 1.70 8.50 > Merb::AbstractController#dispatch > 1.63 3.65 0.15 700 0.21 0.29 Mash#convert_key > 1.52 3.79 0.14 100 1.40 19.90 > Merb::Controller#dispatch > 1.52 3.93 0.14 100 1.40 70.10 > Mongrel::HttpServer#process_client > 1.41 4.06 0.13 100 1.30 2.80 > Merb::Router#match > 1.41 4.19 0.13 800 0.16 0.59 > Merb::Request#route_params 1.41 4.32 0.13 300 > 0.43 0.67 Mongrel::HeaderOut#[]= > 1.30 4.44 0.12 300 0.40 0.40 Hash#key? > 1.30 4.56 0.12 400 0.30 0.30 NilClass#inspect > 1.19 4.67 0.11 400 0.28 0.28 > Mash#convert_value > 1.19 4.78 0.11 1300 0.08 0.08 Kernel.class > 1.19 4.89 0.11 900 0.12 0.12 String#[] > 1.19 5.00 0.11 100 1.10 56.20 > Merb::Dispatcher#handle > 1.08 5.10 0.10 400 0.25 0.70 > Merb::AbstractController#before_filters > 1.08 5.20 0.10 200 0.50 2.10 Mash#default > ... snip less than 1% > 0.00 9.22 0.00 1 0.00 9220.00 #toplevel > > Performance test using ab -n 1000 http://localhost:4000/hello/world > > [Before patch] > > Requests per second: 276.78 [#/sec] (mean) > Time per request: 3.613 [ms] (mean) > > [After patch] > > Requests per second: 401.49 [#/sec] (mean) > Time per request: 2.491 [ms] (mean) > > This is on a 1.1GHz Pentium M. It would be interesting to see what > people > with higher-performance servers achieve. > > Cheers, > > Brian. > > P.S. In this code, a single write is done at the end of each > request. I've > not protected it with a mutex, because I think that IO#write is > atomic, but > I may be wrong. > > More performance could perhaps be achieved by not flushing after every > request, but by doing this in a background thread. However I think > it might > make more sense if we're going this route to give each request its > own log > buffer, so that logs don't get interspersed from overlapping > requests in a > multi-threaded application. > > Also, I notice that the logger class and initialisation is currently > hard-coded into merb.rb; perhaps it would be better to make this > configurable. > Nice one. We were actually just talking about fixing the logger the other day after some profiling and I was going to make a logger that collected up the strings and then output them once per request. I;ll take a look at your patch and will probably make the logger configurable so we can test different loggers. Cheers- -- Ezra Zygmuntowicz -- Founder & Ruby Hacker -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) From scaudill at gmail.com Wed Sep 19 16:08:51 2007 From: scaudill at gmail.com (Stephen Caudill) Date: Wed, 19 Sep 2007 16:08:51 -0400 Subject: Ticket #190 (friendlier way to add / register a mime type) Message-ID: <61CF1164-839C-4B93-9562-506FD33B5AD0@gmail.com> Following up on #190 [1], I've just added a simple patch that allows the manipulation of the TYPES hash from within the Merb module. Use like: Merb.add_mime_type(:png,%w[image/png]) Merb.remove_mime_type(:png) It specifically disallows the removal of the :all MimeType, since content negotiation relies on it. I'm not super wonderful at API design, so comments and suggestions, are of course welcome. If everyone likes it as-is, just shout and I'll commit it. -- Stephen [1] http://merb.devjavu.com/projects/merb/ticket/190 From ivey at gweezlebur.com Thu Sep 20 01:00:24 2007 From: ivey at gweezlebur.com (Michael D. Ivey) Date: Thu, 20 Sep 2007 00:00:24 -0500 Subject: Proposed API change for respond_to Message-ID: <4725AEF0-3E7B-4150-9528-93B298977B75@gweezlebur.com> Ez (or someone) asked on #merb tonight whether respond_to was the right API for what it does. After some discussion and pasties, I offer the following proposed API for content negotiation and response format selection: First, what does respond_to do right now? I see at as performing 3 distinct operations: 1. parse params[:format] and the accepts header to find out what format the client wants 2. look at all the calls to the responder to see what formats the action provides 3. reconcile 1 and 2 and pick a format I propose that we split #2 and #3 into explicit steps. Here's a sample controller using the new API: class ManyFormats < Application # controllers provide :html by default, so this is implied: provides :html # every action in this controller also provides :xml and :txt provides :xml, :txt def index # index also provides :js provides :js # this is smart, and based on all the things # currently provided and all the things the client # accepts, returns a Symbol for the response format case request.format when :html, :txt render when :xml SomeClass.to_xml when :js "Object.new()" end end def textonlyaction only_provides :txt # this wipes out :html and :xml from the controller-level # declarations render end end Win #1: respond_to is no longer a magic black box, we have explicit definition of our formats and explicit flow control of our rendering Win #2: in the case where most/all formats use templates, we get simpler code: class CurrentWay < Application def index respond_to do |fmt| fmt.html { render } fmt.xml { render } fmt.txt { render } fmt.js { render } end end end class ProposedWay < Application def index provides :html, :xml, :txt, :js render end end Win #2.5: Say you wrote an app without respond_to, using only HTML, and then decide you want to support FBML or PBJML. With the current API you have to modify every single action in every single controller to add a respond_to block. With the proposed API you add "provides :pbjml" to Application and add your templates and it's done. Added bonus: we can keep a respond_to on top of the provides() variables for people who like it. Thoughts? Suggestions? I'm not too emotionally attached to this yet, so feel free to pick at it or shoot it down. If it's still deemed viable by the weekend, I'll code it. From josh at hasmanythrough.com Thu Sep 20 01:54:46 2007 From: josh at hasmanythrough.com (Josh Susser) Date: Wed, 19 Sep 2007 22:54:46 -0700 Subject: Proposed API change for respond_to In-Reply-To: <4725AEF0-3E7B-4150-9528-93B298977B75@gweezlebur.com> References: <4725AEF0-3E7B-4150-9528-93B298977B75@gweezlebur.com> Message-ID: <2CA64E1D-966F-4894-8C8C-7BBECE14E1B8@hasmanythrough.com> I very much dislike the respond_to case-statement style of handling multiple formats. If you have a class that has the same case statement in most of its methods, then it should be broken up into multiple classes. Case statements to select behavior that way are redundant in an object-oriented language. I've been mulling over a cleaner way of replacing respond_to with either a superclass and subclasses, or a class and modules. I've been trying to work that out in Rails, but if it's a useful design it should port over to Merb pretty easily. I do like how you break out the provides() method, but I think we can get there another way with less work. I don't mean to be cryptic or anything, but I haven't worked out my ideas well enough to say anything really specific about them yet. Now that you've reminded me again about this issue I'll see if I can get something sorted out soon. --josh On Sep 19, 2007, at 10:00 PM, Michael D. Ivey wrote: > Ez (or someone) asked on #merb tonight whether respond_to was the > right API for > what it does. After some discussion and pasties, I offer the > following proposed > API for content negotiation and response format selection: > > First, what does respond_to do right now? I see at as performing 3 > distinct > operations: > 1. parse params[:format] and the accepts header to find out what > format the > client wants > 2. look at all the calls to the responder to see what formats the > action > provides > 3. reconcile 1 and 2 and pick a format > > I propose that we split #2 and #3 into explicit steps. > > Here's a sample controller using the new API: > > class ManyFormats < Application > # controllers provide :html by default, so this is implied: > provides :html > > # every action in this controller also provides :xml and :txt > provides :xml, :txt > > def index > # index also provides :js > provides :js > > # this is smart, and based on all the things > # currently provided and all the things the client > # accepts, returns a Symbol for the response format > case request.format > when :html, :txt > render > when :xml > SomeClass.to_xml > when :js > "Object.new()" > end > end > > def textonlyaction > only_provides :txt > # this wipes out :html and :xml from the controller-level > # declarations > render > end > end > > > Win #1: respond_to is no longer a magic black box, we have explicit > definition of > our formats and explicit flow control of our rendering > > Win #2: in the case where most/all formats use templates, we get > simpler code: > > class CurrentWay < Application > def index > respond_to do |fmt| > fmt.html { render } > fmt.xml { render } > fmt.txt { render } > fmt.js { render } > end > end > end > > class ProposedWay < Application > def index > provides :html, :xml, :txt, :js > render > end > end > > Win #2.5: Say you wrote an app without respond_to, using only HTML, > and then > decide you want to support FBML or PBJML. With the current API you > have to > modify every single action in every single controller to add a > respond_to block. > With the proposed API you add "provides :pbjml" to Application and > add your > templates and it's done. > > Added bonus: we can keep a respond_to on top of the provides() > variables for > people who like it. > > > Thoughts? Suggestions? I'm not too emotionally attached to this > yet, so feel > free to pick at it or shoot it down. > > If it's still deemed viable by the weekend, I'll code it. -- Josh Susser http://blog.hasmanythrough.com From ivey at gweezlebur.com Thu Sep 20 12:08:09 2007 From: ivey at gweezlebur.com (Michael D. Ivey) Date: Thu, 20 Sep 2007 11:08:09 -0500 Subject: Proposed API change for respond_to In-Reply-To: <2CA64E1D-966F-4894-8C8C-7BBECE14E1B8@hasmanythrough.com> References: <4725AEF0-3E7B-4150-9528-93B298977B75@gweezlebur.com> <2CA64E1D-966F-4894-8C8C-7BBECE14E1B8@hasmanythrough.com> Message-ID: On Sep 20, 2007, at 12:54 AM, Josh Susser wrote: > I very much dislike the respond_to case-statement style of handling > multiple formats. If you have a class that has the same case > statement in most of its methods, then it should be broken up into > multiple classes. Case statements to select behavior that way are > redundant in an object-oriented language. Do you mean you dislike the current respond_to, my proposed change, or both? :) Any chance you'll have a high-level picture of what you're thinking before the weekend? I'd love to see it. From ry at tinyclouds.org Thu Sep 20 13:21:46 2007 From: ry at tinyclouds.org (ry dahl) Date: Thu, 20 Sep 2007 19:21:46 +0200 Subject: Proposed API change for respond_to In-Reply-To: References: <4725AEF0-3E7B-4150-9528-93B298977B75@gweezlebur.com> <2CA64E1D-966F-4894-8C8C-7BBECE14E1B8@hasmanythrough.com> Message-ID: <21ee31950709201021s4110c09ck5ed45786c94f515a@mail.gmail.com> Sometimes it seems like actions deserve to be their own objects: we map routes to them, we'd like to know what parameters they expect, we want to say which http methods they accept, we assign them before/after filters, and we even hold collections of them (Controller.callable_actions). This responds_to issue is another example of how we'd like to treat actions as objects. We would like for the controller to look at the request, determine which format to send, and then simply call my_action.render_json or my_action.render_html. Simultaneously, our controllers are not very class like. They are basically instantiate them only to call the action. Changing the Controller class into a module would not be so hard in the current Merb - they are (more or less) just containers for actions. Has anyone else been having these thoughts? ry On 9/20/07, Michael D. Ivey wrote: > On Sep 20, 2007, at 12:54 AM, Josh Susser wrote: > > I very much dislike the respond_to case-statement style of handling > > multiple formats. If you have a class that has the same case > > statement in most of its methods, then it should be broken up into > > multiple classes. Case statements to select behavior that way are > > redundant in an object-oriented language. > > Do you mean you dislike the current respond_to, my proposed change, > or both? :) > > Any chance you'll have a high-level picture of what you're thinking > before the weekend? I'd love to see it. > _______________________________________________ > Merb-devel mailing list > Merb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/merb-devel > From ry at tinyclouds.org Thu Sep 20 14:13:00 2007 From: ry at tinyclouds.org (ry dahl) Date: Thu, 20 Sep 2007 20:13:00 +0200 Subject: Proposed API change for respond_to In-Reply-To: <21ee31950709201021s4110c09ck5ed45786c94f515a@mail.gmail.com> References: <4725AEF0-3E7B-4150-9528-93B298977B75@gweezlebur.com> <2CA64E1D-966F-4894-8C8C-7BBECE14E1B8@hasmanythrough.com> <21ee31950709201021s4110c09ck5ed45786c94f515a@mail.gmail.com> Message-ID: <21ee31950709201113t75a5e0d6wfb72e5e3c871a5a8@mail.gmail.com> For example, module Controllers::Products class Index < GetAction def initialize(params) @products = Product.paginate(params[:page] || 1) end def response_json @products.to_json end def response_html render 'products/index.erb' end end class Show < GetAction extra_route ':id' def initialize(params) @products = Product.find(params[:id]) end def response_html render 'products/show.erb' end end end <%= link_to 'Products', Controllers::Products::Index.url %> On 9/20/07, ry dahl wrote: > Sometimes it seems like actions deserve to be their own objects: we > map routes to them, we'd like to know what parameters they expect, we > want to say which http methods they accept, we assign them > before/after filters, and we even hold collections of them > (Controller.callable_actions). This responds_to issue is another > example of how we'd like to treat actions as objects. We would like > for the controller to look at the request, determine which format to > send, and then simply call my_action.render_json or > my_action.render_html. Simultaneously, our controllers are not very > class like. They are basically instantiate them only to call the > action. Changing the Controller class into a module would not be so > hard in the current Merb - they are (more or less) just containers for > actions. > > Has anyone else been having these thoughts? > > ry From josh at hasmanythrough.com Thu Sep 20 14:28:37 2007 From: josh at hasmanythrough.com (Josh Susser) Date: Thu, 20 Sep 2007 11:28:37 -0700 Subject: Proposed API change for respond_to In-Reply-To: <21ee31950709201113t75a5e0d6wfb72e5e3c871a5a8@mail.gmail.com> References: <4725AEF0-3E7B-4150-9528-93B298977B75@gweezlebur.com> <2CA64E1D-966F-4894-8C8C-7BBECE14E1B8@hasmanythrough.com> <21ee31950709201021s4110c09ck5ed45786c94f515a@mail.gmail.com> <21ee31950709201113t75a5e0d6wfb72e5e3c871a5a8@mail.gmail.com> Message-ID: <9EAEDBB7-8C03-4974-BD73-0E52128062E9@hasmanythrough.com> That's kind of interesting. I agree that actions seem more like objects than methods sometimes, but here you have them done up as classes, not objects. I think the number of classes involved in this approach might be a bit much. Gets me thinking though. I'll see if I can apply some gray matter to the problem in the next day or two... On Sep 20, 2007, at 11:13 AM, ry dahl wrote: > For example, > > module Controllers::Products > class Index < GetAction > def initialize(params) > @products = Product.paginate(params[:page] || 1) > end > > def response_json > @products.to_json > end > > def response_html > render 'products/index.erb' > end > end > > class Show < GetAction > extra_route ':id' > > def initialize(params) > @products = Product.find(params[:id]) > end > > def response_html > render 'products/show.erb' > end > end > end > > <%= link_to 'Products', Controllers::Products::Index.url %> > > > On 9/20/07, ry dahl wrote: >> Sometimes it seems like actions deserve to be their own objects: we >> map routes to them, we'd like to know what parameters they expect, we >> want to say which http methods they accept, we assign them >> before/after filters, and we even hold collections of them >> (Controller.callable_actions). This responds_to issue is another >> example of how we'd like to treat actions as objects. We would like >> for the controller to look at the request, determine which format to >> send, and then simply call my_action.render_json or >> my_action.render_html. Simultaneously, our controllers are not very >> class like. They are basically instantiate them only to call the >> action. Changing the Controller class into a module would not be so >> hard in the current Merb - they are (more or less) just containers >> for >> actions. >> >> Has anyone else been having these thoughts? >> >> ry > -- Josh Susser http://blog.hasmanythrough.com From ry at tinyclouds.org Thu Sep 20 16:13:01 2007 From: ry at tinyclouds.org (ry dahl) Date: Thu, 20 Sep 2007 22:13:01 +0200 Subject: Proposed API change for respond_to In-Reply-To: References: <4725AEF0-3E7B-4150-9528-93B298977B75@gweezlebur.com> <2CA64E1D-966F-4894-8C8C-7BBECE14E1B8@hasmanythrough.com> <21ee31950709201021s4110c09ck5ed45786c94f515a@mail.gmail.com> <21ee31950709201113t75a5e0d6wfb72e5e3c871a5a8@mail.gmail.com> Message-ID: <21ee31950709201313m5c7bd232o6032a2d57ede6db0@mail.gmail.com> On 9/20/07, John Weir wrote: > how would filters and common methods work? one way this could be done is by attaching a filters as class methods to the actions. for example module Controllers::Products before Index, Show do |request| raise Unauthorized unless request.session[:user].admin? end ... end would take the block argument, add do Index.class_eval { @@before_filter = block } for both Index and Show. At the time of request, the dispatcher could call that block before instantiating the action. this is just an example for entertaining the idea - not a proposal - i haven't thought all the way through it > > For example, > > > > module Controllers::Products > > class Index < GetAction > > def initialize(params) > > @products = Product.paginate(params[:page] || 1) > > end > > > > def response_json > > @products.to_json > > end > > > > def response_html > > render 'products/index.erb' > > end > > end > > > > class Show < GetAction > > extra_route ':id' > > > > def initialize(params) > > @products = Product.find(params[:id]) > > end > > > > def response_html > > render 'products/show.erb' > > end > > end > > end > > > > <%= link_to 'Products', Controllers::Products::Index.url %> > > > > > > On 9/20/07, ry dahl wrote: > >> Sometimes it seems like actions deserve to be their own objects: we > >> map routes to them, we'd like to know what parameters they expect, we > >> want to say which http methods they accept, we assign them > >> before/after filters, and we even hold collections of them > >> (Controller.callable_actions). This responds_to issue is another > >> example of how we'd like to treat actions as objects. We would like > >> for the controller to look at the request, determine which format to > >> send, and then simply call my_action.render_json or > >> my_action.render_html. Simultaneously, our controllers are not very > >> class like. They are basically instantiate them only to call the > >> action. Changing the Controller class into a module would not be so > >> hard in the current Merb - they are (more or less) just containers > >> for > >> actions. > >> > >> Has anyone else been having these thoughts? > >> From ez at engineyard.com Thu Sep 20 17:18:12 2007 From: ez at engineyard.com (Ezra Zygmuntowicz) Date: Thu, 20 Sep 2007 14:18:12 -0700 Subject: Proposed API change for respond_to In-Reply-To: <21ee31950709201313m5c7bd232o6032a2d57ede6db0@mail.gmail.com> References: <4725AEF0-3E7B-4150-9528-93B298977B75@gweezlebur.com> <2CA64E1D-966F-4894-8C8C-7BBECE14E1B8@hasmanythrough.com> <21ee31950709201021s4110c09ck5ed45786c94f515a@mail.gmail.com> <21ee31950709201113t75a5e0d6wfb72e5e3c871a5a8@mail.gmail.com> <21ee31950709201313m5c7bd232o6032a2d57ede6db0@mail.gmail.com> Message-ID: <9AC1CAB9-968D-4983-883A-1A0D9B1D823E@engineyard.com> Merb controllers cannot be modules because modules are not instantiatable. The way merb's thread safety works is by instantiating a new controller object for each new request/thread. -Ezra On Sep 20, 2007, at 1:13 PM, ry dahl wrote: > On 9/20/07, John Weir wrote: >> how would filters and common methods work? > > one way this could be done is by attaching a filters as class methods > to the actions. for example > > module Controllers::Products > before Index, Show do |request| > raise Unauthorized unless request.session[:user].admin? > end > ... > end > > would take the block argument, add do > Index.class_eval { @@before_filter = block } > for both Index and Show. At the time of request, the dispatcher could > call that block before instantiating the action. > > this is just an example for entertaining the idea - not a proposal - i > haven't thought all the way through it > > >>> For example, >>> >>> module Controllers::Products >>> class Index < GetAction >>> def initialize(params) >>> @products = Product.paginate(params[:page] || 1) >>> end >>> >>> def response_json >>> @products.to_json >>> end >>> >>> def response_html >>> render 'products/index.erb' >>> end >>> end >>> >>> class Show < GetAction >>> extra_route ':id' >>> >>> def initialize(params) >>> @products = Product.find(params[:id]) >>> end >>> >>> def response_html >>> render 'products/show.erb' >>> end >>> end >>> end >>> >>> <%= link_to 'Products', Controllers::Products::Index.url %> >>> >>> >>> On 9/20/07, ry dahl wrote: >>>> Sometimes it seems like actions deserve to be their own objects: we >>>> map routes to them, we'd like to know what parameters they >>>> expect, we >>>> want to say which http methods they accept, we assign them >>>> before/after filters, and we even hold collections of them >>>> (Controller.callable_actions). This responds_to issue is another >>>> example of how we'd like to treat actions as objects. We would like >>>> for the controller to look at the request, determine which >>>> format to >>>> send, and then simply call my_action.render_json or >>>> my_action.render_html. Simultaneously, our controllers are not very >>>> class like. They are basically instantiate them only to call the >>>> action. Changing the Controller class into a module would not be so >>>> hard in the current Merb - they are (more or less) just containers >>>> for >>>> actions. >>>> >>>> Has anyone else been having these thoughts? >>>> > _______________________________________________ > Merb-devel mailing list > Merb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/merb-devel -- Ezra Zygmuntowicz -- Founder & Ruby Hacker -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) From adamjroth at gmail.com Fri Sep 21 02:28:40 2007 From: adamjroth at gmail.com (Adam Roth) Date: Fri, 21 Sep 2007 02:28:40 -0400 Subject: merb 0.4.0 - redirect problems Message-ID: <390fc99d0709202328o790d2840i7c18b7d75204c78f@mail.gmail.com> I had redirects working just the other day... before I upgraded to the latest release. Can somebody please chime in as to why this simple redirect is throwing an error? Controller: ----------------------- def do redirect "http://www.ebay.com" end Error Output: ------------------------- Internal server error 500 uninitialized constant Merb::ControllerMixin::MovedTemporarily in /lib/merb/mixins/controller.rb: def redirect( url ) MERB_LOGGER.info("Redirecting to: #{url}") raise MovedTemporarily, url end Thanks Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/merb-devel/attachments/20070921/6d288670/attachment.html From ry at tinyclouds.org Fri Sep 21 06:46:49 2007 From: ry at tinyclouds.org (ry dahl) Date: Fri, 21 Sep 2007 12:46:49 +0200 Subject: merb 0.4.0 - redirect problems In-Reply-To: <390fc99d0709202328o790d2840i7c18b7d75204c78f@mail.gmail.com> References: <390fc99d0709202328o790d2840i7c18b7d75204c78f@mail.gmail.com> Message-ID: <21ee31950709210346i387dc1f0jd8e752ed83d4e74d@mail.gmail.com> I love Chris' controller exceptions rewrite, but I don't think redirects should be handled with exceptions. It used to be very simple: def redirect(url) MERB_LOGGER.info("Redirecting to: #{url}") set_status(302) headers.merge!({'Location'=> url}) return '' end On 9/21/07, Adam Roth wrote: > I had redirects working just the other day... before I upgraded to the > latest release. Can somebody please chime in as to why this simple redirect > is throwing an error? > > Controller: > ----------------------- > def do > redirect "http://www.ebay.com" > end > > Error Output: > ------------------------- > Internal server error 500 > uninitialized constant > Merb::ControllerMixin::MovedTemporarily > > in /lib/merb/mixins/controller.rb: > > def redirect( url ) > MERB_LOGGER.info("Redirecting to: #{url}") > raise MovedTemporarily, url > end > > Thanks > Adam > > > _______________________________________________ > Merb-devel mailing list > Merb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/merb-devel > > From chris at oxdi.eu Fri Sep 21 06:53:14 2007 From: chris at oxdi.eu (Chris Farmiloe) Date: Fri, 21 Sep 2007 11:53:14 +0100 Subject: merb 0.4.0 - redirect problems In-Reply-To: <21ee31950709210346i387dc1f0jd8e752ed83d4e74d@mail.gmail.com> References: <390fc99d0709202328o790d2840i7c18b7d75204c78f@mail.gmail.com> <21ee31950709210346i387dc1f0jd8e752ed83d4e74d@mail.gmail.com> Message-ID: <2DA6D3F0-FEB1-4106-A9D1-F9221713DFE3@oxdi.eu> Yeah that, redirect really wasn't ready and shouldn't have been in the patch. if a raise'd version is ever left in it should be with a "!" def redirect!(url) ... end since it would stop execution, and that is not how you always want it. everyone get your +1's on #188 ;) Regards Farms. Design & Dev Oxygen. http://www.oxdi.eu On 21 Sep 2007, at 11:46, ry dahl wrote: > I love Chris' controller exceptions rewrite, but I don't think > redirects should be handled with exceptions. It used to be very > simple: > > def redirect(url) > MERB_LOGGER.info("Redirecting to: #{url}") > set_status(302) > headers.merge!({'Location'=> url}) > return '' > end > > On 9/21/07, Adam Roth wrote: >> I had redirects working just the other day... before I upgraded to >> the >> latest release. Can somebody please chime in as to why this simple >> redirect >> is throwing an error? >> >> Controller: >> ----------------------- >> def do >> redirect "http://www.ebay.com" >> end >> >> Error Output: >> ------------------------- >> Internal server error 500 >> uninitialized constant >> Merb::ControllerMixin::MovedTemporarily >> >> in /lib/merb/mixins/controller.rb: >> >> def redirect( url ) >> MERB_LOGGER.info("Redirecting to: #{url}") >> raise MovedTemporarily, url >> end >> >> Thanks >> Adam >> >> >> _______________________________________________ >> Merb-devel mailing list >> Merb-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/merb-devel >> >> > _______________________________________________ > Merb-devel mailing list > Merb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/merb-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/merb-devel/attachments/20070921/7bc85527/attachment-0001.html From ivey at gweezlebur.com Fri Sep 21 09:21:24 2007 From: ivey at gweezlebur.com (Michael D. Ivey) Date: Fri, 21 Sep 2007 08:21:24 -0500 Subject: merb 0.4.0 - redirect problems In-Reply-To: <2DA6D3F0-FEB1-4106-A9D1-F9221713DFE3@oxdi.eu> References: <390fc99d0709202328o790d2840i7c18b7d75204c78f@mail.gmail.com> <21ee31950709210346i387dc1f0jd8e752ed83d4e74d@mail.gmail.com> <2DA6D3F0-FEB1-4106-A9D1-F9221713DFE3@oxdi.eu> Message-ID: <89B53961-13EB-49C3-A69B-426ECD295D55@gweezlebur.com> On Sep 21, 2007, at 5:53 AM, Chris Farmiloe wrote: > everyone get your +1's on #188 ;) I just applied the patch in #188, so this should be fixed. From scaudill at gmail.com Fri Sep 21 10:43:16 2007 From: scaudill at gmail.com (Stephen Caudill) Date: Fri, 21 Sep 2007 10:43:16 -0400 Subject: Ticket #190 (friendlier way to add / register a mime type) In-Reply-To: <61CF1164-839C-4B93-9562-506FD33B5AD0@gmail.com> References: <61CF1164-839C-4B93-9562-506FD33B5AD0@gmail.com> Message-ID: <5F6F4288-95B4-40EA-83CF-42EB802A661C@gmail.com> Just wanted to bump this for comment. On Sep 19, 2007, at 4:08 PM, Stephen Caudill wrote: > Following up on #190 [1], I've just added a simple patch that > allows the manipulation of the TYPES hash from within the Merb > module. Use like: > > Merb.add_mime_type(:png,%w[image/png]) > Merb.remove_mime_type(:png) > > It specifically disallows the removal of the :all MimeType, since > content negotiation relies on it. > > I'm not super wonderful at API design, so comments and suggestions, > are of course welcome. If everyone likes it as-is, just shout and > I'll commit it. > > -- > > Stephen > > [1] http://merb.devjavu.com/projects/merb/ticket/190 From paul.dlug at gmail.com Fri Sep 21 11:15:08 2007 From: paul.dlug at gmail.com (Paul Dlug) Date: Fri, 21 Sep 2007 11:15:08 -0400 Subject: RESTful route gives a 500 error when Content-Type is set Message-ID: I have encountered a problem with a RESTful route, I have the simple route; r.resources :people With a corresponding controller, when I tried to access it using ActiveResource I get a server error, I have tracked this down to a problem where if the header 'Content-Type: application/xml' is sent it errors out: > curl -H 'Accept: */*' http://localhost:4000/people/test.xml John > curl -H 'Content-Type: application/xml' -H 'Accept: */*' http://localhost:4000/people/test.xml curl: (18) transfer closed with 475 bytes remaining to read 500 Internal Server Error I can't seem to replicate this with a spec so I'm not sure what's going on here. I'm running trunk merb updated as of this morning. I tried several days ago as well and had the same results. The following trace is in the logs: Request: REQUEST_URI: /people/test.xml (2007-09-21 11:13:31) undefined method `to_hash' for nil:NilClass - (NoMethodError) /usr/lib/ruby/gems/1.8/gems/merb-0.4.0/lib/merb/core_ext/hash.rb:265:in `from_xml' /usr/lib/ruby/gems/1.8/gems/merb-0.4.0/lib/merb/core_ext/hash.rb:67:in `from_xml' /usr/lib/ruby/gems/1.8/gems/merb-0.4.0/lib/merb/request.rb:83:in `xml_params' /usr/lib/ruby/gems/1.8/gems/merb-0.4.0/lib/merb/request.rb:96:in `params' /usr/lib/ruby/gems/1.8/gems/merb-0.4.0/lib/merb/controller.rb:49:in `set_dispatch_variables' /usr/lib/ruby/gems/1.8/gems/merb-0.4.0/lib/merb/controller.rb:43:in `build' /usr/lib/ruby/gems/1.8/gems/merb-0.4.0/lib/merb/dispatcher.rb:84:in `dispatch_default_exception' /usr/lib/ruby/gems/1.8/gems/merb-0.4.0/lib/merb/dispatcher.rb:74:in `dispatch_exception' /usr/lib/ruby/gems/1.8/gems/merb-0.4.0/lib/merb/dispatcher.rb:37:in `handle' /usr/lib/ruby/gems/1.8/gems/merb-0.4.0/lib/merb/mongrel_handler.rb:89:in `process' /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:618:in `process_client' /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:617:in `each' /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:617:in `process_client' /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:736:in `run' /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:736:in `initialize' /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:736:in `new' /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:736:in `run' /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:720:in `initialize' /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:720:in `new' /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:720:in `run' /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:271:in `run' /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:270:in `each' /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:270:in `run' /usr/lib/ruby/gems/1.8/gems/merb-0.4.0/lib/merb/server.rb:523:in `cloaker_' /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:51:in `call' /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:51:in `initialize' /usr/lib/ruby/gems/1.8/gems/merb-0.4.0/lib/merb/server.rb:513:in `new' /usr/lib/ruby/gems/1.8/gems/merb-0.4.0/lib/merb/server.rb:513:in `mongrel_start' /usr/lib/ruby/gems/1.8/gems/merb-0.4.0/lib/merb/server.rb:442:in `run' /usr/lib/ruby/gems/1.8/gems/merb-0.4.0/bin/merb:6 /usr/bin/merb:16:in `load' /usr/bin/merb:16 From ivey at gweezlebur.com Fri Sep 21 11:59:53 2007 From: ivey at gweezlebur.com (Michael D. Ivey) Date: Fri, 21 Sep 2007 10:59:53 -0500 Subject: RESTful route gives a 500 error when Content-Type is set In-Reply-To: References: Message-ID: <17BB150D-BA53-4E0B-8299-D1094926FC5D@gweezlebur.com> On Sep 21, 2007, at 10:15 AM, Paul Dlug wrote: > I have encountered a problem with a RESTful route, I have the > simple route; I put this in Trac: http://merb.devjavu.com/ticket/203 I'll try to look at it this afternoon, if no one else does. (BTW, Ez, I'm seeing 500s on Trac intermittently. Every 2 or 3 requests.) From dscataglini at dancingbeargroup.com Fri Sep 21 13:42:34 2007 From: dscataglini at dancingbeargroup.com (Diego Scataglini) Date: Fri, 21 Sep 2007 13:42:34 -0400 Subject: Fwd: Proposed API change for respond_to In-Reply-To: References: <4725AEF0-3E7B-4150-9528-93B298977B75@gweezlebur.com> <2CA64E1D-966F-4894-8C8C-7BBECE14E1B8@hasmanythrough.com> <21ee31950709201021s4110c09ck5ed45786c94f515a@mail.gmail.com> <21ee31950709201113t75a5e0d6wfb72e5e3c871a5a8@mail.gmail.com> <21ee31950709201313m5c7bd232o6032a2d57ede6db0@mail.gmail.com> <9AC1CAB9-968D-4983-883A-1A0D9B1D823E@engineyard.com> Message-ID: I like the "provides :xml" or "publish :xml" syntax with the usual options (:only, :except, :if etc.).that way you can manage all the response type from one location. Sometimes respond_to case-style works well when each response gets something different but many times that's not the case and when it doesn't, it sucks. In rails I created a helper that looks at the format param so that I can do something like render :xml => @user.to_xml if requested_as(:xml) I personally think that the guys from make_resourceful got it almost right. One thing that I think it's smart is not to use the "def" keyword. Since actions are more than just methods. You could do something more clever. build :index{ something here } that would either define multiple methods or return objects. You can still make it work with just methods, maybe something like this class User < Application # sets default responses and returns values publish :html, :xml, :json, :only => [:show, :edit, :destroy], :returns => {:user => [:login, :email], :head => "success"} # run filters conditionally to request type before :index, :show, :do => [:get_user, :increase_counter] if requested_as(:html, :xml) # custom responses by request types responses_for [:index, :destroy] => {:xml => :user, :html => render(" index.erb")} def index #only code in common with all the responses here. end end Just trowing some ideas out there. Diego I imagine you could pass reponses_for an array of hashes too. responses_for :show => {:xml => :user}, :destroy => {:xml => {:head => "success"}} responses_for :edit => {:xml => Proc.new{ render "index.erb"}} On 9/20/07, Ezra Zygmuntowicz wrote: > > > Merb controllers cannot be modules because modules are not > instantiatable. The way merb's thread safety works is by > instantiating a new controller object for each new request/thread. > > -Ezra > > On Sep 20, 2007, at 1:13 PM, ry dahl wrote: > > > On 9/20/07, John Weir wrote: > >> how would filters and common methods work? > > > > one way this could be done is by attaching a filters as class methods > > to the actions. for example > > > > module Controllers::Products > > before Index, Show do |request| > > raise Unauthorized unless request.session[:user].admin? > > end > > ... > > end > > > > would take the block argument, add do > > Index.class_eval { @@before_filter = block } > > for both Index and Show. At the time of request, the dispatcher could > > call that block before instantiating the action. > > > > this is just an example for entertaining the idea - not a proposal - i > > haven't thought all the way through it > > > > > >>> For example, > >>> > >>> module Controllers::Products > >>> class Index < GetAction > >>> def initialize(params) > >>> @products = Product.paginate(params[:page] || 1) > >>> end > >>> > >>> def response_json > >>> @products.to_json > >>> end > >>> > >>> def response_html > >>> render 'products/index.erb' > >>> end > >>> end > >>> > >>> class Show < GetAction > >>> extra_route ':id' > >>> > >>> def initialize(params) > >>> @products = Product.find(params[:id]) > >>> end > >>> > >>> def response_html > >>> render 'products/show.erb' > >>> end > >>> end > >>> end > >>> > >>> <%= link_to 'Products', Controllers::Products::Index.url %> > >>> > >>> > >>> On 9/20/07, ry dahl < ry at tinyclouds.org> wrote: > >>>> Sometimes it seems like actions deserve to be their own objects: we > >>>> map routes to them, we'd like to know what parameters they > >>>> expect, we > >>>> want to say which http methods they accept, we assign them > >>>> before/after filters, and we even hold collections of them > >>>> (Controller.callable_actions ). This responds_to issue is another > >>>> example of how we'd like to treat actions as objects. We would like > >>>> for the controller to look at the request, determine which > >>>> format to > >>>> send, and then simply call my_action.render_json or > >>>> my_action.render_html. Simultaneously, our controllers are not very > >>>> class like. They are basically instantiate them only to call the > >>>> action. Changing the Controller class into a module would not be so > >>>> hard in the current Merb - they are (more or less) just containers > >>>> for > >>>> actions. > >>>> > >>>> Has anyone else been having these thoughts? > >>>> > > _______________________________________________ > > Merb-devel mailing list > > Merb-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/merb-devel > > -- Ezra Zygmuntowicz > -- Founder & Ruby Hacker > -- ez at engineyard.com > -- Engine Yard, Serious Rails Hosting > -- (866) 518-YARD (9273) > > > _______________________________________________ > Merb-devel mailing list > Merb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/merb-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/merb-devel/attachments/20070921/c540dd96/attachment.html From dscataglini at dancingbeargroup.com Fri Sep 21 13:44:11 2007 From: dscataglini at dancingbeargroup.com (Diego Scataglini) Date: Fri, 21 Sep 2007 13:44:11 -0400 Subject: Ticket #190 (friendlier way to add / register a mime type) In-Reply-To: <5F6F4288-95B4-40EA-83CF-42EB802A661C@gmail.com> References: <61CF1164-839C-4B93-9562-506FD33B5AD0@gmail.com> <5F6F4288-95B4-40EA-83CF-42EB802A661C@gmail.com> Message-ID: I like the yml idea from the ticket discussion for the only exception that :all should be implied. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/merb-devel/attachments/20070921/0b9c0965/attachment.html From ez at engineyard.com Fri Sep 21 14:16:00 2007 From: ez at engineyard.com (Ezra Zygmuntowicz) Date: Fri, 21 Sep 2007 11:16:00 -0700 Subject: Ticket #190 (friendlier way to add / register a mime type) In-Reply-To: <5F6F4288-95B4-40EA-83CF-42EB802A661C@gmail.com> References: <61CF1164-839C-4B93-9562-506FD33B5AD0@gmail.com> <5F6F4288-95B4-40EA-83CF-42EB802A661C@gmail.com> Message-ID: <09C8F287-6293-4EEE-81B8-D99B250E87B7@engineyard.com> Stephen- Go ahead and commit the helper methods. I think that will work fine for now. Cheers- -Ezra On Sep 21, 2007, at 7:43 AM, Stephen Caudill wrote: > Just wanted to bump this for comment. > > On Sep 19, 2007, at 4:08 PM, Stephen Caudill wrote: > >> Following up on #190 [1], I've just added a simple patch that >> allows the manipulation of the TYPES hash from within the Merb >> module. Use like: >> >> Merb.add_mime_type(:png,%w[image/png]) >> Merb.remove_mime_type(:png) >> >> It specifically disallows the removal of the :all MimeType, since >> content negotiation relies on it. >> >> I'm not super wonderful at API design, so comments and suggestions, >> are of course welcome. If everyone likes it as-is, just shout and >> I'll commit it. >> >> -- >> >> Stephen >> >> [1] http://merb.devjavu.com/projects/merb/ticket/190 > > _______________________________________________ > Merb-devel mailing list > Merb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/merb-devel -- Ezra Zygmuntowicz -- Founder & Ruby Hacker -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) From james at plainprograms.com Fri Sep 21 14:46:48 2007 From: james at plainprograms.com (James Thompson) Date: Fri, 21 Sep 2007 14:46:48 -0400 Subject: Ticket 177 - Should be Resolved Message-ID: After seeing this reopened I submitted an appropriate patch to resolve the rest of this issue. Can someone check it and commit it? Also, what are the criteria for getting commit access? I would like to do some more work on improving the Sequel plugin. -James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/merb-devel/attachments/20070921/04a07c12/attachment.html From canadaduane at gmail.com Fri Sep 21 16:22:48 2007 From: canadaduane at gmail.com (Duane Johnson) Date: Fri, 21 Sep 2007 14:22:48 -0600 Subject: Proposed API change for respond_to In-Reply-To: <9AC1CAB9-968D-4983-883A-1A0D9B1D823E@engineyard.com> References: <4725AEF0-3E7B-4150-9528-93B298977B75@gweezlebur.com> <2CA64E1D-966F-4894-8C8C-7BBECE14E1B8@hasmanythrough.com> <21ee31950709201021s4110c09ck5ed45786c94f515a@mail.gmail.com> <21ee31950709201113t75a5e0d6wfb72e5e3c871a5a8@mail.gmail.com> <21ee31950709201313m5c7bd232o6032a2d57ede6db0@mail.gmail.com> <9AC1CAB9-968D-4983-883A-1A0D9B1D823E@engineyard.com> Message-ID: On Sep 20, 2007, at 3:18 PM, Ezra Zygmuntowicz wrote: > > Merb controllers cannot be modules because modules are not > instantiatable. The way merb's thread safety works is by > instantiating a new controller object for each new request/thread. > But under _ry's proposed system, there is still an object to instantiate per request--it's just the action instead of the controller that gets its own class. From a software engineering perspective, I like the direction _ry is going. The question he is raising seems to be, "What is the role of a controller?" and on a related note, "What is the role of an action?" I've seen very large controllers before, and they don't always make a lot of sense as a single class. A typical controller will have a bunch of public actions followed by a bunch of protected methods. Except in very segmented areas of the website (e.g. an admin area), each protected method is generally called once by one public action-- there is not always a lot of re-use going on; rather, factoring these methods out seems to be a way of making the code in public actions more readable. In typical object-oriented design, we try to create classes that map easily to real-world things or events. In this case, it seems that an Action is a reasonable object class to consider. As _ry has mentioned, Actions have: - one or more route mappings - security measures (e.g. you can see an object, but you have to be logged in to edit it) - object state (request parameters) - multiple formats for the response - multiple HTTP request method options (GET/POST etc.) - before / after filters _ry also mentioned that we currently instantiate controllers primarily to call an action. It's possible that we could get a small performance benefit by not having to perform a check on all of the controller's before / after filters to see if they apply to the action. Rather, an action would just be an Action object, and it would make calls to other things in the initialize method (or 'before' method, see below). With this architecture, we could take advantage of inheritance in the OO way (as well as map exceptions to actions the OO way): module Merb class Action def before; end def after; end end end class AdminAction < Merb::Action def before if User.find(session[:user_id]).admin? # ok else # Raise the Unauthorized controller's NeedToLogin action (class): raise Unauthorized::NeedToLogin, "Please log in to the admin area." end super rescue ActiveRecord::RecordNotFound raise InternalServerError::StaleSession end end module Admin module Products class Show < AdminAction def initialize # ... end def before # Add additional before filter code, then # call AdminAction's before filter super end def html_response render end def after # Do something else afterward super end end end end As a side-effect of not using before filters, we would be able to simplify the code to re-load a class in development mode (the complicated part comes when we have to remove constants so that before filters don't get double- or triple-called). I think _ry's ideas in this area are definitely worthy of discussion. Duane Johnson (canadaduane) From canadaduane at gmail.com Fri Sep 21 16:31:26 2007 From: canadaduane at gmail.com (Duane Johnson) Date: Fri, 21 Sep 2007 14:31:26 -0600 Subject: Ticket 177 - Should be Resolved In-Reply-To: References: Message-ID: <5B7A562C-981D-4507-8E07-164554FFB1B0@gmail.com> Applied. Thanks James. Ezra's in charge of commit access. Duane On Sep 21, 2007, at 12:46 PM, James Thompson wrote: > After seeing this reopened I submitted an appropriate patch to > resolve the rest of this issue. Can someone check it and commit it? > > Also, what are the criteria for getting commit access? I would like > to do some more work on improving the Sequel plugin. > > > -James > _______________________________________________ > Merb-devel mailing list > Merb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/merb-devel From chris at oxdi.eu Sat Sep 22 08:11:17 2007 From: chris at oxdi.eu (Chris Farmiloe) Date: Sat, 22 Sep 2007 13:11:17 +0100 Subject: Ticket #190 (friendlier way to add / register a mime type) In-Reply-To: References: <61CF1164-839C-4B93-9562-506FD33B5AD0@gmail.com> <5F6F4288-95B4-40EA-83CF-42EB802A661C@gmail.com> Message-ID: I've always thought that all the configuration options should be in one place and in one format. I think it is messy to have a merb.yml for some options, then the three environments/*.rb files for others.... in fact I think I'll start a new thread about structure generally :) Regards Farms. Design & Dev Oxygen. http://www.oxdi.eu On 21 Sep 2007, at 18:44, Diego Scataglini wrote: > I like the yml idea from the ticket discussion for the only > exception that :all should be implied. > _______________________________________________ > Merb-devel mailing list > Merb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/merb-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/merb-devel/attachments/20070922/3828877e/attachment.html From chris at oxdi.eu Sat Sep 22 08:34:22 2007 From: chris at oxdi.eu (Chris Farmiloe) Date: Sat, 22 Sep 2007 13:34:22 +0100 Subject: Proposed API change for respond_to In-Reply-To: References: <4725AEF0-3E7B-4150-9528-93B298977B75@gweezlebur.com> <2CA64E1D-966F-4894-8C8C-7BBECE14E1B8@hasmanythrough.com> <21ee31950709201021s4110c09ck5ed45786c94f515a@mail.gmail.com> <21ee31950709201113t75a5e0d6wfb72e5e3c871a5a8@mail.gmail.com> <21ee31950709201313m5c7bd232o6032a2d57ede6db0@mail.gmail.com> <9AC1CAB9-968D-4983-883A-1A0D9B1D823E@engineyard.com> Message-ID: <92C4C79A-A922-42D4-B078-6686B7778AB2@oxdi.eu> On 21 Sep 2007, at 21:22, Duane Johnson wrote: > With this architecture, we could take > advantage of inheritance in the OO way (as well as map exceptions to > actions the OO way): I think this is an interesting point! With more of my projects taking the REST view on the world, I'll often have a base controller with common create/update/show/delete methods, that I then overide if they need modifying. By taking an approach where actions are classes, this situation might be improved. Worth thinking about ... but is quite a step away from the current "way" that it's not going to be an easy switch. might the idea maybe be to have: app/controllers/users/index.rb class Users::Index < Users::Action def to_html render end def to_xml '' end end which then renders the template at app/views/users/index.html.erb where Users::Action is the base "action" class for users (where you would put all your methods that all user actions require) and Users::Action is inherited from Application::Action (where all the app-level methods are) which is a Merb::Action I think the GetAction idea is poor and all that sort of logic should stay in the router code. I like the ideas of the matching up of the action.rb file and the template.erb, but I'm not entirly convinced, the directory structures in /controller and /views would be nicely mirrored. anyway this is all very theoretical, more things for the _ry- experimental-playground-branch ;) Regards Farms. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/merb-devel/attachments/20070922/0c81d94d/attachment.html From chris at oxdi.eu Sat Sep 22 07:53:59 2007 From: chris at oxdi.eu (Chris Farmiloe) Date: Sat, 22 Sep 2007 12:53:59 +0100 Subject: skeleton and configs Message-ID: <34D53CEB-847D-4DF2-BB73-EAE806D89FCA@oxdi.eu> Hi people, just thought I'd mumble out my thoughts on merb's apps directory structure and config concepts and see what other people are feeling... the app dir: mvc/application is layed out as expected....maybe without the mailer by default (another discussion) the config dir: I really think that it's confusing to have such a mixture of ways to configure some of the settings merb.yml, 3xenvironment .rb files, a dependancies.rb an init file and potenially an upload.conf. wouldn't it be nicer to just have a very well commented init.rb to contain ALL the app setup and options? the well commented options in merb.yml works well as a quick stop for what can be tweaked, but that same concept would work equally well in an .rb file and make merb's startup sequence obvious and clear without any special knowledge. the deps & lib dirs: Almost every ruby library, gem, or application has a lib dir to contain the required files. This is a kind of standard by consistantcy. Why does the "deps" dir exist?. A /plugins dir would feel equally at home in lib/plugins and it would solve the minor dilemor of "does my little extension count as a "dependancy" or as a "lib" the log dir: can't argue there. the public dir: that's a given. the schema dir: I think this should be created by whichever ORM plugin/lib you have chosen to use. Not all merb apps will even need a database. the spec dir: perfect, one single obvious place to get your mocks/specs in order the scripts dir: this should be removed. Raketasks are to "scripts" as merb is to actionpack ;) ....and "rake -T" is your friend. Regards chrisfarms. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/merb-devel/attachments/20070922/fe58afde/attachment-0001.html From kevwil at gmail.com Sat Sep 22 10:12:05 2007 From: kevwil at gmail.com (Kevin Williams) Date: Sat, 22 Sep 2007 08:12:05 -0600 Subject: merb_sequel raketasks not working? Message-ID: <683a886f0709220712t5cc6b8cei207245fc91bcfc0a@mail.gmail.com> I'm trying to run on trunk. When I run "rake -T" I get an error: undefined local variable or method `full_config' for Merb::Orms::Sequel:Module I'm not 100% sure that I haven't messed something up, so I hesitate to cry "bug" without checking with everyone. Is anyone else seeing this? P.S. I'm running merb trunk installed as a gem, the latest sequel gem, and the merb_sequel gem installed in ./gems. My dependencies.rb file has the 'dependency "merb_sequel"' line enabled. -- Cheers, Kevin Williams http://kevwil.com/ http://www.almostserio.us/ http://kevwil.jaiku.com/ From ivey at gweezlebur.com Sat Sep 22 11:17:06 2007 From: ivey at gweezlebur.com (Michael D. Ivey) Date: Sat, 22 Sep 2007 10:17:06 -0500 Subject: skeleton and configs In-Reply-To: <34D53CEB-847D-4DF2-BB73-EAE806D89FCA@oxdi.eu> References: <34D53CEB-847D-4DF2-BB73-EAE806D89FCA@oxdi.eu> Message-ID: <6130E532-EC1D-457D-B651-7152625EACD7@gweezlebur.com> On Sep 22, 2007, at 6:53 AM, Chris Farmiloe wrote: > the deps & lib dirs: > Almost every ruby library, gem, or application has a lib > dir to contain the required files. This is a kind of standard > by consistantcy. Why does the "deps" dir exist?. A /plugins > dir would feel equally at home in lib/plugins and it would > solve the minor dilemor of "does my little extension count > as a "dependancy" or as a "lib" "deps" is now (r671) "gems", and it exists because it is a Gem Home you can actually install gems into if you want to keep them close to the app. It functions exactly like the system gems path, but doesn't require root. So, the minor dilemma is solved: If it is packaged as a gem, install it to gems/, otherwise put it in lib/ From ivey at gweezlebur.com Sat Sep 22 11:18:36 2007 From: ivey at gweezlebur.com (Michael D. Ivey) Date: Sat, 22 Sep 2007 10:18:36 -0500 Subject: skeleton and configs In-Reply-To: <34D53CEB-847D-4DF2-BB73-EAE806D89FCA@oxdi.eu> References: <34D53CEB-847D-4DF2-BB73-EAE806D89FCA@oxdi.eu> Message-ID: On Sep 22, 2007, at 6:53 AM, Chris Farmiloe wrote: > the schema dir: > I think this should be created by whichever ORM plugin/lib > you have chosen to use. Not all merb apps will even need > a database. +1 ... I assume this is just a leftover. Anyone see a reason to keep schema in generated apps? From chris at oxdi.eu Sat Sep 22 11:27:06 2007 From: chris at oxdi.eu (Chris Farmiloe) Date: Sat, 22 Sep 2007 16:27:06 +0100 Subject: skeleton and configs In-Reply-To: References: <34D53CEB-847D-4DF2-BB73-EAE806D89FCA@oxdi.eu> Message-ID: On 22 Sep 2007, at 14:45, Wayne E. Seguin wrote: >> config/environments/{production,staging,testing,development,...}.rb Reading over my post it did seem I implied that I wanted to scrap the environments. Sorry, that's not what I meant ... the environment structure is very useful. I was more talking about combining all the others. basically leaving us with. router.rb init.rb environments/development.rb environments/production.rb environments/stage.rb environments/test.rb if some options [ala Merb.add_mime_type] are to be set via ruby code, then lets set them ALL via ruby code and make init a nice linear file that is clearly the app's boot script. I thought it very odd to follow the execution path around these files (especially when a line in merb.yml specifies the location of another yaml file for the upload.conf!) Regards Farms. Design & Dev Oxygen. http://www.oxdi.eu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/merb-devel/attachments/20070922/0ae05d13/attachment.html From chris at oxdi.eu Sat Sep 22 11:33:09 2007 From: chris at oxdi.eu (Chris Farmiloe) Date: Sat, 22 Sep 2007 16:33:09 +0100 Subject: skeleton and configs In-Reply-To: <6130E532-EC1D-457D-B651-7152625EACD7@gweezlebur.com> References: <34D53CEB-847D-4DF2-BB73-EAE806D89FCA@oxdi.eu> <6130E532-EC1D-457D-B651-7152625EACD7@gweezlebur.com> Message-ID: <76E1EE9A-E8C8-4F34-85DF-B1105141C5D3@oxdi.eu> > > "deps" is now (r671) "gems", and it exists because it is a Gem Home > you can actually install gems into if you want to keep them close to > the app. It functions exactly like the system gems path, but doesn't > require root. > > So, the minor dilemma is solved: If it is packaged as a gem, install > it to gems/, otherwise put it in lib/ > cool that makes more sense From kevwil at gmail.com Sat Sep 22 15:09:31 2007 From: kevwil at gmail.com (Kevin Williams) Date: Sat, 22 Sep 2007 13:09:31 -0600 Subject: merb_sequel raketasks not working? In-Reply-To: References: <683a886f0709220712t5cc6b8cei207245fc91bcfc0a@mail.gmail.com> Message-ID: <683a886f0709221209o42205c5i96b74d9b8a6309c0@mail.gmail.com> After installing merb_sequel as a gem, rather than "gem install /merb_sequel-0.0.3.gem -i ./deps" your steps worked for me as well. I'm baffled what could be different about my project that is out of sync. 1). My Rakefile has a custom Spec::Rake::SpecTask defined, otherwise it is identical. 2). My config/database.yml is different 3). My config/dependencies.rb has some extra gems required, but that's all commented out right now. 4). My config/merb.yml has a different :secret_session_key: value. 5). I changed script/new_migration to generate Sequel migrations instead of ActiveRecord migrations. 6). I've added 1 Capfile, 1 controller, 1 haml view, some specs, and a migration file. I fail to see what I've done to make this break. Perhaps I'll re-install all the gems again. Very frustrating. On 9/22/07, James Thompson wrote: > Just for documentation here's my process: > > 1.) svn updated and installed trunk versions of merb & merb_sequel > 2.) merb -g test && cd test && mate . > 3.) rake -T (worked fine) > 4.) Added merb_sequel dependency in config/dependencies.rb > 5.) rake -T runs without error and tells me I need the database.yml > 6.) Modify config/database.yml to the following > > --- > # This is a sample database file for the Sequel ORM > :development: &defaults > :adapter: sqlite > :database: sample.db > > :test: > <<: *defaults > > :production: > <<: *defaults > > 7.) rake -T yields no errors > 8.) merb yields no errors, creates the database > 9.) rake -T yields no errors > 10.) rake sequel:db:migrate complains about no target version which is > expected since I have no migrations for it. > 11.) rake sequel:sessions:clear runs without complaint > > > I'm not getting any errors on revision 677. > > > -James > > > > On 9/22/07, Kevin Williams wrote: > > > > I'm trying to run on trunk. When I run "rake -T" I get an error: > > > > undefined local variable or method `full_config' for > Merb::Orms::Sequel:Module > > > > I'm not 100% sure that I haven't messed something up, so I hesitate to > > cry "bug" without checking with everyone. Is anyone else seeing this? > > > > P.S. I'm running merb trunk installed as a gem, the latest sequel gem, > > and the merb_sequel gem installed in ./gems. My dependencies.rb file > > has the 'dependency "merb_sequel"' line enabled. > > > > -- > > Cheers, > > > > Kevin Williams > > http://kevwil.com/ > > http://www.almostserio.us/ > > http://kevwil.jaiku.com/ > > _______________________________________________ > > Merb-devel mailing list > > Merb-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/merb-devel > > > > -- Cheers, Kevin Williams http://kevwil.com/ http://www.almostserio.us/ http://kevwil.jaiku.com/ From kevwil at gmail.com Sat Sep 22 15:19:26 2007 From: kevwil at gmail.com (Kevin Williams) Date: Sat, 22 Sep 2007 13:19:26 -0600 Subject: merb_sequel raketasks not working? In-Reply-To: <683a886f0709221209o42205c5i96b74d9b8a6309c0@mail.gmail.com> References: <683a886f0709220712t5cc6b8cei207245fc91bcfc0a@mail.gmail.com> <683a886f0709221209o42205c5i96b74d9b8a6309c0@mail.gmail.com> Message-ID: <683a886f0709221219m4e6222ccgd4b41643346e35f6@mail.gmail.com> Aha! Using the postgresql adapter seems to break it. I changed my database.yml to sqlite and everything started working. Yay! No, wait a minute, that sucks. :) I've looked at the merb_sequel code and I'm not sure why it's not working for postgresql. I guess I'll switch back to sqlite for now, until some sequel guru can figure out what's wrong. On 9/22/07, Kevin Williams wrote: > After installing merb_sequel as a gem, rather than "gem install > /merb_sequel-0.0.3.gem -i ./deps" your steps worked for me as > well. I'm baffled what could be different about my project that is out > of sync. > > 1). My Rakefile has a custom Spec::Rake::SpecTask defined, otherwise > it is identical. > 2). My config/database.yml is different > 3). My config/dependencies.rb has some extra gems required, but > that's all commented out right now. > 4). My config/merb.yml has a different :secret_session_key: value. > 5). I changed script/new_migration to generate Sequel migrations > instead of ActiveRecord migrations. > 6). I've added 1 Capfile, 1 controller, 1 haml view, some specs, and > a migration file. > > I fail to see what I've done to make this break. Perhaps I'll > re-install all the gems again. Very frustrating. > > On 9/22/07, James Thompson wrote: > > Just for documentation here's my process: > > > > 1.) svn updated and installed trunk versions of merb & merb_sequel > > 2.) merb -g test && cd test && mate . > > 3.) rake -T (worked fine) > > 4.) Added merb_sequel dependency in config/dependencies.rb > > 5.) rake -T runs without error and tells me I need the database.yml > > 6.) Modify config/database.yml to the following > > > > --- > > # This is a sample database file for the Sequel ORM > > :development: &defaults > > :adapter: sqlite > > :database: sample.db > > > > :test: > > <<: *defaults > > > > :production: > > <<: *defaults > > > > 7.) rake -T yields no errors > > 8.) merb yields no errors, creates the database > > 9.) rake -T yields no errors > > 10.) rake sequel:db:migrate complains about no target version which is > > expected since I have no migrations for it. > > 11.) rake sequel:sessions:clear runs without complaint > > > > > > I'm not getting any errors on revision 677. > > > > > > -James > > > > > > > > On 9/22/07, Kevin Williams wrote: > > > > > > I'm trying to run on trunk. When I run "rake -T" I get an error: > > > > > > undefined local variable or method `full_config' for > > Merb::Orms::Sequel:Module > > > > > > I'm not 100% sure that I haven't messed something up, so I hesitate to > > > cry "bug" without checking with everyone. Is anyone else seeing this? > > > > > > P.S. I'm running merb trunk installed as a gem, the latest sequel gem, > > > and the merb_sequel gem installed in ./gems. My dependencies.rb file > > > has the 'dependency "merb_sequel"' line enabled. > > > > > > -- > > > Cheers, > > > > > > Kevin Williams > > > http://kevwil.com/ > > > http://www.almostserio.us/ > > > http://kevwil.jaiku.com/ > > > _______________________________________________ > > > Merb-devel mailing list > > > Merb-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/merb-devel > > > > > > > > > > -- > Cheers, > > Kevin Williams > http://kevwil.com/ > http://www.almostserio.us/ > http://kevwil.jaiku.com/ > -- Cheers, Kevin Williams http://kevwil.com/ http://www.almostserio.us/ http://kevwil.jaiku.com/ From kevwil at gmail.com Sat Sep 22 15:21:55 2007 From: kevwil at gmail.com (Kevin Williams) Date: Sat, 22 Sep 2007 13:21:55 -0600 Subject: skeleton and configs In-Reply-To: References: <34D53CEB-847D-4DF2-BB73-EAE806D89FCA@oxdi.eu> Message-ID: <683a886f0709221221t16b374cfp48a656fe4503129@mail.gmail.com> Where would migrations go if schema is not there? Speaking of migrations, what should happen to script/new_migration? Right now it only generates ActiveRecord migrations, and I'm trying to use Sequel instead. On 9/22/07, Michael D. Ivey wrote: > On Sep 22, 2007, at 6:53 AM, Chris Farmiloe wrote: > > the schema dir: > > I think this should be created by whichever ORM plugin/lib > > you have chosen to use. Not all merb apps will even need > > a database. > > +1 ... I assume this is just a leftover. > > Anyone see a reason to keep schema in generated apps? > > _______________________________________________ > Merb-devel mailing list > Merb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/merb-devel > -- Cheers, Kevin Williams http://kevwil.com/ http://www.almostserio.us/ http://kevwil.jaiku.com/ From ivey at gweezlebur.com Sat Sep 22 15:40:38 2007 From: ivey at gweezlebur.com (Michael D. Ivey) Date: Sat, 22 Sep 2007 14:40:38 -0500 Subject: skeleton and configs In-Reply-To: <683a886f0709221221t16b374cfp48a656fe4503129@mail.gmail.com> References: <34D53CEB-847D-4DF2-BB73-EAE806D89FCA@oxdi.eu> <683a886f0709221221t16b374cfp48a656fe4503129@mail.gmail.com> Message-ID: <6D2A91B7-0F58-4349-92B1-3C448DCA7C96@gweezlebur.com> On Sep 22, 2007, at 2:21 PM, Kevin Williams wrote: > Where would migrations go if schema is not there? Wherever your ORM plugin puts it. Probably schema, but the ORM plugin should create it. > Speaking of migrations, what should happen to script/new_migration? > Right now it only generates ActiveRecord migrations, and I'm trying to > use Sequel instead. It should be a rake task or generator provided by the ORM plugin. From kevwil at gmail.com Sat Sep 22 16:39:07 2007 From: kevwil at gmail.com (Kevin Williams) Date: Sat, 22 Sep 2007 14:39:07 -0600 Subject: skeleton and configs In-Reply-To: <6D2A91B7-0F58-4349-92B1-3C448DCA7C96@gweezlebur.com> References: <34D53CEB-847D-4DF2-BB73-EAE806D89FCA@oxdi.eu> <683a886f0709221221t16b374cfp48a656fe4503129@mail.gmail.com> <6D2A91B7-0F58-4349-92B1-3C448DCA7C96@gweezlebur.com> Message-ID: <683a886f0709221339q3992eb1bh1f5ffc6e0669b019@mail.gmail.com> Sounds good. On 9/22/07, Michael D. Ivey wrote: > On Sep 22, 2007, at 2:21 PM, Kevin Williams wrote: > > Where would migrations go if schema is not there? > > Wherever your ORM plugin puts it. Probably schema, but the ORM > plugin should create it. > > > Speaking of migrations, what should happen to script/new_migration? > > Right now it only generates ActiveRecord migrations, and I'm trying to > > use Sequel instead. > > It should be a rake task or generator provided by the ORM plugin. > > > _______________________________________________ > Merb-devel mailing list > Merb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/merb-devel > -- Cheers, Kevin Williams http://kevwil.com/ http://www.almostserio.us/ http://kevwil.jaiku.com/ From kevwil at gmail.com Sat Sep 22 22:47:41 2007 From: kevwil at gmail.com (Kevin Williams) Date: Sat, 22 Sep 2007 20:47:41 -0600 Subject: merb_sequel raketasks not working? In-Reply-To: References: <683a886f0709220712t5cc6b8cei207245fc91bcfc0a@mail.gmail.com> <683a886f0709221209o42205c5i96b74d9b8a6309c0@mail.gmail.com> <683a886f0709221219m4e6222ccgd4b41643346e35f6@mail.gmail.com> Message-ID: <683a886f0709221947pec7bc83i6441ea10ab5868d2@mail.gmail.com> Silly me, I thought my patch for the same thing was already applied. I guess I forgot to revert the file after creating the patch. My patch might be broken, not sure. I attached the same patch to that ticket, because mine had encoding support. Hopefully a committer can merge the two and get a working fix for postgres users. On 9/22/07, James Thompson wrote: > There's a ticket open (http://merb.devjavu.com/ticket/192) > with a patch to enable Postgres support in the Sequel plugin. Assuming the > patch works, which I can't vouch for myself, that would solve you problem. > > > > -James > > On 9/22/07, Kevin Williams < kevwil at gmail.com> wrote: > > Aha! > > > > Using the postgresql adapter seems to break it. > > > > I changed my database.yml to sqlite and everything started working. > > Yay! No, wait a minute, that sucks. :) I've looked at the merb_sequel > > code and I'm not sure why it's not working for postgresql. I guess > > I'll switch back to sqlite for now, until some sequel guru can figure > > out what's wrong. > > > > On 9/22/07, Kevin Williams wrote: > > > After installing merb_sequel as a gem, rather than "gem install > > > /merb_sequel- 0.0.3.gem -i ./deps" your steps worked for me as > > > well. I'm baffled what could be different about my project that is out > > > of sync. > > > > > > 1). My Rakefile has a custom Spec::Rake::SpecTask defined, otherwise > > > it is identical. > > > 2). My config/database.yml is different > > > 3). My config/dependencies.rb has some extra gems required, but > > > that's all commented out right now. > > > 4). My config/merb.yml has a different :secret_session_key: value. > > > 5). I changed script/new_migration to generate Sequel migrations > > > instead of ActiveRecord migrations. > > > 6). I've added 1 Capfile, 1 controller, 1 haml view, some specs, and > > > a migration file. > > > > > > I fail to see what I've done to make this break. Perhaps I'll > > > re-install all the gems again. Very frustrating. > > > > > > On 9/22/07, James Thompson < james at plainprograms.com> wrote: > > > > Just for documentation here's my process: > > > > > > > > 1.) svn updated and installed trunk versions of merb & merb_sequel > > > > 2.) merb -g test && cd test && mate . > > > > 3.) rake -T (worked fine) > > > > 4.) Added merb_sequel dependency in config/dependencies.rb > > > > 5.) rake -T runs without error and tells me I need the database.yml > > > > 6.) Modify config/database.yml to the following > > > > > > > > --- > > > > # This is a sample database file for the Sequel ORM > > > > :development: &defaults > > > > :adapter: sqlite > > > > :database: sample.db > > > > > > > > :test: > > > > <<: *defaults > > > > > > > > :production: > > > > <<: *defaults > > > > > > > > 7.) rake -T yields no errors > > > > 8.) merb yields no errors, creates the database > > > > 9.) rake -T yields no errors > > > > 10.) rake sequel:db:migrate complains about no target version which is > > > > expected since I have no migrations for it. > > > > 11.) rake sequel:sessions:clear runs without complaint > > > > > > > > > > > > I'm not getting any errors on revision 677. > > > > > > > > > > > > -James > > > > > > > > > > > > > > > > On 9/22/07, Kevin Williams < kevwil at gmail.com> wrote: > > > > > > > > > > I'm trying to run on trunk. When I run "rake -T" I get an error: > > > > > > > > > > undefined local variable or method `full_config' for > > > > Merb::Orms::Sequel:Module > > > > > > > > > > I'm not 100% sure that I haven't messed something up, so I hesitate > to > > > > > cry "bug" without checking with everyone. Is anyone else seeing > this? > > > > > > > > > > P.S. I'm running merb trunk installed as a gem, the latest sequel > gem, > > > > > and the merb_sequel gem installed in ./gems. My dependencies.rb file > > > > > has the 'dependency "merb_sequel"' line enabled. > > > > > > > > > > -- > > > > > Cheers, > > > > > > > > > > Kevin Williams > > > > > http://kevwil.com/ > > > > > http://www.almostserio.us/ > > > > > http://kevwil.jaiku.com/ > > > > > _______________________________________________ > > > > > Merb-devel mailing list > > > > > Merb-devel at rubyforge.org > > > > > http://rubyforge.org/mailman/listinfo/merb-devel > > > > > > > > > > > > > > > > > > > > > > -- > > > Cheers, > > > > > > Kevin Williams > > > http://kevwil.com/ > > > http://www.almostserio.us/ > > > http://kevwil.jaiku.com/ > > > > > > > > > -- > > Cheers, > > > > Kevin Williams > > http://kevwil.com/ > > http://www.almostserio.us/ > > http://kevwil.jaiku.com/ > > _______________________________________________ > > Merb-devel mailing list > > Merb-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/merb-devel > > > > -- Cheers, Kevin Williams http://kevwil.com/ http://www.almostserio.us/ http://kevwil.jaiku.com/ From canadaduane at gmail.com Sun Sep 23 21:14:41 2007 From: canadaduane at gmail.com (Duane Johnson) Date: Sun, 23 Sep 2007 19:14:41 -0600 Subject: skeleton and configs In-Reply-To: References: <34D53CEB-847D-4DF2-BB73-EAE806D89FCA@oxdi.eu> Message-ID: On Sep 22, 2007, at 9:27 AM, Chris Farmiloe wrote: > > > > On 22 Sep 2007, at 14:45, Wayne E. Seguin wrote: > >> config/environments/{production,staging,testing,development,...}.rb > > Reading over my post it did seem I implied that I wanted to scrap > the environments. > Sorry, that's not what I meant ... the environment structure is > very useful. > > I was more talking about combining all the others. > > basically leaving us with. > > router.rb > init.rb > environments/development.rb > environments/production.rb > environments/stage.rb > environments/test.rb > > > > if some options [ala Merb.add_mime_type] are to be set via ruby > code, then lets set them ALL via ruby code and make init a nice > linear file that is clearly the app's boot script. > > I thought it very odd to follow the execution path around these > files (especially when a line in merb.yml specifies the location of > another yaml file for the upload.conf!) > I agree about the difficulty of following the execution path-- ideally, we should make this as straight-forward as possible by defaulting to a single init.rb or merb_init.rb file. For example, why not use a case/when statement instead of the environments/*.rb situation? Just a thought. The only exception I can think of is keeping the dependencies.rb file around--as has been discussed before, we need some way to keep this separate so that "rake" has a way of knowing what to load (without loading the whole application) and can thus add all rake tasks from the dependencies. Duane Johnson (canadaduane) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/merb-devel/attachments/20070923/913ac07c/attachment.html From chris at oxdi.eu Mon Sep 24 04:51:04 2007 From: chris at oxdi.eu (Chris Farmiloe) Date: Mon, 24 Sep 2007 09:51:04 +0100 Subject: skeleton and configs In-Reply-To: References: <34D53CEB-847D-4DF2-BB73-EAE806D89FCA@oxdi.eu> Message-ID: > we need some way to keep this separate so that "rake" has a way of > knowing what to load (without loading the whole application) there are other ways to solve this issue.. for instance the merb_init.rb file could have some form of namespacing: # dependacies are loaded first, you should # place everything your application needs to # run in this block # configure :dependancies do |config| Gem.path.unshift(MERB_ROOT / "deps") config.after_app_loads do # something end end # server options are set in this block # configure :server do |server| server.host = '127.0.0.1' server.port = 4000 end # configure your session store here # configure :session do |session| session.store = 'cookie' end # add additional mime types # configure :mime_types do |mime| mime.type 'text', 'text/html' end looks pretty but might just be adding to much complexity. Regards Farms. Design & Dev Oxygen. http://www.oxdi.eu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/merb-devel/attachments/20070924/7a021e62/attachment-0001.html From kevwil at gmail.com Wed Sep 26 12:06:33 2007 From: kevwil at gmail.com (Kevin Williams) Date: Wed, 26 Sep 2007 10:06:33 -0600 Subject: Fwd: error with schema_info when doing multiple migrations In-Reply-To: <683a886f0709230926m59c48797g16f6a79cfa3f554f@mail.gmail.com> References: <683a886f0709230926m59c48797g16f6a79cfa3f554f@mail.gmail.com> Message-ID: <683a886f0709260906g136a8356w4e12d2af73c9f077@mail.gmail.com> Posting to merb list in case it is a merb problem. (?!??) The error still happens with sequel 0.2.1. ---------- Forwarded message ---------- From: Kevin Williams Date: Sep 23, 2007 10:26 AM Subject: error with schema_info when doing multiple migrations To: sequel-talk at googlegroups.com I tried to post an issue to the project site but it kept giving me 500 server error messages. What steps will reproduce the problem? 0. install merb trunk gem and merb_sequel plugin trunk gem 1. create a merb trunk app 2. put the attached files in the appropriate places 3. run sequel:db:migrate What is the expected output? What do you see instead? I expected to see a "completed successfully" message. I got: rake aborted! table schema_info already exists My two tables were created, but schema_info has no records in it. What version of the product are you using? On what operating system? 0.2.0.2 gem on Mac OS X 10.4.10 Please provide any additional information below. It seems to error on updating the version after the migrations were completed. -- Cheers, Kevin Williams http://kevwil.com/ http://www.almostserio.us/ http://kevwil.jaiku.com/ -- Cheers, Kevin Williams http://kevwil.com/ http://www.almostserio.us/ http://kevwil.jaiku.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: database.yml Type: application/octet-stream Size: 143 bytes Desc: not available Url : http://rubyforge.org/pipermail/merb-devel/attachments/20070926/cd8b9f03/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: dependencies.rb Type: text/x-ruby-script Size: 778 bytes Desc: not available Url : http://rubyforge.org/pipermail/merb-devel/attachments/20070926/cd8b9f03/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: a.rb Type: text/x-ruby-script Size: 91 bytes Desc: not available Url : http://rubyforge.org/pipermail/merb-devel/attachments/20070926/cd8b9f03/attachment-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: b.rb Type: text/x-ruby-script Size: 91 bytes Desc: not available Url : http://rubyforge.org/pipermail/merb-devel/attachments/20070926/cd8b9f03/attachment-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: 001_create_a_table.rb Type: text/x-ruby-script Size: 204 bytes Desc: not available Url : http://rubyforge.org/pipermail/merb-devel/attachments/20070926/cd8b9f03/attachment-0003.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: 002_create_b_table.rb Type: text/x-ruby-script Size: 204 bytes Desc: not available Url : http://rubyforge.org/pipermail/merb-devel/attachments/20070926/cd8b9f03/attachment-0004.bin From dgleal at gmail.com Fri Sep 28 11:52:02 2007 From: dgleal at gmail.com (David Leal) Date: Fri, 28 Sep 2007 16:52:02 +0100 Subject: Any problems with devjavu.com? Message-ID: <1b86cb980709280852g59671d04j589931eb7947c4b6@mail.gmail.com> Hi all, apologies if this isn't the right place to ask. merb.devjavu.com seems to be down for me everyday between 11:00am UTC and 5:00pm UTC. Anyone outside the US seeing this problem? Btw, merb is just... beautiful. Cheers, David From merb at dusty.name Sat Sep 29 12:14:49 2007 From: merb at dusty.name (Dusty Doris) Date: Sat, 29 Sep 2007 12:14:49 -0400 Subject: templates with same name before extension are cached Message-ID: Hi all, I was just wondering if this is the intended behavior. Here is my setup: controller def index respond_to do |f| f.xml { render :xml => true } f.html { render :layout => :none } end end In my views I have a file for each type index.herb index.xerb The first request I send is cached and interferes with the other one. For example, if I send an xml request first, followed by html, here is what I see (those are just some debug statements I put in to follow the code) Request 1 "Accept: text/xml" - "starting find_template, options are :" {:action=>"index", :ext=>"rxml,xerb,builder"} - match on elsif action path is : /Users/dusty/nms/app/views/testing/index - no cache, created glob glob is : /Users/dusty/nms/app/views/testing/index.{rxml,xerb,builder} - searched Dir[glob].first and found found is : /Users/dusty/nms/app/views/testing/index.xerb - finished find_template, template is: "/Users/dusty/nms/app/views/testing/index.xerb" Request 2 "Accept: text/html" - "starting find_template, options are :" {:action=>"index"} - match on elsif action path is : /Users/dusty/nms/app/views/testing/index - finish else, matched cached cached is : /Users/dusty/nms/app/views/testing/index.xerb - finished find_template, template is: "/Users/dusty/nms/app/views/testing/index.xerb" If I restart merb and reverse the order Request 1 "Accept: text/html" - "starting find_template, options are :" {:action=>"index"} - match on elsif action path is : /Users/dusty/nms/app/views/testing/index - no cache, created glob glob is : /Users/dusty/nms/app/views/testing/index.{html.erb,jerb,herb,haml,mab,js.erb,xerb,rhtml,builder,rxml,erb} - searched Dir[glob].first and found found is : /Users/dusty/nms/app/views/testing/index.herb - finished find_template, template is: "/Users/dusty/nms/app/views/testing/index.herb" Request 2 "Accept: text/xml" - "starting find_template, options are :" {:action=>"index", :ext=>"rxml,xerb,builder"} - match on elsif action path is : /Users/dusty/nms/app/views/testing/index - finish else, matched cached cached is : /Users/dusty/nms/app/views/testing/index.herb - finished find_template, template is: "/Users/dusty/nms/app/views/testing/index.herb" * this caught me by suprise, it searched for layouts too. - "starting find_template, options are :" {:layout=>"testing"} - match on elsif _layout path is : /Users/dusty/nms/app/views/layout/testing - no cache, created glob glob is : /Users/dusty/nms/app/views/layout/testing.{html.erb,jerb,herb,haml,mab,js.erb,xerb,rhtml,builder,rxml,erb} - failed Dir[glob].first and set @merb_unmatched: glob is : /Users/dusty/nms/app/views/layout/testing.{html.erb,jerb,herb,haml,mab,js.erb,xerb,rhtml,builder,rxml,erb} - "starting find_template, options are :" {:layout=>:application} - match on elsif _layout path is : /Users/dusty/nms/app/views/layout/application - no cache, created glob glob is : /Users/dusty/nms/app/views/layout/application.{html.erb,jerb,herb,haml,mab,js.erb,xerb,rhtml,builder,rxml,erb} - searched Dir[glob].first and found found is : /Users/dusty/nms/app/views/layout/application.html.erb So, I suppose that the EASY workaround is to rename my xml template to something like index_xml.xerb and then call it like: render :xml => :index_xml I was just wondering if that was the intended behavior, that's all. The documentation threw me off for a second there because of this line. # render :xml => true # render :xml => true, :action => "buffalo" # # Renders the buffalo.xerb template for the current controller. So, render :xml => true, does work out of the box. But, if you have an another view with the same name before the extension, they interfere with eachother. It this is intended, then I'll supply a little documentation patch to warn about that. Thanks Dusty Doris From ez at engineyard.com Sat Sep 29 12:21:44 2007 From: ez at engineyard.com (Ezra Zygmuntowicz) Date: Sat, 29 Sep 2007 09:21:44 -0700 Subject: templates with same name before extension are cached In-Reply-To: References: Message-ID: This is an artifact of some overly clever caching of the globbed templates. I will fix this when i get back home tomorrow. Thanks -Ezra On Sep 29, 2007, at 9:14 AM, Dusty Doris wrote: > Hi all, > > I was just wondering if this is the intended behavior. Here is my > setup: > > controller > > def index > respond_to do |f| > f.xml { render :xml => true } > f.html { render :layout => :none } > end > end > > In my views I have a file for each type > > index.herb > index.xerb > > The first request I send is cached and interferes with the other one. > For example, if I send an xml request first, followed by html, here is > what I see (those are just some debug statements I put in to follow > the code) > > Request 1 "Accept: text/xml" > > - "starting find_template, options are :" > {:action=>"index", :ext=>"rxml,xerb,builder"} > - match on elsif action > path is : /Users/dusty/nms/app/views/testing/index > - no cache, created glob > glob is : /Users/dusty/nms/app/views/testing/index. > {rxml,xerb,builder} > - searched Dir[glob].first and found > found is : /Users/dusty/nms/app/views/testing/index.xerb > - finished find_template, template is: > "/Users/dusty/nms/app/views/testing/index.xerb" > > Request 2 "Accept: text/html" > > - "starting find_template, options are :" > {:action=>"index"} > - match on elsif action > path is : /Users/dusty/nms/app/views/testing/index > - finish else, matched cached > cached is : /Users/dusty/nms/app/views/testing/index.xerb > - finished find_template, template is: > "/Users/dusty/nms/app/views/testing/index.xerb" > > If I restart merb and reverse the order > > Request 1 "Accept: text/html" > > - "starting find_template, options are :" > {:action=>"index"} > - match on elsif action > path is : /Users/dusty/nms/app/views/testing/index > - no cache, created glob > glob is : > /Users/dusty/nms/app/views/testing/index. > {html.erb,jerb,herb,haml,mab,js.erb,xerb,rhtml,builder,rxml,erb} > - searched Dir[glob].first and found > found is : /Users/dusty/nms/app/views/testing/index.herb > - finished find_template, template is: > "/Users/dusty/nms/app/views/testing/index.herb" > > Request 2 "Accept: text/xml" > > - "starting find_template, options are :" > {:action=>"index", :ext=>"rxml,xerb,builder"} > - match on elsif action > path is : /Users/dusty/nms/app/views/testing/index > - finish else, matched cached > cached is : /Users/dusty/nms/app/views/testing/index.herb > - finished find_template, template is: > "/Users/dusty/nms/app/views/testing/index.herb" > > * this caught me by suprise, it searched for layouts too. > > - "starting find_template, options are :" > {:layout=>"testing"} > - match on elsif _layout > path is : /Users/dusty/nms/app/views/layout/testing > - no cache, created glob > glob is : /Users/dusty/nms/app/views/layout/testing. > {html.erb,jerb,herb,haml,mab,js.erb,xerb,rhtml,builder,rxml,erb} > - failed Dir[glob].first and set @merb_unmatched: > glob is : /Users/dusty/nms/app/views/layout/testing. > {html.erb,jerb,herb,haml,mab,js.erb,xerb,rhtml,builder,rxml,erb} > - "starting find_template, options are :" > {:layout=>:application} > - match on elsif _layout > path is : /Users/dusty/nms/app/views/layout/application > - no cache, created glob > glob is : /Users/dusty/nms/app/views/layout/application. > {html.erb,jerb,herb,haml,mab,js.erb,xerb,rhtml,builder,rxml,erb} > - searched Dir[glob].first and found > found is : /Users/dusty/nms/app/views/layout/application.html.erb > > So, I suppose that the EASY workaround is to rename my xml template to > something like index_xml.xerb and then call it like: > > render :xml => :index_xml > > I was just wondering if that was the intended behavior, that's all. > The documentation threw me off for a second there because of this > line. > > # render :xml => true > # render :xml => true, :action => "buffalo" > # > # Renders the buffalo.xerb template for the current controller. > > So, render :xml => true, does work out of the box. But, if you have > an another view with the same name before the extension, they > interfere with eachother. It this is intended, then I'll supply a > little documentation patch to warn about that. > > Thanks > Dusty Doris > _______________________________________________ > Merb-devel mailing list > Merb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/merb-devel -- Ezra Zygmuntowicz -- Founder & Ruby Hacker -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273)