No client side form validation in Joomla 3.2?

[Adam Rifat]

Is it just me or is the client side form validation broken since the update to 3.2.

Is this a result of the migration to Jquery from Moo?

Thanks,

Adam

[Matt Thomas]

Hi Adam,

Can you post a specific example? I can't say as though I remember as seeming broken.

Best,

Matt Thomas
Founder betweenbrain™
Lead Developer Construct Template Development Framework
Phone: 203.632.9322
Twitter: @betweenbrain
Github: https://github.com/betweenbrain

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/groups/opt_out.

[Adam Rifat]

Hi Matt,

Until 3.2 the fields and labels in my component were highlighted in red if they are required but empty and the form wouldn't submit. Now this doesn't happen.

The examples below demonstrate what I mean.

http://joomla25.cloudaccess.net/using-joomla/extensions/components/users-component/registration-form.html

In the 2.5 the required fields are highlighted when empty. Additionally, the email fields are highlighted if a valid email isn't enterd.

http://joomla32.cloudaccess.net/component/users/?view=registration

In 3.2 the fields are only highlighted when you enter an invalid email address. Otherwise, I think, the browser prompts that the fields is valid (I think because of the ARIA label).

Also, http://joomla32.cloudaccess.net/administrator/index.php?option=com_content&view=article&layout=edit&id=1 let's you submit an article with an empty title. In 2.5 you get an alert and it won't submit which was the behaviour with 3 until I updated to 3.2.

Am I missing something here?

Thanks,

Adam

[Achal Aggarwal]

Hi Adam,

In Joomla-cms 3.2 we are using the power of HTML5 to validate fields instead of validation.js which is used earlier. For me it is working at my site and at http://joomla32.cloudaccess.net/component/users/?view=registration. I tested it on Ubuntu 12.04 Chrome Version 26.0.1410.43 and Firefox 11.0.

The only thing required to make it work is HTML5 compatible browser. So please specify your testing env. But it may happen that validation of form fields doesn't work in admin(back end) area. I know the reason and still trying to solve it :(.

Thanks,

Achal

--
Achal

[Adam Rifat]

Working with latest versions of Chrome, Firefox and IE as well as older versions through 'F12'

Correct me if I am wrong but the validation is now handled by html5fallback.js? Is that right? So the field is highlighted as being required and then an additional message is displayed if the entered data is not correct (e.g. an invalid email address).

IE9 appears to fallback to the 'legacy' way where the invalid fields are displayed in a message box and the fields and labels themselves have classes added to them and they go red.

I take it this is why validate.js is still loaded, should this only be loaded if IE <10?

According to this : http://www.w3schools.com/tags/att_input_required.asp

required doesn't work on select lists which certainly breaks my component on the client side at least.

So I need to update my select list to number fields? Eh, seems a bit confusing...

What is the reason it may not work in backend?

Thanks,

Adam

[Adam Rifat]

Thanks Jurian!






On Wednesday, 27 November 2013 13:38:29 UTC, Jurian Even wrote:

Broken form validation for Joomla 3.2.0 is a known issue:

http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=32577&start=0

[Achal Aggarwal]

html5fallback.js is to support HTML5 in non-supported browsers. validation.js is present only for bwc not to the browser but for the existing extension. 

Check this fiddle http://jsfiddle.net/Kd7s6/1/. It seems select list supports required and in joomla check this also http://googlesummerofcode2.cloudaccess.net/index.php/demo#required 

The reason browser validation is not working because in backend the buttons which are doing postback are not present in the form  whose data is being sent in the post request. So there is a workaround to solve this is to add a hidden submit button in the form and then call click event on it just before we start doing any calculation on data (check Joomla.submitform media/system/js/core.js).

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/groups/opt_out.

--
Achal

[Adam Rifat]

Hello Achal,

I am starting to see the light.

In browsers that understand html5 form fields the browser performs all validation natively (based on the type and required attribute). Gotcha!

For other browsers (I guess mainly IE < 10) the html5fallback script is used. This adds the 'required' class to the form fields and then the validate.js validates the form as is ever did. I think that is more or less correct?

Okay, I see why it's not working in the backend. The buttons aren't inside the <form/>.

