Performance improvements

[John Whish]

Hi chaps,

I'm currently looking at reducing the amount of JavaScript that VT
creates based on Dan's suggestions here:
http://groups.google.com/group/validatethis/browse_thread/thread/7ab96008571120b6
I'm also stripping out comments and formatting as well.

From what I can see the generateAddMethod is called every time you
want to have the javascript validation code on your page. As the
generateAddMethod is only called from the Client Side validators, I
think this should be cached (server side). Can anyone see a reason why
it shouldn't be?

Thanks,

- John

[John Whish]

@John - I think you're talking nonsense and everyone should ignore
you.

Thanks, me :)

On Jun 28, 10:03 am, John Whish <john.wh...@googlemail.com> wrote:
> Hi chaps,
>
> I'm currently looking at reducing the amount of JavaScript that VT

> creates based on Dan's suggestions here:http://groups.google.com/group/validatethis/browse_thread/thread/7ab9...

[Dan G. Switzer, II]

@John:

I feel like you're talking to yourself. ;)

-Dan

--
You received this message because you are subscribed to the Google Groups "ValidateThis-dev" group.
To post to this group, send email to validate...@googlegroups.com.
To unsubscribe from this group, send email to validatethis-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/validatethis-dev?hl=en.

--
Dan G. Switzer, II

dswi...@pengoworks.com

http://blog.pengoworks.com/

█▀▀▀▀▀█ ▄▀ ▄█▄▄█  █▀▀▀▀▀█
█ ███ █ ▀███▀ █▀  █ ███ █
█ ▀▀▀ █ █▄ ▄  ▀██ █ ▀▀▀ █
▀▀▀▀▀▀▀ █▄▀ █ █ ▀ ▀▀▀▀▀▀▀
█▀▄█▄▄▀▀  █▄▀██ █▄█▀▀ ▀▀▄
 ▄▀█▄▀▀▀▄▀▀▄▄▄█ ▄█▄▀▀  ▀▀
▀▀▄▄▀▀▀▀█▄▄▀▀█ ▀▀██▄ █▄▀█
▀▄ ▄▀ ▀  ▀▀█▄█▄▄▄ █▄▀▄▀▄▀
▀▀ ▀▀ ▀ █▀ ██▄ ▄█▀▀▀███ ▄
█▀▀▀▀▀█ ▀▄█ ▄▀█▀█ ▀ █▄▄▀█
█ ███ █ ▄▀▀ █▀ ▄▀█▀██ ▄▀ 
█ ▀▀▀ █ ▄ █▄ ▄▄ ▄▄▄ ▀█▀ ▀
▀▀▀▀▀▀▀ ▀▀  ▀▀ ▀▀  ▀   ▀▀

[John Whish]

@Dan - I'm not getting much sense from myself either!

I do have a proper question for the group... :)

I'm currently doing my best to write jQuery QUnit test for the client
side validation methods.

Firstly, is this a worthwhile exercise for VT (I'm assuming that you
can use cfSelenium to run the QUnit tests and check the result but I
haven't got that far yet).

Secondly, looking at the DoesNotContainOtherProperties method and I
notice that it's checking other properties based on field name (as VT
does), but it's not restricted to the current form. Is this going to
cause problems if users have multiple forms on the page. If so, is it
worth changing it to use the id of field instead.

So, instead of:

var propertyValue = jQuery(':input[name='+this+']').getValue();

use:

var propertyValue = jQuery('#'+this+']').getValue();

Thanks,

- John

[Bob Silverberg]

Hi John,

Thanks for tackling the performance improvements.

On Tue, Jun 28, 2011 at 12:40 PM, John Whish <john....@googlemail.com> wrote:

@Dan - I'm not getting much sense from myself either!

I do have a proper question for the group... :)

I'm currently doing my best to write jQuery QUnit test for the client
side validation methods.

