QuackFuzed [ Ramblings of a Con..ColdFuzed Mind ]

cfUniForm New Release - v2.1

Posted on July 19, 2008 at 4:39 PM in ColdFusion, Uni-Form Tag Library

The latest release of cfUniForm includes a couple of new features, along with a minor bug fix.

New Features: type="custom"

It always seems that no matter how hard you try to include every possible scenario in your tag library, there's always a new implementation need that pops up that hadn't previously been thought of. For those situations, you can now use type="custom" to do whatever you need to do.

1. <uform:field type="custom">
2. <p>
3. I exist in the middle of this form just
4. for the sake of being annoying.
5. </p>
6. <hr />
7. <p>
8. Actually, not really. I am here just
9. to prove a point. With type="custom"
10. the developer can do whatever he or she
11. wants to do with their forms.
12. </p>
13. <p>
14. Like maybe placing a "Check Availabilty"
15. button on a new user registration form
16. that sends an Ajax request to the server
17. to see if the desired User Name is available.
18. </p>
19. <button>Check Availability</button>
20. </uform:field>

One word of caution with type="custom". For those of you who actually care about whether or not your markup is valid, be careful about what you place in a custom field, as the library will not do a validation check for you.

New Features: errorMessagePlacement

There is a brand new (optional) argument on the base form tag (<uform:form>) called 'errorMessagePlacement'. This argument does exactly what the name implies, and accepts the following values: top, inline, both, none.

• top - display the errors only at the top of the form (above the fields)
• inline - display the errors only inline (with the offending field)
• both - display both at the top and inline (this is the default)
• none - no error message display

For what it's worth, I really don't know why you'd want to use 'none', since you can achieve the same result by simply not passing an error struct to the tag. However, I included the option nonetheless. Maybe there's a specific use case out there where it might come in handy.

Minor Bug Fix

In previous versions, type="checkbox" did not support the 'isChecked' attribute. This has been fixed in the 2.1 release.

Demo and Download

You can see a quick demo here, or you can download the zip here.

Comments

(Comment Moderation is enabled. Your comment will not appear until approved.)

On 8/2/08 at 12:46 PM, Josen Ruiseco said:

Matt,

Thanks to you for all your hard work bringing the power and simplicity of uniforms to to ColdFusion.

Have you configured the twoSelectsRelated custom tag to work with your code?

Josen

On 8/2/08 at 4:14 PM, Matt Quackenbush said:

Josen,

You're welcome. :-) I have not done anything with the twoSelectsRelated tag, but it should be possible to use it in conjunction with the new type="custom" feature, since it will allow you to do anything inside of it.

HTH

On 8/13/08 at 2:08 AM, Matt MacDougall said:

Hi Matt,

I just noticed on the demo that the DOB field shows the calendar with the first year as 98 and the last as several years in the future. I think an attribute for the date type to set the year range would be helpful.

This tag has become an integral part of my workflow. Thanks for the work!

-Matt

On 8/13/08 at 2:56 AM, Matt Quackenbush said:

Matt,

Glad you find the tags useful!

The datepicker is very customizable, and therefore has a lot of options that can be set. IMO, it would be a treacherous path to go down if there were attributes for all of the options for all of the plugins. If you need to make changes to the defaults, I would suggest either adding a script block (after your form) to set the defaults, or just load the datepicker on your own and set the defaults when you load it.

Here's an example of changing the date range:

<script type="text/javascript">
   $(document).ready(function() {
      $.datepicker.setDefaults({yearRange: "2001:2004"});
   });
</script>

There are quite a number of things you can change. Take a look at the docs (http://docs.jquery.com/UI/Datepicker) for all of the specifics.

On 8/13/08 at 4:04 PM, Matt MacDougall said:

Thanks for the code snip. Yes there are tons of options in jQuerry and I agree, having attributes for each would tedious and probably knock down the usefulness of this. But I think jQuerry's default for the date picker in this tag library is incorrect. I can't think of a single submission form where you'd use a date that could have valid dates in the past as well as the future for a single option. DOB should always be in the past, CC Exp should always be in the future, graduation date, delivery date, etc ... every submission option I can think of should be either or. So the default date range of 10 years in the past and 10 years in the future inherently leaves half of the dates as invalid in real world situations.

Using a bit of JS to change this is a not a big deal. I'll either go that route or make a patch for this to be able to set a -years or +years from today for the range in the past or future years. It is something I think we as users should be doing everytime we use this field for data collection. So maybe it's one of those attributes that should be included in the base ...

On 8/14/08 at 2:15 PM, John said:

Great tags, very good job.

errorMessage attribute for a field doesn't seems to work.
Can you confirm this or do you have or a snippet of code ?

Thanks
John.

On 8/14/08 at 2:45 PM, Matt Quackenbush said:

John,

Thanks for the kind words. :-)

The errorMessage attribute... When I first read your comment, I had to think really hard about that, because I had forgotten that it even existed. When I added the errors struct attribute, my intention was for the individual errorMessage attribute to go away. The behavior that you're seeing is the result of that, I just (obviously) never removed that attribute from the tag.

Essentially, the idea is that after you do server-side validation, you'll pass a struct into the errors attribute on the form, which will contain all of your error messages for each field. So, for instance, let's say you have a form field named 'userName', and the field fails validation. Here's an example of how you might handle passing error messages for that field:

<cfscript>
   errors = structNew();
   errors.userName = "User Name contains invalid characters.";
</cfscript>

When the form is generated, it will search for a key in the errors struct whose name matches the name of the field being built. If one is found, then it is added into the source code. By handling it this way, I feel that it provides a better separation of logic and HTML, as well as gives you more control to build all of your error messages in a single place, such as your controller or a validation object.

Does that make sense?

Now then, for client-side validation error messages, I personally typically just use the default error messages that are built into the jQuery validation plugin. On the occasion that I need to do any "serious" client-side validation routines, I typically don't have the tags load the validation plugin, and then I write my own script for that particular form. You can find more info about the plugin by checking out the docs (http://docs.jquery.com/Plugins/Validation).

Hope that helps.

[Add Comment]