So basically, the template needs reworking to incorporate the toolbar inside the form it's dealing with. Is this just a case of adding the toolbar layout to the component template rather than the admin template. Similar has been done for the submenu. For example in articles list view:

<?php if (!empty( $this->sidebar)) : ?>
    <div id="j-sidebar-container" class="span2">
        <?php echo $this->sidebar; ?>
    </div>
    <div id="j-main-container" class="span10">
<?php else : ?>
    <div id="j-main-container">
<?php endif;?>

Can we do similar for the toolbar?

<?php echo JToolbar::getInstance('toolbar')->render('toolbar'); ?>

That actually seems to work if you remove the onclick handler from the button. Submenu is done via a layout so why not the tool bar as well?

Thanks,

Adam

[Adam Rifat]

The patch supplied in the tracker mentioned above seems to revert the behaviour so that at least we get some form validation on the backend.

Achel, do you have any more thoughts on how we can implement this html5 stuff in the backend? Seems to me it would need rewriting the templates, is there another way?

[Achal Aggarwal]

Take a look on https://github.com/Achal-Aggarwal/joomla-cms/compare/backend-form-validation and if you want to test https://github.com/Achal-Aggarwal/joomla-cms/compare/backend-form-validation.diff

Notice that I modified uncompressed version of core.js

[Adam Rifat]

Thanks Achal, will test this ASAP.

Did you have any thoughts on how the html5 validation could be closely integrated? As the buttons are outside the form that they are related to it seems as though the template needs rewriting to implement the html5 validation in the backend. Do you agree (not asking you to do it, just if you agree)?

Also, I noticed a bug with the html5fallback script where the class attribute 'required' is removed if the field is valid. So that if a field has class='required' if a value is set and then removed the class attribute is removed. I commented on this in the above tracker item mentioned in this post. Or if a required field is loaded with a value then the required class is also removed so that if the field becomes empty it submits without an error.

Although, I guess that is a separate issue. Are you aware of that as well or should I open a new tracker, git hub bug report and/or JIssue? ;-)

Thanks,

Adam

[Achal Aggarwal]

Thanks Adam for finding that bug in html5fallback.js . I corrected it and some other things in html5fallback.

Please take a look on https://github.com/Achal-Aggarwal/joomla-cms/compare/form-validation.

In this branch if you check commit list, in the last commit I made some changes in com_users at backend, so now if we click on "Save" when User Name is empty browser do validation check and it reports error and in any other component at backend, validation.js is doing its magic.

I just read you comment on the tracker http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_id=8103&tracker_item_id=32577 and commented there also.

Achal 

[Kelsang Pagchen]

Hi,
I've tried the new branch as proposed by Achal and it does improve the backend server-side field validation (as there was none before his patch), but I am not able to trigger custom field validation anymore. Also, field validation is only happening one at a time instead of showing all invalid fields as previous joomla version did.

Tested on a Mac with Firefox v26, Chrome and Safari latest version.
I would have thought these browsers won't need the html5fallback.js to be loaded as they are html 5 compatible, but I can see the html5fallback being loaded anyway.

I thought I would share my testing. Thanks for all your effort.

[Adam Rifat]

@Kelsang

You say improve the server side field validation but this thread relates specifically to client side (e.g. on the browser). Assume you meant client side?

Field validation in html5 is handled by the browser and only does one field at a time. I read some research somewhere that this is a more intuitive approach than the traditional show all invalid fields in a red box approach.

If custom fields are now not validating on the client side this is a regression and a b/c break. Achal, are you able to confirm whether custom fields should still validate as before?

Agree with you about the fallback script. Suppose the alternative would be to let older browsers fall back to server side validation?

Anyway, at least this gives us the opportunity to test our server side validation...

[Kelsang Pagchen]

Yes client-side !!! server-side is working ok (as we discovered with this 'new' opportunity to test it ;-)

I don't see why not showing all invalid field at once (when form is submitted) would be less intuitive: At least the user can change all mistakes at once before resubmitting the form.
I can see that we could show the red invalid markup only when the input field is on focus to tell the user not to move to next field until mistake is fixed, but what if a user submit a form without being into each and every input field ? Or maybe I haven't tested this new way enough to see its benefits.

