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. > This sort of flexibility is contrary to the fundamental idea behind > CakePHP. The MVC programming pattern is well tested and well used. > Its benefits are well documented not only in theory but in practice > and experience. Gentle hints toward these benefits are built in the > guts of CakePHP. > > You can override, extend, load and move things around however you > want, but in doing so, you lose benefits proven by years and years of > experience. > With respect, I don't need to be preached at about MVC. I've been doing MVC and object-oriented applications for years in a variety of languages and frameworks -- Ruby on Rails, ColdFusion/Fusebox, Java, C+ +. 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 100% do not agree that handling HTML at the controller level violates the spirit of MVC. 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? I am indeed storing 90% of my HTML in the database, I've created my own layout/templating system for the CMS, with blocks and main content areas all manipulated by end-users. > > When it comes to building content > > management systems, which is 90% of what I do, "presentation" IS my > > data. I need to be able to massage the data, which is presentation, > > from anywhere within the application. > > 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. Which one is true? If using MVC for content management systems isn't appropriate, then what is? The urlconverter callback for TinyMCE doesn't do what I need it to do b/c I actually do not want the paths to change while the content is still within the WYSIWYG. As I stated before, if I change the path to the data in the WYSIWYG then the images are broken within the WYSIWYG. I need to store the data with the "bad" path, but change all the paths when I go to view the data. 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/ Rosie --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
