Feedback Wanted: View Tag Library
Peter J. Farrell
\Matt's message earlier today about the radioGroup tag for the form tag
library. I encourage you to take a peek at his message. Your comments
will help shape how the radioGroup tag works. If you are unfamiliar
with the new form tag library (which is already in the repo and ready to
use except for the radioGroup), check out the wiki entry on how to use it:
Anyways, I wanted to post some thoughts about a couple of improvements /
additions to the view tag library that I want to propose. The view tag
library aims to be a comprehensive set of CFML tags that reduce writing
mundane or complex code within your views. Some useful tags are the
<view:a> tag. Syntax like this:
<view:a event="showProduct" p:id="${event.productId}">some link</view:a>
It creates an HTML a tag like:
<a href="index.cfm/even/showProduct/id/abc1234/">some link</a>
The <view:a> tag aims to simplify your views with less pounds (#s) and
method calls to build URLs). For more information on the other cool
tags in the view tag library, check out our complete documentation here:
Possible New Enhancement to the view:a Tag
-----------
Anyways, I wanted to float a new addition to the <view:a> tag. In a lot
of my applications in the terms of navigation links, I add a CSS class
when the current event is the same as the link (highlighting the link
that is currently active). I do it with a UDF call, but essentially
it's like this:
<a href="#BuildUrl("products.paper.someProduct")#" <cfif
event.getRequestName() EQ
"products.paper.someProduct">class="highlight"</cfif>>Some Product Name</a>
It's a bit nasty, but it works to insert the CSS class name when the
event name in the request matches the URL I'm build. This breaks down
when using the <view:a> tag because you can't nest an if statement in
the custom tag. So I was thinking it would be nice if you could add in
a class name if is the current requested event matches the event/module
name or route name. The tag attribute is not set in stone (taking
suggestions if people think this is an useful enhancement):
<view:a event="products.paper.someProduct"
requestMatchClassName="highlight">Some Product Name</view:a>
By default, we'd only check if there is a match if the
"requestMatchClassName" attribute is defined. If you defined a class
attribute for other CSS classes, we'd append the "highlight" class name
to class names you defined (so they are not overwritten):
<view:a event="products.paper.someProduct"
requestMatchClassName="highlight" class="links">Some Product Name</view:a>
Produces something like this if the request name matched:
<a href="/index.cfm/event/products.paper.someProduct/" class="links
highlight">Some Product Name</a>
Another reason to add this is that this the hand-coded solution becomes
a lot harder if you using view:a with routes because once a route is
intercepted at the beginning of the request by the framework -- it is
translated to an event handler name. So checking if the view:a used
with a route matches, requires you to ask the framework for the event
handler name for the route you are creating a link for to do the match.
This is because URLs really are just mapping a route name (plus ordered
parameters) to an event handler and event args.
Possible inLevel Tag (idea)
-------------
I've been looking over my view code for more ideas for the view tag
library and I noticed something I do a lot when building navigation:
<cfset variables.mainEvent = event.getRequestName() />
<div class="navgroup">
<h3><a href="#BuildUrl("products.selection.index")#">Selection &
Retention</a></h3>
<cfif variables.udfs.inNavigationLevel("products.selection",
variables.mainEvent)>
<ul>
<li>
<a
href="#BuildUrl("products.selection.buyBatteries.index")#">Buy
Employment Assessment Batteries</a>
<cfif
variables.udfs.inNavigationLevel("products.selection.buyBatteries",
variables.mainEvent)>
<ul>
<li><a
href="#BuildUrl("products.selection.buyBatteries.generalOperationsSupport")#">General
Operations Support Jobs</a></li>
<li><a
href="#BuildUrl("products.selection.buyBatteries.financialSupport")#">Financial
Support Jobs</a></li>
</ul>
</cfif>
</li>
</ul>
</cfif>
</div>
Notice the UDFs function called inNavigationLevel(). Would it be nice
to simplify it?
<div class="navgroup">
<h3><a href="#BuildUrl("products.selection.index")#">Selection &
Retention</a></h3>
<view:inLevel eventLevel="products.selection">
<ul>
<li>
<a
href="#BuildUrl("products.selection.buyBatteries.index")#">Buy
Employment Assessment Batteries</a>
<view:inLevel eventLevel="products.selection.buyBatteries">
<ul>
<li><a
href="#BuildUrl("products.selection.buyBatteries.generalOperationsSupport")#">General
Operations Support Jobs</a></li>
<li><a
href="#BuildUrl("products.selection.buyBatteries.financialSupport")#">Financial
Support Jobs</a></li>
</ul>
</view:inLevel>
</li>
</ul>
</view:inLevel>
</div>
Most people use "." (dots) or "-" (dashes) to help show "hierarchy" of
their event-handlers so basically the inLevel tag would match to see if
the current request event named matched the all the passed eventLevel
from the tag. The tag name could be named better or more generic, so
suggestions are welcome.
Maybe I'm reaching on this tag (which I know I am), but maybe it will
make people think about the stuff they do "just too much" in their
views. I'm trying to keep things generic and stuff that doesn't require
configuration. For instance, the a "date" tag for the form library would
probably require configuration and therefore less just drop in and use
which is what we are aiming for.
So feel free to comment on my ideas or feel free to suggest a "generic"
tag that you think would be a great addition to the view tag library.
Best,
.Peter
Adrian Scott
I'm looking forward to all of the nifty 1.8 changes and am glad that you guys are willing to involve the community with so much gusto. Please see my comments below, inline.
While it's true that there are a lot of instances where I check to see whether the current event name is the same as the value I'm trying to check in order to change a class or two, I think we can generalize this even further by using some of the same expression syntax used elsewhere, just expanded in order to use conditionals, e.g.... I was thinking it would be nice if you could add in a class name if is the current requested event matches the event/module name or route name. The tag attribute is not set in stone (taking suggestions if people think this is an useful enhancement): <view:a event="products.paper.someProduct" requestMatchClassName="highlight">Some Product Name</view:a> By default, we'd only check if there is a match if the "requestMatchClassName" attribute is defined. If you defined a class attribute for other CSS classes, we'd append the "highlight" class name to class names you defined (so they are not overwritten): <view:a event="products.paper.someProduct" requestMatchClassName="highlight" class="links">Some Product Name</view:a> Produces something like this if the request name matched: <a href="/index.cfm/event/products.paper.someProduct/" class="links highlight">Some Product Name</a>
<view:a event="products.paper.someProduct" class="${event.getRequestName() eq 'products.paper.someProduct'?'highlight':''}">Some Product Name</view:a>
Which would allow greater flexibility in cases where you may want to check logic other than just the request name. It would be pretty handy elsewhere too, not just within a view:a tag.
Most people use "." (dots) or "-" (dashes) to help show "hierarchy" of their event-handlers so basically the inLevel tag would match to see if the current request event named matched the all the passed eventLevel from the tag. The tag name could be named better or more generic, so suggestions are welcome. Maybe I'm reaching on this tag (which I know I am), but maybe it will make people think about the stuff they do "just too much" in their views. I'm trying to keep things generic and stuff that doesn't require configuration. For instance, the a "date" tag for the form library would probably require configuration and therefore less just drop in and use which is what we are aiming for. So feel free to comment on my ideas or feel free to suggest a "generic" tag that you think would be a great addition to the view tag library.
- Tag to generate simplified breadcrumbs, perhaps by providing two comma-separated lists (one for the link URL and one for the label) and even include similar data-binding notation as the radiogroup that Matt has proposed
- A tag to nicely format a list of elements such as "1,2,3" into "1, 2, and 3"
-- Adrian Scott Software Developer adr...@alluradirect.com 604.707.6713 AlluraDirect.com Vacations Ltd. www.alluradirect.com Book smarter. Play harder. Local Phone: 604.707.6714 Toll-Free North America: 1.866.4.ALLURA Toll-Free UK: 0.800.028.9346 Toll-Free Australia: 877.226.6358 Toll-Free Hong Kong: 800.903.329