One thing that has always bugged me with client-side validation in Joomla is that invalid fields in different Tabs (of fieldsets in form.xml) can only be discovered when user manually opens the tab.
It would be nice to have the parent tab to 'inherit' the invalid class in order to indicate where the invalid field is (for example by changing the tab name color to red). Or maybe one reason to do a one-by-one field validation is to bring focus to the invalid field directly, have user correct it, re-submit, go to next invalid field if any, etc.

Anyway, I am working on a backend-exclusive component with needs to extend user profile. As of now, I still have much to work on before focusing on client-side validation for my extended user profile, but if this is not solved when I'll be working on it and come out with any solution, I'll post it here.
Cheers,

[Adam Rifat]

See http://alistapart.com/article/inline-validation-in-web-forms which advocates inline form validation which as far as I can tell is the 'html5' way.

If the user submits the form before it's completed and the field has a required attribute then the browser won't submit the form (assuming it's a 'modern browser'). This is partly where all the confusion in this thread stems from. In the previous versions the field needed class="required" but now some browsers understand required="true" and handle that natively without javascript. I think.

As for highlighting fields in a non active tab I've got no idea how to handle that one. I guess you would need to create a multi stage form or have the tabs as separate urls with their own controllers.

[Achal Aggarwal]

@Kelsang, as Adam mentioned new browsers implement html5 form field validation natively which is substantially faster than javascript polyfils. The current scenario is backend validation is not working at all. And the proposed branch form-validation enables that.

@Kelsang, @ Adam, I checked yes it is true that for custom field like checkboxes and radio no validation at client is present because that validation is done by validation.js . I did some changes in html5fallback.js and these custom fields can be supported at onchange basis means they are only validated when user change their status/value in the old validate.js fashion way.

[Kelsang Pagchen]

@Adam: thanks for the link, I will take a look at that for sure.
@achal: Will checkout your new changes, thanks !

[Achal Aggarwal]

I didn't pushed new changes to github. Will do asap.

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/groups/opt_out.

--
Achal

[Adam Rifat]

Checkboxes and radio buttons are one thing but I think Kelsang was referring to the custom validation rules that you could define via javascript.

For example on your form field you would have: class="validate-vat"

and that would call a javascript function called vat which validated the form value.

I haven't checked but if these rules are working then that is a b/c break.

[Achal Aggarwal]

I guess then we can add custom handler functions in html5fallback.js . Because it is really getting messy when we are trying to have html5 validation with non supported browser compatibility with custom validations. Each of the function is provided by different plugin and when I tried to run each after one another, it doesn't look good.

Fortunately, Joomla provides behavior.formvalidation API to include validation.js in the form. So if extension developers are not using validation.js and following http://docs.joomla.org/Client-side_form_validation then we can have clean & effective solution
for client side validation for once and all.

html5fallbac.jsk does what validation.js does except custom handlers. So I am going to modify it little bit and clean it for custom validation.

[Adam Rifat]

I'm probably missing the point but is html5fallback.js needed at all?

As long as JForm adds the appropriate classes (e.g. class="required" class="validate-this-and-that") to the form and also the relevant html5 attributes all we would need is to detect whether the browser is capable of html5 form validation. Jurians PR above fixed the issue with class="required" not being added.

So validate.js stays as it was and picks up forms with class="validate" and validates as it ever did.

Then all you need is a feature detection which removes that class from the form for html5 compliant browsers so that the browser validation kicks in?

Would that work?

[Achal Aggarwal]

What validation.js do?
=> do validation on the basis of presence of a specific class like required, validate-username, validate-password, validate-numeric, validate-email and valdaite-xxx (for custom handlers) with form-validate class present at form tag.
=> provide validation for missing value in checkboxes and radio field.

What html5fallback.js do?
=>provide support for html5 attributes like placeholder, required, autofocus, multiple, formnovalidate, pattern
=>provide support for html5 fields like  email, url, number

So I guess there is some overlapping of functions provided by each of them. IMO it is better to merge a smaller set to somewhat bigger one. Like in this case validation.js can be merged into html5fallback.js easily than the otherway around. I also thought about this when I was developing html4fallback. I first thought of doing exactly what you just mentioned. But after consulting with my mentors I came to conclusion to not to do so.

If you want some demo like structure, give me some time. I can show you what I meant by mapping validation.js onto html5fallback.js

[Adam Rifat]

Thanks for your paitience Atchal and thanks for the clarifications.

So the polyfills are required because html5 elements have been introduced to the CMS? I can see the email fields type is used in the edit user form.

<input type="email" name="jform[email]" class="validate-email inputbox" id="jform_email" value="" size="30" required="" aria-required="true" aria-invalid="false">

I just opened this in IE8 and I get

<INPUT name=jform[email] class="required validate-email inputbox" id=jform_email aria-invalid=false aria-required=true type=text size=30 required="">

So surely in this case without html5fallback this would just get *ahem* validated by validate.js as a normal text field?

Without html5fallback what would break in the CMS apart from placeholders?

[infograf768]

@Achal
Please look at this undesired regression:
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=33105&start=0

[Achal Aggarwal]

@JM I commented on the tracker what I think about it.

I decided to look back at html5fallback.js 10 days ago and modified its structure a bit. https://github.com/Achal-Aggarwal/joomla-cms/compare/rebuild-html5

If developers are reading http://docs.joomla.org/Client-side_form_validation and using this validation API then we have no problem in merging validation.js in to html5fallback.js

Branch rebuild-html5 is not completed yet. Need few days more to test it more exhaustively.

@Adam I can't really guess now what would break in CMS now like placeholder if we remove html5fallback but I am sure that the solution I am working on would minimize all problems and give a sleek validation API.

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/groups/opt_out.

--
Achal

[Richard McDaniel]

@Achal I am still experiencing problems with the client-side validation not scaling well on 3.2.1. I looked at both validate-uncompressed.js and the validate-jquery-uncompressed.js and it still is looping through every label multiple times instead of doing it just once. This makes the performance O(n^2) which is pretty bad and makes my browser freeze.

[Angie Radtke]

@ Achal

great that you are working on that.
One question , I saw some strings

requiredMessage : " is required."
invalidMessage : " is not valid.",
patternMessage : " doesn't match pattern.",

Is it possible to use JText::script()- to make these strings translatable, or is the an other possibility to do that?

Bye Angie

[Achal Aggarwal]

@Richard

I don't know what happened to that PR. But consider that the jquery version of validate.js is not in use. We are still using mootools version. After looking at code it seems that we are not using optimized code for calculating label references. If you remember the PR number please give it to me. 

@Angie

Take a look on https://github.com/Achal-Aggarwal/joomla-cms/blob/a423ec229143dbf49c79ec99613e9be379b064ad/media/system/js/html5fallback-uncompressed.js .

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send an email to joomla-dev-cms@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/groups/opt_out.

--
Achal

[Angie Radtke]

Hi Achal

GREAT :-)))

