As long as you code your form to fit the lowest common denominator (no duplicate names) you can switch between html and xml forms. Now in practice, this is rare because as soon as you add inline actionscript (onCLick, onChange, etc..) you can't switch between flash and xml, since the actionscript won't work in the xml forms.
---nimer -----Original Message----- From: Adrian Lynch [mailto:[EMAIL PROTECTED] Sent: Monday, February 28, 2005 5:44 AM To: CF-Talk Subject: RE: cfinput question... That's a very good reason. Not just in regards to the client but just out of ease of code change. I've not checked but isn't it the case that you can change between flashpaper and pdf in cfdocument's format attribute without worrying about the code used? Ade -----Original Message----- From: Calvin Ward [mailto:[EMAIL PROTECTED] Sent: 28 February 2005 10:32 To: CF-Talk Subject: RE: cfinput question... I'd like to point out that it would be advantageous to be able to easily switch between flash/xml cfform based on the client without having to worry about such things. I thought that same named form fields were covered in the html spec? - Calvin -----Original Message----- From: Mike Nimer [mailto:[EMAIL PROTECTED] Sent: Friday, February 25, 2005 11:03 AM To: CF-Talk Subject: RE: cfinput question... The radio buttons works as groups. Technically the group has 1 name with child radio components (basically an array of children). And only 1 child can be selected, so you don't need to differentiate between the kids. And like other fields you can't have multiple groups with the same name in a form. I know it's odd that radio buttons can be grouped and checkboxes can't, I can see the point for and against it too. I have my own list of things I wished worked differently. But the flash designers who designed these components, with a lot of heated discussions, decided to implement them one way vs. another. Submit an enhancement and I'll see if I can't get grouping of checkboxes added to the next release of flex (then we can use it in CF) As for the point of flash forms - I wouldn't say the point was to map directly to, or replace completely, html forms. We are not expecting users to run and edit all of their existing html forms and change the attribute format="flash" and have them all work automatically. Flash forms are a new form type with it's own rules. It is these rules that allow the form to do more powerful and richer things, such as binding. Binding is one of the reason why duplicate id's aren't allowed. Imagine trying to bind a field to a check box and it's selected status, if you had 3 checkboxes with duplicate names . The point we tried to achieve with the flash forms was to create richer forms for the web. And we did try to model them after the html forms, So they would be familiar and easy to use for the non-flash developer. Which I think we did pretty well. When we could go two ways with the forms and how they behaved we would choose the html path. But there were some things that had to be done 1 way for the form to work. ---nimer -----Original Message----- From: Adrian Lynch [mailto:[EMAIL PROTECTED] Sent: Thursday, February 24, 2005 6:18 PM To: CF-Talk Subject: RE: cfinput question... Then why can you have radio inputs with the same name? I thought the point of Flash forms was to map directly to HTML forms, of course with improvements also, but holding onto the way they work. I know that sounds like a simplistic view. It's almost always the case that we use both radio and checkbox inputs to show related data with radio capturing one and checkbox capturing many. Are there any benefits with moving away from this? Flash groups radio inputs, why not checkboxes? If name maps to ID why not have a group attribute? Identifying a form element with a unique ID makes sense, but why have a way of grouping these form elements which can then be referered to by another ID? Have I missed the point with this? Ade -----Original Message----- From: Mike Nimer [mailto:[EMAIL PROTECTED] Sent: 24 February 2005 21:43 To: CF-Talk Subject: RE: cfinput question... The reason the names have to be unique is because flex requires each component to have a unique id (which I believe is something flash forces on flex). And since we are using Flex under the covers we have to follow their rules for what a movie is and how it's defined. ---nimer -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 266.5.1 - Release Date: 27/02/2005 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:196789 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
