Of course it's an Opt-in, but once you decide that this association
should use the NilUserClass, all of the application will be affected.
The code i showed is not done in the View but in other models, in
controllers or anywhere else. For example I have a serializer that takes
the Post record, it will ask for the association, will get an object and
try to serialize it which is NOT what I want because the association
should have lead to nil.
Once again, the problem here is that (even with opt-in) it affects the
whole application (plugins, engines, etc...) and you still want to fix a
view problem.
Regards,
Le 09.09.12 12:07, Kensodev a écrit :
@Pascal.
This is a complete Opt-In proposition, if you will not have the nil
class present, it will not try to load it.
The code in your sample is EXACTLY the kind of code that I want to
avoid with this feature, you should "Tell" object and not "ask" objects.
It will not break any existing code as long as you don't opt into the
nil class.
On Saturday, September 8, 2012 10:18:17 PM UTC+3, Pascal Hurni wrote:
I understand the need behind your proposition but you want to
insert some behaviour for the view in the model.
This breaks the MVC separation.
I do a lot of the following:
if some_model.user
...
end
to check the presence of the association. Your proposition will
break this idiom which is IMHO heavily used in code.
Regards,
Pascal
Le 08.09.12 20:57, Kensodev a écrit :
This kind of response is precisely why I came here first and
didn't just invest the time and opened a pull request.
IMHO this should be supported in the frame work, and I will be
more then happy to work on it if you guys think it should go in.
I know Ruby can be used to override the relation.
I actually had a plan that the loading of the "Nil class" will be
automatically based on the relation name, but you can override it
with the :nil_class definition.
Anyway, let me know if you think it's viable.
On Friday, September 7, 2012 9:42:29 PM UTC+3, Aaron Patterson
wrote:
On Fri, Sep 07, 2012 at 02:57:25PM -0300, Carlos Antonio da
Silva wrote:
> I believe you should be able to achieve the same just by
overriding the
> #user method in your class. I've commented on your last
gist example with
> an example code to make things more clear.
Agreed. We don't need any framework support for the null object
pattern. Just use Ruby.
--
Aaron Patterson
http://tenderlovemaking.com/
--
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
https://groups.google.com/d/msg/rubyonrails-core/-/P9-vM1sUesMJ
<https://groups.google.com/d/msg/rubyonrails-core/-/P9-vM1sUesMJ>.
To post to this group, send email to [email protected]
<javascript:>.
To unsubscribe from this group, send email to
[email protected] <javascript:>.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
<http://groups.google.com/group/rubyonrails-core?hl=en>.
--
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
https://groups.google.com/d/msg/rubyonrails-core/-/4z6FB0nouM0J.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
--
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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