at the moment im working on an summary about accessibele forms using
html5 having an fallbackscript as well.
It is very interesting how different the behavior of the various
screenreaders and browsers is.
For example:
chrome is displaying the title of the inputfield in its native HTML5
validation message, behind the normal message. This behavior is very clever.
On the other hand screenreader cobra is ignoring the text of the label
element and speaks out this title instead. If there is no title cobra
will read the contents of the label-element.
If we decide to use the title-attribute of the input-element we
should think very carefully about the content of the title-attribute .

Safari: HTML-Validation is not full supported, so the fallback will be used.
Have you checked the form with voiceover on an Iphone? It is very
interesting where the focus is when the error message will be displayed.

It is also very interesting who wins when we are using the native
validation, Wai Aria and the Falllback simultaneously.
If there is no browser switch and an additional Javascript is used and
this is triggered by the onsubmit event,the native HTML5 validation
comes to to train if the browser supports it.
This a clever behavior as well.

Now I will check what will happen if we use aria-attriutes as well. (
screenreaders)
I actually expect that the aria-attributes and the HTML5 required
attribute will be readboth.
If this is the truth we will have semantic overkill.

Bye Angie

> @Richard
>
> I don't know what happened to that PR. But consider that the jquery
> version of validate.js is not in use. We are still using mootools
> version. After looking at code it seems that we are not using
> optimized code for calculating label references. If you remember the
> PR number please give it to me.
>
> @Angie
>
> Take a look on
> https://github.com/Achal-Aggarwal/joomla-cms/blob/a423ec229143dbf49c79ec99613e9be379b064ad/media/system/js/html5fallback-uncompressed.js .
>
>
> On Wed, Jan 15, 2014 at 10:56 PM, Angie Radtke
> <a.ra...@derauftritt.de <mailto:a.ra...@derauftritt.de>> wrote:
>
> @ Achal
>
> great that you are working on that.
> One question , I saw some strings
>
> requiredMessage : " is required."
> invalidMessage : " is not valid.",
> patternMessage : " doesn't match pattern.",
>
> Is it possible to use JText::script()- to make these strings
> translatable, or is the an other possibility to do that?
>
> Bye Angie
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from it,

