Re: [Rails-core] [3795] render_component doesn't work with modules?
Rick Olson wrote:
On 2/10/06, Trevor Squires <[EMAIL PROTECTED]> wrote:
Hi Nathaniel,
I'm using a version of edge (not the most recent, but after module
namespace support was improved) and I use render_component into a
module namespace quite extensively with no problems.
I know you said you "nailed it down to having a '/' in the
controller" but are you sure it's not simply the *leading* slash
character that's giving you problems?
Regards,
Trevor
This might be related to changeset [3563]
(http://dev.rubyonrails.org/changeset/3563). When I get some time
I'll dig into the issue if no one else has by then.
--
Rick Olson
http://techno-weenie.net
___
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
This is a bug in the constantize implementation. I suggest to change it
to the following code, which apart from fixing the bug, is a faster as well:
def constantize(camel_cased_word)
begin
if camel_cased_word[0, 2] == '::'
Object.module_eval(camel_cased_word, __FILE__, __LINE__)
else
Object.module_eval("::#{camel_cased_word}", __FILE__, __LINE__)
end
rescue NameError, SyntaxError
raise NameError, "#{camel_cased_word.inspect} is not a valid
constant name!"
end
end
See ticket http://dev.rubyonrails.org/ticket/3803
-- stefan
--
For rails performance tuning, see: http://railsexpress.de/blog
Subscription: http://railsexpress.de/blog/xml/rss20/feed.xml
___
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
RE: [Rails-core] AR Unit Tests
Hi Wilson, The problem was with the comment in front of the table. In MySQL, comments starting with -- need a whitespace character following it. Bob Silva http://www.railtie.net/ > -Original Message- > From: [EMAIL PROTECTED] [mailto:rails-core- > [EMAIL PROTECTED] On Behalf Of Wilson Bilkovich > Sent: Friday, February 10, 2006 6:38 AM > To: rails-core@lists.rubyonrails.org > Subject: Re: [Rails-core] AR Unit Tests > > On 2/10/06, Bob Silva <[EMAIL PROTECTED]> wrote: > > > > test_lock_column_name_existing(LockingTest): > > > > ActiveRecord::StatementInvalid: Mysql::Error: #42S02Table > > 'activerecord_unittest.legacy_things' doesn't exist: DELETE > > FROM legacy_things > > This is a test I wrote. I don't use MySQL, unfortunately, so I can > only hope that I got the definition syntax right. This is what is in > the mysql.sql file.. is this correct? > > CREATE TABLE `legacy_things` ( > `id` int(11) NOT NULL auto_increment, > `tps_report_number` int(11) default NULL, > `version` int(11) NOT NULL default 0, > PRIMARY KEY (`id`) > ) TYPE=InnoDB; > ___ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
RE: [Rails-core] Date Helper Mega Patch
The current way I'm planning on implementing this is to have hidden text fields for the date components. The only database this doesn't work with is SQLite since it won't convert the datetime into a time upon save. Haven't checked to see if there was a hook to convert the Time object into a time string when saving within AR. Do you see any issues with this implementation? Bob Silva http://www.railtie.net/ > -Original Message- > From: [EMAIL PROTECTED] [mailto:rails-core- > [EMAIL PROTECTED] On Behalf Of Michael Koziarski > Sent: Friday, February 10, 2006 6:30 PM > To: rails-core@lists.rubyonrails.org > Subject: Re: [Rails-core] Date Helper Mega Patch > > > They all have to do with the Date Helper. > > > > * Support index and/or @auto_index > > * Enable discard year > > * time_select (alias to datetime_select with previous patch applied) > > * Unique id's as per w3c spec > > * :order for datetime_select to mimic date_select :order option > > * add :include_seconds to datetime_select, select_datetime and > time_select > > > > > > Opinions, ideas or objections so I don't have anything in the patch > which is > > likely to get it shot down. > > I like the idea and have no objections. However, what will > time_select 'select'? Ruby 'times' have a date component: > > irb(main):002:0> Time.now > => Sat Feb 11 15:29:17 NZDT 2006 > > > > Thanks > > > > Bob Silva > > http://www.railtie.net/ > > > > > > ___ > > Rails-core mailing list > > Rails-core@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails-core > > > > > -- > Cheers > > Koz > ___ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Multithreaded script/runner
Hi Tom, Thanks for the update. Have you heard anything about getting this code committed into subversion? On Feb 10, 2006, at 5:24 AM, Tom Ward wrote: I've been using the pooled adapter on some installations without any obvious problems, but not running against rails 1.0. I know that some changes were made in #428 that may affect the pool. I'll take a look at the code I wrote over the weekend, and see how it looks against 1.0 and trunk. I'll comment against #2162 with anything I find. Tom On 2/9/06, Greg Lappen <[EMAIL PROTECTED]> wrote: Your guess is as good as mine. Tom Ward did some work based on my original patch to implement a pooled adaptor which I thought was on track to be integrated into the core, but i still don't see it in subversion. We would like to be able to use Rails with webrick in multithreaded mode for small admin apps and the like. Can anyone comment on the status of integration the connection pooling patch? Greg On Jan 31, 2006, at 6:53 PM, Kyle Maxwell wrote: I'm trying to use a multi-threaded script/runner, which dies with too many (mysql) database connections. I reading up, and it appears that this is because each thread uses a new database connection. Moreover, the thread doesn't close out the connection when it's done. It appears that patch #2162, which would enable connection pooling, was stalled. Is this planned for 1.1? Is there another way around the issue? -- Kyle Maxwell Chief Technologist E Factor Media // FN Interactive [EMAIL PROTECTED] 1-866-263-3261 ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] AR Unit Tests
Good to know. I'll be more careful with when guessing at MySQL syntax next time. Sorry for the inconvenience. :) On 2/11/06, Bob Silva <[EMAIL PROTECTED]> wrote: > Hi Wilson, > > The problem was with the comment in front of the table. In MySQL, comments > starting with -- need a whitespace character following it. > > Bob Silva > http://www.railtie.net/ > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:rails-core- > > [EMAIL PROTECTED] On Behalf Of Wilson Bilkovich > > Sent: Friday, February 10, 2006 6:38 AM > > To: rails-core@lists.rubyonrails.org > > Subject: Re: [Rails-core] AR Unit Tests > > > > On 2/10/06, Bob Silva <[EMAIL PROTECTED]> wrote: > > > > > > test_lock_column_name_existing(LockingTest): > > > > > > ActiveRecord::StatementInvalid: Mysql::Error: #42S02Table > > > 'activerecord_unittest.legacy_things' doesn't exist: DELETE > > > FROM legacy_things > > > > This is a test I wrote. I don't use MySQL, unfortunately, so I can > > only hope that I got the definition syntax right. This is what is in > > the mysql.sql file.. is this correct? > > > > CREATE TABLE `legacy_things` ( > > `id` int(11) NOT NULL auto_increment, > > `tps_report_number` int(11) default NULL, > > `version` int(11) NOT NULL default 0, > > PRIMARY KEY (`id`) > > ) TYPE=InnoDB; > > ___ > > Rails-core mailing list > > Rails-core@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails-core > > ___ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core > ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] anyone in a committing mood?
On Feb 10, 2006, at 11:49 AM, David Heinemeier Hansson wrote: If it would help I can bundle them all up into a single patch, just let me know. It would. Please do roll them all up into 1 patch and get a few Oracle'ers to try that out. If you could get them to comment on this new ticket with "+1 works for me", then that'd be great. Thanks! I can give the rolled up patch a try on our Oracle/Rails apps. Please drop me a note when it's ready to go, or the ticket number that you'll attach the patch to. Regards, Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies <[EMAIL PROTECTED]> Subversion training, consulting and support http://www.orcaware.com/svn/ ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
[Rails-core] Default <%= to use the h (html safe) method.
I was just reading a blog post, about how PHP applications lack so much as far as security goes, and it got me thinking that Rails should come default secure, and you should have to force it to be less secure. On that note, I came up with the idea of having <%= default to use the XSS safe (or soon to be) h method. So, <%=h var %> and <%= var %> are really the same. Any thoughts? -Nb ~ Nathaniel S. H. Brown http://nshb.net ~ ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Default <%= to use the h (html safe) method.
On 2/12/06, Nathaniel S. H. Brown <[EMAIL PROTECTED]> wrote: > I was just reading a blog post, about how PHP applications lack so much as > far as security goes, and it got me thinking that Rails should come default > secure, and you should have to force it to be less secure. > > On that note, I came up with the idea of having <%= default to use the XSS > safe (or soon to be) h method. > > So, <%=h var %> and <%= var %> are really the same. > > Any thoughts? Unftortunately this would break existing applications which rely on the original behaviour. So even if we thought it was something we'd like to do, it'd have to wait until rails 2.0. It's also a little counter-intuitive, I don't know that I like the idea. -- Cheers Koz ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Default <%= to use the h (html safe) method.
+1 Would reduce clutter on the templates. It's pretty annoying to have to remember to put them in, and even more annoying to get tickets from QA about XSS. On 2/11/06, Nathaniel S. H. Brown <[EMAIL PROTECTED]> wrote: > I was just reading a blog post, about how PHP applications lack so much as > far as security goes, and it got me thinking that Rails should come default > secure, and you should have to force it to be less secure. > > On that note, I came up with the idea of having <%= default to use the XSS > safe (or soon to be) h method. > > So, <%=h var %> and <%= var %> are really the same. > > Any thoughts? > > -Nb > > ~ > Nathaniel S. H. Brown http://nshb.net > ~ > > ___ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core > ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
RE: [Rails-core] Default <%= to use the h (html safe) method.
Good point. We could always make it a configuration option for 1.0? -Nb ~ Nathaniel S. H. Brown http://nshb.net ~ > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Michael Koziarski > Sent: February 11, 2006 8:31 PM > To: rails-core@lists.rubyonrails.org > Subject: Re: [Rails-core] Default <%= to use the h (html safe) method. > > On 2/12/06, Nathaniel S. H. Brown <[EMAIL PROTECTED]> wrote: > > I was just reading a blog post, about how PHP applications lack so > > much as far as security goes, and it got me thinking that > Rails should > > come default secure, and you should have to force it to be > less secure. > > > > On that note, I came up with the idea of having <%= default > to use the > > XSS safe (or soon to be) h method. > > > > So, <%=h var %> and <%= var %> are really the same. > > > > Any thoughts? > > Unftortunately this would break existing applications which > rely on the original behaviour. So even if we thought it was > something we'd > like to do, it'd have to wait until rails 2.0. It's also a little > counter-intuitive, I don't know that I like the idea. > > -- > Cheers > > Koz > ___ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core > ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Default <%= to use the h (html safe) method.
huh? that would break url_for, link_to, textilize, markdown and every single other helper which outputs html tags. I use the h helper in like 3 different places in shopify, thats definitely the exception. > On that note, I came up with the idea of having <%= default to use the XSS > safe (or soon to be) h method. -- Tobi http://shopify.com - modern e-commerce software http://typo.leetsoft.com - Open source weblog engine http://blog.leetsoft.com - Technical weblog ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
RE: [Rails-core] Default <%= to use the h (html safe) method.
All of those helper functions would obviously need to be changed so that they work with the default <%=h methods. The <%= tag could be smart enough to realize what it is parsing, and if it's a helper method, to skip it. It's an abstract idea. If it's worth investigating, we can look at how to implement it, on a more specific level. Especially what implications it has, as you have mentioned. As far as I am concerned, these are minor details which can be ironed out with a bit of creativity. -Nb ~ Nathaniel S. H. Brown http://nshb.net ~ > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Tobias Luetke > Sent: February 11, 2006 9:04 PM > To: rails-core@lists.rubyonrails.org > Subject: Re: [Rails-core] Default <%= to use the h (html safe) method. > > huh? that would break url_for, link_to, textilize, markdown > and every single other helper which outputs html tags. I use > the h helper in like 3 different places in shopify, thats > definitely the exception. > > > On that note, I came up with the idea of having <%= default > to use the > > XSS safe (or soon to be) h method. > > -- > Tobi > http://shopify.com - modern e-commerce software > http://typo.leetsoft.com - Open source weblog engine > http://blog.leetsoft.com - Technical weblog > ___ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core > ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Default <%= to use the h (html safe) method.
On 2/12/06, Nathaniel S. H. Brown <[EMAIL PROTECTED]> wrote: > All of those helper functions would obviously need to be changed so that > they work with the default <%=h methods. The <%= tag could be smart enough > to realize what it is parsing, and if it's a helper method, to skip it. > > It's an abstract idea. If it's worth investigating, we can look at how to > implement it, on a more specific level. Especially what implications it has, > as you have mentioned. > > As far as I am concerned, these are minor details which can be ironed out > with a bit of creativity. I don't actually think that's possible.Whatever new output link_to returned, would just be the new target for XSS guys. -- Cheers Koz ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Default <%= to use the h (html safe) method.
Nathaniel S. H. Brown wrote: I was just reading a blog post, about how PHP applications lack so much as far as security goes, and it got me thinking that Rails should come default secure, and you should have to force it to be less secure. On that note, I came up with the idea of having <%= default to use the XSS safe (or soon to be) h method. So, <%=h var %> and <%= var %> are really the same. Any thoughts? Several. * Introducing this will break existing applications, which already make use of h, since h isn't idempotent. * If <%= expr %> already produces valid html (or a html fragment like "", which becomes valid through the page context), applying h to expr will produce garbage. * And of course, it would severely hurt performance. So -10 from me. -- stefan -- For rails performance tuning, see: http://railsexpress.de/blog Subscription: http://railsexpress.de/blog/xml/rss20/feed.xml ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
[Rails-core] select_datetime
Hi guys, Spent most of the day rewriting date_helper to close all the open tickets against it. Was just making sure everything was tested when I noticed that select_datetime doesn't use the dash between the date and time, nor : for the time components. Ditto on the select_time method. Would it be a BC break to add those or should I just add an option to specify the separator? Without them, you just get a bunch of select boxes slammed together. I'd think the display behavior should be identical between these and the datetime_select and new time_select methods. Bob Silva http://www.railtie.net/ ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
