Very limited use-case. Can't see the point of it.
-1
On Monday, 9 July 2012 at 3:58 PM, angelo capilleri wrote:
Many users try to overwrite the to_param method of AR to add more
expressivness and value of Seo to the url using something like the
following:
def to_param
id.to_s + title.
Agreed, If you want custom slugs use something like
https://github.com/norman/friendly_id and then you can just forego the id in
the url all together.
On Monday, July 9, 2012 at 1:18 AM, Ryan Bigg wrote:
Very limited use-case. Can't see the point of it.
-1
On Monday, 9 July 2012 at
Moreover, in order to really optimize your SEO, you shouldn't rely only on
the ID, but you should also check the slug.
Otherwise, it generates duplicate content as you can have hundreds of
different urls with the same content.
Damien MATHIEU | Ingénieur logiciel
84, rue Chevreul | 69 007 Lyon
Hello:
1.9.3p194 :014 .blank?
= true
1.9.3p194 :015 [, ].blank?
= false
Proposal: the second line should also produce true.
Thoughts?
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group.
To view this discussion on the web visit
Michael,
That array isn't blank, empty strings aren't the same as nils. I think changing
that behavior would be confusing. If you don't want to count those elements,
it's probably best to filter the array for non-blank strings.
-Geoff
--
Geoff Harcourt
On Monday, July 9, 2012 at 10:15 AM,
On Jul 9, 2012, at 10:15 AM, Michael Boutros wrote:
Hello:
1.9.3p194 :014 .blank?
= true
1.9.3p194 :015 [, ].blank?
= false
Proposal: the second line should also produce true.
Thoughts?
If you really want to check for are all the values in this array blank, try:
Geoff,
But from the Rails documentation: An object is blank if it’s false, empty,
or a whitespace string. For example, “”, “ ”, nil, [], and {} are all
blank. That's why I think an array full of false, empty, or whitespace
strings should be empty.
- Michael
On Monday, July 9, 2012 10:18:04
On Mon, Jul 9, 2012 at 4:23 PM, Michael Boutros
michael.bout...@gmail.comwrote:
Geoff,
But from the Rails documentation: An object is blank if it’s false,
empty, or a whitespace string. For example, “”, “ ”, nil, [], and {} are
all blank. That's why I think an array full of false, empty, or
An object is blank if it’s false, empty, or a whitespace string. For
example, “”, “ ”, nil, [], and {} are all blank. That's why I think an
array full of false, empty, or whitespace strings should be empty.
But that's not mathematically accurate.
.size #= 0
[].size #= 1
[nil].size #= 1
An
Sorry, where I last wrote empty I meant to write blank, ie: That's why
I think an array full of false, empty, or whitespace strings should be
_blank_. Rails defines blank as a convenience method instead of checking if
something is nil and then if it's empty or not. I think extending that
https://gist.github.com/3076887
On Monday, July 9, 2012 10:15:04 AM UTC-4, Michael Boutros wrote:
Hello:
1.9.3p194 :014 .blank?
= true
1.9.3p194 :015 [, ].blank?
= false
Proposal: the second line should also produce true.
Thoughts?
--
You received this message because you are
Ah, OK. So the definition of blank? is clear but you are proposing to
change it for Arrays right?
--
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 rubyonrails-core@googlegroups.com.
To unsubscribe from
Yes.
On Monday, July 9, 2012 10:31:30 AM UTC-4, Xavier Noria wrote:
Ah, OK. So the definition of blank? is clear but you are proposing to
change it for Arrays right?
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group.
To view this
On Mon, Jul 9, 2012 at 4:38 PM, Michael Boutros
michael.bout...@gmail.comwrote:
Yes.
Your implementation makes sense. I mean, I believe that if blank? was
defined on enumerables as all?(:blank?) from the very first day, one could
have accepted that definition just fine.
But the current
Hi guys!
I want to propose the debate to setup the *RoR convention* for
*Observers*organization.
I search in the forum and found some posts about where put observers, but
no convention results as core on *convention over configuration*
paradigm.
Observers for model, sweepers, mailers ...
Yes, we need #blank? to be extra expensive because beginners needn't
control what gets injected in their Arrays. Maybe `{ = }.blank?`
should be true, too?
Here you go:
class Array
def super_blank?
# Go!
end
end
Scott
On Mon, Jul 9, 2012 at 7:15 AM, Michael Boutros
That's very unlikely to happen. Pretty much all Rails app rely on this behavior.
--
Oscar Del Ben
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
On Monday, July 9, 2012 at 7:38 AM, Michael Boutros wrote:
Yes.
On Monday, July 9, 2012 10:31:30 AM UTC-4, Xavier Noria wrote:
Ah, OK.
dup takes no args
create and new both take the same args, and create can take a block
It seems to me it would be more consistent (and convenient) if I could do
some_record.dup(attributes_i_want_to_change) do |dup_record|
dup_record.attribute = some_value
Lock down your data at the gates and this is not a problem. Making
#blank? incredibly slow is silly.
On Jul 9, 7:15 am, Michael Boutros michael.bout...@gmail.com wrote:
Hello:
1.9.3p194 :014 .blank?
= true
1.9.3p194 :015 [, ].blank?
= false
Proposal: the second line should also
The array has objects on it, so it isn't blank.
-
Maurício Linhares
http://techbot.me/ - http://twitter.com/#!/mauriciojr
On Monday, July 9, 2012 at 11:15 AM, Michael Boutros wrote:
Hello:
1.9.3p194 :014 .blank?
= true
1.9.3p194 :015 [, ].blank?
= false
Proposal: the
Blank is a convenience method for not checking the type of object. If you want
to do that you should use:
array.all?(:blank)
--
Oscar Del Ben
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
On Monday, July 9, 2012 at 7:30 AM, Michael Boutros wrote:
Sorry, where I last wrote empty I
Empty means that it has no elements.
--
Oscar Del Ben
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
On Monday, July 9, 2012 at 7:23 AM, Michael Boutros wrote:
Geoff,
But from the Rails documentation: An object is blank if it’s false, empty, or
a whitespace string. For
Sounds nice.
On Mon, Jul 9, 2012 at 12:23 PM, Kurt Werle k...@circlew.org wrote:
dup takes no args
create and new both take the same args, and create can take a block
It seems to me it would be more consistent (and convenient) if I could do
some_record.dup(attributes_i_want_to_change) do
Not only breaking Ruby semantics, but you can get what you want with this:
some_record.dup.tap do |dup_record|
dup_record.attribute = some_value
self.relationship.dup(reverse_relationship: dup_record)
end
--
You received this message because you are subscribed to the Google Groups Ruby
on
What about initialize_dup?
El jul 9, 2012 2:11 p.m., Nicolas Sanguinetti godf...@gmail.com
escribió:
dup doesn't take arguments because in ruby dup doesn't take arguments. It
wouldn't make sense to break the semantics of ruby just for this, IMO.
Cheers,
-foca
On 09/07/2012, at 14:23,
On Mon, Jul 9, 2012 at 4:22 PM, Francesco Rodriguez
lrodriguezs...@gmail.com wrote:
What about initialize_dup?
What about it?
-f
El jul 9, 2012 2:11 p.m., Nicolas Sanguinetti godf...@gmail.com
escribió:
dup doesn't take arguments because in ruby dup doesn't take arguments. It
wouldn't
(I posted this as a bug in GitHub
(https://github.com/rails/rails/issues/7018), but then someone there told
me I should post it here, so here it is.)
If you set attr_accessible on some properties in an ActiveRecord-descended
class, and then attr_protected on others - the class becomes
I personally think we should deprecate attr_protected, and go with
whitelisting only (attr_accessible + strong_parameters) route. I think
it make more sense from the security standpoint, and all the exploit
we have seen.
Core teams, wdyt?
- Prem
--
You received this message because you are
Just a guy with an opinion weighing in... I would love to see
attr_protected removed. The official Rails Guide on
securityhttp://guides.rubyonrails.org/security.html#countermeasures calls
attr_accessible A much better way, and I don't think Michael Hartl's
popular Ruby on Rails Tutorial
For the record: I don't mention attr_protected at all in Rails 3 in Action
either.
+1 to removing attr_protected.
On Tuesday, 10 July 2012 at 11:57 AM, Peter Brown wrote:
Just a guy with an opinion weighing in... I would love to see attr_protected
removed. The official Rails Guide on
30 matches
Mail list logo