> send an email to joomla-dev-cm...@googlegroups.com
> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.

> To post to this group, send an email to

> joomla-...@googlegroups.com
> <mailto:joomla-...@googlegroups.com>.

> Visit this group at http://groups.google.com/group/joomla-dev-cms.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
> --
> Achal

> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to joomla-dev-cm...@googlegroups.com.
> To post to this group, send an email to joomla-...@googlegroups.com.

> Visit this group at http://groups.google.com/group/joomla-dev-cms.
> For more options, visit https://groups.google.com/groups/opt_out.

--

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------
ausdrucks | STARK
B�ro f�r Kommunikation
Angie Radtke
Fon: 0049 (0)228-6420467

Twitter: https://twitter.com/AngieRadtke

Publikationen:
Joomla!-Templates entwickeln
Barrierefreie & attraktive Designs von Entwurf bis Umsetzung
von Angie Radtke
Addison-Wesley

Barrierefreies Webdesign. Attraktive Websites zug�nglich gestalten
von Angie Radtke
Addison-Wesley

[Adam Rifat]

Hi All,

I wonder if there is an update with this in light of Joomla 3.3 and the removal of mootools? How is the client side validation looking for the backend these days?

Thanks in advance,

Adam

B�ro f�r Kommunikation

Angie Radtke
Fon: 0049 (0)228-6420467

Twitter: https://twitter.com/AngieRadtke

Publikationen:
Joomla!-Templates entwickeln
Barrierefreie & attraktive Designs von Entwurf bis Umsetzung
von Angie Radtke
Addison-Wesley

Barrierefreies Webdesign. Attraktive Websites zug�nglich gestalten
von Angie Radtke
Addison-Wesley

[Achal Aggarwal]

Hi Adam, thanks for posting request for an update. I forgot to keep track of this thread. I checked 3.3-dev branch and in there we have backend client side form validation through validation.js

The reason for not having html5 validation is the old issue, "button not in form". Another  issue is that it is not right to run two client side validation APIs which renders errors differently. 

I read several comments about providing html5 form fallbacks. In most of them I found that people recommends that web sites should not do the work required from a browser. Means users would continue to use old backdated browsers until they feel the difference between new and old ones.

Still, I have something for next release (the one in which we could break b/c). For this release I would try to propose one client side validation API which will support custom validations (currently done by validation.js) with (limited) fallback for html5 form fields.

I think we should not solely depend on client side form validation, as it might be case that user has turned js off. I think the best approach would be to just describe validation basis in the field description (in xml) and get validation for both client side as well as server side accordingly.

Now the question is what would happen if html5 field attributes are used in backend forms. So ans. is, html5 is designed in a way that browser itself fallback if the attribute or field is not supported by it. No need to worry there, we just have to make sure to enable server side validation.

Stay tuned. :)

--
Achal

[Adam Rifat]

Hi Achal,

Thanks for the update.

I agree with you, I don't really think we need to provide fallback for browser that don't support html5 forms as the server side validation should prevent forms being submitted anyway.

Why can't we move the buttons into the form. Surely this would be the most logical approach?

Thanks,

Adam

[Achal Aggarwal]

I checked and found out that toolbar is a module. And I really don't know how we can move it under a component's form tag.

Although the way we are using currently to submit form would suffice with this patch.

This is the patch that should do the work :- https://github.com/Achal-Aggarwal/joomla-cms/compare/rebuild-html5.patch

Now this needs extensive testing in different browsers and in different areas. I checked in IE8 and Chrome ver 33.0.1750.146
I am going to create a tracker for this and try to push it in community.

This time I am not going to leave it behind. I will see it through until it is fixed.

Note:- I checked again and there is NO backend form validation for required fields. I think earlier I got cached result.

--
Achal

[Achal Aggarwal]

I created a tracker item for this 

http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=33596

Please do test this and post result/feedback either here or on tracker.

--
Achal

[Adam Rifat]

Actually it seems pretty easy to move the toolbar into the form. Consider the isis template:

https://github.com/joomla/joomla-cms/blob/staging/administrator/templates/isis/index.php#L185

The above 10 lines or so adds the toolbar to every admin page except the control panel of the admin area.

If you look at the mod_toolbar module:

https://github.com/joomla/joomla-cms/blob/staging/administrator/modules/mod_toolbar/mod_toolbar.php#L12

it's basically a call to render an instance of the 'toolbar' object which is generated in the component view.html.php file.

I just copied this into the article edit view of com_content:

<form action="<?php echo JRoute::_('index.php?option=com_content&layout=edit&id=' . (int) $this->item->id); ?>" method="post" name="adminForm" id="item-form" class="form-validate">

<a class="btn btn-subhead" data-toggle="collapse" data-target=".subhead-collapse"><?php echo JText::_('TPL_ISIS_TOOLBAR'); ?>
  <i class="icon-wrench"></i></a>
<div class="subhead-collapse collapse">
  <div class="subhead">
    <div class="container-fluid">
      <div id="container-collapse" class="container-collapse"></div>
      <div class="row-fluid">
        <div class="span12">
          <?php echo $toolbar = JToolbar::getInstance('toolbar')->render('toolbar'); ?>
        </div>
      </div>
    </div>
  </div>
</div>
...
</form>

and now I get a tool bar showing up which is *inside* the form. This could easily be abstracted into a layout and reused across all core templates. 

I'm not sure if there would be any b/c issues with doing this but I can't see any. Doing that you would add 'html5' browser validation, as far as I can tell? You might also want to offer a client side validation library to maintain backwards compatibility...oh no, wait, we've already broken client side validation anyway...

Does that make sense to anyone?







Personally, I think once the MooTools dependency is removed it should be possible to to drop in one of the jQuery client side validation plugins quite easily.

Have you tested much on a clean install of 3.3 beta? Would be interesting to see what happens there.

[Achal Aggarwal]

Yeah, you are right. We can move toolbar inside "form". But did you noticed once we remove it from index.php of a template we have to include it in each admin component. And 3rd party admin components and templates would also be need to  modify. This would break backward compatibility.

The patch I proposed is "NOT" doing its validation on its on unless browser doesn't support it. It is just rendering error messages the way we were getting them before. It is also taking into account of custom fields and custom handlers in sequence. 

Let me explain it to you. If we do validation on form, on submit by clicking on a submit button present in the form then browser will do validation by calling checkValidity() method of "form" object. Now we have two ways, either run our custom validation before checkValidity() or after that. Example 

<input type="text" required> <!-- First Field  -->

<input type="text" class="validate-username" required> <!-- Second Field  -->

<fieldset class="checkboxes" required> <!-- Third Field  -->

 ..checkboxes..

</fieldset>

<input type="text" pattern="[A-Z][0-9]" required> <!-- Fourth Field  -->

 

Assume whole form is blank, none of the fields are filled.

Now if we run checkvalidity()  then browser will render error for "First Field". If we filled that out then it will render error for "requiredness" of "Second Field". If we fill "Second Field" with invalid username then it will show error for "Fourth Field". That means it will skip fields with custom validation. 

So it will be very absurd, throwing validation errors in interleaving manner. API be linear in validating those fields. IMHO it is not possible with checkvalidity() method to do it. Luckily html5 also provides validityState object which return validity status of a field. This validation is done by browser natively on field value change event. I am using this one to validate each field linearly.

So no point in using jQuery validation plugin or any other html5 support plugin.

I have tested this patch on Joomla3.3.0-Beta2 with chrome ver 33.0.1750.146 using xml form of http://googlesummerofcode2.cloudaccess.net/index.php/demo. For testing I am attaching the xml.

Note:- I forgot to add IDN validation fix, what JM added in validation.js. No worries, I have added it now.

Please do test it. I am gonna test it on firefox 24, firefox 4, IE8 and maybe chrome 1 if possible.

--
Achal

[Adam Rifat]

That's true, moving the toolbar would break a lot of 3rd party components that use the isis template.

In that case we need to find a way to move the button toolbar in a backwards compatible way...

https://groups.google.com/d/msg/joomla-dev-cms/VOqfoxT4LQU/pSX7lWzWsxEJ

Perhaps that can be done with a template parameter or a plugin?

[Achal Aggarwal]

Moving button inside or using it from outside of form doesn't effect the behavior of html5falllback.js now. Any approach can be used to add validation to the form. Give it a try.

-

Achal

[Adam Rifat]

Hi Achal,

What is the situation with html5fallback.js now?

I have recently stumbled across (http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=33312) which submits the placeholder as a form value due the the polyfill included with html5fallback. This is unfortunate as it effectively breaks the majority of list view in IE9 or below.

Thanks,

Adam

[Achal Aggarwal]

Hi Adam,

I feel bad for saying that there is no progress since then. http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=33596 is still in pending state. It needs testers.

I also mentioned it in each tracker that I found related to client side form validation on joomlacode, to attract testers but have no success.

If you get some time please do test it. I tested most of its part on IE9 and IE8 and some older version of firefox and chrome. But as the developer of plugin my tests doesn't count.

Kind Regards

Achal

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.

To post to this group, send email to joomla-...@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-cms.

For more options, visit https://groups.google.com/d/optout.

--
Achal

[Adam Rifat]

Hi Achal,

I'm also interested in:

http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=33312
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=32777&start=0

The above bug means the 'Search tools' feature is effectively broken on all list views (e.g. Articles) in IE9. This is because onclick='this.form.submit()' on the filter select dropdowns doesn't trigger the javascript 'submit' event so the placeholder value cannot be cleared before the form is submitted.

The cleanest way to address this is to simply remove the placeholder polyfill or replace it for one that does not set a value. Do your changes to html5fallback address this issue?

There is a lot to test in your merged validate and fallback scripts. It would probably take someone at least a day to test it thoroughly. What would be the advantage of having one script instead of two?

Thanks,

Adam

[Achal Aggarwal]

Adam, as you mentioned form.submit() doesn't trigger callbacks registered on form submit event through javascript. So we can't fix this issue unless all instances of form.submit() is converted to jQuery(form).sumbit().

Another solution is to remove placeholder polyfil at all. Replacing it with another placeholder polyfill wouldn't help. All of them set a value, which needs to be cleared on submit, same as our case.

My solution fixes tracker no. 33312 but 32777 didn't get fixed by it. To particularly fix search tools issue I have a solution, soon going to post it on tracker but there is no generalized solution for form submit using `form.submit()`.

I understand that it is very difficult to thoroughly test this plugin, so we can do it in parts. For example you can test only placeholder functionality in IE8 & IE9. Problematic browsers are IE8, IE9, and some middle age chrome, firefox versions which doesn't support html5.

Regards

Achal

[Achal Aggarwal]

I personally favors the idea of not providing poly-fill for placeholders (at least), even if we are providing fallback for html5 form validation.

--
Achal

[rolandd]

Hello Achal,

Could you push the PR here:
https://github.com/Achal-Aggarwal/joomla-cms/compare/rebuild-html5

That way we will get a tracker item on the new issue tracker and I can comment on it with test results.

Does your PR supersede https://github.com/joomla/joomla-cms/pull/3484 ?

Thanks.

[Achal Aggarwal]

Hi Roland,

I'll rebase the branch on current staging and make a PR for https://github.com/Achal-Aggarwal/joomla-cms/compare/rebuild-html5

About PR3484, as it is mentioned in the PR it is basically to call the callback attached on form submit by other js libs, it would be nice to have jquery version. After adding jQuery version we can remove the onsubmit call and form.submit(); from the end. I'll make the changes to core.js as well.

Regards

Achal