From noe.rubinstein at gmail.com Mon Jan 1 00:51:46 2007 From: noe.rubinstein at gmail.com (=?UTF-8?Q?No=C3=A9_Rubinstein?=) Date: Mon, 1 Jan 2007 06:51:46 +0100 Subject: [Nitro] create_on_insert In-Reply-To: References: <45958D41.5070103@tastapod.com> Message-ID: create_on_insert is an excellent, very intuitive and self-explanatory name. cascade_create isn't, IMHO. 2006/12/31, George Moschovitis : > nice idea thanks. > > > -g. > > > -- > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > From george.moschovitis at gmail.com Mon Jan 1 05:41:37 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 1 Jan 2007 12:41:37 +0200 Subject: [Nitro] Happy new year Message-ID: Dear devs, happy new year! George. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070101/b0f7e7e0/attachment-0001.html From john at oxyliquit.de Mon Jan 1 06:24:46 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Mon, 01 Jan 2007 12:24:46 +0100 Subject: [Nitro] Happy new year In-Reply-To: References: Message-ID: Hi, > Dear devs, And to all readers, lurkers, silent admirers, part time watchers, newcomers and whatever types run around in these circles. :P > happy new year! ! Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From john at oxyliquit.de Mon Jan 1 10:56:46 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Mon, 01 Jan 2007 16:56:46 +0100 Subject: [Nitro] Samples/Examples 0.41 Message-ID: Hi George, http://oxyliquit.de/question/90 Since I have no idea about those examples and never tried them, someone gotta answer that. :P Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From transfire at gmail.com Wed Jan 3 19:30:04 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Thu, 04 Jan 2007 00:30:04 -0000 Subject: [Nitro] Build scripts as modules or plain scripts Message-ID: <1167870604.858204.52590@v33g2000cwv.googlegroups.com> I'm cross posting this b/c it has to do with Ratchets: I'm having a little debate with myself. On my current project I have a bunch of little reusable task scripts that a command line tool runs. The scripts are written as the top-level (although I actually simulate the top-level when running them). So for example a script would just be something like: # example.rb def example puts "This is an example!" end Then on the command line I would do: % mytool example This is an example! That's all well and good, but many of the scripts have generally useful routines and I would like them to be accessible by other programs too, not just my command line tool. So I thoght maybe it would be better if a module were required to wrap the defs. # another.rb module MyToolAnother def another puts "This is another!" end end That works, of course, but it adds an additonal layer of essentially redundant code, which IMHO is ugly. Then I got to thinking. Why don't we write resuable lib in this fashion anyway and just create our own containers on the fly when loading them? MyToolExample = load_as_module "example.rb" What intersting about that is then we could determine in what capacity it is to be used. For example: # adds module_function MyToolExample = load_as_function_module "example.rb" # adds self extend MyToolExample = load_as_self_extended_module "example.rb" Or even MyToolExample = load_as_class "example.rb" We could even have include and extend take a lib path. include "example.rb" Of course this effectively puts encapsulation, at least at the top level, on a per-file basis. But in many respects that seems kind of nice. It increases flexability and reduces configuration complexity. So what do your think? Is this technique worth promoting? Or am I being silly and should just wrap all my scripts in modules? T. From surrender_it at yahoo.it Thu Jan 4 02:53:22 2007 From: surrender_it at yahoo.it (gabriele renzi) Date: Thu, 04 Jan 2007 08:53:22 +0100 Subject: [Nitro] Build scripts as modules or plain scripts In-Reply-To: <1167870604.858204.52590@v33g2000cwv.googlegroups.com> References: <1167870604.858204.52590@v33g2000cwv.googlegroups.com> Message-ID: transfire at gmail.com ha scritto: > Of course this effectively puts encapsulation, at least at the top > level, on a per-file basis. But in many respects that seems kind of > nice. It increases flexability and reduces configuration complexity. > > So what do your think? Is this technique worth promoting? Or am I being > silly and should just wrap all my scripts in modules? first: adding the "as_foo" just adds useless complexity, imho, just load a module and include id when needed. Then, if you just add and a directory is a module, too so that require 'foo' loads module Foo and require 'foo/bar' requires module Foo::Bar and you have the python's import system, which is a very good thing imo and could reduce ruby's stdlib size of a 1/2% :) -- blog en: http://www.riffraff.info blog it: http://riffraff.blogsome.com jabber : rff.rff at gmail dot com From george.moschovitis at gmail.com Thu Jan 4 09:28:39 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 4 Jan 2007 16:28:39 +0200 Subject: [Nitro] Build scripts as modules or plain scripts In-Reply-To: <1167870604.858204.52590@v33g2000cwv.googlegroups.com> References: <1167870604.858204.52590@v33g2000cwv.googlegroups.com> Message-ID: I like this but I am not sure if there are problems with this approach. It looks nice though... -g. On 1/4/07, transfire at gmail.com wrote: > > I'm cross posting this b/c it has to do with Ratchets: > > I'm having a little debate with myself. On my current project I have a > bunch of little reusable task scripts that a command line tool runs. > The scripts are written as the top-level (although I actually simulate > the top-level when running them). So for example a script would just be > something like: > > # example.rb > > def example > puts "This is an example!" > end > > Then on the command line I would do: > > % mytool example > This is an example! > > That's all well and good, but many of the scripts have generally useful > routines and I would like them to be accessible by other programs too, > not just my command line tool. So I thoght maybe it would be better if > a module were required to wrap the defs. > > # another.rb > > module MyToolAnother > > def another > puts "This is another!" > end > > end > > That works, of course, but it adds an additonal layer of essentially > redundant code, which IMHO is ugly. > > Then I got to thinking. Why don't we write resuable lib in this fashion > anyway and just create our own containers on the fly when loading them? > > MyToolExample = load_as_module "example.rb" > > What intersting about that is then we could determine in what capacity > it is to be used. For example: > > # adds module_function > MyToolExample = load_as_function_module "example.rb" > > # adds self extend > MyToolExample = load_as_self_extended_module "example.rb" > > Or even > > MyToolExample = load_as_class "example.rb" > > We could even have include and extend take a lib path. > > include "example.rb" > > Of course this effectively puts encapsulation, at least at the top > level, on a per-file basis. But in many respects that seems kind of > nice. It increases flexability and reduces configuration complexity. > > So what do your think? Is this technique worth promoting? Or am I being > silly and should just wrap all my scripts in modules? > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070104/ac040b69/attachment.html From transfire at gmail.com Thu Jan 4 10:07:54 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Thu, 04 Jan 2007 15:07:54 -0000 Subject: [Nitro] Build scripts as modules or plain scripts In-Reply-To: References: <1167870604.858204.52590@v33g2000cwv.googlegroups.com> Message-ID: <1167923274.725991.30670@q40g2000cwq.googlegroups.com> gabriele renzi wrote: > transfire at gmail.com ha scritto: > > > Of course this effectively puts encapsulation, at least at the top > > level, on a per-file basis. But in many respects that seems kind of > > nice. It increases flexability and reduces configuration complexity. > > > > So what do your think? Is this technique worth promoting? Or am I being > > silly and should just wrap all my scripts in modules? > > > first: adding the "as_foo" just adds useless complexity, imho, just load > a module and include id when needed. That's true. I was primarily just highlighting the potential of this approach with those methods. > Then, if you just add > > and a directory is a module, too so that > require 'foo' > loads module Foo > and > require 'foo/bar' > requires module Foo::Bar > > and you have the python's import system, which is a very good thing imo > and could reduce ruby's stdlib size of a 1/2% :) interesting... some thoughts * it would require all core extensions be prefixed with '::' (eg. ::Kernel). * would toplevel need a name, eg. ::Toplevel. how else could we load anything to it? or maybe we shouldn't be able to? * what if two libs have the same path but are in different load paths (a la gems) -- though I suppose a smart developer would make sure that didn't happen. For example, all things Facets are in {load_path}/facets/. * being able to assign the name seems much more flexible though --this would prevent potential name clashes of items that might share the same path but are within different load paths. (I suppose we could have two different methods). * if we added #new to module, would we even need to bother with classes directly? Ie. class Module def new(*args,&blk) Class.new{ include self }.new(*args,&blk) end end (hmm... how would we access the underlying class?) Thoughts? btw. what does python use for the name of its "require" method? T. From transfire at gmail.com Thu Jan 4 11:54:59 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Thu, 04 Jan 2007 16:54:59 -0000 Subject: [Nitro] Build scripts as modules or plain scripts In-Reply-To: References: <1167870604.858204.52590@v33g2000cwv.googlegroups.com> Message-ID: <1167929699.432332.143630@v33g2000cwv.googlegroups.com> gabriele renzi wrote: > transfire at gmail.com ha scritto: > > > Of course this effectively puts encapsulation, at least at the top > > level, on a per-file basis. But in many respects that seems kind of > > nice. It increases flexability and reduces configuration complexity. > > > > So what do your think? Is this technique worth promoting? Or am I being > > silly and should just wrap all my scripts in modules? > > > first: adding the "as_foo" just adds useless complexity, imho, just load > a module and include id when needed. > > Then, if you just add > > and a directory is a module, too so that > require 'foo' > loads module Foo > and > require 'foo/bar' > requires module Foo::Bar > > and you have the python's import system, which is a very good thing imo > and could reduce ruby's stdlib size of a 1/2% :) > > Mind if I cross post this on ruby-talk? I'd like to see waht others have to say about it. T. From john at oxyliquit.de Fri Jan 5 07:59:10 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Fri, 05 Jan 2007 13:59:10 +0100 Subject: [Nitro] [PATCH] parameter error output enhancement Message-ID: Hi, Fri Jan 5 13:53:05 CET 2007 Jonathan Buch * logger fix, print argument error when $DBG Also adds a testcase to tc controller params, thanks Kartesus. Since any ArgumentError triggered the 'Wrong parameter count' error, we better use $DBG to make the old error available when developing Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From john at oxyliquit.de Fri Jan 5 08:06:26 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Fri, 05 Jan 2007 14:06:26 +0100 Subject: [Nitro] [PATCH] parameter error output enhancement In-Reply-To: References: Message-ID: And now the patch *sigh* Jo -- Feel the love http://pinkjuice.com/pics/ruby.png -------------- next part -------------- A non-text attachment was scrubbed... Name: lgfxargerr.patch.tar.bz2 Type: application/bzip2 Size: 4717 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070105/79011788/attachment-0001.bin From vikingtux at gmail.com Fri Jan 5 08:59:36 2007 From: vikingtux at gmail.com (Alexandre Gravem) Date: Fri, 5 Jan 2007 11:59:36 -0200 Subject: [Nitro] [PATCH] parameter error output enhancement In-Reply-To: References: Message-ID: <40b05ebe0701050559l5a95cd2hde8f785d76c77499@mail.gmail.com> I am glad my sloopy coding was useful for something :) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070105/16feedfc/attachment.html From transfire at gmail.com Fri Jan 5 11:44:03 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Fri, 05 Jan 2007 16:44:03 -0000 Subject: [Nitro] Darcs Tags? Message-ID: <1168015443.973112.18950@q40g2000cwq.googlegroups.com> I'm a piss poor user of Darcs. I really only use it to track change logs. For instance I don't understand how one manages tags with darcs. T. From george.moschovitis at gmail.com Sun Jan 7 11:54:06 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 7 Jan 2007 18:54:06 +0200 Subject: [Nitro] [PATCH] parameter error output enhancement In-Reply-To: <40b05ebe0701050559l5a95cd2hde8f785d76c77499@mail.gmail.com> References: <40b05ebe0701050559l5a95cd2hde8f785d76c77499@mail.gmail.com> Message-ID: thanks for the patch! -g. On 1/5/07, Alexandre Gravem wrote: > > I am glad my sloopy coding was useful for something :) > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070107/08c53d35/attachment.html From malte at gmx-topmail.de Sun Jan 7 17:53:52 2007 From: malte at gmx-topmail.de (Malte Milatz) Date: Sun, 07 Jan 2007 23:53:52 +0100 Subject: [Nitro] Lighttpd and Fastcgi, innovative work flow Message-ID: <1168210432.5526.22.camel@aligatoro.ret> Hi, I'm still trying to get into Nitro. Today's topic: How to set up Nitro with lighttpd and fastcgi? I have fiddled with the following for about half an hour. $ gen app testme $ cd testme $ chmod u+x public/fcgi.rb $ vi public/fcgi.rb # corrected shebang $ vi conf/lhttpd.conf # deleted corrupted lines (82 following) # configured the paths $ mkdir log Quite a lot to do already. Now: $ lighttpd -D -f conf/lhttpd.conf Gives: /usr/lib/ruby/gems/1.8/gems/nitro-0.41.0/lib/nitro/adapter/fastcgi.rb:10: uninitialized constant Socket (NameError) Added ?require 'socket'? to fcgi.rb. Gives: /usr/lib/ruby/gems/1.8/gems/nitro-0.41.0/lib/nitro/adapter/fastcgi.rb:38:in `start': uninitialized constant Nitro::FastCGI::FCGI (NameError) Added ?require 'fcgi'? to fcgi.rb. Works now. Hm. Is this a version issue? $ lighttpd -v lighttpd-1.4.11 (ssl) - a light and fast webserver Build-Date: May 11 2006 00:31:57 $ ruby -v ruby 1.8.4 (2005-12-24) [x86_64-linux] $ apt-cache show libfcgi-ruby1.8 | grep ^Version Version: 0.8.6-1 Happy coding and regards, Malte From john at oxyliquit.de Mon Jan 8 03:19:41 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Mon, 08 Jan 2007 09:19:41 +0100 Subject: [Nitro] Lighttpd and Fastcgi, innovative work flow In-Reply-To: <1168210432.5526.22.camel@aligatoro.ret> References: <1168210432.5526.22.camel@aligatoro.ret> Message-ID: Hi, > /usr/lib/ruby/gems/1.8/gems/nitro-0.41.0/lib/nitro/adapter/fastcgi.rb:10: uninitialized constant Socket (NameError) I might be completely off, but could it be that the pure ruby fastcgi lib had been loaded? Did you install the fastcgi .so? (libfcgi0c2 package on debian) You can test fcgi also by doing: NITRO_INVOKE=fcgi_proc ./run.rb This should start your app (and then block of course, waiting for fcgi requests). If the libfcgi.so.0 was already there, could you try installing the gem version of the fcgi lib and see what it does about the C ext? Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From malte at gmx-topmail.de Mon Jan 8 06:20:09 2007 From: malte at gmx-topmail.de (Malte Milatz) Date: Mon, 08 Jan 2007 12:20:09 +0100 Subject: [Nitro] Lighttpd and Fastcgi, innovative work flow In-Reply-To: References: <1168210432.5526.22.camel@aligatoro.ret> Message-ID: <1168255210.7364.24.camel@aligatoro.ret> Jonathan Buch: > Hi, > > > /usr/lib/ruby/gems/1.8/gems/nitro-0.41.0/lib/nitro/adapter/fastcgi.rb:10: uninitialized constant Socket (NameError) > > I might be completely off, but could it be that the pure ruby fastcgi > lib had been loaded? Did you install the fastcgi .so? (libfcgi0c2 package > on debian) Hm, interesting. I'm adding package details to the end of this mail. > If the libfcgi.so.0 was already there, could you try installing the gem > version of the fcgi lib and see what it does about the C ext? When using the gem instead of the Ubunutu package, the only difference I've noticed is that I had to pay attention to the load path order. I.e., I had to replace my require 'fcgi' with require 'fcgi.so' because the first line would load public/fcgi.rb. So I did the following: - rename fcgi.rb to dispatch_fcgi.rb (require 'fcgi' won't work with public/fcgi.rb being present) - in conf/lhttpd.conf replace both occurences of fcgi.rb with dispatch_fcgi.rb - still leave require 'socket' in the code This works on my system both with the gem and with the Ubuntu package. I still wonder why I have to require 'socket' on my own. Package information: malte at aligatoro:~$ apt-cache show libfcgi0 Package: libfcgi0 Priority: optional Section: universe/libs Installed-Size: 812 Maintainer: Tatsuki Sugiura Architecture: amd64 Source: libfcgi Version: 2.4.0-5 Provides: libfcgi Depends: libc6 (>= 2.3.2.ds1-4) Filename: pool/universe/libf/libfcgi/libfcgi0_2.4.0-5_amd64.deb Size: 280018 MD5sum: 4aca3794844cfa0dec2e97ae681b985c Description: Shared library of FastCGI FastCGI is a language independent, scalable, open extension to CGI that provides high performance without the limitations of server specific APIs. Bugs: mailto:ubuntu-users at lists.ubuntu.com Origin: Ubuntu malte at aligatoro:testmenow$ apt-cache show libfcgi-ruby1.8 Package: libfcgi-ruby1.8 Priority: optional Section: universe/web Installed-Size: 88 Maintainer: Tatsuki Sugiura Architecture: amd64 Source: libfcgi-ruby Version: 0.8.6-1 Provides: libfcgi-ruby Depends: libc6 (>= 2.3.4-1), libfcgi0, libruby1.8 (>= 1.8.2-5) Filename: pool/universe/libf/libfcgi-ruby/libfcgi-ruby1.8_0.8.6-1_amd64.deb Size: 15730 MD5sum: b7b2e0db9877a8a1e296c7c8f00155c4 Description: FastCGI library for Ruby FastCGI is a language independent, scalable, open extension to CGI that provides high performance without the limitations of server specific APIs. For more information, see http://www.fastcgi.com/. . This merges matz's C version(fcgi.so) & Eli's pure ruby version(fastcgi.rb) Bugs: mailto:ubuntu-users at lists.ubuntu.com Origin: Ubuntu From john at oxyliquit.de Mon Jan 8 07:00:57 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Mon, 08 Jan 2007 13:00:57 +0100 Subject: [Nitro] Lighttpd and Fastcgi, innovative work flow In-Reply-To: <1168255210.7364.24.camel@aligatoro.ret> References: <1168210432.5526.22.camel@aligatoro.ret> <1168255210.7364.24.camel@aligatoro.ret> Message-ID: Hi, > This works on my system both with the gem and with the Ubuntu package. I > still wonder why I have to require 'socket' on my own. I have no idea. I looked at my code, at nitros, and I wonder why I don't get bitten by that. It might be the memcached code, though I can't be sure of that. George, could you add the `require 'socket'` at the start of the fcgi.rb? I's so minor I don't even want to make a patch for it. :P Anyway, glad you got it to work, Malte! Thanks for the description how you did it, I'm sure it'll help someone. Do I have permission to copy your guidelines and put them up on the lighttpd tip on Oxyliquit? Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From malte at gmx-topmail.de Mon Jan 8 08:06:15 2007 From: malte at gmx-topmail.de (Malte Milatz) Date: Mon, 08 Jan 2007 14:06:15 +0100 Subject: [Nitro] Lighttpd and Fastcgi, innovative work flow In-Reply-To: References: <1168210432.5526.22.camel@aligatoro.ret> <1168255210.7364.24.camel@aligatoro.ret> Message-ID: <1168261575.5544.13.camel@aligatoro.ret> Jonathan Buch: > George, could you add the `require 'socket'` at the start of the fcgi.rb? > I's so minor I don't even want to make a patch for it. :P Please, may someone also look into the following (mentioned before)? 1. Rename fcgi.rb to avoid name conflicts, 2. Fix lhttpd.conf and add comments anywhere where the user has to adjust a path, 3. Cosmetic change: Use the same shebang in any executable *.rb that gen generates (and maybe make these files really executables, or generate a README file that clearly states to make them executable), 4. Add an empty log directory in the Nitro proto. > Anyway, glad you got it to work, Malte! I'm glad about that, too. ;-) > Do I have permission to copy your guidelines and put them up on the lighttpd > tip on Oxyliquit? Sure. Regards, Malte From fabian at fabian-buch.de Mon Jan 8 08:23:30 2007 From: fabian at fabian-buch.de (Fabian Buch) Date: Mon, 8 Jan 2007 14:23:30 +0100 Subject: [Nitro] Lighttpd and Fastcgi, innovative work flow In-Reply-To: <1168261575.5544.13.camel@aligatoro.ret> References: <1168210432.5526.22.camel@aligatoro.ret> <1168255210.7364.24.camel@aligatoro.ret> <1168261575.5544.13.camel@aligatoro.ret> Message-ID: <0F93B59D-4E6E-48DC-BC73-721FC3951DB1@fabian-buch.de> Am 08.01.2007 um 14:06 schrieb Malte Milatz: > Jonathan Buch: >> George, could you add the `require 'socket'` at the start of the >> fcgi.rb? >> I's so minor I don't even want to make a patch for it. :P > > Please, may someone also look into the following (mentioned before)? > > 1. Rename fcgi.rb to avoid name conflicts, For various reasons I name this the rails way in all my projects: dispatch.cgi dispatch.fcgi Maybe this could be made standard in Nitro? Fabian -- Nitro Q&A: http://oxyliquit.de LoxParts: http://loxparts.de Blog: http://blog.fabian-buch.de From m.fellinger at gmail.com Mon Jan 8 14:23:40 2007 From: m.fellinger at gmail.com (Michael Fellinger) Date: Tue, 9 Jan 2007 04:23:40 +0900 Subject: [Nitro] Request for help In-Reply-To: <458F6081.6020607@gmail.com> References: <1166978085.809422.22010@73g2000cwn.googlegroups.com> <1166980695.673202.261850@a3g2000cwd.googlegroups.com> <458ECDF9.90800@gmail.com> <1167001141.682836.180060@42g2000cwt.googlegroups.com> <458F6081.6020607@gmail.com> Message-ID: <9c00d3e00701081123r3f585b4k8b683ebb378f9aae@mail.gmail.com> On 12/25/06, James Britt wrote: > transfire at gmail.com wrote: > > George Moschovitis wrote: > >>> Needs actual unit tests to see that it does something good. > >> It also needs some cleanup to make it look more like nitro and/or > >> facets/ruby code ;-) > >> I wonder if Tom could post his version as well. > > > > Okay, I basically finsihed it and emailed you and Britt a copy. > > I've not seen this arrive, though. Any updates on this front? > > -- > James Britt > > "Trying to port the desktop metaphor to the Web is like working > on how to fuel your car with hay because that is what horses eat." > - Dare Obasanjo > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > From george.moschovitis at gmail.com Mon Jan 8 14:39:49 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 8 Jan 2007 21:39:49 +0200 Subject: [Nitro] Request for help In-Reply-To: <9c00d3e00701081123r3f585b4k8b683ebb378f9aae@mail.gmail.com> References: <1166978085.809422.22010@73g2000cwn.googlegroups.com> <1166980695.673202.261850@a3g2000cwd.googlegroups.com> <458ECDF9.90800@gmail.com> <1167001141.682836.180060@42g2000cwt.googlegroups.com> <458F6081.6020607@gmail.com> <9c00d3e00701081123r3f585b4k8b683ebb378f9aae@mail.gmail.com> Message-ID: you can see a version in nitro/lib/nitro/util/htmlfilter.rb in the repository. I don't like this much though, will convert it to a single method when I have time. -g. On 1/8/07, Michael Fellinger wrote: > > On 12/25/06, James Britt wrote: > > transfire at gmail.com wrote: > > > George Moschovitis wrote: > > >>> Needs actual unit tests to see that it does something good. > > >> It also needs some cleanup to make it look more like nitro and/or > > >> facets/ruby code ;-) > > >> I wonder if Tom could post his version as well. > > > > > > Okay, I basically finsihed it and emailed you and Britt a copy. > > > > I've not seen this arrive, though. > > Any updates on this front? > > > > > -- > > James Britt > > > > "Trying to port the desktop metaphor to the Web is like working > > on how to fuel your car with hay because that is what horses eat." > > - Dare Obasanjo > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070108/0c1b002d/attachment-0001.html From malte at gmx-topmail.de Tue Jan 9 15:41:29 2007 From: malte at gmx-topmail.de (Malte Milatz) Date: Tue, 09 Jan 2007 21:41:29 +0100 Subject: [Nitro] FormHelper::FormXmlBuilder#attribute without label Message-ID: <1168375289.6881.7.camel@aligatoro.ret> I'm trying to understand FormHelper. What should I write where I have some_method_call? I do not need a label there because I want a proper
structure, so #attribute is of no use to me. I need a plain field instead. form(:object => Item, :action => 'go', :method => 'multipart') do |f| f.form_errors # By the way, is this the right place for it? f.dl { f.dt { f.label "What's your name?", :for => 'poster_name' } f.dd { f.some_method_call :poster_name } } end Thanks, Malte From george.moschovitis at gmail.com Tue Jan 9 16:42:56 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 9 Jan 2007 23:42:56 +0200 Subject: [Nitro] FormHelper::FormXmlBuilder#attribute without label In-Reply-To: <1168375289.6881.7.camel@aligatoro.ret> References: <1168375289.6881.7.camel@aligatoro.ret> Message-ID: how about f.input .... ? -g. On 1/9/07, Malte Milatz wrote: > > I'm trying to understand FormHelper. What should I write where I have > some_method_call? I do not need a label there because I want a proper >
structure, so #attribute is of no use to me. I need a plain > field instead. > > form(:object => Item, :action => 'go', :method => 'multipart') do |f| > f.form_errors # By the way, is this the right place for it? > f.dl { > f.dt { f.label "What's your name?", :for => 'poster_name' } > f.dd { f.some_method_call :poster_name } > } > end > > > Thanks, > > Malte > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070109/e239125d/attachment.html From malte at gmx-topmail.de Wed Jan 10 07:32:50 2007 From: malte at gmx-topmail.de (Malte Milatz) Date: Wed, 10 Jan 2007 13:32:50 +0100 Subject: [Nitro] FormHelper::FormXmlBuilder#attribute without label In-Reply-To: References: <1168375289.6881.7.camel@aligatoro.ret> Message-ID: <1168432371.8256.6.camel@aligatoro.ret> George Moschovitis: > how about f.input .... ? Hm, alright, then I do not need the helper at all. Thanks, next question: f.attribute appends "_ctl" to the id. Should I imitate this, or does it not matter? By the way, this seems to be a bug in FormHelper: The for attribute of