Firstly, is this a worthwhile exercise for VT (I'm assuming that you
can use cfSelenium to run the QUnit tests and check the result but I
haven't got that far yet).

I am not familiar with QUnit.  Right now I'm just doing straight Selenium tests using CFSelenium to test out each of the built-in client-side validations. If there is a nice way to do this as a straight Javascript test, rather than using Selenium I can see value in that.  I guess I need to understand how QUnit works and what it's relationship to Selenium is to know whether it's a better approach than what I'm doing now.  Maybe we can chat about that sometime soon.

 

Secondly, looking at the DoesNotContainOtherProperties method and I
notice that it's checking other properties based on field name (as VT
does), but it's not restricted to the current form. Is this going to
cause problems if users have multiple forms on the page. If so, is it
worth changing it to use the id of field instead.

So, instead of:

var propertyValue = jQuery(':input[name='+this+']').getValue();

use:

var propertyValue = jQuery('#'+this+']').getValue();

I haven't looked at the code for this yet, but I know that for some of the client-side stuff it's written to address the issue of multiple forms. It locates DOM elements by specifying the form on which they should appear. Can we take that same approach with this, to be consistent? Or is there a reason that won't work in this case?

Thanks,

Bob

--
Bob Silverberg
www.silverwareconsulting.com

[John Whish]

Thanks Bob.

> I am not familiar with QUnit.  Right now I'm just doing straight Selenium
> tests using CFSelenium to test out each of the built-in client-side
> validations. If there is a nice way to do this as a straight Javascript
> test, rather than using Selenium I can see value in that.  I guess I need to
> understand how QUnit works and what it's relationship to Selenium is to know
> whether it's a better approach than what I'm doing now.  Maybe we can chat
> about that sometime soon.

QUnit produces a green/red report in the browser. Here's an example:
http://docs.jquery.com/Qunit

If you want to try it out, the jQuery validate plugin has numerous
QUnit tests if you download it and look in the tests directory.

>
> I haven't looked at the code for this yet, but I know that for some of the
> client-side stuff it's written to address the issue of multiple forms. It
> locates DOM elements by specifying the form on which they should appear. Can
> we take that same approach with this, to be consistent? Or is there a reason
> that won't work in this case?
> Thanks,
> Bob

I might be being dumb, but as these are the generic validation methods
I don't see how you could bind it to a form. You could change the way
the method works so you can pass in a selector of '#myform
:input[name=foo]', which means that the developer is responsible for
binding to the form. This will break existing code though... Thinking
about it a bit more I suppose I could get the element being validated
and derive the form it's in from that and restrict the other
properties selector to the validated elements form, that might
work....

[Bob Silverberg]

On Wed, Jun 29, 2011 at 8:45 AM, John Whish <john....@googlemail.com> wrote:

Thanks Bob.

> I am not familiar with QUnit.  Right now I'm just doing straight Selenium
> tests using CFSelenium to test out each of the built-in client-side
> validations. If there is a nice way to do this as a straight Javascript
> test, rather than using Selenium I can see value in that.  I guess I need to
> understand how QUnit works and what it's relationship to Selenium is to know
> whether it's a better approach than what I'm doing now.  Maybe we can chat
> about that sometime soon.

QUnit produces a green/red report in the browser. Here's an example:
http://docs.jquery.com/Qunit

If you want to try it out, the jQuery validate plugin has numerous
QUnit tests if you download it and look in the tests directory.

Thanks John, but that still leaves me pretty clueless. I would need to see how you are using it to test the validation code that VT is generating. Once again, I do think it's a great idea to have a JS testing tool to test the JS, but I think I'll need you to actually walk me through what you're doing with it.

 

>
> I haven't looked at the code for this yet, but I know that for some of the
> client-side stuff it's written to address the issue of multiple forms. It
> locates DOM elements by specifying the form on which they should appear. Can
> we take that same approach with this, to be consistent? Or is there a reason
> that won't work in this case?
> Thanks,
> Bob

I might be being dumb, but as these are the generic validation methods
I don't see how you could bind it to a form. You could change the way
the method works so you can pass in a selector of '#myform
:input[name=foo]', which means that the developer is responsible for
binding to the form. This will break existing code though... Thinking
about it a bit more I suppose I could get the element being validated
and derive the form it's in from that and restrict the other
properties selector to the validated elements form, that might
work....

Again, an unhelpful response from me, as I haven't looked at any of the code, but I wonder why this case is different from others where the context of the form is being used. Your idea does sound like a good one, but if we can do it in the same manner as other CRSs that might be a more maintainable approach.

