Consistent required field indicators

[Bilgin Ibryam-2]

I see 3 different ways to indicate required fields in the system:

1. "asterix" generated from form widget when required-field="true" (55
occurrences + 346 auto-fields-service occurrences which also have some
required fields)
2. "gray background of text field " done by widget-style="required" (122
occurrences )
3. "required" the label is set in FTLs and also in form widgets using
tooltip="${uiLabelMap.CommonRequired} (280 occurrences )
There are also different combinations of above 3 ways

I don't know why there are 3 different ways and what is the current best
practice but I think we should agree on one way to indicate required
fields and use it all over the framework.

Here is what I propose:
Remove all the ${uiLabelMap.CommonRequired} tooltips from form
definitions. The tooltip should be used to provide other information as
it is for not required fields (the purpose of the field, the format)
Remove all the widget-style="required" from form definitions.
If a field is required, (on form widget) set only its attribute
required-field="true". In cases when the form is based on service
definition (auto-fields-service) it is not neccessary to set this
attribute. Then  no need to add tooltip="${uiLabelMap.CommonRequired} or
widget-style="required" attibutes on the form definition. The renderer
should decide how to indicate the required field.

Change form renderer, so if a field is required it is indicated by
asterix plus required style ( same as widget-style="required")

WDYT?

Bilgin Ibryam

[Bob Morley]

+1 - I think properly modeling the field using the required-field  
attribute makes perfect sense.  I would think our html form renderer  
implementation should probably just apply a class "required" at render  
time and the visual should be handled by css.

On Apr 23, 2010, at 2:35 PM, Bilgin Ibryam wrote:

> Here is what I propose:
> Remove all the ${uiLabelMap.CommonRequired} tooltips from form  
> definitions. The tooltip should be used to provide other information  
> as it is for not required fields (the purpose of the field, the  
> format)
> Remove all the widget-style="required" from form definitions.
> If a field is required, (on form widget) set only its attribute  
> required-field="true". In cases when the form is based on service  
> definition (auto-fields-service) it is not neccessary to set this  
> attribute. Then  no need to add tooltip="$
> {uiLabelMap.CommonRequired} or widget-style="required" attibutes on  
> the form definition. The renderer should decide how to indicate the  
> required field.
>
> Change form renderer, so if a field is required it is indicated by  
> asterix plus required style ( same as widget-style="required")
>

[Adrian Crum-2]

--- On Fri, 4/23/10, Robert Morley <[hidden email]> wrote:
> +1 - I think properly modeling the
> field using the required-field attribute makes perfect
> sense.  I would think our html form renderer
> implementation should probably just apply a class "required"
> at render time and the visual should be handled by css.

I believe I was the one who introduced the required CSS class and that was my reasoning - have the style sheet determine what a required field looks like.

At the time, the asterisk was being used to indicate a required field. The problem was, most forms didn't have an explanation as to what the asterisk meant. So the result looked odd.

No "best practice" was discussed or decided upon. I just put the new CSS class in the style sheet and I left it to the community to decide by using it or not.

I like the idea of service definitions driving the required fields.

-Adrian

>
> On Apr 23, 2010, at 2:35 PM, Bilgin Ibryam wrote:
>
> > Here is what I propose:
> > Remove all the ${uiLabelMap.CommonRequired} tooltips
> from form definitions. The tooltip should be used to provide
> other information as it is for not required fields (the
> purpose of the field, the format)
> > Remove all the widget-style="required" from form
> definitions.
> > If a field is required, (on form widget) set only its
> attribute required-field="true". In cases when the form is
> based on service definition (auto-fields-service) it is not
> neccessary to set this attribute. Then  no need to add
> tooltip="${uiLabelMap.CommonRequired} or
> widget-style="required" attibutes on the form definition.
> The renderer should decide how to indicate the required
> field.
> >
> > Change form renderer, so if a field is required it is
> indicated by asterix plus required style ( same as
> widget-style="required")
> >
>

[Adam Heath-2]

Adrian Crum wrote:

> --- On Fri, 4/23/10, Robert Morley <[hidden email]> wrote:
>> +1 - I think properly modeling the
>> field using the required-field attribute makes perfect
>> sense.  I would think our html form renderer
>> implementation should probably just apply a class "required"
>> at render time and the visual should be handled by css.
>
> I believe I was the one who introduced the required CSS class and that was my reasoning - have the style sheet determine what a required field looks like.
>
> At the time, the asterisk was being used to indicate a required field. The problem was, most forms didn't have an explanation as to what the asterisk meant. So the result looked odd.
>
> No "best practice" was discussed or decided upon. I just put the new CSS class in the style sheet and I left it to the community to decide by using it or not.
>
> I like the idea of service definitions driving the required fields.

Sure, that would be nice.  However, what happens when service A calls
service B, and service C sometimes dependening on the situation.  How
would you chain the validations, so that no processing code was run in
A until both B and C were satisified that the data was correct?

>
> -Adrian
>
>> On Apr 23, 2010, at 2:35 PM, Bilgin Ibryam wrote:
>>
>>> Here is what I propose:
>>> Remove all the ${uiLabelMap.CommonRequired} tooltips
>> from form definitions. The tooltip should be used to provide
>> other information as it is for not required fields (the
>> purpose of the field, the format)
>>> Remove all the widget-style="required" from form
>> definitions.
>>> If a field is required, (on form widget) set only its
>> attribute required-field="true". In cases when the form is
>> based on service definition (auto-fields-service) it is not
>> neccessary to set this attribute. Then  no need to add
>> tooltip="${uiLabelMap.CommonRequired} or
>> widget-style="required" attibutes on the form definition.
>> The renderer should decide how to indicate the required
>> field.
>>> Change form renderer, so if a field is required it is
>> indicated by asterix plus required style ( same as
>> widget-style="required")
>
>
>      

[Adrian Crum-2]

--- On Fri, 4/23/10, Adam Heath <[hidden email]> wrote:

> Adrian Crum wrote:
> > --- On Fri, 4/23/10, Robert Morley <[hidden email]>
> wrote:
> >> +1 - I think properly modeling the
> >> field using the required-field attribute makes
> perfect
> >> sense.  I would think our html form renderer
> >> implementation should probably just apply a class
> "required"
> >> at render time and the visual should be handled by
> css.
> >
> > I believe I was the one who introduced the required
> CSS class and that was my reasoning - have the style sheet
> determine what a required field looks like.
> >
> > At the time, the asterisk was being used to indicate a
> required field. The problem was, most forms didn't have an
> explanation as to what the asterisk meant. So the result
> looked odd.
> >
> > No "best practice" was discussed or decided upon. I
> just put the new CSS class in the style sheet and I left it
> to the community to decide by using it or not.
> >
> > I like the idea of service definitions driving the
> required fields.
>
> Sure, that would be nice.  However, what happens when
> service A calls
> service B, and service C sometimes dependening on the
> situation.  How
> would you chain the validations, so that no processing code
> was run in
> A until both B and C were satisified that the data was
> correct?

The model widget could crawl service definitions and service code, following each execution branch. It would collect all required parameters along the way. Which branch the program flow will take could be predicted by extrapolating user intent from a histogram of previous user activity. The resulting service code branch could then be examined for parameter validation (not empty, upper case, digits only, etc) and that information can be fed back to the user as well.


Just kidding.


Twine and duct tape?

>
> >
> > -Adrian
> >
> >> On Apr 23, 2010, at 2:35 PM, Bilgin Ibryam wrote:
> >>
> >>> Here is what I propose:
> >>> Remove all the ${uiLabelMap.CommonRequired}
> tooltips
> >> from form definitions. The tooltip should be used
> to provide
> >> other information as it is for not required fields
> (the
> >> purpose of the field, the format)
> >>> Remove all the widget-style="required" from
> form
> >> definitions.
> >>> If a field is required, (on form widget) set
> only its
> >> attribute required-field="true". In cases when the
> form is
> >> based on service definition (auto-fields-service)
> it is not
> >> neccessary to set this attribute. Then  no
> need to add
> >> tooltip="${uiLabelMap.CommonRequired} or
> >> widget-style="required" attibutes on the form
> definition.
> >> The renderer should decide how to indicate the
> required
> >> field.
> >>> Change form renderer, so if a field is
> required it is
> >> indicated by asterix plus required style ( same
> as
> >> widget-style="required")
> >
> >
> >       
>
>

