Hey Peter and gang,
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.
> ... 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>
>
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.
<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.
>
I can see how an inLevel tag would come in handy and would probably use
it because I prefer a bit cleaner, simplified code. Some other tags I
would probably be interested in would be:
* 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"
... and I'm sure there will be others. When they come to me, I will let
you know.
--
Adrian Scott
Software Developer
[email protected]
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
--~--~---------~--~----~------------~-------~--~----~
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/
-~----------~----~----~----~------~----~------~--~---
