I'd second that comment on Renderer objects and methods being very useful in handling complexity! I'm not sure on this, but in a general sense they may be more performant as well handling complex rendering, because they can be initiated as singletons and held in memory.
On Wed, Aug 5, 2009 at 4:35 PM, Dennis Clark <[email protected]> wrote: > 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 >> >> >> > > > > -- Nando M. Breiter The CarbonZero Project CP 234 6934 Bioggio Switzerland +41 76 303 4477 [email protected] --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