Thanks,

Bob

 

--
Bob Silverberg
www.silverwareconsulting.com

[Bob Silverberg]

John has made some improvements to the JS code that is being generated by VT. I have pulled his changes into the develop branch at https://github.com/ValidateThis/ValidateThis.

Dan, if you have some time over the next couple of weeks (I'll be on vacation until then) to check out the new JS that's being generated and comment on whether it addresses some of your concerns, that would be great.

We do plan on tackling the default failure message issue as well, and I think John had some other ideas which would involve a more significant rewrite of the client-side generation code, so please feel free to make any new suggestions at this time.  If anyone else cares to review the new JS that's being generated and provide feedback that would be most appreciated.

Thanks,

Bob

--
Bob Silverberg
www.silverwareconsulting.com

[Dan G. Switzer, II]

Bob,

I tried checking out the version up on Github, but I get the error:

Element jQuery is undefined in a CFML structure referenced as part of an expression. <br>The error occurred on line 156.

It's throwing an error in ClientValidator.cfc.

I spent a few minutes looking at the problem and in the setScriptWriters() function, the call to the variables.childObjectFactory.loadChildObjects() method returns an empty struct.

I don't have any more time to look at the issue right now, but I did try to take a look at the JS code. If someone can just post a snippet of the JS that now gets generated, I'll be happy to review it!

-Dan

--
You received this message because you are subscribed to the Google Groups "ValidateThis-dev" group.
To post to this group, send email to validate...@googlegroups.com.
To unsubscribe from this group, send email to validatethis-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/validatethis-dev?hl=en.

[John Whish]

Hi Dan,

Thanks for looking - I'll have to grab a copy of what's in the github
branch and see if I can replicate that error when I can 5 mins spare.

I've attached the sourcecode from the FacadeDemo in my local repo.

Cheers,

- John

[Dan G. Switzer, II]

John,

Thanks for sending me the file. Here are my comments:

1. The $form_frmMain variable gets created in the global window namespace because it's not var'ed. This feels dirty to me and could problems with existing code. If this is done on purpose (so the variable is available anywhere) then I'd recommend creating a ValidateThis name space and stick things in there. So, instead of: 

$form_frmMain = $("#frmMain");

I'd do:

if( !window.VT ) window.VT = {};

VT.frmMain = $("#frmMain");

2. You can save some bytes of code with the following change. You currently have your code structured like this:

jQuery(document).ready(function(){

$form_frmMain = jQuery("#frmMain");

});

I'm sure you're doing this to avoid name collisions with the $ namespace, but here's a trick that will save you some bytes:

jQuery(function($){

$form_frmMain = $("#frmMain");

});

The jQuery(function) is a shortcut for the jQuery(document).ready(function) and has been in the code base forever, so I don't think it's going away.

Also, the document ready() callback passes in a single argument, which is a reference to jQuery. So jQuery(function($){}) gives you a safe way to call $ in your ready event handler that's guaranteed to reference jQuery.

3. Also, since the "fields" variable is only available to the ready() event handler, I wonder if it doesn't just make sense to call it "f" to save some bytes. Sure you lose readability, but since this is automatically generated code and it saves some bytes I don't think it's that big of a deal.

-Dan

[John Whish]

Hi Dan,

Thanks for looking at this and your suggestions. Until now, I've not
really been worrying about saving a few bytes, but I'm happy to review
that as well if you think it's worthwhile. There are quite of lot of
places where you could save the odd byte.

I'll definitely sort out the namespacing, I should have thought of
that originally.

Thanks again,

- John

[Dan G. Switzer, II]

John,

If I'm writing code for a page, readability is always more important than saving a couple of bytes, but when you get to automated code generation, where you can document what's happening in the CFML, then I tend to lean towards saving a few bytes--since the readability of the generated code isn't all that important.

-Dan

[John Whish]

Quick update on this if folks are interested. From an initial run
through of the code I've managed to shave off around 900bytes.

Do you guys think that this is worthwhile as you're loosing some
readability in the generated JS?

P.S. I could save a few extra bytes by removing the Copyright notice
on the jQuery Field Plug-in :)