[Bob Morley]

On Apr 23, 2010, at 5:18 PM, Adam Heath wrote:

> Adrian Crum wrote:
>> --- On Fri, 4/23/10, Robert Morley <[hidden email]> wrote:
>>> +1 - I think properly modeling the
>>> field using the required-field attribute makes perfect
>>> sense.  I would think our html form renderer
>>> implementation should probably just apply a class "required"
>>> at render time and the visual should be handled by css.
>>
>> I believe I was the one who introduced the required CSS class and  
>> that was my reasoning - have the style sheet determine what a  
>> required field looks like.
>>
>> At the time, the asterisk was being used to indicate a required  
>> field. The problem was, most forms didn't have an explanation as to  
>> what the asterisk meant. So the result looked odd.
>>
>> No "best practice" was discussed or decided upon. I just put the  
>> new CSS class in the style sheet and I left it to the community to  
>> decide by using it or not.
>>
>> I like the idea of service definitions driving the required fields.
>
> Sure, that would be nice.  However, what happens when service A calls
> service B, and service C sometimes dependening on the situation.  How
> would you chain the validations, so that no processing code was run in
> A until both B and C were satisified that the data was correct?
>

I think you would be using the required fields defined by the service  
definition of service A which is what the form would be bound to.  If  
there are optional parameters to service A that are required by  
service B (and service B is always called) then service A should have  
them marked as required as well.  However, if service B is optionally  
called itself (based on logic) then without the client duplicating  
that logic client-side, the page has no choice but to make those  
parameters optional as well.

[Adam Heath-2]

Robert Morley wrote:

>
> On Apr 23, 2010, at 5:18 PM, Adam Heath wrote:
>
>> Adrian Crum wrote:
>>> --- On Fri, 4/23/10, Robert Morley <[hidden email]> wrote:
>>>> +1 - I think properly modeling the
>>>> field using the required-field attribute makes perfect
>>>> sense.  I would think our html form renderer
>>>> implementation should probably just apply a class "required"
>>>> at render time and the visual should be handled by css.
>>>
>>> I believe I was the one who introduced the required CSS class and
>>> that was my reasoning - have the style sheet determine what a
>>> required field looks like.
>>>
>>> At the time, the asterisk was being used to indicate a required
>>> field. The problem was, most forms didn't have an explanation as to
>>> what the asterisk meant. So the result looked odd.
>>>
>>> No "best practice" was discussed or decided upon. I just put the new
>>> CSS class in the style sheet and I left it to the community to decide
>>> by using it or not.
>>>
>>> I like the idea of service definitions driving the required fields.
>>
>> Sure, that would be nice.  However, what happens when service A calls
>> service B, and service C sometimes dependening on the situation.  How
>> would you chain the validations, so that no processing code was run in
>> A until both B and C were satisified that the data was correct?
>>
>
> I think you would be using the required fields defined by the service
> definition of service A which is what the form would be bound to.  If
> there are optional parameters to service A that are required by service
> B (and service B is always called) then service A should have them
> marked as required as well.  However, if service B is optionally called
> itself (based on logic) then without the client duplicating that logic
> client-side, the page has no choice but to make those parameters
> optional as well.

Validation is more than just a required check.  Various fields may be
restricted to a certain list of allowed values.  This list could
change based on other incoming parameters.  And copying such
validation all over the place would lead to more madness(I have enough
of my own).

[Adam Heath-2]

Adrian Crum wrote:
> Twine and duct tape?

I prefer chewing gum and super glue.

