Dev - Proposed enhancement to the ModelFormField.getTitle() method

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Dev - Proposed enhancement to the ModelFormField.getTitle() method

Jacopo Cappellato
Hi,

what do you think of the attached patch?
The idea is this: when the field's "title" element is not set in the
form definition, we try to get a localized label for the field's "name";
if the label is not found then the field's "name" is formatted (as
happens now).

In this way, in order to localize a form's field, we could simply add
the field's name to a *UiLabelMap file and we will not need to add the
'title' element to the field's definition (for example fromDate=Valid
 From Date); also the auto generated fields (e.g. <auto-fields-service>)
will be automatically localized in this way.

The patch can be improved:

1) the following instruction should be moved inside a class constructor:

FlexibleStringExpander nameExpander = new
FlexibleStringExpander("${uiLabelMap." + this.name + "}");

2) is there a way to remove the hardcoded reference to the "uiLabelMap"
variable?

3) it would be nice to search for more than one label names, for
example, for a form called "exampleForm" and a field called "exampleField":

search for a label with name: exampleForm_exampleField
if not found, search for a label with name: exampleField

What do you think?

Can I crate a patch for this?

Jacopo


Index: framework/widget/src/org/ofbiz/widget/form/ModelFormField.java
===================================================================
--- framework/widget/src/org/ofbiz/widget/form/ModelFormField.java (revision 7181)
+++ framework/widget/src/org/ofbiz/widget/form/ModelFormField.java (working copy)
@@ -920,7 +920,13 @@
                 // this should never happen, ie name is required
                 return "";
             }
-
+            // search for a localized label for the field's name
+            FlexibleStringExpander nameExpander = new FlexibleStringExpander("${uiLabelMap." + this.name + "}");
+            String localizedName = nameExpander.expandString(context);
+            if (!localizedName.equals(this.name)) {
+                return localizedName;
+            }
+            // create a title from the name of this field; expecting a Java method/field style name, ie productName or productCategoryId
             StringBuffer autoTitleBuffer = new StringBuffer();
 
             // always use upper case first letter...

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Dev - Proposed enhancement to the ModelFormField.getTitle() method

David E. Jones

Jacopo,

I think this is a fine idea.

We should probably use a prefix for these so we don't just have the field name sitting in the properties file as the property name. Something that denotes that it is an entity field title would be good (like entity.field.title, for example).

Also, there is no need to use the FlexibleStringExpander just to get a Map Entry... It would be more direct and faster to get the "uiLabelMap" Map from the context, and then just do "uiLabelMap.get("entity.field.title." + this.name)".

-David


Jacopo Cappellato wrote:

> Hi,
>
> what do you think of the attached patch?
> The idea is this: when the field's "title" element is not set in the
> form definition, we try to get a localized label for the field's "name";
> if the label is not found then the field's "name" is formatted (as
> happens now).
>
> In this way, in order to localize a form's field, we could simply add
> the field's name to a *UiLabelMap file and we will not need to add the
> 'title' element to the field's definition (for example fromDate=Valid
>  From Date); also the auto generated fields (e.g. <auto-fields-service>)
> will be automatically localized in this way.
>
> The patch can be improved:
>
> 1) the following instruction should be moved inside a class constructor:
>
> FlexibleStringExpander nameExpander = new
> FlexibleStringExpander("${uiLabelMap." + this.name + "}");
>
> 2) is there a way to remove the hardcoded reference to the "uiLabelMap"
> variable?
>
> 3) it would be nice to search for more than one label names, for
> example, for a form called "exampleForm" and a field called "exampleField":
>
> search for a label with name: exampleForm_exampleField
> if not found, search for a label with name: exampleField
>
> What do you think?
>
> Can I crate a patch for this?
>
> Jacopo
>
>
> ------------------------------------------------------------------------
>
> Index: framework/widget/src/org/ofbiz/widget/form/ModelFormField.java
> ===================================================================
> --- framework/widget/src/org/ofbiz/widget/form/ModelFormField.java (revision 7181)
> +++ framework/widget/src/org/ofbiz/widget/form/ModelFormField.java (working copy)
> @@ -920,7 +920,13 @@
>                  // this should never happen, ie name is required
>                  return "";
>              }
> -
> +            // search for a localized label for the field's name
> +            FlexibleStringExpander nameExpander = new FlexibleStringExpander("${uiLabelMap." + this.name + "}");
> +            String localizedName = nameExpander.expandString(context);
> +            if (!localizedName.equals(this.name)) {
> +                return localizedName;
> +            }
> +            // create a title from the name of this field; expecting a Java method/field style name, ie productName or productCategoryId
>              StringBuffer autoTitleBuffer = new StringBuffer();
>  
>              // always use upper case first letter...
>
>
> ------------------------------------------------------------------------
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Dev - Proposed enhancement to the ModelFormField.getTitle() method

