0 comments - Posted by David Freerksen at 9:55 AM - Categories: Technical Articles | Adobe AIR | Adobe Flex
Anyone who has built forms in Flex knows the frustration of trying to build a good experience with validation using the default Flex components. Validation is not tied to the field, validation messages only show up when you mouseover the invalid fields and when you want to process the form you essentially have to revalidate all of the data, unless you've written custom methods to handle all of your validation. I've spent a couple of days working through this and I was frustrated, to say the least. I sat down with the rest of the team and said "Hey, how can we make this easier?"
What we came up with was the ValidatingTextInput. True, the first draft we are offering here is a bit rough around the edges, but it works! I am planning to add data binding and other critical features soon, so this is an "alpha" version. Let me show you how simple this is:
<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" xmlns:ui="net.sanative.ui.*"
layout="vertical"
width="100%" height="100%"
paddingBottom="9" paddingLeft="9" paddingTop="9" paddingRight="9"
creationComplete="init()">
<mx:Style source="/assets/styles.css"/>
<mx:Script>
<![CDATA[
import mx.validators.EmailValidator;
import mx.validators.StringValidator;
[Bindable]
private var emailValidator:EmailValidator = new EmailValidator();
[Bindable]
private var noBlanksValidator:StringValidator = new StringValidator();
private function init():void
{
noBlanksValidator.required = true;
}
]]>
</mx:Script>
<mx:Form>
<ui:ValidatingTextInput id="ti_FirstName"
label="First Name"
validator="{noBlanksValidator}"
toolTipStyleName="errorTip"
plainTextError="is a required field."/>
<ui:ValidatingTextInput id="ti_Email"
label="Email"
validator="{emailValidator}"
toolTipStyleName="errorTip"
plainTextError="must be a valid email address."/>
</mx:Form>
</mx:Application>
You will notice the ValidatingTextField accepts a few parameters: label, validator, tooltipStyleName and plainTextError. I will describe each of these briefly:
label: This is the text to display the name of the field to the user
validator: this attribute accepts any validator and will check the data in the field against the validator you pass it. Just configure your validator and pass it to the component, it's that simple.
toolTipStyleName: The name of a CSS class to pass to the component for styling the look of the tooltips
plainTextError: This attribute is combined with the label attribute to make up the full text of the tooltip.
We display the tooltip on focusOut so that the user does not have to mouse over the field to determine what the problem is. Additionally, the component has a property named isValid available to you. This property allows you to simply check the value to determine if the field is valid or not, making it much easier to determine if your entire form is ready for processing. Instead of rerunning all your validation again, simply check to ensure all the fields you want to validate have a isValid value of true!
Here's the demo:
There are a ton of possibilities for this component and we also plan on expanding it to other components such as the ComboBox, List, etc. If you have any suggestions, let us know!
Many of the ideas we implemented came from Aral Balkan and his readers, so thanks guys! If you would like the source, right click the example and "View Source".
0 comments - Posted by TJ Downes at 7:52 PM - Categories: Technical Articles | Adobe AIR | Adobe Flex
The other day I was working on an event management for a client. It's a very basic app: a few different "views" to handle the administration of the application. Each view was built using a custom component. I was refactoring code and adding enhancements when I noticed something interesting in all of them. Every component had a reference to the parent application and was calling methods directly. This immediately fired off some big warnings in my mind. What happens if we want to use the component in a different application or the parent application changes? Then we would need to go in and modify every component to be able to work with the parent application. With a larger application this can be time-consuming and expensive to do.
1 comments - Posted by Jeff Anderson at 5:00 PM - Categories: Technical Articles | Adobe Flex
0 comments - Posted by TJ Downes at 5:04 PM - Categories: Site Launches | Cool Stuff | Adobe Flex | Adobe ColdFusion
0 comments - Posted by TJ Downes at 5:39 PM - Categories: Technical Articles | Cool Stuff
6 comments - Posted by TJ Downes at 12:30 PM - Categories:
0 comments - Posted by TJ Downes at 7:10 AM - Categories:
