Definitely need to think this through. Right now, nothing on the front end is using JForm, so if we do client side validation, we'll have to roll something ourselves, jQuery preferred because of Bootstrap use and whatnot. Or, find something properly licensed and use that.

Server side validation we get via JTableIssue::check(), which is called during the save process. We just need to handle redirects on that as well.

As far as I know,
http://bassistance.de/jquery-plugins/jquery-plugin-validation/ is one of
the more advanced and actively developed/supported jQuery plugins. I've
used it quite a bit and woudl be happy to implement it. It is licensed
MIT/GPL.

Best,

Matt Thomas
Founder betweenbrain http://betweenbrain.com/™
Lead Developer Construct Template Development
Frameworkhttp://construct-framework.com/
Phone: 203.632.9322
Twitter: @betweenbrain
Github: https://github.com/betweenbrain

On Fri, Jan 4, 2013 at 5:35 PM, Michael Babker notifications@github.comwrote:

Definitely need to think this through. Right now, nothing on the front end
is using JForm, so if we do client side validation, we'll have to roll
something ourselves, jQuery preferred because of Bootstrap use and whatnot.
Or, find something properly licensed and use that.

Server side validation we get via JTableIssue::check(), which is called
during the save process. We just need to handle redirects on that as well.

—
Reply to this email directly or view it on GitHubhttps://github.com/JTracker/jissues/issues/48#issuecomment-11903057.

BUMP
We could use this definitely now ;)

v1 worthy?

Would be nice to have a general form validation method but - not a stopper for v1

Hmm, I can't find - does jQuery Validation Plugin provide multilingual support?

That's a great question. In my experience with solutions from that developer, and with the plugin itself, I would imagine that it may. Generally speaking, it checks for patterns versus language specific strings. Would any of the "List of built-in Validation methods" at http://jqueryvalidation.org/documentation/ be language specific?

My initial thought is that we'd be doing for basic validation such as required and email. There are also additional methods available (https://github.com/jzaefferer/jquery-validation/tree/master/src/additional) and localization availble (https://github.com/jzaefferer/jquery-validation/tree/master/src/localization) that can be implemented in a language specific way.

Seems that localization files could be loaded based on the user selected language.

I've flagged this a v1 requirement. We should have basic validation in place on the add and edit views so we aren't getting deep into the store process and failing when we can catch it early.

So currently we have in Add form:

• Title
• Description
• Priority (default is 3)
• Build

What are the validation rules should be for each of them? My option:

• Title (required; min: 5; max: 60; characters: a-zA-Z0-9-+_@&$#%)
• Description (min: 100; max: 1000)
• Priority (required; default should be empty not 3)
• Build (required; min: 3; max: 10)

Each of those 4 fields should be required. I'd say title should be 50 characters max (the same length as a short commit message), description I don't think we should impose an upper limit on unless it matches that of GitHub. Priority defaults to 3 (Medium) which is the same behavior as Joomlacode (most issues, if prioritized properly, wouldn't go higher than 3, and the voting system now allows people to opinionate on the importance to them). Build we made as a 25 character varchar which is more than enough for that (typical uses would be master or 2.5/3.1).

What about allowed characters in Title?

I'd add . and ! otherwise it looks good to me

On Monday, August 19, 2013, Dmitry Rekun wrote:

What about allowed characters in Title?

—
Reply to this email directly or view it on GitHub#48 (comment)
.

I'd add ()/[]= and probably others.. not sure about a length limitation for any field.. Looking at the current j.org tracker, there are actually very few issue titles with less than 60 chars....

For the build field, "power users" might use the actual SHA instead of just "master" - which is a 40 character varchar..

I think the client side validation should be more an "aid" for the user rather than an annoyance, so I think we should keep it at a bare minimum to avoid scaring people away...

That's a use case we didn't think of for build. So I guess we make it a 40
char max and roll with it.

My suggestion on the titles is so that we get a very clear short title, we
place a feasible upper limit. These end up being the commit messages and
CHANGELOG entries (until we can wean folks away from that process ;-) ) so
they should be better than "bug in content.php".

Client validation should be extremely simple, just making sure we have data
where needed and in cases where there's an upper limit that it isn't
exceeded. Let the server (Table classes) handle the rest.

On Monday, August 19, 2013, Nikolai Plath wrote:

I'd add ()/[]= and probably others.. not sure about a length limitation
for any field.. Looking at the current j.org tracker, there are actually
very few issue titles with less than 60 chars....

For the build field, "power users" might use the actual SHA instead of
just "master" - which is a 40 character varchar..

I think the client side validation should be more an "aid" for the user
rather than an annoyance, so I think we should keep it at a bare minimum to
avoid scaring them away...

—
Reply to this email directly or view it on GitHub#48 (comment)
.