Validation attempt

[Jacob Wright]

I put together a Flex-independent validation utility. I liked yours Ryan, much smaller than Flex's, but you are sticking with the Flex API so that it can be used in Flex too since it is OpenFlux.

We aren't limiting ourself to Flex interfaces, so I changed some things. I don't like having an invalidateProperties, invalidateSize, etc. for each thing. It limits validation to only be used for what we assume it will be. What if layout want to tie in, or styling, or some other component. I also don't want to force a validation interface onto our components that say there must be a validateSize method. So I made it so you pass in your validation method when invalidating. This keeps it flexible for anything to use and provides greater pay-as-you-go-ability (I think I'll use expandability for now on, but assume it means pay-as-you-go).

Another thing I don't like about Flex implementation is using a globals class to access the application class. It isn't testable and validation happens always, even when things aren't on the stage and don't need to layout, redraw, etc. Maybe we still want that to happen, but right now I've got it optimized to only validate when on the stage using the RENDER event.

I'm also using EventDispatcher to do all the heavy lifting for me so the code is very small. I don't have to iterate through arrays, check if items are on the stage or not, etc. I've only keep a dictionary of listeners so that I can remove them if uninvalidate is called.

I've got a lot of comments in there so hopefully everything makes sense. I didn't have anywhere else to commit it, so I put it in the project. We can take it out if we have a different or better solution we want to do.

http://github.com/jacwright/reflex/blob/master/src/reflex/core/Validation.as

I've tested it and it works great. I'd be happy for feedback.

Jacob

[Ben Clinkinbeard]

I only skimmed the code but I definitely like the idea of being able to register your own validation methods. No clue how you'd implement it but it also might be cool if you could specify when the validation method was run. Maybe you can specify the event type that triggers that validation? enterFrame, indexChange, etc. I dunno, just thing out loud here.

Ben C.

[Ryan Campbell]

Hmm, that's an interesting idea (specifying which events cause invalidation). Instead of calling Validator.invalidate( target, validate ) all the time you would just call Validator.register( target, eventType, validationMethod ) once.

I also like passing the validationMethod since it allows you to pass private methods.

[Jacob Wright]

Hmm, that's an interesting idea (specifying which events cause invalidation). Instead of calling Validator.invalidate( target, validate ) all the time you would just call Validator.register( target, eventType, validationMethod ) once.

So, a real use case like this:

Validator.register(target, Event.RESIZE, validateLayout);

Validator.register(target, "minWidthChange", validateLayout);

Validator.register(target, "minHeightChange", validateLayout);

....etc.

Then you don't have to add the invalidate logic into every setter of your layout. You add it at the top of the class. That could be cool. So any of those events would invalidate the target and on the next RENDER event before the screen redraw they would validate. Good idea.

[Ben Clinkinbeard]

Hmmm, in thinking about more broad uses of this I wonder if we are just replicating addEventListener. For instance, there is no reason you couldn't say Validator.register( target, "audioFinishedPlaying", disableAudioPlayer ). I think its cool to support that but its not really about validation at that point. It might also be cool to provide a mechanism for specifying what gets sent to the handler, similar to event mediation in Swiz. In Swiz, you can decorate a method with something like [Mediate( event="someEvent", properties="user, status" )] and Swiz will catch that event, pull the user and status properties off of the event, and pass them to the method. This allows the methods to be more encapsulated and to not care how they are called (in response to an event or manually).

Thoughts?

Ben

[Jacob Wright]

Well, invalidation is all about reducing processes that only need to run once before being visually displayed on the screen. The main example is in layout. You don't want layout to update everything (especially when it affects children and children's children and parents etc.) every time you change a property. Otherwise when you set width, then height, then verticalGap, then padding, you've just run the layout algorithm 4 times in one thread possibly resizing everything on the stage 4 times. You really only need the layout algorithm to run once after you've set all your properties, and it only needs to run right before a screen refresh, and only run for items that are on the stage.

So invalidation calls stage.invalidate() and listens to the RENDER event and runs the layout algorithm at that point. RENDER happens right before a screen refresh, and only for those items on the stage.

But it might be nice to not have to call invalidate(target, validateLayout) in all the setters that could change your layout. So I did add a register and unregister method to the Validation class. Oh, and renamed it to Invalidator so it doesn't get confused with user-input validation.

http://github.com/jacwright/reflex/blob/master/src/reflex/core/Invalidator.as

Is that sorta what you were thinking Ryan? So the layout class could register widthChange, heightChange, verticalGapChange, events to trigger the invalidation. Or maybe just the propertyChange event so when anything changes it invalidates the layout object.

Jacob

[Ben Clinkinbeard]

Any item that has a RENDER listener will get called though, so what purpose is Invalidator really serving? Why wouldn't the components just create their own listeners?

[Tyler Wright]

This type of solution could be built into the base component class, but as a separate implementation the way Jacob has it, other objects can take advantage of the invalidation cycle. For example, Layout as an add-on will add its own validation method using its own target (a component or displayObject) as the validation target (the DisplayObject that will dispatch RENDER).

[Jacob Wright]

On Thu, Sep 17, 2009 at 11:47 AM, Ben Clinkinbeard <ben.clin...@gmail.com> wrote:

Any item that has a RENDER listener will get called though, so what purpose is Invalidator really serving? Why wouldn't the components just create their own listeners?

We could have every setter that invalidates layout include these lines of code:

if (stage) {

  stage.invalidate();

}

addEventListener(Event.RENDER, validateLayout);

Or those could be put in a method called invalidate(listener); on component (which I actually did for my demo) including an addedToStage handler that calls stage.invalidate if any listeners are still waiting. And all the listeners will need to remember to remove themselves from the render event. Or we could abstract the code out into a utility class that does that for you. Either way works. Just cutting down on code duplication, though having it part of the base component makes sense to me too. You wouldn't be able to use Layout with non-components, but I don't see that being a huge problem. Make people have their Flash IDE sprites extend our component to use layout if they want it.

So, should I put the invalidation stuff on component instead of a separate utility? Would make the code smaller is the plus. The minus is it's tied to component (if that's a big deal).

Jacob

[Ben Stucki]

Alright, so I'm not totally sold on the invalidation model (I'm afraid the usage might seem complicated for devs), but I think the conversation is starting to get pretty technical for email. Maybe you (Jacob) could create a branch with a basic reference implementation to look at? - and of course we're setting up a Skype call soon to talk some of this over.

Also, we're just coordinating the call with the core contributors right now, but if any committee members want on feel free to email me directly.