Jacopo Cappellato
David,

thanks for your suggestions.

The patch is ready in:

http://jira.undersunconsulting.com/browse/OFBIZ-837

Jacopo


David E. Jones wrote:
> Jacopo,
>
> I think this is a fine idea.
>
> We should probably use a prefix for these so we don't just have the field name sitting in the properties file as the property name. Something that denotes that it is an entity field title would be good (like entity.field.title, for example).
>
> Also, there is no need to use the FlexibleStringExpander just to get a Map Entry... It would be more direct and faster to get the "uiLabelMap" Map from the context, and then just do "uiLabelMap.get("entity.field.title." + this.name)".
>
> -David

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Dev - Proposed enhancement to the ModelFormField.getTitle() method

Hans Bakker
Jacopo,
This is a very nice enhancement

if we now put

FormFieldTitle_description=description

in the CommonUiLabels.properties file, everywhere on every menu where there is
no title we can put the description in the related
commonUiLabels_xx.properties files.......and they are all translated.....

i tested it here and it works very well....

saves a lot of time.....thanks!

regards,
Hans


On Saturday 08 April 2006 13:11, Jacopo Cappellato wrote:

> David,
>
> thanks for your suggestions.
>
> The patch is ready in:
>
> http://jira.undersunconsulting.com/browse/OFBIZ-837
>
> Jacopo
>
> David E. Jones wrote:
> > Jacopo,
> >
> > I think this is a fine idea.
> >
> > We should probably use a prefix for these so we don't just have the field
> > name sitting in the properties file as the property name. Something that
> > denotes that it is an entity field title would be good (like
> > entity.field.title, for example).
> >
> > Also, there is no need to use the FlexibleStringExpander just to get a
> > Map Entry... It would be more direct and faster to get the "uiLabelMap"
> > Map from the context, and then just do
> > "uiLabelMap.get("entity.field.title." + this.name)".
> >
> > -David
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
--
Regards,
Hans Bakker
ANT Websystems Co.,Ltd (http://www.antwebsystems.com)

If you want to verify that this message really originates from
from the above person, download the public key from:
http://www.antwebsystems.com/hbakkerAntwebsystems.asc

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Dev - Proposed enhancement to the ModelFormField.getTitle() method

Jacopo Cappellato
Hans,

I'm glad it's useful for you.
I think it is something we should have done before: in fact, in order to
localize the form widgets, it was necessary to explicitly declare a lot
of field definitions (just to add the title attribute)... now this is no
more necessary and it would be nice to remove that fields from the forms.

Jacopo

Hans Bakker wrote:

> Jacopo,
> This is a very nice enhancement
>
> if we now put
>
> FormFieldTitle_description=description
>
> in the CommonUiLabels.properties file, everywhere on every menu where there is
> no title we can put the description in the related
> commonUiLabels_xx.properties files.......and they are all translated.....
>
> i tested it here and it works very well....
>
> saves a lot of time.....thanks!
>
> regards,
> Hans
>
>
> On Saturday 08 April 2006 13:11, Jacopo Cappellato wrote:
>> David,
>>
>> thanks for your suggestions.
>>
>> The patch is ready in:
>>
>> http://jira.undersunconsulting.com/browse/OFBIZ-837
>>
>> Jacopo
>>
>> David E. Jones wrote:
>>> Jacopo,
>>>
>>> I think this is a fine idea.
>>>
>>> We should probably use a prefix for these so we don't just have the field
>>> name sitting in the properties file as the property name. Something that
>>> denotes that it is an entity field title would be good (like
>>> entity.field.title, for example).
>>>
>>> Also, there is no need to use the FlexibleStringExpander just to get a
>>> Map Entry... It would be more direct and faster to get the "uiLabelMap"
>>> Map from the context, and then just do
>>> "uiLabelMap.get("entity.field.title." + this.name)".
>>>
>>> -David
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>
>
> ------------------------------------------------------------------------
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Dev - Proposed enhancement to the ModelFormField.getTitle () method

Hans Bakker
Yes i agree with you.

another proposal: we should standardize on the find screens, like using
'searchButton' for the name of the submitbutton, then every find screen is
translated when the name is present in the commonuilables properties file

but i agree with you we should get rid of the field "title" alltogether....

REgards,
Hans


On Tuesday 11 April 2006 16:20, Jacopo Cappellato wrote:

> Hans,
>
> I'm glad it's useful for you.
> I think it is something we should have done before: in fact, in order to
> localize the form widgets, it was necessary to explicitly declare a lot
> of field definitions (just to add the title attribute)... now this is no
> more necessary and it would be nice to remove that fields from the forms.
>
> Jacopo
>
> Hans Bakker wrote:
> > Jacopo,
> > This is a very nice enhancement
> >
> > if we now put
> >
> > FormFieldTitle_description=description
> >
> > in the CommonUiLabels.properties file, everywhere on every menu where
> > there is no title we can put the description in the related
> > commonUiLabels_xx.properties files.......and they are all translated.....
> >
> > i tested it here and it works very well....
> >
> > saves a lot of time.....thanks!
> >
> > regards,
> > Hans
> >
> > On Saturday 08 April 2006 13:11, Jacopo Cappellato wrote:
> >> David,
> >>
> >> thanks for your suggestions.
> >>
> >> The patch is ready in:
> >>
> >> http://jira.undersunconsulting.com/browse/OFBIZ-837
> >>
> >> Jacopo
> >>
> >> David E. Jones wrote:
> >>> Jacopo,
> >>>
> >>> I think this is a fine idea.
> >>>
> >>> We should probably use a prefix for these so we don't just have the
> >>> field name sitting in the properties file as the property name.
> >>> Something that denotes that it is an entity field title would be good
> >>> (like
> >>> entity.field.title, for example).
> >>>
> >>> Also, there is no need to use the FlexibleStringExpander just to get a
> >>> Map Entry... It would be more direct and faster to get the "uiLabelMap"
> >>> Map from the context, and then just do
> >>> "uiLabelMap.get("entity.field.title." + this.name)".
> >>>
> >>> -David
> >>
> >> _______________________________________________
> >> Dev mailing list
> >> [hidden email]
> >> http://lists.ofbiz.org/mailman/listinfo/dev
> >
> > ------------------------------------------------------------------------
> >
> >
> > _______________________________________________
> > Dev mailing list
> > [hidden email]
> > http://lists.ofbiz.org/mailman/listinfo/dev
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
--
Regards,
Hans Bakker
ANT Websystems Co.,Ltd (http://www.antwebsystems.com)

If you want to verify that this message really originates from
from the above person, download the public key from:
http://www.antwebsystems.com/hbakkerAntwebsystems.asc

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

attachment0 (196 bytes) Download Attachment