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 mi