What do YOU like about CFML for your views compared to jsp, erb, etc?
OK, so in my last posting Keith and Neil asked why a Ruby or Java developer might be interested in using CFML tags for view templates.
I haven't done enough jsp or Ruby web dev to have a strong opinion, so come one, come all with strong opinions :-) What do you like/dislike about the various other view templating technologies available when compared to CFML?
That said, clearly there "isn't anything that you can do in CFML that you can't do in Ruby or JSP". A language is a language. Sure there are CFML tags that make certain things very easy, but each platform has its pros and cons.
All that said, my view layer has become dumber and dumber over the years, so I do almost nothing in there any more. I think I could get by with just CFOUTPUT, CFLOOP, CFIF, CFSET, and CFCONTENT, plus the formatting functions. As such, switching technologies would likely be a totally mindless task.
I hate doing if/else in JSPs. You can't do [if condition].. [else] ...[/if] in JSP,
you have to do: --if true-- [if condition].. [/if] --if false-- [if condition].. [/if] because you need self-closing tags or matching start and end tags for everything.
This just bugged me. If all you're doing is checking a boolean, it's not so bad. And if things didn't bleed up into your view (which happens more often than we like), it's not too bad, but that happens and makes conditionals in your view very ugly.
I'm starting to side more with the Velocity and StringTemplate school of thought where the operations of the view layer should be very limited so that things can't bleed up to your view layer. Obviously CFML gives too much power for the view layer in that case. That's always been the case with CFML though, it requires a lot of discipline because you're not really restricted by the language.
It all depends on your application though. If it's a green application and you have lots of control and don't have to deal with legacy code; then you may be able to take a more pure route for your view, but there are plenty of old code bases out there with lots of logic in the view layer, in which case CFML is MUCH nicer to work with than JSP.
CFML makes solving a lot of these problems easy and productive, at least in my experience. I will second the power of grouped cfoutput- I also use query of queries quite happily in the view layer (horror!) so cfquery maybe has more shelf life than Peter thinks.
I don't think there is much point in comparing languages other than the bottom line of productivity. If it works for you, just keep using it
http://www.djangoproject.com/documentation/templat...
Interesting. I like a lot of things about Django, but I'm not a big fan of the templating system. I like some of the helpers like Upper and truncatewords, but why the | syntax:
{{ story.headline|upper }}
Why not story.headline.asUpper() or Upper(story.headline) (method or function)? It'd be more consistent. I *know* tem plating languages aren't primarily for programmers, but I find the syntax in Django to be just a little verbose and unintuitive. That said, like CFML, jsp, Velocity et al, it allows you to get the job done. Below is a longer snippet of Django template for anyone who is interested:
{% for story in story_list %}
<h2>
<a href="{{ story.get_absolute_url }}">
{{ story.headline|upper }}
</a>
</h2>
<p>{{ story.tease|truncatewords:"100" }}</p>
{% endfor %}
I know #headline# (within a cfoutput) isn't THAT much shorter than {{ story.headline }} (which requires you to wrap every single variable in a pair of curly brackets), but it is those little things that make the difference if you're working with a templating system all the time. I think the design choice to use a single character for variables in CF (as opposed to {{ or <% or whatever) was a good one and has an impact on everyday productivity.
Where logic is specific to a single view, I don't think it does any harm to include that logic in the view (although as we let designers play with our templates, we actually use view helper cfc's to keep the template screens nice and simple so the designers can focus on pure presentation concerns). The reason I don't generally like logic in the views (other than the occasional conditional or loop) is that if you're not careful you can end up with repeated logic in a bunch of views that display instances of the same objects and that gets messy fast (which I can attest to from previous, painful experience).
Personally, I'd encapsulate any QoQ functionality into methods on an IBO to get it to return an IBO with a subset of the data. That way I could hide the QoQ code from designers and would still be able to add custom getters if I needed to vary the way properties were displayed over time across multiple views. That said, if you don't have designers working on the templates, the QoQ's are specific to a single template, and you don't have any calculated properties being displayed on the screen that could use custom getters effectively, the argument could easily be made that my approach would add unnecessary flexibility for your use case.
I do think it is useful to compare templating languages, though. To me programming is all about having a well stocked toolkit and a good understanding of what tools are most appropriate for solving which problems. The more different languages and features I see, the more tools I have in my toolkit (if the feature isn't native to CF I can probably add it myself if I need it enough) and the better I can start to understand the relative strengths and weaknesses of different tools for different specific use cases.
It's also fascinating to see all of the comments - especially when people talk a little bit about their use cases. I'm always fascinated by all the different things we do as a community using the same set of tools (ColdFusion). No wonder we find it hard to agree on best practices sometimes!
Know what you mean. I've actually been experimenting with a completely language agnostic simple templating language for our designers which I can compile down to the appropriate view template technology. It isn't a priority yet, but as we start to ramp up, the more of our API that is generic, the more easily we can (for example) deploy different sites to different 3gl languages well after the ites have been developed, which could be useful for us.
I appreciate your comments, but indeed the functionality that I'm talking about is usually very specific so redundancy doesn't enter into it. Common routines are usually easy to spot and are encapsulated in one way or another.
I'm curious about this concept of handing code to designers who produce the finished view templates (if that's what you were implying). With us it happens the other way around - they produce the basic design and deliver it to us. We then incorporate it into the presentation layer as appropriate
Makes perfect sense. The best solution is always use case dependent.
The reason we hand over a simple templating language to designers is so they can not only implement the look and feel but also handle any rounds of revisions or tweaks. There are many people who are able to edit HTML, but few of that can (for instance) architect a versioned cms with workflow. We focus on providing the enabling technology which we can do very efficiently using our Software Product Line, and the designers can do all of the time intensive "would you like that a little bit to the left" stuff with the client.
Works well for us!
1) I dislike the character-combination to enter code blocks in most other templating systems (<% %>) or (%%) if the angled-brackets don't show up. I've been using it for years and it still feels awkward and slow to type it.
2) I like that the language is not tag-or-function based, but basically the entire language is available to me inside the code areas. So, just pick a better key combo and I would prefer the jsp/asp/erb style over CF.
3) I like the logic tags. They integrate better with the HTML and I spot it easier than the (% style.
4) I like the ability to define functions using tags and HTML. Makes things much easier when you want to go that route for reuse.
I suppose it depends what we mean by designers. For me, designers produce the look and feel. Translating that into XHTML/CSS is programming in my opinion, especially nowadays. Moving things a little bit to the left is done by us if it doesn't break any of the agreed visual rules. Constructing the UI components is quite an art. The key to HTML for us is structure - the structure and underlying CSS are I think as important to the maintability of the application as is adherence to any coding practices. CFML seems to fit nicely into that, even if it is sometimes only a visual thing
Anyway, this is maybe getting a bit off topic because it doesn't really engage in any comparisons with other languages. Interesting though