On Feb 14, 2007, at 8:58 AM, Rosie F. wrote:
> > psychic, I don't think you're really understanding my problem/ > question. > >> If the data was corrected by the controller (via a component or >> whatever) before it hit the view, you'd have to do nothing to the >> HtmlHelper. > > That's what I'm doing. I'm correcting the data at the controller. I > don't want to change the HTML Helper. I want to use it at the > controller level for a few things. Is there a drawback to creating some shared logic that fixes URLs? Such an approach doesn't make changes to data in a presentational way. > Where we disagree is what is considered data manipulation and what is > considered presentation. In my case, in the course of manipulating > data, where the data is of a presentational nature, I need some tools > that will allow me to construct HTML tags with proper paths at any > level of my app. I'm not *outputting* the tags at that point. I'm > simply manipulating them. I don't think it really matters when you're outputting the data. I would also say that all data is going to presented at one point or another, regardless if it is stored as HTML or binary data. The less the controller has to do with changing data in a presentational way (HTML is a presentational), the better off you're going to be down the road. > I 100% do not agree that handling HTML at the controller level > violates the spirit of MVC. I agree with you. Where we disagree is the line between model manipulation (done by a controller) and data presentation (done by the view). Creating HTML links in the controller seems to me like you're formatting data for presentation to a browser. If you're just adjusting URL paths, that would seem to be more like data manipulation to me. > If data stored in database = HTML, then > tools for manipulating data = tools for manipulating HTML. Why is it > so hard to grasp that HTML is not only present in the views? That > some people store it in the database and need to validate it or verify > it at the controller or model level? Having an HTML helper that functions in the controller isn't manipulating HTML, it's creating it. >> If you're coding presentational information in at every level of the >> application, there is no need for the MVC separation at all. The >> drawbacks from doing this kind of coding are well documented. >> > > First you tell me that MVC is a well documented reliable way of > architecting with many benefits. Now you tell me that using MVC to > create an application that handles a lot of "presentational" > information isn't the right way to go. That's not what I said. If you're coding in logic that has to do with data presentation at every level of the application, then there's really no benefit to the MVC design. > Well, the responses here have been irksome and not helpful. Through > my own research I found this, in case anyone else needs it: http:// > rossoft.wordpress.com/2006/02/11/cool-flash-effect-3/ My apologies if you viewed my responses as offensive. I didn't mean to attack you personally. I do however disagree with this approach, however irksome that may sound. @Chris: "If you want to contribute some code that creates this functionality, many MANY developers would be grateful (me included). I could argue endlessly about MVC and why manipulating HTML in the [controller] is a bad thing, but that's a waste of time for all parties involved." I think I'd have to disagree Chris here as well. While many developers would be grateful for such an object, I personally feel its a step in the wrong direction. MVC places short-term constraints as a trade for long-term freedom. Its an argument that is not a waste of time in my view. -- John --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Cake PHP" 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/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
