field format checker in issue editor ...

View: New views
2 Messages — Rating Filter:   Alert me  

field format checker in issue editor ...

by hussayn :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi;

I have implemented a small add on feature to Scarab. A field checker based on regular
expressions. I originaly wanted to use intake for this purpose, but i could not find out,
how to define dynamic rules with intake. so i modified ReportIssue.java and ModifyIssue.java
instead. The concept is easy:

When you define a new attribute, you now can define an associated regular expression,
which is used to check the field input for validity. If the format field is kept empty in the attribute
definition, then no field checking is done during issue creation/modification. Of course the regex
is stored in the database along with the attribute.

Now there is one little caveat with this :

When a user enters a wrong value, an error message is generated "invalid pattern used for field xxx"
and the regular expression is shown. Now this is good for developers, but bad for customers.
Customers seem to not know about regular expressions. for instance:

    invalid value in field "daytime": "12.20". expected format is "\d\d?:\d\d?"

Now it would be much more convenient to see something like this:

    invalid value in field "daytime": "12.20". expected format is "nn:nn"

which more people tend to understand immediately.


So i think about adding yet another field to the Attribute definition, namely "patternHint" with
a human  readable representation of whichever format is expected.  And as another goodie this
value could be used as default value for the field:

Lets assume, the "patternHint" would be set to "nn:nn". Now Scarab uses this value as default
in the daytime field and if the user does not change the value, scarab will complain:

    invalid value in field "daytime": "nn:nn". expected format is "nn:nn"

Now i could derive from the fact, that the value is invalid AND it is equal to the default value,
that the correct error message would be:

   Please type a valid value into the field "daytime" and use the given format "nn:nn"

All this can be done with Scarab and very little logic. Do you think this is a good idea or does
it feel more like a hack ?

When i started this feature, i also thought it might be a good idea to invent a new fieldType
"daytime" but i quickly decided, that such an implementation is not flexible enough. So i ended
with the regex implementation, which could be used in many other circumstances too.

otoh having a daytime widget similar to the javascript-calendar would be something valuable
in itself too...

comments appreciated.

regards, hussayn

Re: field format checker in issue editor ...

by Johannes Höchstädter :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi,

I would appreciate this feature, having optional constraints (regex
patterns), for some types of attributes.

I like the second idea you had, by applying the optional regexp pattern
as an additional filed for every attribute, best.

cheers

Hussayn Dabbous schrieb:

> Hi;
>
> I have implemented a small add on feature to Scarab. A field checker based
> on regular
> expressions. I originaly wanted to use intake for this purpose, but i could
> not find out,
> how to define dynamic rules with intake. so i modified ReportIssue.java and
> ModifyIssue.java
> instead. The concept is easy:
>
> When you define a new attribute, you now can define an associated regular
> expression,
> which is used to check the field input for validity. If the format field is
> kept empty in the attribute
> definition, then no field checking is done during issue
> creation/modification. Of course the regex
> is stored in the database along with the attribute.
>
> Now there is one little caveat with this :
>
> When a user enters a wrong value, an error message is generated "invalid
> pattern used for field xxx"
> and the regular expression is shown. Now this is good for developers, but
> bad for customers.
> Customers seem to not know about regular expressions. for instance:
>
>     invalid value in field "daytime": "12.20". expected format is
> "\d\d?:\d\d?"
>
> Now it would be much more convenient to see something like this:
>
>     invalid value in field "daytime": "12.20". expected format is "nn:nn"
>
> which more people tend to understand immediately.
>
>
> So i think about adding yet another field to the Attribute definition,
> namely "patternHint" with a human  readable representation of whichever
> format is expected.  And as another goodie this value could be used as
> default value for the field:
>
> Lets assume, the "patternHint" would be set to "nn:nn". Now Scarab uses this
> value as default in the daytime field and if the user does not change the
> value, scarab will complain:
>
>     invalid value in field "daytime": "nn:nn". expected format is "nn:nn"
>
> Now i could derive from the fact, that the value is invalid AND it is equal
> to the default value, that
> the correct error message would be:
>
>    Please type a valid value into the field "daytime" and use the given
> format "nn:nn"
>
> All this can be done with Scarab and very little logic. Do you think this is
> a good idea or does it feel
> more like a hack ?
>
> When i started this feature, i also thought it might be a good idea to
> invent a new fieldType "daytime" but i quickly decided, that such an
> implementation is not flexible enough. So i ended with the regex
> implementation, which could be used in many other circumstances too.
>
> otoh having a daytime widget like the calendar would be something valuable
> in itself ...
>
> comments appreciated.
>
> regards, hussayn
>  

--

Johannes Höchstädter

memoComp Software Engineering & Consulting
Frank Freund
Michelsberg 28
65183 Wiesbaden
Germany
Fon +49 (0)611 9320054
Fax +49 (0)611 9320059
Amtsgericht Wiesbaden HRA 4304

------------------------------------------------------
http://scarab.tigris.org/ds/viewMessage.do?dsForumId=455&dsMessageId=2398818

To unsubscribe from this discussion, e-mail: [dev-unsubscribe@...].