Thanks Jeremy,
Here is the ticket:
http://dev.rubyonrails.org/ticket/8448
if the patch is used, one can start a rails app just like that:
rake my_project
rake db:create
ruby script/server
That's it! ready to go. (compatible with PostgreSQL, MySQL, and
SQLite3)
One thing though, we might want
On May 23, 2007, at 5:57 PM, Michael Koziarski wrote:
>
>> http://dev.rubyonrails.org/ticket/8305
>> http://dev.rubyonrails.org/ticket/8308
>
> An XML namespace has to be declared to be valid xml, so the patches
> submitted seem to leave us in the same situation where .to_xml will
> produce inva
> http://dev.rubyonrails.org/ticket/8305
> http://dev.rubyonrails.org/ticket/8308
An XML namespace has to be declared to be valid xml, so the patches
submitted seem to leave us in the same situation where .to_xml will
produce invalid xml.
So given Module::Model, the only options I can think of a
> introducing this is to write a plugin that will monkey patch rails
> core and provide the no-op api for l10n plugins. Once we do that we
> can sell it to all the l10n plugin devs and try to standardize around
> it. If we've got that going, it will look a lot more attractive to
> rails core dev
There was a presentation at RejectConf about something similar: The
ability to encapsulate partial logic in a controller method to get all
the DRY goodness without the need for components. I think it was done
by someone in the NY group, but I am not sure. Does anyone remember
who did this? It migh
This is essentially the idea I was promoting. I think a good way of
introducing this is to write a plugin that will monkey patch rails
core and provide the no-op api for l10n plugins. Once we do that we
can sell it to all the l10n plugin devs and try to standardize around
it. If we've got that goi
On May 22, 2007, at 10:50 PM, Michael Koziarski wrote:
>
> Stefan kaes would be the guy to talk to about this.
>
> While performance is / was a concern, it was not a reason for our lack
> of enthusiasm for component based web development. So a solution to
> any performance issues is unlikely to
Why not have RoR define a reference set of modules and class (call it
i18n for now) whose API implements the most basic i18n methods with no
real functionality? Then the plugins could flesh out the
functionality. I know this is pretty simplistic, but we need to start
somewhere. As RoR evolves,
> Nothing fancy, nothing specially designed to help l10n/i18n plugins
> but just to avoid patching the core methods. (extending is fine)
Provided there are no adverse performance or understandability
impacts, I think we could apply a patch which refactored the core code
a little. If a little bit
Alright, that's exactly what I wanted to avoid... a long thread about
how the core should deal with localization :(
I don't think the core team should adopt a .t method or another way of
dealing with translation. That's really up to the plugin developers to
decide.
What I would like to see is sim
Alright, that's exactly what I wanted to avoid... a long thread about
how the core should deal with localization :(
I don't think the core team should adopt a .t method or another way of
dealing with translation. That's really up to the plugin developers to
decide.
What I would like to see is sim
On 5/23/07, Matt Aimonetti <[EMAIL PROTECTED]> wrote:
> Somebody from the core team? Do you want a patch or sould I keep that
> in my plugin?
Please do patch. Let's encourage Unicode end-to-end.
jeremy
--~--~-~--~~~---~--~~
You received this message because you a
For your consideration, two snippets from a routes.rb file:
map.namespace(:bookshelf, :path_prefix => "/bookshelf/:book_id") do
|bookshelf|
bookshelf.resources :sections
bookshelf.resources :templates
end
map.namespace(:bookshelf) do |bookshelf|
bookshelf.publish ":book_id/publi
I understand that many people won't get use out of 't', but I think
the extra work involved (we're talking about an extra charcter, and
letting the people who care submit patches to clean up what's already
there) is trivial in comparison to what is gained here. It means that
i18n efforts can hook
OK. I've uploaded my patch with the scaffold generator tests at:
http://dev.rubyonrails.org/ticket/8443
It also includes a generator_test_helper module, which has lots of
helpful assertions, which could be used for testing most kinds of
generators.
Regards
Pelle
On May 21, 12:04 pm, "Jeremy Ke
Somebody from the core team? Do you want a patch or sould I keep that
in my plugin?
m|a
On May 22, 9:03 am, Manfred Stienstra <[EMAIL PROTECTED]> wrote:
> > On May 21, 8:47 pm, DHH <[EMAIL PROTECTED]> wrote:
> >>> If you use ActiveRecord::Base.connection.create_database you'll
> >>> notice
> >>>
Is it possible to auto-extract strings like Heckle?
Doing so it would be very easy to lookup for translatable strings and
no change to core would be needed.
Marcello
On May 23, 12:36 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> +1
>
> I don't want to get into details yet, but I agree tha
Is it possible to auto-extract strings like Heckle?
Doing so it would be very easy to lookup for translatable strings and
no change to core would be needed.
Marcello
On May 23, 12:50 pm, "Mislav Marohnić" <[EMAIL PROTECTED]>
wrote:
> On 5/23/07, Michael Koziarski <[EMAIL PROTECTED]> wrote:
>
>
>
Is it possible to auto-extract strings like Heckle?
Doing so it would be very easy to lookup for translatable strings and
no change to core would be needed.
Marcello
On May 23, 12:50 pm, "Mislav Marohnić" <[EMAIL PROTECTED]>
wrote:
> On 5/23/07, Michael Koziarski <[EMAIL PROTECTED]> wrote:
>
>
>
On May 22, 2007, at 10:50 PM, Michael Koziarski wrote:
>
> Stefan kaes would be the guy to talk to about this.
>
> While performance is / was a concern, it was not a reason for our lack
> of enthusiasm for component based web development. So a solution to
> any performance issues is unlikely to
Is it possible to auto-extract strings like Heckle?
Doing so it would be very easy to lookup for translatable strings and
no change to core would be needed.
Marcello
On May 23, 12:50 pm, "Mislav Marohnić" <[EMAIL PROTECTED]>
wrote:
> On 5/23/07, Michael Koziarski <[EMAIL PROTECTED]> wrote:
>
>
>
yeah!
On May 22, 2007, at 10:30 PM, Alexey Verkhovsky wrote:
> ActiveRecord builds for SQLite and SQLite3 have been added to the
> CI build.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" g
On 5/23/07, Joshua Sierles <[EMAIL PROTECTED]> wrote:
>
> >
> >
> > It seems the best bet is to leave the concern entirely outside rails
> > itself, until the current disparate efforts can be folded into a
> > single 'best practise'. Failing that, perhaps it's something where
> > there isn't a
Michael Koziarski wrote:
>> Well, each i18n plugin would override String#t to actually translate
>> the validation message. Anybody who doesn't want i18n just uses Rails
>> as usual. But anyone who does want to translate, just adds their
>> localization plugin of choice, which now can automaticall
>
>
> It seems the best bet is to leave the concern entirely outside rails
> itself, until the current disparate efforts can be folded into a
> single 'best practise'. Failing that, perhaps it's something where
> there isn't a solution which suits 'most of the people most of the
> time'.
>
>
On 5/23/07, Michael Koziarski <[EMAIL PROTECTED]> wrote:
>
>
> But String#t, or anything else, would be entirely redundant without
> localisation code in rails right? Adding a bunch of method
> invocations for no new functionality doesn't seem like a good trade :)
Is this the opinion of the whol
> Well, each i18n plugin would override String#t to actually translate
> the validation message. Anybody who doesn't want i18n just uses Rails
> as usual. But anyone who does want to translate, just adds their
> localization plugin of choice, which now can automatically translate
> all of the Rail
On 5/22/07, Rich Cox <[EMAIL PROTECTED]> wrote:
> On a related note, does anyone have any ideas how to fix error #3? I started
> looking at it tonight but don't have any ideas where to start...
I think that fixture should probably use a smaller binary.
jeremy
--~--~-~--~~---
The build has been fixed.
See http://cruisecontrolrb.thoughtworks.com/builds/RubyOnRails/6822 for details.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To post to this group, send emai
The build failed.
See http://cruisecontrolrb.thoughtworks.com/builds/RubyOnRails/6821 for details.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To post to this group, send email to rub
The build failed.
See http://cruisecontrolrb.thoughtworks.com/builds/RubyOnRails/6820 for details.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To post to this group, send email to rub
The build failed.
See http://cruisecontrolrb.thoughtworks.com/builds/RubyOnRails/6819 for details.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To post to this group, send email to rub
The build failed.
See http://cruisecontrolrb.thoughtworks.com/builds/RubyOnRails/6818 for details.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To post to this group, send email to rub
33 matches
Mail list logo
