session variable and model code
michalyad
My new application is language dependent, according to user's choice.
I set the current language in the application controller and I would
like that certain accessors in my model will transparantly recognize
the current language and will get the relevant content.
I have tried to put the current language in a global variable i.e.
$current_language. That is working fine for the model. I.e. my model
code recognizes this variable. however global variable changes the
current on a server level and not on a session level.
I have tried session[:language], but the model does not know this
variable.
I have tried @current_language, but the model thinks its null.
so how can I set a value in the application controller, so that any of
my models will recognize the variable?
Elad Meidar
Elad Meidar, Nautilus6
http://blog.eizesus.com
http://twitter.com/eladmeidar
> --
> You received this message because you are subscribed to the Google
> Groups "Israel.rb - the Israel Ruby & Israel Rails Developers group"
> group.
> To post to this group, send email to isra...@googlegroups.com.
> To unsubscribe from this group, send email to israelrb+u...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/israelrb?hl=en
> .
>
Michal Yad-Shalom
Michal Yad Shalom
054-4315617
Michal Yad-Shalom
Dor Kalev
Michal Yad-Shalom
labria
- Did you see the Avatar movie?
- Yeah, the book is better.
- Which book?
- ANY book!
=)
> which guide?
>
>
>
>
>
> On Mon, Jun 14, 2010 at 7:05 PM, Elad Meidar <eize....@gmail.com> wrote:
> > I would read about model translations, it's in the guide on
> > guides.rubyonrails.org
>
> > Elad Meidar, Nautilus6
> >http://blog.eizesus.com
> >http://twitter.com/eladmeidar
>
>
> > Hi,
> >> My new application is language dependent, according to user's choice.
> >> I set the current language in the application controller and I would
> >> like that certain accessors in my model will transparantly recognize
> >> the current language and will get the relevant content.
>
> >> I have tried to put the current language in a global variable i.e.
> >> $current_language. That is working fine for the model. I.e. my model
> >> code recognizes this variable. however global variable changes the
> >> current on a server level and not on a session level.
>
> >> I have tried session[:language], but the model does not know this
> >> variable.
>
> >> I have tried @current_language, but the model thinks its null.
>
> >> so how can I set a value in the application controller, so that any of
> >> my models will recognize the variable?
>
> >> -- You received this message because you are subscribed to the Google
> >> Groups "Israel.rb - the Israel Ruby & Israel Rails Developers group" group.
> >> To post to this group, send email to isra...@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> .
> >>http://groups.google.com/group/israelrb?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Israel.rb - the Israel Ruby & Israel Rails Developers group" group.
> > To post to this group, send email to isra...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > .
Dor Kalev
Michal Yad-Shalom
Vitaly Kushner
Well, Elad was right to send you to guides.rubyonrails.org
=== lets start with "What?":
When translating a web application you have mostly 2 things to
translate:
1) application ui
2) application content.
There are lot of applications that only translate (1). Its enough in
many cases.
For that you use Rails I18n API (described in the guide).
translating (2) is trickier and generally depends on the application.
From your question I suppose you already have
some means to do it, like having separate content fields in db per
locale or whatever.
So you basically only need a way to set and check the current locale
in any place of the application.
=== So we are getting to "How?":
You don't do global variables, but you do a functionally equivalent
thing (except that it works right with multiple threads and the like)
I18n.locale = "he"
# from now on, I18n.locale will return "he" anywhere within the same
thread.
You usually set it in some before_filter.
=== conclusion
you didn't read the guide too carefully, RTFM now please ;)
http://guides.rubyonrails.org/i18n.html
Cheers,
/V
P.S. BTW, if you still need a way to access the current controller/
request from model context which is handy sometimes you can use our
plugin: http://github.com/astrails/let_my_controller_go
--
Vitaly Kushner
http://twitter.com/vkushner
Founder, Astrails Ltd. http://astrails.com/
Check out our blog: http://blog.astrails.com/
Dor Kalev
--
Michal Yad-Shalom
--
You received this message because you are subscribed to the Google Groups "Israel.rb - the Israel Ruby & Israel Rails Developers group" group.
To post to this group, send email to isra...@googlegroups.com.
To unsubscribe from this group, send email to israelrb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/israelrb?hl=en.
Dor Kalev
Elad Meidar
accessing the controller/request in a model is totally, absolutely
wrong.
breaking MVC is never *ever* required and in the past 190~ rails
project I had anything to do with, it wasn't even considered ;)
I am more than willing to hear a test case.
Elad Meidar, Nautilus6
http://blog.eizesus.com
http://twitter.com/eladmeidar
Elad Meidar
Dor Kalev
Vitaly Kushner
> MVC is a great framework! Elad, I think what you are really looking for is a
> religion ;-)
> On Tue, Jun 15, 2010 at 12:02 AM, Elad Meidar <eize...@gmail.com> wrote:
>>
>> I just vomited a little bit in my mouth ;)
Indeed dogma is never right. You always have exceptions. An
inexperienced craftsman is better be following the strictest rules for
the purpose of not hurting himself. But with time you acquire enough
knowledge to see beyond the rules and dogmas and to bend the rules
when needed in a careful and elegant way.
Several use-cases I had (all so far required url helpers in the model).
==== 1
* existing rails site. clean code. restful and a lot of
inherited_resources use.
* requirement: add an .xml api with minimal effort
* some xml responses need to include urls of other xml resources (this
is required by the *proper* rest api)
i.e. resource /users.xml doesn't just list user ids, but as is
required by the properly designed rest it includes direct urls to user
resources.
the most natural way to implement something like this in Rails is to
just use model.to_xml or collection.to_xml. the only thing that needs
to be
done then is to override as_json funciton in the models where you
don't want to expose the whole internal structure or need special
handling (like the urls)
problem: you can't construct urls in the model.
simplest possible solution: give models access to controller's url helpers.
And don't bring me this 'you break MVC' bullshit, because it is just
that : bullshit ;)
by your logic I18n breaks MVC too because it saves current locale in a
global variable.
the thing is, some stuff in the 'current request context' can be
required all over the place. one example is current_locale, another is
current_anything_that_knows_to_construct_urs_using_the_right_host_and_port_and_routes.
in case of I18n they had a clear place to stick their global into as
they had a separate module for it. but it still breaks the frigging
MVC.
in our case I couldn't care less for the purity of MVC and exposing
the current_controller for the purpose of
current_controller.user_path(user) was the right thing to do.
==== 2
There is another use case. I had it on one of our first projects and
at the time it was solved by some other hack I don't even remember
now, but if I were to implement it today I would definitely use
current_controller.
We needed to implement db backed html widgets. there were several
kinds and they were implemented with single-table-inheritance over a
single table.
Again, from the usage pattern of it it made a lot of sense to just
have widget.to_html. This use case is arguably less demanding to break
the MVC since there *is* a fairly easy workaround (pass current view.
i.e. you'd do <%= @widget.to_html(self) %> in your views, but it also
looks and feels quite kludgy
You can read my old blog post about it
http://blog.astrails.com/2009/10/27/liberate-my-controller
Elad Meidar
there's a reason MVC was consulidated.. the fact that you can go through that many projects without even scratching it should stand for itself.
but hi, everyone can do whatever they want with their code, i am doing my bitching when i am hired to make it finally work
--
Elad Meidar, CEO, Nautilus6
+954-805-0504 | http://www.nautilus6.com | @nautilus6
Elad Meidar
2. screw it, i added my comments on your mail body.
--
Elad Meidar, CEO, Nautilus6
+954-805-0504 | http://www.nautilus6.com | @nautilus6
you can call it whatever you want, but there's a standard which is not so hard to play along with, sorry if you find that hard :)
> by your logic I18n breaks MVC too because it saves current locale in a
> global variable.
>
nope, i18n is *above* MVC in my imaginary stack, since it's something that clearly applies on top of each and every segment.
> the thing is, some stuff in the 'current request context' can be
> required all over the place. one example is current_locale, another is
> current_anything_that_knows_to_construct_urs_using_the_right_host_and_port_and_routes.
> in case of I18n they had a clear place to stick their global into as
> they had a separate module for it. but it still breaks the frigging
> MVC.
>
it has a separate module.
> in our case I couldn't care less for the purity of MVC and exposing
> the current_controller for the purpose of
> current_controller.user_path(user) was the right thing to do.
which would be retarded and a huge overkill to have it just to respond to a VERY specific, godknowswhereitcamefrom API.
>
> ==== 2
> There is another use case. I had it on one of our first projects and
> at the time it was solved by some other hack I don't even remember
> now, but if I were to implement it today I would definitely use
> current_controller.
> We needed to implement db backed html widgets. there were several
> kinds and they were implemented with single-table-inheritance over a
> single table.
> Again, from the usage pattern of it it made a lot of sense to just
> have widget.to_html. This use case is arguably less demanding to break
> the MVC since there *is* a fairly easy workaround (pass current view.
> i.e. you'd do <%= @widget.to_html(self) %> in your views, but it also
> looks and feels quite kludgy
>
let me just say this. it all starts with the design... and if you put the wrong brick at the bottom, you whole wall sucks :)
>
> You can read my old blog post about it
> http://blog.astrails.com/2009/10/27/liberate-my-controller
>
read it before, wanted to eat your head.
call me religious or whatever, it all doesn't matter when there's a set of tools with clear instructions and usage notes. i am not the kind of developer that will rape something into submission until if fits my need (i imagine a little kid trying to stick a round piece of plastic into a square hole) i will investigate, design and eventually choose the best tool for my task.. if it doesn't fit 100% i'll make the minor adjustments as long as it's not "rape" as i was mentioning before.
if all else fails, i'll build my own based on my knowledge and need of standards, conventions and guidelines.
> --
> Vitaly Kushner
> http://twitter.com/vkushner
> Founder, Astrails Ltd. http://astrails.com/
> Check out our blog: http://blog.astrails.com/
>
Vitaly Kushner
> 1. As you indicate, some of your problem exists due to the fact the actual API you are working with is retarded. what i would do is add a private action in the controller (?) that responds/sends to the API that will simply generate @model.to_json(:url1 => whatever_url, :url2 => .......). yes, it's ugly as well. no pretty solution here but i don't see the real benefit of adding it to the model. in a perfect world it could be the ultimate solution but since it's already a weird API request i guess everything goes.
The API is not retarded. You just don't understand REST. What you call
REST is actually XML-RPC.
Go and read the REST original definition. You are SUPPOSED to provide
full urls to resources. In a *proper* REST API client should never do
any url mangling, like receiving user_id 123 and then knowing to go to
http://whateverdomain/users/123. API is supposed to supply such links
in the response. for example in a response to /users.xml.
RTFM before you start bitching about retarded APIs that I design ;)
http://www.w3.org/Protocols/rfc2616/rfc2616.html
If you are too lazy to read the whole loooooooooong thing (I know I am
;), here are some short points about what you are doing wrong about
REST: http://www.theamazingrando.com/blog/?p=107 ;)
>
>
> 2. screw it, i added my comments on your mail body.
good. thats the way I prefer it (shhhhhhts. don't tell Shlomi, or
he'll kill me with his big netiquette book ;)
standard-shmandard. I'm not religious about *anything*, and I consider
myself smart enough to make a decision where to follow whatever
standard there is, and where to make my own thing.
I *could* follow the standard and implement all the xml generation in
controller and views with xml builder templates which would be at
least 10 times more code to write. What is the point? To make you fill
safe? ;)
And model.to_xml is there for a reason. it is *extremely* useful. In
my case it was a 99.9% fit to the problem with a single problem, I
needed to know current domain of the request to properly construct the
urls.
>
>> by your logic I18n breaks MVC too because it saves current locale in a
>> global variable.
>>
>
> nope, i18n is *above* MVC in my imaginary stack, since it's something that clearly applies on top of each and every segment.
Bullshit. 'current_locale' is just a parameter of the current_request,
just like 'current_domain', or 'current_action' etc. To really follow
MVC you would have to pass current_locale from controller to all model
methods that would require it. Clearly this would be a very big hairy
mess. Thats why a shortcut was made and current_locale is stored in a
global variable. it is in a module and per-thread, blah blah blah, it
is still essentially a global variable. it is available from any
context.
Incidentally I needed the domain name for the request in the first
place because domain changed according to the locale. i.e. we had
domain.com, and it.domain.com, he.domain.com etc. I *could* hack my
own url creation using just I18n.locale and some constant base_domain,
but in my opinion that would be much much uglier and less elegant then
my solution with current_controller. and much more code and places for
potential bugs too.
>
>> the thing is, some stuff in the 'current request context' can be
>> required all over the place. one example is current_locale, another is
>> current_anything_that_knows_to_construct_urs_using_the_right_host_and_port_and_routes.
>> in case of I18n they had a clear place to stick their global into as
>> they had a separate module for it. but it still breaks the frigging
>> MVC.
>>
>
> it has a separate module.
So what? Whats the difference? It still a global variable accessible
from anywhere which holds a piece of information from a controller.
current_locale is much more pervasive then current_domain but they are
both just request state variables and not conceptually different.
if its OK to "globalize" current_locale then it *should* be OK to
globalize anything else given good enough reason is found. In my case
I did find it.
The way to "save" MVC in my case would be to start passing controller
to to_xml methods so that instead of doing
current_controller.user_path(..) models would do
controller.user_path(...) with controller being passed as an argument
of to_xml. this would be ugly as hell and I'd had to hack not only
model's to_xml but also Hash.to_xml and Array.to_xml to support
various places in the system. And what for? completely and utterly
pointless.
Saying otherwise is just MVC dogma bigotry.
>
>> in our case I couldn't care less for the purity of MVC and exposing
>> the current_controller for the purpose of
>> current_controller.user_path(user) was the right thing to do.
>
> which would be retarded and a huge overkill to have it just to respond to a VERY specific, godknowswhereitcamefrom API.
it is not VERY specific, it is just VERY RESTFUL ;)
>>
>> ==== 2
>> There is another use case. I had it on one of our first projects and
>> at the time it was solved by some other hack I don't even remember
>> now, but if I were to implement it today I would definitely use
>> current_controller.
>> We needed to implement db backed html widgets. there were several
>> kinds and they were implemented with single-table-inheritance over a
>> single table.
>> Again, from the usage pattern of it it made a lot of sense to just
>> have widget.to_html. This use case is arguably less demanding to break
>> the MVC since there *is* a fairly easy workaround (pass current view.
>> i.e. you'd do <%= @widget.to_html(self) %> in your views, but it also
>> looks and feels quite kludgy
>>
>
> let me just say this. it all starts with the design... and if you put the wrong brick at the bottom, you whole wall sucks :)
if your beautiful design requires me to write x10 times the code I say
fuck the purity in design and embrase the elegance of heresy.
Again, I don't care about standard, I only care about my code being as
clean and as short and as elegant as possible. *Any* solution you
propose would require me to write more code, uglier code, and most
probably buggier code. So why should I do such a stupid thing?
>
>>
>> You can read my old blog post about it
>> http://blog.astrails.com/2009/10/27/liberate-my-controller
>>
>
> read it before, wanted to eat your head.
>
> call me religious or whatever, it all doesn't matter when there's a set of tools with clear instructions and usage notes. i am not the kind of developer that will rape something into submission until if fits my need (i imagine a little kid trying to stick a round piece of plastic into a square hole) i will investigate, design and eventually choose the best tool for my task.. if it doesn't fit 100% i'll make the minor adjustments as long as it's not "rape" as i was mentioning before.
If you are afraid to cut yourself, then indeed, by all means, don't
play with sharp tools.
Adding 10-15 lines of carefully considered non-MVC-compliant code to
the application to save possibly hundreds of lines of
standard-compliant-ugly-mess is not a 'rape', its a 'elegant hack' in
my book.
>
> if all else fails, i'll build my own based on my knowledge and need of standards, conventions and guidelines.
MVC is just a concept, an abstraction. And like *any* other
abstraction without limitations it 'leaks' in edge cases. What you do
when it leaks, shut your eyes and keep banging your head into the
standard-compliant wall or open your eyes and see that there is a door
one step to the right is completely your decision. I've made mine ;)
Reuven M. Lerner
I'm going to side more with Elad in this discussion than Vitaly. Over
the years, I've definitely done my share of reaching across the MVC
divide, putting methods in the "wrong" place. And nearly every time
I've done so, I've regretted it -- either because it made the code
harder to read, or harder to test, or less modular.
I'm willing to be flexible (or un-dogmatic, if you prefer) when it comes
to controllers sometimes doing a bit of model-related stuff. But
putting controller-type logic in the view is something I try to avoid.
Putting controller-type or view-type logic in models strikes me as
something that there's almost no good reason to do. Vitaly's argument
doesn't totally convince me; while I'm sympathetic to wanting to have
various URLs produced by a model's .to_xml method, the moment that you
start to import helper methods into a model, the red lights should start
flashing.
As Elad wrote, the model shouldn't ever know about the HTTP request or
handle it; the power of MVC is in the decoupling of such things. There
have been some occasions on which I've used ActiveRecord outside of a
Web application -- yes, such software exists! -- and the fact that the
model neither knew nor cared about an HTTP request was obviously quite
helpful, and allowed me to reuse the code.
Vitaly, I looked at your blog post
(http://blog.astrails.com/2009/10/27/liberate-my-controller); perhaps
you didn't notice, but all of the people commenting on the post said
that they disagreed with you, and suggested alternatives. This doesn't
necessarily mean that you were wrong and they were right, but it should
give you pause before suggesting that this is a practice others should
follow.
Finally, I've been using metric_fu quite a bit to look over my code.
I've found that while I sometimes disagree with the points that it
makes, and find them to be extreme (e.g., the notion that no method
should be longer than six lines), it does help to push me to make my
code more elegant, readable, and testable. On a number of occasions,
I've rewritten things according to suggestions provided by Reek, for
example, trying to "prove" that my implementation was just fine -- and
lo and behold, when I started to change things to adhere to Reek's
suggestions, I've been surprised by the improvement that has emerged.
Reuven
Elad Meidar
--
Elad Meidar, CEO, Nautilus6
+954-805-0504 | http://www.nautilus6.com | @nautilus6
On Jun 15, 2010, at 3:52 AM, Vitaly Kushner wrote:
> On Tue, Jun 15, 2010 at 2:43 AM, Elad Meidar <eize...@gmail.com> wrote:
>> 1. As you indicate, some of your problem exists due to the fact the actual API you are working with is retarded. what i would do is add a private action in the controller (?) that responds/sends to the API that will simply generate @model.to_json(:url1 => whatever_url, :url2 => .......). yes, it's ugly as well. no pretty solution here but i don't see the real benefit of adding it to the model. in a perfect world it could be the ultimate solution but since it's already a weird API request i guess everything goes.
>
> The API is not retarded. You just don't understand REST. What you call
> REST is actually XML-RPC.
> Go and read the REST original definition. You are SUPPOSED to provide
> full urls to resources. In a *proper* REST API client should never do
> any url mangling, like receiving user_id 123 and then knowing to go to
> http://whateverdomain/users/123. API is supposed to supply such links
> in the response. for example in a response to /users.xml.
> RTFM before you start bitching about retarded APIs that I design ;)
I said, maybe the need i there, but the design sucks.. regardless of the demands. generate the freaking XML as a view (as it SHOULD be) and stop tying your shoelaces to your earrings :)
> http://www.w3.org/Protocols/rfc2616/rfc2616.html
OH ffs, realy? :)
Yeah, until i'll have to fix it :)
> And model.to_xml is there for a reason. it is *extremely* useful. In
> my case it was a 99.9% fit to the problem with a single problem, I
> needed to know current domain of the request to properly construct the
> urls.
yes "useful". but you think that if you have a hammer it will solve all your problems... newsflash: not every problem is a nail.
>
>>
>>> by your logic I18n breaks MVC too because it saves current locale in a
>>> global variable.
>>>
>>
>> nope, i18n is *above* MVC in my imaginary stack, since it's something that clearly applies on top of each and every segment.
>
> Bullshit. 'current_locale' is just a parameter of the current_request,
> just like 'current_domain', or 'current_action' etc. To really follow
> MVC you would have to pass current_locale from controller to all model
> methods that would require it. Clearly this would be a very big hairy
> mess. Thats why a shortcut was made and current_locale is stored in a
> global variable. it is in a module and per-thread, blah blah blah, it
> is still essentially a global variable. it is available from any
> context.
>
> Incidentally I needed the domain name for the request in the first
> place because domain changed according to the locale. i.e. we had
> domain.com, and it.domain.com, he.domain.com etc. I *could* hack my
> own url creation using just I18n.locale and some constant base_domain,
<whisper>:host parameter</whisper>
> but in my opinion that would be much much uglier and less elegant then
> my solution with current_controller. and much more code and places for
> potential bugs too.
pfft, potential bugs.. if i had to maintain something like you suggest, i'd probably skip the project. (now i know i can transfer it to you :) ).
seriously now, it's a matter of approach. "Bullshit" and stuff like that do not hold bad when you try to explain your positing.. unless of course, you are a 4yo girl.
do whatever you want, i've seen way too many people doing what you need and it's common to people in israel to think they are better from algos and methods that were sketched for years by people that have a *little* more idea about what they are doing... well, good luck to those people.
do whatever you'd like, i'm not judging :)
no, let's tie up everything together and dance around it!
>
> Again, I don't care about standard, I only care about my code being as
> clean and as short and as elegant as possible. *Any* solution you
> propose would require me to write more code, uglier code, and most
> probably buggier code. So why should I do such a stupid thing?
"ugly" is an opinion, "wrong" is a fact.
>
>>
>>>
>>> You can read my old blog post about it
>>> http://blog.astrails.com/2009/10/27/liberate-my-controller
>>>
>>
>> read it before, wanted to eat your head.
>>
>> call me religious or whatever, it all doesn't matter when there's a set of tools with clear instructions and usage notes. i am not the kind of developer that will rape something into submission until if fits my need (i imagine a little kid trying to stick a round piece of plastic into a square hole) i will investigate, design and eventually choose the best tool for my task.. if it doesn't fit 100% i'll make the minor adjustments as long as it's not "rape" as i was mentioning before.
>
> If you are afraid to cut yourself, then indeed, by all means, don't
> play with sharp tools.
indeed, masochism is not for me. but by all means - enjoy,.
> Adding 10-15 lines of carefully considered non-MVC-compliant code to
> the application to save possibly hundreds of lines of
> standard-compliant-ugly-mess is not a 'rape', its a 'elegant hack' in
> my book.
>
>>
>> if all else fails, i'll build my own based on my knowledge and need of standards, conventions and guidelines.
>
> MVC is just a concept, an abstraction. And like *any* other
> abstraction without limitations it 'leaks' in edge cases. What you do
> when it leaks, shut your eyes and keep banging your head into the
> standard-compliant wall or open your eyes and see that there is a door
> one step to the right is completely your decision. I've made mine ;)
and i'm glad you've made it. on the long term it works the best for me too.
Vitaly Kushner
>
>
> --
> Elad Meidar, CEO, Nautilus6
> +954-805-0504 | http://www.nautilus6.com | @nautilus6
>
> On Jun 15, 2010, at 3:52 AM, Vitaly Kushner wrote:
>
>> On Tue, Jun 15, 2010 at 2:43 AM, Elad Meidar <eize...@gmail.com> wrote:
>>> 1. As you indicate, some of your problem exists due to the fact the actual API you are working with is retarded. what i would do is add a private action in the controller (?) that responds/sends to the API that will simply generate @model.to_json(:url1 => whatever_url, :url2 => .......). yes, it's ugly as well. no pretty solution here but i don't see the real benefit of adding it to the model. in a perfect world it could be the ultimate solution but since it's already a weird API request i guess everything goes.
>>
>> The API is not retarded. You just don't understand REST. What you call
>> REST is actually XML-RPC.
>> Go and read the REST original definition. You are SUPPOSED to provide
>> full urls to resources. In a *proper* REST API client should never do
>> any url mangling, like receiving user_id 123 and then knowing to go to
>> http://whateverdomain/users/123. API is supposed to supply such links
>> in the response. for example in a response to /users.xml.
>> RTFM before you start bitching about retarded APIs that I design ;)
>
> I said, maybe the need i there, but the design sucks.. regardless of the demands. generate the freaking XML as a view (as it SHOULD be) and stop tying your shoelaces to your earrings :)
should? said who? the "the only true mvc design pattern given to us by
god on some frigging programmer's mountain?"
Again, I know pretty well HOW to solve this problem while staying in
the realm of mvc. there are basically 2 ways:
a) instead of doing to_xml implement all views rendering with builder
templates. -> LOTS of extra files, extra code and extra bugs.
b) pass 'controller' to all models as a pseudo-opaq 'link_builder'
parameter and use that for link creation. this is just a hack but
would pass the MVC purity test. this solution is also much more
verbose and typing intense then my. but except for the added boiler
plate code and hacks into core to_xml implementation the actual
application code will look EXACTLY the same. just using passed
parameter instead of current_controller method.
BOTH those methods are much uglier and verbose. very un-ruby like. I
see a clear shortcut, which has NO downsides WHATSOEVER except for the
offending the purity sense of the dogma prophets.
Doing more verbose and harder to understand code for the sole benefit
of 'not breaking the frigging pattern' is just stupid.
>
>> http://www.w3.org/Protocols/rfc2616/rfc2616.html
>
> OH ffs, realy? :)
yes, really. Whatever you were calling rest wasn't. just using more
then get/post is not enough. what is your problem with this rfc btw?
This is at the core of what we do. And unfortunately for years 99.9%
of so called web developers ignored a lot of what is there from the
beginning and invented their own square wheels.
You making this comment 2nd time around. Let me tell you, the chance
of you getting to fix my 'mess' in any of my recent projects are very
very slim to say the least ;)
and I don't think any of the uglier 'first timers' will every get to
you as well.
is it? ;) the 'wrong' here is as opinionated as the 'ugly', you are
blind if you are denying that.
>
>>
>>>
>>>>
>>>> You can read my old blog post about it
>>>> http://blog.astrails.com/2009/10/27/liberate-my-controller
>>>>
>>>
>>> read it before, wanted to eat your head.
>>>
>>> call me religious or whatever, it all doesn't matter when there's a set of tools with clear instructions and usage notes. i am not the kind of developer that will rape something into submission until if fits my need (i imagine a little kid trying to stick a round piece of plastic into a square hole) i will investigate, design and eventually choose the best tool for my task.. if it doesn't fit 100% i'll make the minor adjustments as long as it's not "rape" as i was mentioning before.
>>
>> If you are afraid to cut yourself, then indeed, by all means, don't
>> play with sharp tools.
>
> indeed, masochism is not for me. but by all means - enjoy,.
>
>> Adding 10-15 lines of carefully considered non-MVC-compliant code to
>> the application to save possibly hundreds of lines of
>> standard-compliant-ugly-mess is not a 'rape', its a 'elegant hack' in
>> my book.
>
>>
>>>
>>> if all else fails, i'll build my own based on my knowledge and need of standards, conventions and guidelines.
>>
>> MVC is just a concept, an abstraction. And like *any* other
>> abstraction without limitations it 'leaks' in edge cases. What you do
>> when it leaks, shut your eyes and keep banging your head into the
>> standard-compliant wall or open your eyes and see that there is a door
>> one step to the right is completely your decision. I've made mine ;)
>
> and i'm glad you've made it. on the long term it works the best for me too.
not too sure what you re implying here. if you imply what I think you
do, I think I'll ignore that. for now ;)
Elad Meidar
--
Elad Meidar, CEO, Nautilus6
+954-805-0504 | http://www.nautilus6.com | @nautilus6
Vitaly Kushner
I did notice the comments. Interestingly the 2 posts on our blog that
produces the biggest number of comments were the 2 posts I'd never
expect to do it. this one and the other one is
http://blog.astrails.com/2009/5/12/ruby-http-require.
In both cases I just released a very simple, just a couple of lines of
code plugins that were created along the way for some side purpose and
were just thrown on the github "just in case" anyone needs them for
whatever reason.
In both cases it got a lot of very negative comments and while the
exact reasons for both are very different I think the underlying cause
is quite similar. Both plugins touched some sacred caws for certain
people and the arguments for the change were completely ignored by the
dogma. the http_require case is waiting for a long post about everyday
security blindness I'm going to write one day. but for this anti-MVC
thing....
OK, lets try to see how not breaking MVC it will produce a better code
by some realistic metric. and 'it doesn't break MVC' is not a metric.
MVC is just a tool and the reason for its existence is that it
facilitates other 'real virtues' like maintainability, concept
separation (again proxy from maintainability), testability (again,
just a proxy), yada yada yada.
I created a test project on github http://github.com/vitaly/mvcchallenge
Its just a stupid Rails application that was thrown together in a
hurry so please don't bring the 'oh, it doesn't check x, or it doesn't
do y kinds of comments'.
For the purpose of this problem we are only interested in users#index,
users#show, ideas#index and ideas#show. All the rest is just to let
you create db records easily through the web.
As I said the app is a hack and it doesn't do near enough checks, it
uses clear text passwords and the security model is broken (I'd do it
somewhat differently in the real app) and it lacks lots of html
templates (edit *anything* for example), but it
represents a fairly typical inherited_resource restfulish rails application.
Now the challenge. Please fork it and do the followin 3 steps:
== step1
add a .json api to it so that it will answer /users.json
/users/:id.json /ideas.json /ideas/:id.json /users/:id/ideas.json and
/users/:id/ideas/:id.json
if you do it "right" it requires very VERY little code :)
additional requirements:
* ignore auth.
* users should not reveal passwords through the api
* users should include idea_ids array in its data
* ideas should include full data for comments and ratings
* try hard to ignore step 2 when doing this ;)
== step2
add direct uris to each resource. instead of idea_ids in user.json
include ideas array with hrefs to the idea resources.
make idea point to user's href instead of user_id. consider that
comments and ratings might need to be accessed separately too, so be
prepared to have them with a resource too.
Note: this is a simple example with just 4 models, a real world
example wold involve much more models, controllers and associations,
so when evaluating the cost of your solution consider a much bigger
codebase (importantly: with a big and quite complicated routing
table).
== step 3
now tell me if you'd do it differently if you knew step 2 is coming
from the start. if so, how differently, and why?
Note: though this example is obviously contrived it is not that far
from a realistic production need in a real life project (in fact this
is exactly what we needed on one of ours)
less talk, more code! fork it on github ;)
Michael Mazyar (astrails.com)
one that worked on this "mvc heresy" with Vitaly.
As Vitaly already pointed, MVC is just one of the many many
abstractions we use to make our craft a bit easier.
And as with ALL abstractions in the world, it's never meant to be
perfect, it was not given to us on mount Sinai.
And while each specific case where someone felt it needs to be
"bended" is debatable, i totally disagree to the notion of "it's MVC
=> it's perfect => never ever brake it".
By programming ruby we already break enormous amount of design
patterns, best practices and abstractions in other languages. Try talk
monkey patching to even python programmers, let alone java and .net
guys. And yet we use monkey patching to our code benefit many times a
day. Feels right? For shizzle.
So why do you refuse to apply same logic with MVC? It's some how
different from other abstractions? No, it's not.
I see it as totally double standards.
We all shout "monkey patching is dangerous, sure, but it makes me
powerful far beyond your java little safe whathaveyou's. And i love
it!" and in the next sentence "you will code visual basic for the rest
of your life for messing with my MVC"
And again, we can argue a lot about whether it was right to break it
in this or that specific case. But for me it's not arguable that the
minute you say "never ever do <some heresy>" you closed a possible,
even remotely, better path for elegant solution in some specific edge
cases.
If you have a really good understanding of some abstraction and
reasons behind it and still think you have a better solution that it's
imposing on you, you thought it through, than by all means, just do
it. And if you not as smart a programmer as you think you are it will
bite you. Or not.
But!
No to dogmatism, whatever the issue is :)
P.S. In the specific case Vitaly presented with to_xml, i think it was
totally right, i'm doing it in my projects as we speak.
> code plugins that were created along the way for some side purpose and
> were just thrown on the github "just in case" anyone needs them for
> whatever reason.
> In both cases it got a lot of very negative comments and while the
> exact reasons for both are very different I think the underlying cause
> is quite similar. Both plugins touched some sacred caws for certain
> people and the arguments for the change were completely ignored by the
> dogma. the http_require case is waiting for a long post about everyday
> security blindness I'm going to write one day. but for this anti-MVC
> thing....
>
> OK, lets try to see how not breaking MVC it will produce a better code
> by some realistic metric. and 'it doesn't break MVC' is not a metric.
> MVC is just a tool and the reason for its existence is that it
> facilitates other 'real virtues' like maintainability, concept
> separation (again proxy from maintainability), testability (again,
> just a proxy), yada yada yada.
>
Vitaly Kushner
to show.
Anyway, I think the following quote is very much relevant here:
If you’re about to take a hundred lines to write what you could in
ten, stop and ask yourself this: what the fuck?
– Mark, Criminal Overengineering
(http://coderoom.wordpress.com/2010/06/23/criminal-overengineering/)
Cheers, and happy overengineering.
> code plugins that were created along the way for some side purpose and
> were just thrown on the github "just in case" anyone needs them for
> whatever reason.
> In both cases it got a lot of very negative comments and while the
> exact reasons for both are very different I think the underlying cause
> is quite similar. Both plugins touched some sacred caws for certain
> people and the arguments for the change were completely ignored by the
> dogma. the http_require case is waiting for a long post about everyday
> security blindness I'm going to write one day. but for this anti-MVC
> thing....
>
> OK, lets try to see how not breaking MVC it will produce a better code
> by some realistic metric. and 'it doesn't break MVC' is not a metric.
> MVC is just a tool and the reason for its existence is that it
> facilitates other 'real virtues' like maintainability, concept
> separation (again proxy from maintainability), testability (again,
> just a proxy), yada yada yada.
>
Elad Meidar
i am very happy for you that you have the time to code an app to prove a point that will never be determined, i don't.
code your way, and i'll code mine... no app will convince me that you are right and i can safly say that no matter what i do, you won't change yours so there's no point to carry on this bikeshedding thread.
all i can say, "if it works for you, good luck" - sorry i don't have a fancy link to back that up ;)
--
You received this message because you are subscribed to the Google Groups "Israel.rb - the Israel Ruby & Israel Rails Developers group" group.
To post to this group, send email to isra...@googlegroups.com.
To unsubscribe from this group, send email to israelrb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/israelrb?hl=en.
Dor Kalev
Vitaly Kushner
On Jun 24, 1:08 am, Elad Meidar <eize....@gmail.com> wrote:
> Let me just make it clear,
>
> i am very happy for you that you have the time to code an app to prove a
> point that will never be determined, i don't.
But you aren't alone here, so I hoped for may be someone else will
enlighten me.
> code your way, and i'll code mine... no app will convince me that you are right
> and i can safly say that no matter what i do, you won't change yours
someone to come along and teach me the 'right' way to do it ;)
> so there's no point to carry on this bikeshedding thread.
minor unimportant point like border color of some button. We actually
discuss a very basic and fundamental thing - whether you should treat
'patterns' and 'principles' as something set in stone as if given to
us at the mt. Sinai or we should exercise our jugement for if and when
those principles can be bent or broken.
>
> all i can say, "if it works for you, good luck" - sorry i don't have a fancy
> link to back that up ;)
I'm too very much overworked right now, but I'll try to find some more
time and clean the app I provided some more and then I'll just post it
on HN.
> > .
Elad Meidar
Expected or not, i really don't care less about how you code, think or play with your little toy... my way works for me and your claim that it "produces more bugs" is practically invalid.
Not in the mood or anxiety to play games really, so let's shut this one down.. you can keep it up on HN as you say
To unsubscribe from this group, send email to israelrb+u...@googlegroups.com.
--
Elad Meidar,