ofbiz-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "risalitim@gmail.com" <risali...@gmail.com>
Subject Re: About issue: Clean up labels between order and ecommerce application (OFBIZ-1780)
Date Mon, 19 May 2008 19:19:38 GMT

Yes, exactly probably "AssetMaintFixedAssetMaintMeterReading" is more  
readable and appropriate.

Another different example can be the following label:

AccountingFixedAssetIdents --> Identifications

on AccountingUiLabels.xml and AssetMaintUiLabels.xml

in my opinion in this case I will delete it from  
AssetMaintUiLabels.xml and use it from the first one (reusing of  
labels between different applications).

Also because in the main-decorator of assetmaint application there was  
already the following actions:

<property-map resource="AssetMaintUiLabels" map-name="uiLabelMap"  
<property-map resource="AccountingUiLabels" map-name="uiLabelMap"  
<property-map resource="PartyUiLabels" map-name="uiLabelMap"  
<property-map resource="ProductUiLabels" map-name="uiLabelMap"  
<property-map resource="WorkEffortUiLabels" map-name="uiLabelMap"  
<property-map resource="CommonUiLabels" map-name="uiLabelMap"  

So as you can see there are a lot of confusion and seems to me that  
the cleaning of labels is something that we cannot skip or we cannot  
consider it.


Il giorno 19/mag/08, alle ore 21:00, David E Jones ha scritto:

> On May 19, 2008, at 12:51 PM, Marco Risaliti wrote:
>> I agree with David, also I didn't like to overriding the labels  
>> between applications.
>> To be me clear I like to give a simple example that I didn't like:
>> in AccountingUiLabels.xml the label  
>> AccountingFixedAssetMaintIntervalQuantity has the meaning "Interval  
>> Quantity"
>> in AssetMaintUiLabel.xml the same label  
>> AccountingFixedAssetMaintIntervalQuantity has the meaning "Meter  
>> Reading"
>> I prefer that in this case it was :
>> AccountingFixedAssetMaintIntervalQuantity --> "Interval Quantity"
>> AssetMaintFixedAssetMaintIntervalQuantity --> "Meter Reading"
> Or perhaps "AssetMaintFixedAssetMaintMeterReading" as they do mean  
> different things (BTW, not sure if "Meter Reading" is the best term  
> for whatever this is applied to, but I guess that's irrelevant for  
> the discussion...).
> -David
>> I suggest that all the labels inside an xml file will be start with  
>> the same prefix (example all the labels in OrderUiLabels will have  
>> a Order as prefix).
>> If we will use this simple rules we will have more maintaneable and  
>> reusing of existing labels between different applications.
>> Thanks
>> Marco
>> Il giorno 19/mag/08, alle ore 18:54, David E Jones ha scritto:
>>> On May 19, 2008, at 8:56 AM, Adrian Crum wrote:
>>>> Jacques Le Roux wrote:
>>>>> From: "Bruno Busco" <bruno.busco@gmail.com>
>>>>>> I think that in order to keep things simple and maintaneable we 

>>>>>> should avoid
>>>>>> that a label is overwritten in two different UiLabels files to  
>>>>>> have a
>>>>>> different and more specific text.
>>>>>> If we do like this it will be an easy job to automatically  
>>>>>> check for label
>>>>>> duplication.
>>>>> +1000, I totally agree : simple is beautiful. We don't need  
>>>>> complexity at this level. Or someone has to explain me why...
>>>> A good example is the Asset Maintenance component - which reuses  
>>>> screens from the Accounting component, but changes some  
>>>> terminology so that it makes more sense to a maintenance person.  
>>>> In that case, the UI labels used in the Accounting component  
>>>> screens are redefined in Asset Maintenance.
>>> This is an interesting use of label overriding, but I'm not sure I  
>>> like it... If the meaning of some text somewhere is different from  
>>> the meaning implied by the previously used label then my  
>>> preference would be to see a different label.
>>> The labels are really meant for enabling translation and not so  
>>> much for overriding text. They can certainly be used that way, but  
>>> if it obfuscates meaning them over time it may make things more  
>>> difficult to understand and maintain.
>>> That's just my thought though... either way I don't want to see us  
>>> paint ourselves into a corner with something like this.
>>> -David

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message