Adrian Scott said the following on 07/16/2009 12:18 PM:
>> I have no clue what the future brings for the form and view tag library,
>> but for some reason I'm thinking it might be a good idea to have a scope
>> attached for uniformity across the framework. Plus, who knows we might
>> support EL syntax stuff inside of this display output format. I'd love
>> for people to chime in, but having an phantom "output" scope (since the
>> tag is generating stuff) is beginning to look like a good idea to me.
>>
>
> I like the scoping that you'd described; it sounds like a good idea,
> especially moving forward into more (potentially) complex EL syntax
> and mechanisms to use that information.
>
>
>>> Let me know if I'm just missing something about what you're proposing.
>>> After your explanation I agree it makes sense not to have the tag
>>> auto-generate the label tags.
>>>
>> Yeah, I at first thought that was a good idea to auto-generate the
>> labels, but it seems like such PITA. If we had a way to set a default
>> output format -- that would be another way to do that. Maybe something
>> for 1.9 if people ask for it (which I hope people will speak up if that
>> is the case).
>>
>
> I can see where both cases could come in handy. It would be nice for
> me, a lazy developer, to have the ability to essentially generate all
> the code without worrying too much about tags within the layout we
> have to define, though it would also be nice to be able to structure
> the labels however we see fit. Perhaps another attribute like
> generateLabels="true" would be in order here?
>
Yeah, I thought about having that as an addition attribute, however
there is the problem I posed in my previous email about where does the
<label> go (especially when the display format content has other
formatting stuff in it)? There are a multitude of options and it gets
more complicated when you mix in <li>'s (as the <label> needs to be
nested inside). The tag would have to become somewhat good as
introspecting the HTML and what would be valid.
Another idea if you want to be lazy is to add in an
displayFormat="#getProperty("somePreFomatedString")#" that would supply
the display format. No nested code would be needed. As for a timeline,
I hope to get the basic stuff into the beta and add stuff like this in
during the beta as refinements.
> Also, I don't know how much more complicated it would make this tag
> call, but would there be an ability to specify the template that the
> RadioGroup form tag utilizes to generate the individual radio
> buttons? For instance, if I wanted to modify it from:
>
> <input type="radio" id="${loop.path}_${loop.value}" name="$
> {loop.path}" value="${loop.value}" />
>
> to something like:
>
> <input type="radio" id="${loop.path}_${loop.value}" name="$
> {loop.path}" value="${loop.value}" onclick="alert('You clicked me, and
> I am ${loop.value}');" />
>
For something like this, you're probably better using a cfloop and the
m2 "radio" tag:
<cfloop collection="#items" item="i">
<form:radio path="favoriteColors" onclick="alert(...)"/> #items[i].label#
</cfloop>
Although, we might be able to add some stuff like this depending on what
datatype you supply to the radioGroup tag. With items and labels lists,
I don't think that is possible, but if you supply a struct of items or
array of struct items -- we might be able to use additional keys to
stuff like that. Matt is going to be sending an additional email on the
accepted datatypes and this an additional area where we can possibly
refine during the beta. Let's wait for Matt and other to chime, but
don't forget this stuff -- I'm sure I'll want you to file a ticket once
the radioGroup tag becomes a little more baked (right now it's not even
oven ready ;-)
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/
-~----------~----~----~----~------~----~------~--~---
