Matt Williams said the following on 06/16/2009 07:39 AM:
> On Jun 15, 11:33 pm, "Peter J. Farrell" <[email protected]> wrote:
>
>> I'm wondering if we should have a "default layout". However, I guess
>> the default should be with <p>'s. I'm wondering if should build
>> something (like HTML helper) for people to define layouts for it and
>> then reference <form:radioGroup layoutName="coolVerticalList" ... />>
>>
>
> I partly agree with Peter here. Don't have a default layout and don't
> even have vertical vs. horizontal or a <p> tag. The output could
> simply be the necessary <input type="radio"> piece. I could go either
> way on adding a <label> tag by default. If it isn't added, I'd
> probably end up doing it myself 99% of the time. Doing this would
> result in a horizontal layout, but styling or adding my own <li>, <p>
> or <br> tags could change that.
>
> This syntax example of <li>${radio} ${label}</li> seems logical to me.
> I haven't looked at how other tags are handling this, but obviously
> we'd want consistency where appropriate.
>
>
Yeah, I'm asking these questions:
* Do we want to get into the business of providing a "default" layout?
* If we do, are we sure the choice of which type of layout really is the
most common?
Another option is to allow people to pass in a layout pattern via tag
attribute so people could parameterize it:
<view:radioGroup path="emailSubscriptionOptions"
layoutPattern="#getProperty("radioLayoutPattern")#"/>
I'd just define the pattern in my XML properties:
<property name="radioLayoutPattern">
<value><!--//--><![CDATA[//><!--<li><label for="${tag.id}">${radio}
${label}</label></li>//--><!]]></value>
</property>
> Matt Woodward wrote:
>
>> When explicit lists are used, both values and labels must be provided.
>> Or do people see a need to be able to provide values without providing
>> labels? Didn't make sense to me but figured I better ask since there
>> might be a valid use case I'm just not coming up with.
>>
> I suppose for a simple True/False, the value and label would be the
> same. So perhaps if only values are supplied, use those as the label
> also.
>
For example, the options tag (which generates multiple options) when
used with an array uses the array element value for both the value and
label of the option tag. If you use a list, it uses the list element
for value and label. Structs are just sorted ASC text where the struct
key is the value and the struct key value is the label.
>> Also an overall question: do people want to have the ability to use one
>> datatype for values and another for labels, or is requiring the same for
>> both (when both values and labels are provided) OK?
>>
> Keep it simple here and keep them both the same.
>
I'd look at the options tags for what I've come up with so far. We
should make sure they match in functionality. Too bad we can't use the
options tag for the layout stuff we're figuring out. Options are part
of a drop down so there isn't any layout stuff to do with that (in the
terms of form element and label placement).
> STRUCTS:
>
>> * If values is a struct and labels is provided, the struct key will be used
>> as the value
>>
> How would this work with structs not returning in a consistent sort
> order? If I provide a structure and then a list of labels, I don't see
> how you could reliably match those up.
>
I don't think we should allow independent values attribute and labels
attribute. It makes for a nightmare as to match up. As I stated above
for the options tags, I think if we get a struct we should just sorta by
text ASC.
If you want a specific order, I think an array is a perfect choice. If
it's an array of simple values (strings), use the array element for both
the value and the label. If the array element has a struct in it, use
the key called value for the radio value and the key called label for
the radio value. This way you can have an explicit order for your radio
group.
For lists, I don't like the independent values and labels attributes.
I'd prefer to push people to structs or arrays of structs. The reason
is that I think independent lists would be developer error prone. Or
allow for lists just like the name / value pairs that BuildUrl() uses
which would keep things inline with the rest of the framework (including
BuildUrl() and the view:a tag):
<view:radioGroup path="emailSubscriptionOptions" items="marketing=Cool
Marketing Emails|product=New Product Notifications|account=Changes to
Your Account" delimiter="|">
<li><label for="${tag.id}">${radio} ${label}</label></li>
</view:radioGroup>
I think that brings things inline with our the rest of the framework
allows for quasi "ordered" structs via lists. I'd have to add this
support to the options tag as it currently uses the list element for
both the value and label (it doesn't support quasi structs via lists
using the "=" to indicate the name/value pair).
I'm debating if queries are a good thing but I'm fine with it if people
think it would be useful. I suspect that some people store this stuff
in a DB so it saves a data transformation step into an array of structs
or other data structure:
<view:radioGroup path="emailSubscriptionOptions"
items="#event.getArg("someQuery")#" labelCol="col1" valueCol="col8">
<li><label for="${tag.id}">${radio} ${label}</label></li>
</view:radioGroup>
The tag would throw an exception if you use a query and don't provide
the labelCol or valueCol attributes. The tag would use the query in the
order it is given. If queries are supported, I'll be sure to add
support for queries for the options tag as well.
Thoughts? I think these are reasonable and powerful while keeping
things simple and not to confusing.
I'm not to crazy about the two-dimensional arrays such such. Sounds
confusing (is the first or second array in a two-dimension array the
value or label?) and moreover a pain to maintain for us.
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/
-~----------~----~----~----~------~----~------~--~---