[Bob Morley]

On Apr 23, 2010, at 5:33 PM, Adam Heath wrote:

>>>> I like the idea of service definitions driving the required fields.
>>>
>>> Sure, that would be nice.  However, what happens when service A  
>>> calls
>>> service B, and service C sometimes dependening on the situation.  
>>> How
>>> would you chain the validations, so that no processing code was  
>>> run in
>>> A until both B and C were satisified that the data was correct?
>>>
>>
>> I think you would be using the required fields defined by the service
>> definition of service A which is what the form would be bound to.  If
>> there are optional parameters to service A that are required by  
>> service
>> B (and service B is always called) then service A should have them
>> marked as required as well.  However, if service B is optionally  
>> called
>> itself (based on logic) then without the client duplicating that  
>> logic
>> client-side, the page has no choice but to make those parameters
>> optional as well.
>
> Validation is more than just a required check.  Various fields may be
> restricted to a certain list of allowed values.  This list could
> change based on other incoming parameters.  And copying such
> validation all over the place would lead to more madness(I have enough
> of my own).
>

No argument about validation; but I thought the original point was  
adjusting the model form field's required attribute based on the  
service that is it bound to.  In that case, my expectation would be  
that it would honour what is marked as non-optional from the service  
definition.

One could certainly harness the power of the model to walk and  
transform based on all sorts of associations.  Internally we have  
added the visitor pattern to the presentment, service, and controller  
models with the intent of doing these sort of things.  To date we have  
applied (traditional ofbiz) security -- think service definition  
defines a permission check for PARTYMGR_VIEW and because a controller  
request "ViewParty" uses that as a service event, it gets transformed  
to have the same security check.  Naturally, the modeled MenuItem has  
a link to this controller request, so it gets transformed to be  
wrapped with the security check.  Net result is that the application  
no longer renders the menu link because the logged in user does not  
have that permission.  But alas, I suspect that is a discussion for  
another day .... or is it?  ;)  (Please don't tell me I have to look  
at the security re-design, i know know!)

[David E. Jones-2]

On Apr 23, 2010, at 4:18 PM, Adam Heath wrote:

> Adrian Crum wrote:
>> --- On Fri, 4/23/10, Robert Morley <[hidden email]> wrote:
>>> +1 - I think properly modeling the
>>> field using the required-field attribute makes perfect
>>> sense.  I would think our html form renderer
>>> implementation should probably just apply a class "required"
>>> at render time and the visual should be handled by css.
>>
>> I believe I was the one who introduced the required CSS class and that was my reasoning - have the style sheet determine what a required field looks like.
>>
>> At the time, the asterisk was being used to indicate a required field. The problem was, most forms didn't have an explanation as to what the asterisk meant. So the result looked odd.
>>
>> No "best practice" was discussed or decided upon. I just put the new CSS class in the style sheet and I left it to the community to decide by using it or not.
>>
>> I like the idea of service definitions driving the required fields.
>
> Sure, that would be nice.  However, what happens when service A calls
> service B, and service C sometimes dependening on the situation.  How
> would you chain the validations, so that no processing code was run in
> A until both B and C were satisified that the data was correct?

