Hi All, \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:
http://bit.ly/RvCrI 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: http://bit.ly/m5gCb 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to Mach-II for CFML list. 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/mach-ii-for-coldfusion?hl=en SVN: http://greatbiztoolsllc.svn.cvsdude.com/mach-ii/ Wiki / Documentation / Tickets: http://greatbiztoolsllc.trac.cvsdude.com/mach-ii/ -~----------~----~----~----~------~----~------~--~---
