I like Renderer objects, especially when the objects you need to render are quite complex. Handling such complexity in a non-OO way can get quite ugly. For instance, one of the legacy applications I maintain renders complex "widgets" by using a line similar to the following:
<cfinclude template="dspWidget_#widget.getWidgetTypeId()#.cfm" /> Eeeeewwww! For one thing, the different widget types are not rendered that differently, so there is a _LOT_ of code duplication across the widget type templates. A WidgetRenderer would definitely be a better approach for improved maintainability. On the other extreme, sometimes I just want to render some "stuff" that I don't yet need to be represented as an object in my model. The emails that I render using the MG ViewRenderer contain daily report data for business units to be sent to the corresponding business unit managers. Once the emails are sent I never refer to them again, so creating a DailyAlertEmail.cfc to represent the report data and recipients and then creating a DailyAlertEmailRenderer.cfc to render DailyAlertEmail objects as text for the email body feels a little like overkill ... at least for this instance. As for a perfect world, remember the maxim that "perfect is the enemy of the good". In my case the MG ViewRender hits a sweet spot for me: I can pass simple data to it and it renders output in the exact same way my normal views are rendered, and I can loop over the business units and use the same ViewRenderer to render the email for each one. That was enough for what I needed to do in this case, even though it may not be the best solution for _every_ case. -- Dennis On Wed, Aug 5, 2009 at 5:24 AM, denstar <[email protected]> wrote: > > On Wed, Aug 5, 2009 at 3:11 AM, Chris Blackwell<[email protected]> wrote: > > Hi Rob, > > I don't know whether you found this but there was a similar discussion a > > while back > > > http://groups.google.com/group/model-glue/browse_thread/thread/22ca37547741b669 > > FWIW I favour the same approach as Dennis. The simplicity of keeping all > my > > templates as "views", rather than a mixture of views, custom tags and > > home-grown templating language, is worth the trade-off of using MG in a > > slightly unorthodox way to render those templates when needed. > > Chris > > That sounds like a decent solution to mee too (especially since we > don't do much fancy stuff in views, tho linkTo() and whatnot are > getting us there), but I gotta say, that also sounds like mixing > things that shouldn't be *cough*in a perfect world*cough*. > > For my money, "renderers" are where "it's" at. You're not > copy-and-pasting various views from project to project, you can do > inheritance type deals (theoretically reducing repetition, but it > might depend on if you work on many projects or few projects, etc.), > and you can use them in "views" (not just MG views). > > I mean, this is probably from futsing with eclipse, but it seems like > the UI is a model itself, as confusing as that may be with terms like > MVC (they're all models! ahhhhh!). > > Eh. I'll holler when I've got The Perfect Code to share, if ya dig, > but that's sorta my line of thinking. > > -- > No noble or right style was ever yet founded but out of a sincere heart. > --Ruskin > > > > --~--~---------~--~----~------------~-------~--~----~ Model-Glue Sites: Home Page: http://www.model-glue.com Documentation: http://docs.model-glue.com Bug Tracker: http://bugs.model-glue.com Blog: http://www.model-glue.com/blog You received this message because you are subscribed to the Google Groups "model-glue" 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/model-glue?hl=en -~----------~----~----~----~------~----~------~--~---