IMO it would be a bad idea to do something like that. If service A calls services B and C then service A is responsible for what it passes to those. Just because there is a required parameter on service B that happens to have the same name as an optional parameter doesn't mean we'd want to make it required when calling service A, it just means that service A is filling in a value before calling service B (or if it isn't then there is a bug in service A).

-David

[Adam Heath-2]

Robert Morley wrote:

>
> On Apr 23, 2010, at 5:33 PM, Adam Heath wrote:
>
>>>>> I like the idea of service definitions driving the required fields.
>>>>
>>>> Sure, that would be nice.  However, what happens when service A calls
>>>> service B, and service C sometimes dependening on the situation.  How
>>>> would you chain the validations, so that no processing code was run in
>>>> A until both B and C were satisified that the data was correct?
>>>>
>>>
>>> I think you would be using the required fields defined by the service
>>> definition of service A which is what the form would be bound to.  If
>>> there are optional parameters to service A that are required by service
>>> B (and service B is always called) then service A should have them
>>> marked as required as well.  However, if service B is optionally called
>>> itself (based on logic) then without the client duplicating that logic
>>> client-side, the page has no choice but to make those parameters
>>> optional as well.
>>
>> Validation is more than just a required check.  Various fields may be
>> restricted to a certain list of allowed values.  This list could
>> change based on other incoming parameters.  And copying such
>> validation all over the place would lead to more madness(I have enough
>> of my own).
>>
>
> No argument about validation; but I thought the original point was
> adjusting the model form field's required attribute based on the service
> that is it bound to.  In that case, my expectation would be that it
> would honour what is marked as non-optional from the service definition.
>
> One could certainly harness the power of the model to walk and transform
> based on all sorts of associations.  Internally we have added the
> visitor pattern to the presentment, service, and controller models with
> the intent of doing these sort of things.  To date we have applied
> (traditional ofbiz) security -- think service definition defines a
> permission check for PARTYMGR_VIEW and because a controller request
> "ViewParty" uses that as a service event, it gets transformed to have
> the same security check.  Naturally, the modeled MenuItem has a link to
> this controller request, so it gets transformed to be wrapped with the
> security check.  Net result is that the application no longer renders
> the menu link because the logged in user does not have that permission.
> But alas, I suspect that is a discussion for another day .... or is it?
> ;)  (Please don't tell me I have to look at the security re-design, i
> know know!)

Such a walker can not make any assumptions.  Events called from
widgets are difficult to walk down into, as are services themselves.
services can be written in just about any language.

What should be done, is that for each defined service, add a security
check service(which can then cascade), and a validation service(which
could do the same thing).

[Bob Morley]

On Apr 23, 2010, at 5:53 PM, Adam Heath wrote:

> Robert Morley wrote:
>>
>> One could certainly harness the power of the model to walk and  
>> transform
>> based on all sorts of associations.  Internally we have added the
>> visitor pattern to the presentment, service, and controller models  
>> with
>> the intent of doing these sort of things.  To date we have applied
>> (traditional ofbiz) security -- think service definition defines a
>> permission check for PARTYMGR_VIEW and because a controller request
>> "ViewParty" uses that as a service event, it gets transformed to have
>> the same security check.  Naturally, the modeled MenuItem has a  
>> link to
>> this controller request, so it gets transformed to be wrapped with  
>> the
>> security check.  Net result is that the application no longer renders
>> the menu link because the logged in user does not have that  
>> permission.
>> But alas, I suspect that is a discussion for another day .... or is  
>> it?
>> ;)  (Please don't tell me I have to look at the security re-design, i
>> know know!)
>
> Such a walker can not make any assumptions.  Events called from
> widgets are difficult to walk down into, as are services themselves.
> services can be written in just about any language.
>
> What should be done, is that for each defined service, add a security
> check service(which can then cascade), and a validation service(which
> could do the same thing).
>

I do not believe the walker is making any assumptions.  It cascades  
security artifacts from wherever they are defined.  In just so happens  
that a controller request (which in our world can have security  
artifacts) may define an event of type service.  We do not attempt to  
walk any deeper than the service definition; and it can harvest  
security artifacts from there regardless if they are primitive  
security checks or invocations to a security method (as long as it is  
modeled).

If one was to do what you are saying, I believe it would boil down to  
the same thing -- service definition defines behaviour and modeled  
objects that have a hard reference to that service definition could  
obtain that behaviour and transform themselves as a result.

Is it complete?  Of course not -- if a widget has a soft reference  
(say a target is determined dynamically) then we can not do anything  
(remember this is loaded at cache time).  Moreover, there is (in this  
case) permission join considerations.  Say I have a form that has two  
links; does the parent widget OR those permissions or AND them?  We  
have expected the presentment model to account for this; so on a  
screenlet (for example) you can indicate if all permissions are  
required to show that widget (AND) or if you can partially show it (OR).

