On Jun 16, 2:59 pm, "Peter J. Farrell" <[email protected]> wrote:
> 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>
I can't see me defining form field layout code in a property. Even on
one form I think radio inputs have different looks:
Gender: _Male _Female
Hobbies:
_Hiking _Movies
_Biking _Shopping
_Coding _Mach-II
> 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).
I agree. Keep radio options and select options the same as far as
populating values and labels. As for layout, I don't think I'd make it
an attribute of the custom tag at all and force the user to control
layout in the body of the tag as in Matt's original example:
<form:radiogroup name="foo" labels="Fee,Fi,Fo,Fum" values="1,2,3,4">
<li>${radio} ${label}</li>
</form:radiogroup>
If you really want to put an html snippet into a <property> tag, you
could and just reference getProperty() in that body instead.
> 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>
Agreed. What about javascript/jquery type of syntax with the colon
instead of the equal sign?
items="marketing:Cool Marketing Emails,product:New Product
Notifications,account:Changes to Your Account"
Easier to read in my opinion. I started to wrap it into curly brackets
too but that may throw a CF parsing error or something. Maybe not
though.
> 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:
Queries would be good and consistent with many regular CF tags also. I
have definitely worked on apps where radio and select options are DB
driven.
I almost wonder if you should do
<view:radioGroup query="qRadioOptions" ...> OR <view:radioGroup
struct="someStructure" ...>
> 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.
Agreed.
> 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.
Agreed. I can't see an advantage over structs and 2D arrays generally
have more complexity.
Matt Williams
--~--~---------~--~----~------------~-------~--~----~
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/
-~----------~----~----~----~------~----~------~--~---
