ck is clemensk. I'd love to discuss this with you and hear
your opinions.
- Clemens
On May 25, 12:48 pm, Adam Meehan wrote:
> Wondering whether my validates_timeliness plugin may give some ideas
> on the date/time parsing front. The Formats class handles I18n
> parsinghttp
4th March 03, right? The only dates that are fairly
unambiguous are dates including month names and 4-digit years. So how
do I circumvent this issue when trying to parse? Question is: What
would/should happen if the user passes a date/time that can't be
parsed? Raise errors? Just set it to n
Just thinking: There are actually two more options (maybe more, but I
can think of two right now) if accepting localized input for all
numbers seems too drastic.
a) Have a config hook that is disabled by default, e.g.
config.active_record.delocalize_input = false. Only when this is set
to true, n
27;
would become 19.0 and @product.price = 'a string' would become 0.0).
Or am I misunderstanding the point you're trying to make?
In any case: Thanks for the feedback so far - it helped me see that I
needed to present my ideas more clearly.
- Clemens
--~--~-~--~~
Hi guys,
I was wondering if there's any interest in including support for
localized numbers directly in Rails core.
Example:
@product.price = '19,95' # => 19.95
There's a really simply way to get this done as can be seen at
http://github.com/
I like that. It would make the handling of permalinks much more
transparent.
On Mar 23, 12:37 am, Sven Fuchs wrote:
> I wondered why routing does not pass the current route segment key to
> to_param if to_param accepts a parameter.
>
> This would allow to have a route like
>
> map.article "
I agree with José - for the same reasons he mentioned. Maybe it makes
sense to just drop the current implementation and include the
localized templates plugin (if that's possible)?
- Clemens
On Jan 30, 6:33 pm, José Valim wrote:
> Hi guys,
>
> I just saw that localized templates
f TDD.
I don't know if this is still true (it's been a while since my last
contribution), but I think you need three people to +1 your suggestion/
patch before core team members look at it. Another option would be to
announce tickets in the rails-contrib IRC channel.
- Clemens
On
Obviously, I like that too - otherwise I wouldn't have made the
suggestion half a year ago! :-) Make sure that you contact me as soon
as something's decided - I'd be happy to help implementing this!
- Clemens
On Jan 29, 3:36 am, Mislav Marohnić wrote:
> On Thu, Jan 29,
on
- makes plenty of sense and is a valid reason for deprecation, even if
it occasionally results in some verbosity like you indicated.
I hope this explains the change sufficiently. Otherwise maybe Josh
would like to chime in since he was the one who committed it.
- Clemens
On Nov 16, 10:40 pm, &
If anyone's interested, I've forked Rails and started work on it here:
http://github.com/clemens/rails
NumberHelper is already updated, including tests and docs (although I
might rework the docs to make them more consistent).
--~--~-~--~~~---~--~~
You rec
suming than
actually writing the patch.
- Clemens
On Jul 17, 5:37 am, Tim Haines <[EMAIL PROTECTED]> wrote:
> Hi there,
>
> I'm wondering if a decision has been made as to whether it's desirable
> to have issues logged in lighthouse that are about documentation only?
>
I'm generally in favor of this for pretty much the same reason as
Hique.
One thing, though: If this kind of behavior was merged into core, the
fields_for method should also be updated to accept an array as its
first parameter to facilitate the use of nested hashes.
Right now, we have to do someth
for the next major release - but then again, who am I to
decide that stuff? ;-)
I'd love to hear what you guys from the core team and other people
think about it before getting down to work. The NumberHelper is, I
think, would be fairly easy to refactor b
Sadeesh,
a little hint from my side: It may be a better idea to post this on
railsforum.com or the workingwithrails.com forums. This mailing list
is more related to the development of the framework than providing
help.
Cheers,
- Clemens
On Jul 12, 11:45 am, sadeesh kumar <[EMAIL PROTEC
ultra-DRY but this way the actual API stays clean and keeps it down to
a reasonable amount of magic while still covering most cases.
- Clemens
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core&q
> I like the spirit of that. I kinda wonder if it becomes a little too
> magical. Some times the fallback URL will be set, some times it won't.
> And if the implementor hasn't considered this and used a respond_to
> block, expecting that all calls will be JS, then the non-JS user will
> just end u
> Wouldn't this defeat the entire purpose of *not* using a link. The
> rationale as I understand it is 'links should be safe to click'. If
> it looks like a link, acts like a link, but still isn't safe, then
> we're worse off than with the current implementations. It still
> surprises people bu
te", but maybe
also configurable) so we can easily add our unobtrusive JS layer to it
(using lowpro or whatever). That way, we're backwards compatible and
satisfy most people's needs that don't care about unobtrusive JS while
the unobtrusive folks could take a shortcut and use link_
> Given how widely used the current fuctionality is, then we'd need to
> see much better adoption of the better solution before we could do
> something like this.
>
> If something easier, and more accesible emerges then we can go for it,
> but personally I definitely prefer to use link_to_remote
that I might get in
trouble for saying it or at least kick off a discussion because what I
said can easily be misunderstood. I had already written an answer to
that one but I've deleted it a few seconds ago to not kick of the
argument about that because I think the matter at hand is way more
impo
s, to me, is a whole lot of good practices and rules and it
should be consistent in that way without any exceptions - not even
something as "humble" as the helpers.
Anyways, I'd love to hear more opinions on the topic.
Best,
- Clemens
On Jul 8, 12:11 am, "Nik Wakelin" <[
ovide patches if you agree with me that
this is an issue worth being addressed.
Please let me know what you think.
Best,
- Clemens
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" gr
23 matches
Mail list logo