Having said all this; it is one of the reasons why we like minilang.  
Being heavily modeled it provides an opportunity to get right in there  
and walk and transform it.  That is something that has come up quite a  
bit as well as additional uses for walking the entity model.  In my  
mind the form can be shaped quite a bit if you have a deterministic  
way to link it to the entity it operates on and the service that does  
that work.

[Bilgin Ibryam-2]

Inline

> Adrian Crum wrote:
>  
>> --- On Fri, 4/23/10, Robert Morley <[hidden email]> wrote:
>>    
>>> +1 - I think properly modeling the
>>> field using the required-field attribute makes perfect
>>> sense.  I would think our html form renderer
>>> implementation should probably just apply a class "required"
>>> at render time and the visual should be handled by css.
>>>      
>> I believe I was the one who introduced the required CSS class and that was my reasoning - have the style sheet determine what a required field looks like.
>>
>> At the time, the asterisk was being used to indicate a required field. The problem was, most forms didn't have an explanation as to what the asterisk meant. So the result looked odd.
>>    

Asterix is used to indicate required fields, and it is pretty common
practice  http://simplyaccessible.org/examples/required-form-fields


>> No "best practice" was discussed or decided upon. I just put the new CSS class in the style sheet and I left it to the community to decide by using it or not.
>>    
It seems community is still not agreed on what to use, and the result is
a mess
>> I like the idea of service definitions driving the required fields.
>>    
>
>  

When a form is based on a service definition (auto-fields-service) not
optional fields are marked as required. My intention is not to change or
extend this behavior. It is already working correct. My intention is to
cleanup other forms which have manually set required indicators.

> Sure, that would be nice.  However, what happens when service A calls
> service B, and service C sometimes dependening on the situation.  How
> would you chain the validations, so that no processing code was run in
> A until both B and C were satisified that the data was correct?
>  

This thread is only about:

1. Cleaning up the forms: remove the "required" label
(tooltip="${uiLabelMap.CommonRequired}") and css style
(widget-style="required") and add in their place required-field="true"
2. Change macro renderer so that if a field is required it is indicated
by asterix (as it is right now) plus a css style (the same as
widget-style="required")

Are there any objections to this?

Bilgin

>  
>  
>> -Adrian
>>
>>    
>>> On Apr 23, 2010, at 2:35 PM, Bilgin Ibryam wrote:
>>>
>>>      
>>>> Here is what I propose:
>>>> Remove all the ${uiLabelMap.CommonRequired} tooltips
>>>>        
>>> from form definitions. The tooltip should be used to provide
>>> other information as it is for not required fields (the
>>> purpose of the field, the format)
>>>      
>>>> Remove all the widget-style="required" from form
>>>>        
>>> definitions.
>>>      
>>>> If a field is required, (on form widget) set only its
>>>>        
>>> attribute required-field="true". In cases when the form is
>>> based on service definition (auto-fields-service) it is not
>>> neccessary to set this attribute. Then  no need to add
>>> tooltip="${uiLabelMap.CommonRequired} or
>>> widget-style="required" attibutes on the form definition.
>>> The renderer should decide how to indicate the required
>>> field.
>>>      
>>>> Change form renderer, so if a field is required it is
>>>>        
>>> indicated by asterix plus required style ( same as
>>> widget-style="required")
>>>      
>>      
>>    
>
>  

[Bob Morley]

Bilgin Ibryam-2 wrote

1. Cleaning up the forms: remove the "required" label
(tooltip="${uiLabelMap.CommonRequired}") and css style
(widget-style="required") and add in their place required-field="true"
2. Change macro renderer so that if a field is required it is indicated
by asterix (as it is right now) plus a css style (the same as
widget-style="required")

Are there any objections to this?

I very much like it.

Would it be possible to include an element with a class around the required-marker?  Perhaps something like * ?  Thinking people could remove/change the styling of the marking in a particular theme.  Would also like to see the marker rendering in a single place rather than rendered in the macro for each widget.