enzo - this is FANTASTIC work, thank you so much for doing this! I just took a cursory look at your demos, and OH MY GOD they are hot!!! I have to spend some time actually looking through your code and setting up the examples on the examples site, but so far - WOW! Thank you so much for doing this!!!

Great work enzo. The JQuery problems you mention maybe related to the integration of the JQuery files. I got a thread on this (http://qcu.be/content/jquery-integration-current-stable-stripped-versions).

My opinion is that plugins shouldn't bring their own JQuery files with them. Instead they should all base on the stripped production ready JQuery files for the core and the UI, which are currently not in the framework.

Cheers,
Andreas

Those look pretty cool, though the slider doesn't want to run in Opera 9.62. I look forward to seeing more controls come out. :)

Hello Akron

The error I mention is because the framework try to include the js and css files in a wrong path, but I resolve include inside the control.

If you use firebug could you see, I don't have time to check in deep to figure out.

Thanks for your comments

enzo

Hello enzo, this sounds like something needs to be fixed. Could you make a ticket?

Good job! Awesome.

Tiny update: I just looked through the code of the QEmailTextBox, it's great; I made a few tiny changes (just checked them in) and the example is now hosted on examples.qcu.be: http://examples.qcu.be/assets/plugins/QEmailTextBox/example/emailtextbox....

I just did the same thing (slight improvements + posting to examples.qcu.be) for the QSlider plugin: http://examples.qcu.be/assets/plugins/QSlider/example/qslider.php

Nice Approach alex

Enzo - I started looking at the QProgressBar, and I think it needs more work before we can get it out the door. Specifically, a developer would use a progress bar if there's some long-running process on the server - right? That would be their way to tell the user that their request is not hung, that something is going on.

For example, when you submit a request for a complex report to the database server, you can imagine the server popping up a progress dialog, showing you the state of what's going on (Stage 1: query to the server done => progress indicator at 20%; stage 2: custom data munging complete => progress indicator at 50%; stage 3: PDF generated, progress indicator at 100%).

To do so, the example in the indicator needs to be reworked significantly to show this kind of progress. I imagine the client doing regular polling of the server, asking what the current state of the progress indicator should be. The server would respond.

How you can illustrate this: have the server sleep for 3 seconds; then update the status of the progress indicator; then sleep again; then update the progress indicator again. You may need to use client-side proxies for this. Totally a non-trivial problem, think about it some more.

Thanks!

I think the validation for QEmailTextBox needs to be more robust. For example using the current regular expression "bob@" validates as a proper email address when according to the standard it isn't.

I added the IsEmail function to the control in my development environment to test. So far it works wonderfully. I would suggest replacing: "if ( !eregi("^[a-z0-9]+([_\\.-][a-z0-9]+)*"."@([a-z0-9]+([\.-][a-z0-9]{1,})+)*$", $this->strText) )" with this function or a similar function.

Hello Alex

I understand your point, but when I did I just think on steps across a wizard program

Hello Allegro

Could you create a patch ?

thx

enzo

I have the patch ready. How should I submit it?

Can we ensure that the control matches the testing used for QEmailServer? It would be silly for something to pass here and then fail when sending.

If you want stricter than that, please also contribute to http://trac.qcu.be/projects/qcubed/ticket/170 to make QEmailServer stricter as well.

It seems that we might want to create a string constant in QEmailServer that specifies this regex - and then have the plugin refer to this regex. How does that sound?

The only concern I have about that is that the regex used by QEmailServer is designed to accept a sequence of e-mail addresses in the string (seperated by ;s), while I'm guessing the intent is that QEmailTextBox does not.

This is why the arpad 3 RegEx was never applied to QEmailServer. No one has figured out the multi-email version of it. :P

We have a client who is wanting the stricter email validation so we did some research.

We ran several unit test on the current RegExp used by Qcubed and the pure PHP function from Dominic Sayers.

Out of 228 test:
Dominic's script passes all unit test 100%
Current RegExp ("/[a-zA-Z0-9_.'%+-]+[@][\-a-zA-Z0-9_.]+/") 16 False Positives 64 False Negatives

Observing the data we found that most of the false positives were from IPv6 addressing which is not widely adopted yet. Therefore, we have decided to use the RegExp that is currently in place and passing any failures to Dominic's PHP function for further testing.

Did you try the arpad 3 regex? If you're using single address strings, it works beautifully, and is faster than the PHP solution.

arpad 3 results:

using regex

False Positive: 55
False Negative: 16
Total Test: 228

Strange. http://www.pgregg.com/projects/php/code/showvalidemail.php led me to believe ARPAD 3 was accurate. (And that dominicsayers isn't 100% either.)

What tests did you run against it?

I used Dominic's test set as it seemed to be more comprehensive. http://www.dominicsayers.com/isemail/

Ok, reading his page, he does seem more reputable. :)

Great Job Enzo!
By the way, how can I change strValidationError property without changing control source code?
I mean, how can I change "Invalid e-mail address" message directly from form controller?

For example QIntegerTextBox have a protected property such as $strLabelForInvalid.
In order to change a message I have to assign
$this->LabelForInvalid = QApplication::Translate('My message');

How can I do that with QEmailTextBox control?