Robert Walker wrote: > Marnen Laibow-Koser wrote: >> Or Cocoa is poorly designed in this regard. (And Obj-C is such a weird >> language that it wouldn't entirely surprise me if there was in fact a >> language reason for this decision.) > > So you're saying here that Cocoa MUST be poorly designed, and Obc-C is > weird, because you don't understand it?
No, that's absolutely *not* what I meant; sorry if I was unclear. I meant this: * You seemed to be saying that we should use this pattern because Cocoa does. My respose was that yes, that's possible, but it's also possible that Cocoa made a mistake. I make no judgement on which is the case; I merely wanted to point out the other possibility. As far as Obj-C being weird, well...I think it is. That doesn't mean I dislike it; in fact, I think it's kind of neat. But a C-Smalltalk hybrid is like garlic-flavored ice cream: even if you like the way it tastes, it's still conceptually odd. :) > How about let's leave the code > bigotry out of the discussion. Happy to. No code bigotry was meant on my part at all. > >>> What does make a difference is that Cocoa is a desktop >>> application framework >> >> Perhaps. The complexity of the formatting might also make a difference >> -- I wouldn't want to put a whole Rails partial into a to_s in most >> cases! >> >>> with a more extensive use of the MVC pattern than >>> does Rails. >> >> My impression from the little bit I've played with Cocoa is that it has >> a very *different* way of using the MVC pattern than does Rails. > > Yes, I agree. Cocoa implements the "original" MVC design pattern (with > some variations). Yes, that was my impression. Rails' MVC is a bit idiosyncratic. > MVC actually does predate the web itself after all. > I know. And Reenskaug-style MVC is probably not that well suited to the Web without some modifications (I've just been reading a bunch of stuff on Ward's Wiki about this, in fact). >>>> Yes. And it may be that your approach has some benefits that I haven't >>>> thought of... >>>> Best, >>> >>> There is a very fine line between model and view responsibility in the >>> case of numbers and dates. I agree that it's good for model object to >>> know how to present themselves to the view, but in the case of numbers >>> and dates there can be some benefit in factoring out that responsibility >>> to view helper classes (i.e. NSNumberFormatter & NSDateFormatter). >> >> What is that benefit? Making it easier to adapt to the user's >> preferences? > > If you consider separation of responsibility a benefit, then the > formatter pattern has the same benefit as the MVC design pattern. > Formatters can be attached to other view objects, such as text fields or > any other view object responsible for displaying, validating and > interpreting data. This attachment can then be implemented and managed > completely within the view layer isolating the responsibility from the > model and controller layers. Perhaps. I'll have to think about this some more. This looks like about the same thing as the Presenter pattern that Jay Fields has written about, and frankly, I'm suspicious of it. It looks like needless complexity and/or too much logic in the view layer. Or are you saying that one could potentially use the same Formatter/Presenter for two completely different underlying models? That could certainly be an advantage of introducing the extra layer. Best, -- Marnen Laibow-Koser http://www.marnen.org [email protected] -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" 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-talk?hl=en -~----------~----~----~----~------~----~------~--~---
