Re: Permission service not on the same transaction

[Nicolas Malin]

Hi Rishi,

in line

Le 19/09/2016 à 16:20, Rishi Solanki a écrit :

Nicolas,

"If you are dealing with money, or precision is a must, use BigDecimal.
Otherwise Doubles tend to be good enough." That means, for quantity fields
double should be fine. But within OFBiz, I see entities like OrderItem,
OISGIR, and many other uses BigDecimal for quantity field. But I think that
is because in orderred quantity due to Product.orderDecimalQuantity user
may enter the decimal quantity.

With all this said, if we think WorkEffortGoodStandard.estimatedQuantity
may contains precision values in it in some business scenarios then we
should go for the #3. Or simple conversion should work as you suggested in
#1.
Sure the #3 would be the better choice, but the step is hard ! I agree 
with you to move on first stable point, and close this too long task.

My suggestion is to go with #1, as I couldn't think of scenario where
precision required upto many decimal places for the
WorkEffortGoodStandard.estimatedQuantity field.

Hope its not too late for original topic in this thread, +1 for using the
same transaction for the permission services. As whenever we call
permission service in a wrapper service we always use the same transaction.
It's never too late ;) , I continue the work and add new parameter on 
permission service to give the possibility to use or not the same 
transaction. But by default don't use the same.


If you want look forward, I create a branch permission-same-transaction 
on github.com:nmalin/ApacheOFBiz.git to work easily on it.


Nicolas


Thanks!


Best Regards,
--



Rishi Solanki
Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com

On Sat, Sep 17, 2016 at 5:30 PM, Nicolas Malin 
wrote:


Hi all, I need some Help !! I put my arm in a gearing :(

After refactor the permission service, I raise a silent problem that is
all call-service used on mini-lang test didn't passed to service validation.

I correct some easier case like bad attribut passed but now rest some
complicate case like this :

testProductionRunCreation : Type check failed for field
[createWorkEffortGoodStandard.estimatedQuantity]; expected type is
[Double]; actual type is [java.math.BigDecimal]

The problem came from that :

  * Field has define as BigDecimal on mini-lang

  * The service definition use auto-attribute to resolve the java type

  * The field on the entity is define as floating-point and is converted by
fieldType as Double

So to reallign this I have some possibility

1. Easy : test are wrong : convert field instantiation to Double instead
of BigDecimal for all tests failed

2. Medium : service need realign : I surcharge attribute definition to
accept BigDecimal for these service

3. Hard : Why Double for floating-point, I had in my mind that BigDecimal
would be preferred to Double if is the case, we can change all fieldType
conversion to BigDecimal instead of Double and realign all ofbiz code
related.

Your suggest will be truly appreciated ;)

Nicolas


Le 15/04/2016 à 08:23, Taher Alkhateeb a écrit :


Hi Nicolas,

I have to note that in ModelPermission the same exact call is also made
with a new transaction. I did not dig deep into it but I advice to at
least
check it over there as well. This makes me suspect that either both call
are wrong or both calls are right.

HTH

Taher Alkhateeb

On Fri, Apr 15, 2016 at 9:18 AM, Pranay Pandey <
pranay.pan...@hotwaxsystems.com> wrote:

Hi Nicolas,

Calling it as permission service is tricky. I see the comment in
implementation above the simple method in ShipmentServices.xml-

  

It was implemented with a purpose to be called inline, may be supporting
the traditional way of doing things. Reviewing at a complete patch with
all
the modifications you have done for making shipment CRUD operations can
help here getting the opinion. WDYT?

Best regards,

Pranay Pandey
HotWax Systems
http://www.hotwaxsystems.com/

On Thu, Apr 7, 2016 at 1:30 PM, Nicolas Malin 
wrote:

Hello,

Currently I continue the conversion on shipment  crud service and I
detected that many service use the same mini-lang call to check if the
shipment status is ok for editing "checkCanChangeShipmentStatusPacked"

I convert it on service to call it directly by the permission-service
like that :

  ...
  
  ...
  

The problem with this change that when I run the unit tests, I have some
failed to due database lock on shipment.
After some analyse I founded that the permission service wasn't call on
the same service's transaction.
I a realize this change :

Index: framework/service/src/org/ofbiz/service/ModelService.java
===
--- framework/service/src/org/ofbiz/service/ModelService.java
(révision 1737860)
+++ framework/service/src/org/ofbiz/service/ModelService.java(copie
de travail)
@@ -985,7 +985,7 @@
   LocalDispatcher dispatcher = dctx.getDispatch

Re: Put "Reverts" in the commit template?

[Jacques Le Roux]

Hi Jacopo,

What is the logical behind this? It's not the first time I ask and I'd really 
like to have a clarification.

We have "Fix for" and "Documentation". Why not "Fixed" and "Documented"?

Thanks

Jacques

Le 21/09/2016 à 19:09, Jacopo Cappellato a écrit :

I have changed it to "Reverted" for consistency reasons.

Jacopo



On Wed, Sep 21, 2016 at 7:01 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Done

Jacques


Le 18/09/2016 à 11:19, Jacques Le Roux a écrit :


Hi,

In some cases we need to revert a commit done for a Jira after we
discover it causes an issue. We have not yet other means that using the fix
word.
I suggest we put in the "Reverts" (or "Revert for" or "Reverted" as it
please you) word in the commit template for this reason.
Because it's a different thing than really fixing the initial issue
reported in the Jira but it's sill related to it

What do you think?

Jacques

Re: Apache POI 3.15 released

[Taher Alkhateeb]

+1 always to update to stable new releases

On Thu, Sep 22, 2016 at 2:22 AM, Michael Brohl 
wrote:

> Hi everyone,
>
> Apache POI 3.15 is released, we are currently using 3.14.
>
> Should we do an update?
>
> I'd create a Jira and do this work.
>
> What do you think?
>
> Regards,
>
> Michael
>
>
> Am 22.09.16 um 00:32 schrieb David North:
>
>> The Apache POI PMC are pleased to announce the release of Apache POI 3.15.
>>
>> For details of changes in this release, refer to the release notes:
>>
>> https://www.apache.org/dyn/closer.lua/poi/release/RELEASE-NOTES.txt
>>
>> Thank you to all our contributors for making this release possible.
>>
>> Some of us will be at ApacheCon Europe in Seville later in the year; do
>> find us there if you have input and suggestions.
>>
>> On behalf of the Apache POI PMC,
>>
>> David North
>>
>
>
>

Re: [ANNOUNCE] Apache Solr 6.2.1 released

[Taher Alkhateeb]

I think an update is _always_ a welcomed thing not only for feature set but
also security and bug fixes. So always +1 to upgrade to new versions of
anything.

However, I have to say Solr and Birt are two massive components in terms of
dependencies. So while upgrading and fixing compilation errors if we can
refactor anything to make it lighter that would be an added value

On Thu, Sep 22, 2016 at 2:15 AM, Michael Brohl 
wrote:

> Hi everyone,
>
> there's an new Solr/Lucene version released. Should we do an update?
>
> It will need some refactoring, there are a few compile errors to be solved.
>
> I'd create a Jira and do this work if we want to update, what do you think?
>
> Regards,
>
> Michael
>
>
> Am 20.09.16 um 22:26 schrieb Shalin Shekhar Mangar:
>
>>
>> 20 September 2016, Apache Solr™ 6.2.1 available
>>
>> The Lucene PMC is pleased to announce the release of Apache Solr 6.2.1
>>
>> Solr is the popular, blazing fast, open source NoSQL search platform from
>> the Apache Lucene project. Its major features include powerful full-text
>> search, hit highlighting, faceted search and analytics, rich document
>> parsing, geospatial search, extensive REST APIs as well as parallel SQL.
>> Solr is enterprise grade, secure and highly scalable, providing fault
>> tolerant distributed search and indexing, and powers the search and
>> navigation features of many of the world's largest internet sites.
>>
>> This release includes 11 bug fixes since the 6.2.0 release. Some of the
>> major fixes are:
>>
>>  *
>>
>> SOLR-9490: BoolField always returning false for non-DV fields when
>> javabin involved (via solrj, or intra node communication)
>>
>>  *
>>
>> SOLR-9188: BlockUnknown property makes inter-node communication
>> impossible
>>
>>   * SOLR-9389: HDFS Transaction logs stay open for writes which leaks
>> Xceivers
>>   * SOLR-9438: Shard split can fail to write commit data on shutdown
>> leading to data loss
>>
>> Furthermore, this release includes Apache Lucene 6.2.1 which includes 3
>> bug fixes since the 6.2.0 release.
>>
>> The release is available for immediate download at:
>>
>>  *
>>
>> http://www.apache.org/dyn/closer.lua/lucene/solr/6.2.1
>> 
>>
>> Please read CHANGES.txt for a detailed list of changes:
>>
>>  *
>>
>> https://lucene.apache.org/solr/6_2_1/changes/Changes.html
>> 
>>
>> Please report any feedback to the mailing lists (
>> http://lucene.apache.org/solr/discussion.html <
>> http://lucene.apache.org/solr/discussion.html>)
>>
>> Note: The Apache Software Foundation uses an extensive mirroring network
>> for distributing releases. It is possible that the mirror you are using may
>> not have replicated the release yet. If that is the case, please try
>> another mirror. This also goes for Maven access.
>>
>>
>>
>> --
>> Regards,
>> Shalin Shekhar Mangar.
>>
>
>
>

Re: Apache POI 3.15 released

[Michael Brohl]

Hi everyone,

Apache POI 3.15 is released, we are currently using 3.14.

Should we do an update?

I'd create a Jira and do this work.

What do you think?

Regards,

Michael


Am 22.09.16 um 00:32 schrieb David North:

The Apache POI PMC are pleased to announce the release of Apache POI 3.15.

For details of changes in this release, refer to the release notes:

https://www.apache.org/dyn/closer.lua/poi/release/RELEASE-NOTES.txt

Thank you to all our contributors for making this release possible.

Some of us will be at ApacheCon Europe in Seville later in the year; do
find us there if you have input and suggestions.

On behalf of the Apache POI PMC,

David North





smime.p7s
Description: S/MIME Cryptographic Signature

Re: [ANNOUNCE] Apache Solr 6.2.1 released

[Michael Brohl]

Hi everyone,

there's an new Solr/Lucene version released. Should we do an update?

It will need some refactoring, there are a few compile errors to be solved.

I'd create a Jira and do this work if we want to update, what do you think?

Regards,

Michael


Am 20.09.16 um 22:26 schrieb Shalin Shekhar Mangar:


20 September 2016, Apache Solr™ 6.2.1 available

The Lucene PMC is pleased to announce the release of Apache Solr 6.2.1

Solr is the popular, blazing fast, open source NoSQL search platform 
from the Apache Lucene project. Its major features include powerful 
full-text search, hit highlighting, faceted search and analytics, rich 
document parsing, geospatial search, extensive REST APIs as well as 
parallel SQL. Solr is enterprise grade, secure and highly scalable, 
providing fault tolerant distributed search and indexing, and powers 
the search and navigation features of many of the world's largest 
internet sites.


This release includes 11 bug fixes since the 6.2.0 release. Some of 
the major fixes are:


 *

SOLR-9490: BoolField always returning false for non-DV fields when
javabin involved (via solrj, or intra node communication)

 *

SOLR-9188: BlockUnknown property makes inter-node communication
impossible

  * SOLR-9389: HDFS Transaction logs stay open for writes which leaks
Xceivers
  * SOLR-9438: Shard split can fail to write commit data on shutdown
leading to data loss

Furthermore, this release includes Apache Lucene 6.2.1 which includes 
3 bug fixes since the 6.2.0 release.


The release is available for immediate download at:

 *

http://www.apache.org/dyn/closer.lua/lucene/solr/6.2.1


Please read CHANGES.txt for a detailed list of changes:

 *

https://lucene.apache.org/solr/6_2_1/changes/Changes.html


Please report any feedback to the mailing lists 
(http://lucene.apache.org/solr/discussion.html 
)


Note: The Apache Software Foundation uses an extensive mirroring 
network for distributing releases. It is possible that the mirror you 
are using may not have replicated the release yet. If that is the 
case, please try another mirror. This also goes for Maven access.




--
Regards,
Shalin Shekhar Mangar.





smime.p7s
Description: S/MIME Cryptographic Signature

Re: Preliminary question about themes before possible votes

[Jacques Le Roux]

Hi Julien,

We spoke about having themes like plugins, but I think it was just a small talk 
so far

In 1st place they should go in attic (ie stay in OFBiz trunk in svn repo ) and 
then possibly resurrected from there as themes-plugins, or not.

Jacques


Le 21/09/2016 à 22:59, Julien NICOLAS a écrit :

Hi Jacques,

I agree that it's important to remove themes from the framework (keep at least 
one is important ^^ ).

But you don't mention what's happening with theme that is not in the OOTB. I think it could be available from public repository instead of simply 
deleted.


For me pors is to stop to maintain outdated theme that is never used. We can focus on one theme and go further to upgrade the theme management (and 
rendering management).


Julien.

On 21/09/2016 18:35, Jacques Le Roux wrote:

Ah something I missed to precise: it's not about giving arguments, pro or cons. 
It's only about taking decisions, so again: please stay focused.

Thanks

Jacques


Le 21/09/2016 à 18:13, Jacques Le Roux a écrit :

Hi All,

At OFBIZ-8293 we began to informally discuss about reducing the number of OOTB 
themes. But we could clearly agree and believe a vote is better/

1. Now the 1st question which has been already discussed several time without a 
clear decision in this ML:
   do we, as a community, want to reduce the number  of themes?
   Should we vote on that before starting votes on or a lazy consensus could 
apply.
   I suggest that we try a lazy consensus and if nobody is against with strong 
argument we move on.
2. Should we vote on the number of themes to keep?
   Again I suggest a lazy consensus ratehr than a vote
3. The theme/s to remove, I think we should make several votes, one by theme, 
to clearly decide which theme/s to remove

Thanks for your help deciding on this, please try to keep focused :)

Jacques

Re: Preliminary question about themes before possible votes

[Julien NICOLAS]

Hi Jacques,

I agree that it's important to remove themes from the framework (keep at 
least one is important ^^ ).


But you don't mention what's happening with theme that is not in the 
OOTB. I think it could be available from public repository instead of 
simply deleted.


For me pors is to stop to maintain outdated theme that is never used. We 
can focus on one theme and go further to upgrade the theme management 
(and rendering management).


Julien.

On 21/09/2016 18:35, Jacques Le Roux wrote:
Ah something I missed to precise: it's not about giving arguments, pro 
or cons. It's only about taking decisions, so again: please stay focused.


Thanks

Jacques


Le 21/09/2016 à 18:13, Jacques Le Roux a écrit :

Hi All,

At OFBIZ-8293 we began to informally discuss about reducing the 
number of OOTB themes. But we could clearly agree and believe a vote 
is better/


1. Now the 1st question which has been already discussed several time 
without a clear decision in this ML:

   do we, as a community, want to reduce the number  of themes?
   Should we vote on that before starting votes on or a lazy 
consensus could apply.
   I suggest that we try a lazy consensus and if nobody is against 
with strong argument we move on.

2. Should we vote on the number of themes to keep?
   Again I suggest a lazy consensus ratehr than a vote
3. The theme/s to remove, I think we should make several votes, one 
by theme, to clearly decide which theme/s to remove


Thanks for your help deciding on this, please try to keep focused :)

Jacques

Re: Put "Reverts" in the commit template?

[Jacopo Cappellato]

I have changed it to "Reverted" for consistency reasons.

Jacopo



On Wed, Sep 21, 2016 at 7:01 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Done
>
> Jacques
>
>
> Le 18/09/2016 à 11:19, Jacques Le Roux a écrit :
>
>> Hi,
>>
>> In some cases we need to revert a commit done for a Jira after we
>> discover it causes an issue. We have not yet other means that using the fix
>> word.
>> I suggest we put in the "Reverts" (or "Revert for" or "Reverted" as it
>> please you) word in the commit template for this reason.
>> Because it's a different thing than really fixing the initial issue
>> reported in the Jira but it's sill related to it
>>
>> What do you think?
>>
>> Jacques
>>
>>
>>
>

Re: Put "Reverts" in the commit template?

[Jacques Le Roux]

Done

Jacques


Le 18/09/2016 à 11:19, Jacques Le Roux a écrit :

Hi,

In some cases we need to revert a commit done for a Jira after we discover it 
causes an issue. We have not yet other means that using the fix word.
I suggest we put in the "Reverts" (or "Revert for" or "Reverted" as it please 
you) word in the commit template for this reason.
Because it's a different thing than really fixing the initial issue reported in 
the Jira but it's sill related to it

What do you think?

Jacques

Re: Use ecomseo on demo rather than ecommerce

[Jacques Le Roux]

After 3 day, I consider this a lazy consensus since nobody chimed in and will 
change accordingly tomorrow

Jacques


Le 18/09/2016 à 15:27, Jacques Le Roux a écrit :

Hi,

Maybe you don't know about or did not try it, but we have ecomseo a clone of 
the ecommerce component tailored for SEO

https://cwiki.apache.org/confluence/display/OFBIZ/Search+Engine+Optimisation,+SEO+in+ecommerce

I propose to use it as the default ecommerce demo. This mostly to somehow 
battle test it, even if I know it works well.

As it's based on ecommerce, users should not experience a big changes, apart 
the changed URLs

What do you think?

Jacques

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

[Pierre Smits]

Nice that you're trying to keep this alive, Jacques. But there is basically
nothing to discuss as it is a done deal.

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Wed, Sep 21, 2016 at 5:45 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> I'm not against reverting myself. Doing so it also means that everybody
> agree about continuing to use the FormFieldTitle_ feature
>
> So if you really don't like it and have arguments, it's the moment to
> raise your hand. Before I revert in, say 2 days, and put this discussion
> back in the limbo
>
> Jacques
>
>
>
> Le 21/09/2016 à 16:04, Michael Brohl a écrit :
>
>> Jacques,
>>
>> please take care of the revert, this will keep the commit history cleaner.
>>
>> Thanks,
>>
>> Michael
>>
>>
>> Am 21.09.16 um 14:04 schrieb Jacques Le Roux:
>>
>>> I'm not against reverting it, it's a moot point to me. Please help
>>> yourselves (Michael or Taher. Or maybe Christian? :D)
>>>
>>> Jacques
>>>
>>>
>>> Le 21/09/2016 à 11:11, Taher Alkhateeb a écrit :
>>>
 I suggest also to revert. If we want to apply such a change in the
 future
 then we must take a decision to stop using convention-over-configuration
 for _all_ widget fields. And if we do not want to use that convention
 then
 we should remove the related code accordingly.

 On Wed, Sep 21, 2016 at 12:04 PM, Michael Brohl <
 michael.br...@ecomify.de>
 wrote:

 I'd suggest to revert this commit.
>
> Thanks,
>
> Michael
>
> Am 21.09.16 um 09:47 schrieb gil portenseigne:
>
> Hi Jacques,
>>
>> Like Nicolas said in previous Michael commit answer:
>> http://markmail.org/message/x4ulworuwgbotvrv?q=r1761332
>>
>> I do not understand these kindof improvements. Adding a title when and
>> FormFieldTitle_XXX properties exists is not good in my opinion (i did
>> not
>> check these ones).
>>
>>
>> Moreover i liked Michael answer on this JIRA :
>> https://issues.apache.org/jira/browse/OFBIZ-8056?focusedComm
>> entId=15501066&page=com.atlassian.jira.plugin.system.
>> issuetabpanels:comment-tabpanel#comment-15501066
>>
>> Gil
>>
>> Le 21/09/2016 à 09:34, jler...@apache.org a écrit :
>>
>> Author: jleroux
>>> Date: Wed Sep 21 07:34:13 2016
>>> New Revision: 1761687
>>>
>>> URL:http://svn.apache.org/viewvc?rev=1761687&view=rev
>>> Log:
>>> Improves: Maximise the utilisation of common labels in various
>>> applications
>>> (OFBIZ-8110)
>>>
>>> There are many commonalities among entity field definitions. Often
>>> these
>>> field
>>> definitions have led to unique label definitions, where a shared
>>> (common) label
>>> could have sufficed.
>>>
>>> As examples you can take:
>>> * the various Id fields (where for most label CommonId could be used)
>>> * the various Type fields (where for most label CommonType could be
>>> used)
>>>
>>> This is a placeholder ticket, intended to capture applicable issues
>>> as
>>> sub tasks
>>>to address the aspect of maximising the utilisation of labels in
>>> the
>>> CommonUiLabels.xml file and to track progress.
>>>
>>> Thanks: Pierre Smits
>>>
>>> Modified:
>>> ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml
>>>
>>> Modified: ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.
>>> xml
>>> URL:http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/
>>> myportal/widget/PortalAdmForms.xml?rev=1761687
>>> &r1=1761686&r2=1761687&view=diff
>>> 
>>> ==
>>> --- ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml
>>> (original)
>>> +++ ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml
>>> Wed
>>> Sep 21 07:34:13 2016
>>> @@ -27,7 +27,7 @@ under the License.
>>>>> position="2">
>>>>> title="${uiLabelMap.CommonName
>>> }">
>>>>> position="2">>> ld>
>>> -
>>> +
>>>>> title="${uiLabelMap.CommonSecurityGroupId}">
>>>>> widget-style="smallSubmit">
>>>
>>> @@ -88,8 +88,8 @@ under the License.
>>>
>>>
>>>>> position="2">
>>> -
>>> ->> size="60"/>
>>> +
>>> +>> position="2">
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
>>>
>>
>>
>

Re: Preliminary question about themes before possible votes

[Jacques Le Roux]

Ah something I missed to precise: it's not about giving arguments, pro or cons. 
It's only about taking decisions, so again: please stay focused.

Thanks

Jacques


Le 21/09/2016 à 18:13, Jacques Le Roux a écrit :

Hi All,

At OFBIZ-8293 we began to informally discuss about reducing the number of OOTB 
themes. But we could clearly agree and believe a vote is better/

1. Now the 1st question which has been already discussed several time without a 
clear decision in this ML:
   do we, as a community, want to reduce the number  of themes?
   Should we vote on that before starting votes on or a lazy consensus could 
apply.
   I suggest that we try a lazy consensus and if nobody is against with strong 
argument we move on.
2. Should we vote on the number of themes to keep?
   Again I suggest a lazy consensus ratehr than a vote
3. The theme/s to remove, I think we should make several votes, one by theme, 
to clearly decide which theme/s to remove

Thanks for your help deciding on this, please try to keep focused :)

Jacques

Preliminary question about themes before possible votes

[Jacques Le Roux]

Hi All,

At OFBIZ-8293 we began to informally discuss about reducing the number of OOTB 
themes. But we could clearly agree and believe a vote is better/

1. Now the 1st question which has been already discussed several time without a 
clear decision in this ML:
   do we, as a community, want to reduce the number  of themes?
   Should we vote on that before starting votes on or a lazy consensus could 
apply.
   I suggest that we try a lazy consensus and if nobody is against with strong 
argument we move on.
2. Should we vote on the number of themes to keep?
   Again I suggest a lazy consensus ratehr than a vote
3. The theme/s to remove, I think we should make several votes, one by theme, 
to clearly decide which theme/s to remove

Thanks for your help deciding on this, please try to keep focused :)

Jacques

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

[Jacques Le Roux]

I'm not against reverting myself. Doing so it also means that everybody agree 
about continuing to use the FormFieldTitle_ feature

So if you really don't like it and have arguments, it's the moment to raise your hand. Before I revert in, say 2 days, and put this discussion back in 
the limbo


Jacques


Le 21/09/2016 à 16:04, Michael Brohl a écrit :

Jacques,

please take care of the revert, this will keep the commit history cleaner.

Thanks,

Michael


Am 21.09.16 um 14:04 schrieb Jacques Le Roux:

I'm not against reverting it, it's a moot point to me. Please help yourselves 
(Michael or Taher. Or maybe Christian? :D)

Jacques


Le 21/09/2016 à 11:11, Taher Alkhateeb a écrit :

I suggest also to revert. If we want to apply such a change in the future
then we must take a decision to stop using convention-over-configuration
for _all_ widget fields. And if we do not want to use that convention then
we should remove the related code accordingly.

On Wed, Sep 21, 2016 at 12:04 PM, Michael Brohl 
wrote:


I'd suggest to revert this commit.

Thanks,

Michael

Am 21.09.16 um 09:47 schrieb gil portenseigne:


Hi Jacques,

Like Nicolas said in previous Michael commit answer:
http://markmail.org/message/x4ulworuwgbotvrv?q=r1761332

I do not understand these kindof improvements. Adding a title when and
FormFieldTitle_XXX properties exists is not good in my opinion (i did not
check these ones).


Moreover i liked Michael answer on this JIRA :
https://issues.apache.org/jira/browse/OFBIZ-8056?focusedComm
entId=15501066&page=com.atlassian.jira.plugin.system.
issuetabpanels:comment-tabpanel#comment-15501066

Gil

Le 21/09/2016 à 09:34, jler...@apache.org a écrit :


Author: jleroux
Date: Wed Sep 21 07:34:13 2016
New Revision: 1761687

URL:http://svn.apache.org/viewvc?rev=1761687&view=rev
Log:
Improves: Maximise the utilisation of common labels in various
applications
(OFBIZ-8110)

There are many commonalities among entity field definitions. Often these
field
definitions have led to unique label definitions, where a shared
(common) label
could have sufficed.

As examples you can take:
* the various Id fields (where for most label CommonId could be used)
* the various Type fields (where for most label CommonType could be used)

This is a placeholder ticket, intended to capture applicable issues as
sub tasks
   to address the aspect of maximising the utilisation of labels in the
CommonUiLabels.xml file and to track progress.

Thanks: Pierre Smits

Modified:
ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

Modified: ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml
URL:http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/
myportal/widget/PortalAdmForms.xml?rev=1761687
&r1=1761686&r2=1761687&view=diff

==
--- ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml
(original)
+++ ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml Wed
Sep 21 07:34:13 2016
@@ -27,7 +27,7 @@ under the License.
   
   
   
-
+
   
   
   
@@ -88,8 +88,8 @@ under the License.
   
   
   
-
-
+
+
   
   
   

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

[Michael Brohl]

Jacques,

please take care of the revert, this will keep the commit history cleaner.

Thanks,

Michael


Am 21.09.16 um 14:04 schrieb Jacques Le Roux:
I'm not against reverting it, it's a moot point to me. Please help 
yourselves (Michael or Taher. Or maybe Christian? :D)


Jacques


Le 21/09/2016 à 11:11, Taher Alkhateeb a écrit :
I suggest also to revert. If we want to apply such a change in the 
future

then we must take a decision to stop using convention-over-configuration
for _all_ widget fields. And if we do not want to use that convention 
then

we should remove the related code accordingly.

On Wed, Sep 21, 2016 at 12:04 PM, Michael Brohl 


wrote:


I'd suggest to revert this commit.

Thanks,

Michael

Am 21.09.16 um 09:47 schrieb gil portenseigne:


Hi Jacques,

Like Nicolas said in previous Michael commit answer:
http://markmail.org/message/x4ulworuwgbotvrv?q=r1761332

I do not understand these kindof improvements. Adding a title when and
FormFieldTitle_XXX properties exists is not good in my opinion (i 
did not

check these ones).


Moreover i liked Michael answer on this JIRA :
https://issues.apache.org/jira/browse/OFBIZ-8056?focusedComm
entId=15501066&page=com.atlassian.jira.plugin.system.
issuetabpanels:comment-tabpanel#comment-15501066

Gil

Le 21/09/2016 à 09:34, jler...@apache.org a écrit :


Author: jleroux
Date: Wed Sep 21 07:34:13 2016
New Revision: 1761687

URL:http://svn.apache.org/viewvc?rev=1761687&view=rev
Log:
Improves: Maximise the utilisation of common labels in various
applications
(OFBIZ-8110)

There are many commonalities among entity field definitions. Often 
these

field
definitions have led to unique label definitions, where a shared
(common) label
could have sufficed.

As examples you can take:
* the various Id fields (where for most label CommonId could be used)
* the various Type fields (where for most label CommonType could 
be used)


This is a placeholder ticket, intended to capture applicable 
issues as

sub tasks
   to address the aspect of maximising the utilisation of labels 
in the

CommonUiLabels.xml file and to track progress.

Thanks: Pierre Smits

Modified:
ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

Modified: 
ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

URL:http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/
myportal/widget/PortalAdmForms.xml?rev=1761687
&r1=1761686&r2=1761687&view=diff

==
--- ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml
(original)
+++ ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml Wed
Sep 21 07:34:13 2016
@@ -27,7 +27,7 @@ under the License.
   
   title="${uiLabelMap.CommonName

}">
   position="2">
ld>
-
+
   
   title="${uiLabelMap.CommonFind}"

widget-style="smallSubmit">
   
@@ -88,8 +88,8 @@ under the License.
   
   
   position="2">

-
-size="60"/>

+
+title="${uiLabelMap.CommonDescription}"

position="2">
   
   
   












smime.p7s
Description: S/MIME Cryptographic Signature

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

[Jacques Le Roux]

I'm not against reverting it, it's a moot point to me. Please help yourselves 
(Michael or Taher. Or maybe Christian? :D)

Jacques


Le 21/09/2016 à 11:11, Taher Alkhateeb a écrit :

I suggest also to revert. If we want to apply such a change in the future
then we must take a decision to stop using convention-over-configuration
for _all_ widget fields. And if we do not want to use that convention then
we should remove the related code accordingly.

On Wed, Sep 21, 2016 at 12:04 PM, Michael Brohl 
wrote:


I'd suggest to revert this commit.

Thanks,

Michael

Am 21.09.16 um 09:47 schrieb gil portenseigne:


Hi Jacques,

Like Nicolas said in previous Michael commit answer:
http://markmail.org/message/x4ulworuwgbotvrv?q=r1761332

I do not understand these kindof improvements. Adding a title when and
FormFieldTitle_XXX properties exists is not good in my opinion (i did not
check these ones).


Moreover i liked Michael answer on this JIRA :
https://issues.apache.org/jira/browse/OFBIZ-8056?focusedComm
entId=15501066&page=com.atlassian.jira.plugin.system.
issuetabpanels:comment-tabpanel#comment-15501066

Gil

Le 21/09/2016 à 09:34, jler...@apache.org a écrit :


Author: jleroux
Date: Wed Sep 21 07:34:13 2016
New Revision: 1761687

URL:http://svn.apache.org/viewvc?rev=1761687&view=rev
Log:
Improves: Maximise the utilisation of common labels in various
applications
(OFBIZ-8110)

There are many commonalities among entity field definitions. Often these
field
definitions have led to unique label definitions, where a shared
(common) label
could have sufficed.

As examples you can take:
* the various Id fields (where for most label CommonId could be used)
* the various Type fields (where for most label CommonType could be used)

This is a placeholder ticket, intended to capture applicable issues as
sub tasks
   to address the aspect of maximising the utilisation of labels in the
CommonUiLabels.xml file and to track progress.

Thanks: Pierre Smits

Modified:
  ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

Modified: ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml
URL:http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/
myportal/widget/PortalAdmForms.xml?rev=1761687
&r1=1761686&r2=1761687&view=diff

==
--- ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml
(original)
+++ ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml Wed
Sep 21 07:34:13 2016
@@ -27,7 +27,7 @@ under the License.
   
   
   
-
+
   
   
   
@@ -88,8 +88,8 @@ under the License.
   
   
   
-
-
+
+
   
   
   

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

[Jacques Le Roux]

I don't think the performance argument is solid here

But the FormFieldTitle_ thing is questionnable, yes. Even if I must say I missed this point when I committed this in my haste to close OFBIZ-8110. I'm 
actually slightly for FormFieldTitle_s, though it's maybe blurring things a bit, really a moot point to me.


Jacques


Le 21/09/2016 à 11:03, Pierre Smits a écrit :

FormFieldTitle_XXX is for lazy programmers, only considering the OFBiz Demo
implementation as the only adopter of the product. Who use
{code}{code}
as their means to display entity elements (fields) in forms.

Unfortunately that doesn't work for all.

Furthermore, like I said in
https://issues.apache.org/jira/browse/OFBIZ-8121?focusedCommentId=15501193&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15501193
A specific title applied processes faster than none applied.

Also, applying specific labels reduces the total number of labels, when one
takes the context into consideration.
E.g.

CommonProduct

vs

AccountingProduct

ManufacturingProduct

OrderProduct

WorkEffortProduct
PartyProduct

FormFieldTitle_Product

ScrumProduct

EtcProduct


Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Wed, Sep 21, 2016 at 9:47 AM, gil portenseigne <
gil.portensei...@nereide.fr> wrote:


Hi Jacques,
Like Nicolas said in previous Michael commit answer:
http://markmail.org/message/x4ulworuwgbotvrv?q=r1761332

I do not understand these kind of improvements. Adding a title when and F
ormFieldTitle_XXX properties exists is not good in my opinion (i did not
check these ones).

Moreover i liked Michael answer on this JIRA :
https://issues.apache.org/jira/browse/OFBIZ-8056?focusedComm
entId=15501066&page=com.atlassian.jira.plugin.system.
issuetabpanels:comment-tabpanel#comment-15501066

Gil

Le 21/09/2016 à 09:34, jler...@apache.org a écrit :

Author: jleroux
Date: Wed Sep 21 07:34:13 2016
New Revision: 1761687

URL: http://svn.apache.org/viewvc?rev=1761687&view=rev
Log:
Improves: Maximise the utilisation of common labels in various applications
(OFBIZ-8110)

There are many commonalities among entity field definitions. Often these field
definitions have led to unique label definitions, where a shared (common) label
could have sufficed.

As examples you can take:
* the various Id fields (where for most label CommonId could be used)
* the various Type fields (where for most label CommonType could be used)

This is a placeholder ticket, intended to capture applicable issues as sub tasks
  to address the aspect of maximising the utilisation of labels in the
CommonUiLabels.xml file and to track progress.

Thanks: Pierre Smits

Modified:
 ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

Modified: ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml?rev=1761687&r1=1761686&r2=1761687&view=diff
==
--- ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml (original)
+++ ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml Wed Sep 21 
07:34:13 2016
@@ -27,7 +27,7 @@ under the License.
  
  
  
-
+
  
  
  
@@ -88,8 +88,8 @@ under the License.
  
  
  
-
-
+
+
  
  
  

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

[Jacques Le Roux]

This is a moot point, ask Christian :)

Jacques


Le 21/09/2016 à 09:47, gil portenseigne a écrit :


Hi Jacques,

Like Nicolas said in previous Michael commit answer: 
http://markmail.org/message/x4ulworuwgbotvrv?q=r1761332

I do not understand these kindof improvements. Adding a title when and FormFieldTitle_XXX properties exists is not good in my opinion (i did not 
check these ones).


Moreover i liked Michael answer on this JIRA : 
https://issues.apache.org/jira/browse/OFBIZ-8056?focusedCommentId=15501066&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15501066


Gil

Le 21/09/2016 à 09:34, jler...@apache.org a écrit :

Author: jleroux
Date: Wed Sep 21 07:34:13 2016
New Revision: 1761687

URL:http://svn.apache.org/viewvc?rev=1761687&view=rev
Log:
Improves: Maximise the utilisation of common labels in various applications
(OFBIZ-8110)

There are many commonalities among entity field definitions. Often these field
definitions have led to unique label definitions, where a shared (common) label
could have sufficed.

As examples you can take:
* the various Id fields (where for most label CommonId could be used)
* the various Type fields (where for most label CommonType could be used)

This is a placeholder ticket, intended to capture applicable issues as sub tasks
  to address the aspect of maximising the utilisation of labels in the
CommonUiLabels.xml file and to track progress.

Thanks: Pierre Smits

Modified:
 ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

Modified: ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml
URL:http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml?rev=1761687&r1=1761686&r2=1761687&view=diff
==
--- ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml (original)
+++ ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml Wed Sep 21 
07:34:13 2016
@@ -27,7 +27,7 @@ under the License.
  
  
  
-
+
  
  
  
@@ -88,8 +88,8 @@ under the License.
  
  
  
-
-
+
+
  
  
  

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

[Pierre Smits]

So what is the point you're trying to make?

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Wed, Sep 21, 2016 at 12:18 PM, gil portenseigne <
gil.portensei...@nereide.fr> wrote:

> Yes i did express myself bad :), it was not a point i wanted to insist on.
> Sorry for the distraction.
>
> Le 21/09/2016 à 12:16, Pierre Smits a écrit :
>
> No it doesn't. In fact it is completely off. Because the inclusion of the
> component name (MyComponent, in your reference) is nowhere required.
>
> Unless I am misunderstanding you.
>
> Best regards,
>
>
> Pierre Smits
>
> ORRTIZ.COM  
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplacehttp://oem.ofbizci.net/oci-2/
>
> On Wed, Sep 21, 2016 at 11:59 AM, gil portenseigne 
>  wrote:
>
>
> In the commit for instance :
>
> title="${uiLabelMap.CommonDescription}"
>
> the MyComponent/Common explain both possible cases...
>
> Le 21/09/2016 à 11:52, Pierre Smits a écrit :
>
>
> HI Gil,
>
> Where do you see "uiLabelMap.MyComponent/CommonX"  in widgets and
> templates? Nowhere, as far as I can tell. But in each (most?) component
> you'll find
> {code} global=
> "true"/>
> {code}
>
> And for what it is worth: a product in manufacturing, accounting, party,
> workeffort or any other component referencing a product from the product
> component is a product. No difference in context.
>
> Best regards,
>
> Pierre Smits
> ORRTIZ.COM  
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplacehttp://oem.ofbizci.net/oci-2/
>
> On Wed, Sep 21, 2016 at 11:25 AM, gil portenseigne 
>  wrote:
>
> Hi Pierre,
>
>
> I do not agree that FormFieldTitle_XXX is *only* for lazy programmer (and
> i remember a teacher that used to tell that to be good, you have to be
> sma
> rtly lazy :) ).
>
> The fact that this label contains default translation for XXX fields
> allow
> speed developpment and is far more readable than having
> title="uiLabelMap.MyComponent/CommonX" everywhere in your form
> file... And if you want to overload this label its very easy. I don't see
> the problem here.
>
> inline
> Le 21/09/2016 à 11:03, Pierre Smits a écrit :
>
> FormFieldTitle_XXX is for lazy programmers, only considering the OFBiz
> Demo
> implementation as the only adopter of the product. Who use
> {code} default-field-type=""
> />{code}
> as their means to display entity elements (fields) in forms.
>
> Unfortunately that doesn't work for all.
>
> Furthermore, like I said inhttps://issues.apache.org/ji
> ra/browse/OFBIZ-8121?focusedCommentId=15501193&page=com 
> .
> atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel#comment-15501193
> A specific title applied processes faster than none applied.
>
> How much ? For display i guess it's not significant.
>
>
> Also, applying specific labels reduces the total number of labels, when
> one
> takes the context into consideration.
>
> Labels for products or others object could be different in each
> component,
> thus i don't like replacing all with CommonXXX
>
> Regards,
>
> Gil
>
>
> E.g.
>
> CommonProduct
>
> vs
>
> AccountingProduct
>
> ManufacturingProduct
>
> OrderProduct
>
> WorkEffortProduct
> PartyProduct
>
> FormFieldTitle_Product
>
> ScrumProduct
>
> EtcProduct
>
>
> Best regards,
>
> Pierre SmitsORRTIZ.COM   
>  
>
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplacehttp://oem.ofbizci.net/oci-2/
>
>
> On Wed, Sep 21, 2016 at 9:47 AM, gil portenseigne 
>  wrote:
>
>
> Hi Jacques,
> Like Nicolas said in previous Michael commit 
> answer:http://markmail.org/message/x4ulworuwgbotvrv?q=r1761332
>
> I do not understand these kind of improvements. Adding a title when and F
> ormFieldTitle_XXX properties exists is not good in my opinion (i did not
> check these ones).
>
> Moreover i liked Michael answer on this JIRA 
> :https://issues.apache.org/jira/browse/OFBIZ-8056?focusedComm
> entId=15501066&page=com.atlassian.jira.plugin.system.
> issuetabpanels:comment-tabpanel#comment-15501066
>
> Gil
>
> Le 21/09/2016 à 09:34, jler...@apache.org a écrit :
>
> Author: jleroux
> Date: Wed Sep 21 07:34:13 2016
> New Revision: 1761687
>
> URL: http://svn.apache.org/viewvc?rev=1761687&view=rev
> Log:
> Improves: Maximise the utilisation of common labels in various
> applications
> (OFBIZ-8110)
>
> There are many commonalities among entity field definitions. Often these
> field
> definitions have led to unique label definitions, where a shared
> (common) label
> could have sufficed.
>
> As examples you can take:
> * the various Id fields (where for most label CommonId could be used)
> * the various Type fields (where for most label CommonType could be used)
>
> This 

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

[gil portenseigne]

Yes idid express myself bad :), it was not a point i wanted to insist 
on. Sorry for the distraction.



Le 21/09/2016 à 12:16, Pierre Smits a écrit :

No it doesn't. In fact it is completely off. Because the inclusion of the
component name (MyComponent, in your reference) is nowhere required.

Unless I am misunderstanding you.

Best regards,


Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Wed, Sep 21, 2016 at 11:59 AM, gil portenseigne <
gil.portensei...@nereide.fr> wrote:


In the commit for instance :

title="${uiLabelMap.CommonDescription}"

the MyComponent/Common explain both possible cases...

Le 21/09/2016 à 11:52, Pierre Smits a écrit :


HI Gil,

Where do you see "uiLabelMap.MyComponent/CommonX"  in widgets and
templates? Nowhere, as far as I can tell. But in each (most?) component
you'll find
{code}
{code}

And for what it is worth: a product in manufacturing, accounting, party,
workeffort or any other component referencing a product from the product
component is a product. No difference in context.

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Wed, Sep 21, 2016 at 11:25 AM, gil portenseigne <
gil.portensei...@nereide.fr> wrote:

Hi Pierre,

I do not agree that FormFieldTitle_XXX is *only* for lazy programmer (and
i remember a teacher that used to tell that to be good, you have to be
sma
rtly lazy :) ).

The fact that this label contains default translation for XXX fields
allow
speed developpment and is far more readable than having
title="uiLabelMap.MyComponent/CommonX" everywhere in your form
file... And if you want to overload this label its very easy. I don't see
the problem here.

inline
Le 21/09/2016 à 11:03, Pierre Smits a écrit :

FormFieldTitle_XXX is for lazy programmers, only considering the OFBiz
Demo
implementation as the only adopter of the product. Who use
{code}{code}
as their means to display entity elements (fields) in forms.

Unfortunately that doesn't work for all.

Furthermore, like I said inhttps://issues.apache.org/ji
ra/browse/OFBIZ-8121?focusedCommentId=15501193&page=com.
atlassian.jira.plugin.system.issuetabpanels:comment-
tabpanel#comment-15501193
A specific title applied processes faster than none applied.

How much ? For display i guess it's not significant.


Also, applying specific labels reduces the total number of labels, when
one
takes the context into consideration.

Labels for products or others object could be different in each
component,
thus i don't like replacing all with CommonXXX

Regards,

Gil


E.g.

CommonProduct

vs

AccountingProduct

ManufacturingProduct

OrderProduct

WorkEffortProduct
PartyProduct

FormFieldTitle_Product

ScrumProduct

EtcProduct


Best regards,

Pierre Smits
ORRTIZ.COM  

OFBiz based solutions & services

OFBiz Extensions Marketplacehttp://oem.ofbizci.net/oci-2/


On Wed, Sep 21, 2016 at 9:47 AM, gil portenseigne <
gil.portensei...@nereide.fr> wrote:


Hi Jacques,
Like Nicolas said in previous Michael commit answer:
http://markmail.org/message/x4ulworuwgbotvrv?q=r1761332

I do not understand these kind of improvements. Adding a title when and F
ormFieldTitle_XXX properties exists is not good in my opinion (i did not
check these ones).

Moreover i liked Michael answer on this JIRA :
https://issues.apache.org/jira/browse/OFBIZ-8056?focusedComm
entId=15501066&page=com.atlassian.jira.plugin.system.
issuetabpanels:comment-tabpanel#comment-15501066

Gil

Le 21/09/2016 à 09:34, jler...@apache.org a écrit :

Author: jleroux
Date: Wed Sep 21 07:34:13 2016
New Revision: 1761687

URL: http://svn.apache.org/viewvc?rev=1761687&view=rev
Log:
Improves: Maximise the utilisation of common labels in various
applications
(OFBIZ-8110)

There are many commonalities among entity field definitions. Often these
field
definitions have led to unique label definitions, where a shared
(common) label
could have sufficed.

As examples you can take:
* the various Id fields (where for most label CommonId could be used)
* the various Type fields (where for most label CommonType could be used)

This is a placeholder ticket, intended to capture applicable issues as
sub tasks
   to address the aspect of maximising the utilisation of labels in the
CommonUiLabels.xml file and to track progress.

Thanks: Pierre Smits

Modified:
  ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

Modified: ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml
URL: http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/mypo
rtal/widget/PortalAdmForms.xml?rev=1761687&r1=1761686&r2=
1761687&view=diff

==
--- ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml
(original)
+++ ofbiz/trunk/specialpurpose/myportal/widg

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

[Pierre Smits]

No it doesn't. In fact it is completely off. Because the inclusion of the
component name (MyComponent, in your reference) is nowhere required.

Unless I am misunderstanding you.

Best regards,


Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Wed, Sep 21, 2016 at 11:59 AM, gil portenseigne <
gil.portensei...@nereide.fr> wrote:

> In the commit for instance :
>
> title="${uiLabelMap.CommonDescription}"
>
> the MyComponent/Common explain both possible cases...
>
> Le 21/09/2016 à 11:52, Pierre Smits a écrit :
>
>> HI Gil,
>>
>> Where do you see "uiLabelMap.MyComponent/CommonX"  in widgets and
>> templates? Nowhere, as far as I can tell. But in each (most?) component
>> you'll find
>> {code}> global=
>> "true"/>
>> {code}
>>
>> And for what it is worth: a product in manufacturing, accounting, party,
>> workeffort or any other component referencing a product from the product
>> component is a product. No difference in context.
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> ORRTIZ.COM 
>> OFBiz based solutions & services
>>
>> OFBiz Extensions Marketplace
>> http://oem.ofbizci.net/oci-2/
>>
>> On Wed, Sep 21, 2016 at 11:25 AM, gil portenseigne <
>> gil.portensei...@nereide.fr> wrote:
>>
>> Hi Pierre,
>>>
>>> I do not agree that FormFieldTitle_XXX is *only* for lazy programmer (and
>>> i remember a teacher that used to tell that to be good, you have to be
>>> sma
>>> rtly lazy :) ).
>>>
>>> The fact that this label contains default translation for XXX fields
>>> allow
>>> speed developpment and is far more readable than having
>>> title="uiLabelMap.MyComponent/CommonX" everywhere in your form
>>> file... And if you want to overload this label its very easy. I don't see
>>> the problem here.
>>>
>>> inline
>>> Le 21/09/2016 à 11:03, Pierre Smits a écrit :
>>>
>>> FormFieldTitle_XXX is for lazy programmers, only considering the OFBiz
>>> Demo
>>> implementation as the only adopter of the product. Who use
>>> {code}>> default-field-type=""
>>> />{code}
>>> as their means to display entity elements (fields) in forms.
>>>
>>> Unfortunately that doesn't work for all.
>>>
>>> Furthermore, like I said inhttps://issues.apache.org/ji
>>> ra/browse/OFBIZ-8121?focusedCommentId=15501193&page=com.
>>> atlassian.jira.plugin.system.issuetabpanels:comment-
>>> tabpanel#comment-15501193
>>> A specific title applied processes faster than none applied.
>>>
>>> How much ? For display i guess it's not significant.
>>>
>>>
>>> Also, applying specific labels reduces the total number of labels, when
>>> one
>>> takes the context into consideration.
>>>
>>> Labels for products or others object could be different in each
>>> component,
>>> thus i don't like replacing all with CommonXXX
>>>
>>> Regards,
>>>
>>> Gil
>>>
>>>
>>> E.g.
>>>
>>> CommonProduct
>>>
>>> vs
>>>
>>> AccountingProduct
>>>
>>> ManufacturingProduct
>>>
>>> OrderProduct
>>>
>>> WorkEffortProduct
>>> PartyProduct
>>>
>>> FormFieldTitle_Product
>>>
>>> ScrumProduct
>>>
>>> EtcProduct
>>>
>>>
>>> Best regards,
>>>
>>> Pierre Smits
>>> ORRTIZ.COM  
>>>
>>> OFBiz based solutions & services
>>>
>>> OFBiz Extensions Marketplacehttp://oem.ofbizci.net/oci-2/
>>>
>>>
>>> On Wed, Sep 21, 2016 at 9:47 AM, gil portenseigne <
>>> gil.portensei...@nereide.fr> wrote:
>>>
>>>
>>> Hi Jacques,
>>> Like Nicolas said in previous Michael commit answer:
>>> http://markmail.org/message/x4ulworuwgbotvrv?q=r1761332
>>>
>>> I do not understand these kind of improvements. Adding a title when and F
>>> ormFieldTitle_XXX properties exists is not good in my opinion (i did not
>>> check these ones).
>>>
>>> Moreover i liked Michael answer on this JIRA :
>>> https://issues.apache.org/jira/browse/OFBIZ-8056?focusedComm
>>> entId=15501066&page=com.atlassian.jira.plugin.system.
>>> issuetabpanels:comment-tabpanel#comment-15501066
>>>
>>> Gil
>>>
>>> Le 21/09/2016 à 09:34, jler...@apache.org a écrit :
>>>
>>> Author: jleroux
>>> Date: Wed Sep 21 07:34:13 2016
>>> New Revision: 1761687
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1761687&view=rev
>>> Log:
>>> Improves: Maximise the utilisation of common labels in various
>>> applications
>>> (OFBIZ-8110)
>>>
>>> There are many commonalities among entity field definitions. Often these
>>> field
>>> definitions have led to unique label definitions, where a shared
>>> (common) label
>>> could have sufficed.
>>>
>>> As examples you can take:
>>> * the various Id fields (where for most label CommonId could be used)
>>> * the various Type fields (where for most label CommonType could be used)
>>>
>>> This is a placeholder ticket, intended to capture applicable issues as
>>> sub tasks
>>>   to address the aspect of maximising the utilisation of labels in the
>>> CommonUiLabels.xml file and to track progress.
>>>
>>> Thanks: Pierre Smits
>>>
>>> Modified:
>>>  ofbiz/trunk/specialpurpose/

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

[gil portenseigne]

In the commit for instance :

title="${uiLabelMap.CommonDescription}"

the MyComponent/Common explain both possible cases...

Le 21/09/2016 à 11:52, Pierre Smits a écrit :

HI Gil,

Where do you see "uiLabelMap.MyComponent/CommonX"  in widgets and
templates? Nowhere, as far as I can tell. But in each (most?) component
you'll find
{code}
{code}

And for what it is worth: a product in manufacturing, accounting, party,
workeffort or any other component referencing a product from the product
component is a product. No difference in context.

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Wed, Sep 21, 2016 at 11:25 AM, gil portenseigne <
gil.portensei...@nereide.fr> wrote:


Hi Pierre,

I do not agree that FormFieldTitle_XXX is *only* for lazy programmer (and
i remember a teacher that used to tell that to be good, you have to be sma
rtly lazy :) ).

The fact that this label contains default translation for XXX fields allow
speed developpment and is far more readable than having
title="uiLabelMap.MyComponent/CommonX" everywhere in your form
file... And if you want to overload this label its very easy. I don't see
the problem here.

inline
Le 21/09/2016 à 11:03, Pierre Smits a écrit :

FormFieldTitle_XXX is for lazy programmers, only considering the OFBiz Demo
implementation as the only adopter of the product. Who use
{code}{code}
as their means to display entity elements (fields) in forms.

Unfortunately that doesn't work for all.

Furthermore, like I said 
inhttps://issues.apache.org/jira/browse/OFBIZ-8121?focusedCommentId=15501193&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15501193
A specific title applied processes faster than none applied.

How much ? For display i guess it's not significant.


Also, applying specific labels reduces the total number of labels, when one
takes the context into consideration.

Labels for products or others object could be different in each component,
thus i don't like replacing all with CommonXXX

Regards,

Gil


E.g.

CommonProduct

vs

AccountingProduct

ManufacturingProduct

OrderProduct

WorkEffortProduct
PartyProduct

FormFieldTitle_Product

ScrumProduct

EtcProduct


Best regards,

Pierre Smits
ORRTIZ.COM  

OFBiz based solutions & services

OFBiz Extensions Marketplacehttp://oem.ofbizci.net/oci-2/

On Wed, Sep 21, 2016 at 9:47 AM, gil portenseigne  
wrote:


Hi Jacques,
Like Nicolas said in previous Michael commit 
answer:http://markmail.org/message/x4ulworuwgbotvrv?q=r1761332

I do not understand these kind of improvements. Adding a title when and F
ormFieldTitle_XXX properties exists is not good in my opinion (i did not
check these ones).

Moreover i liked Michael answer on this JIRA 
:https://issues.apache.org/jira/browse/OFBIZ-8056?focusedComm
entId=15501066&page=com.atlassian.jira.plugin.system.
issuetabpanels:comment-tabpanel#comment-15501066

Gil

Le 21/09/2016 à 09:34, jler...@apache.org a écrit :

Author: jleroux
Date: Wed Sep 21 07:34:13 2016
New Revision: 1761687

URL: http://svn.apache.org/viewvc?rev=1761687&view=rev
Log:
Improves: Maximise the utilisation of common labels in various applications
(OFBIZ-8110)

There are many commonalities among entity field definitions. Often these field
definitions have led to unique label definitions, where a shared (common) label
could have sufficed.

As examples you can take:
* the various Id fields (where for most label CommonId could be used)
* the various Type fields (where for most label CommonType could be used)

This is a placeholder ticket, intended to capture applicable issues as sub tasks
  to address the aspect of maximising the utilisation of labels in the
CommonUiLabels.xml file and to track progress.

Thanks: Pierre Smits

Modified:
 ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

Modified: ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml?rev=1761687&r1=1761686&r2=1761687&view=diff
==
--- ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml (original)
+++ ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml Wed Sep 21 
07:34:13 2016
@@ -27,7 +27,7 @@ under the License.
  
  
  
-
+
  
  
  
@@ -88,8 +88,8 @@ under the License.
  
  
  
-
-
+
+
  
  
  

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

[Pierre Smits]

HI Gil,

Where do you see "uiLabelMap.MyComponent/CommonX"  in widgets and
templates? Nowhere, as far as I can tell. But in each (most?) component
you'll find
{code}
{code}

And for what it is worth: a product in manufacturing, accounting, party,
workeffort or any other component referencing a product from the product
component is a product. No difference in context.

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Wed, Sep 21, 2016 at 11:25 AM, gil portenseigne <
gil.portensei...@nereide.fr> wrote:

> Hi Pierre,
>
> I do not agree that FormFieldTitle_XXX is *only* for lazy programmer (and
> i remember a teacher that used to tell that to be good, you have to be sma
> rtly lazy :) ).
>
> The fact that this label contains default translation for XXX fields allow
> speed developpment and is far more readable than having
> title="uiLabelMap.MyComponent/CommonX" everywhere in your form
> file... And if you want to overload this label its very easy. I don't see
> the problem here.
>
> inline
> Le 21/09/2016 à 11:03, Pierre Smits a écrit :
>
> FormFieldTitle_XXX is for lazy programmers, only considering the OFBiz Demo
> implementation as the only adopter of the product. Who use
> {code} />{code}
> as their means to display entity elements (fields) in forms.
>
> Unfortunately that doesn't work for all.
>
> Furthermore, like I said 
> inhttps://issues.apache.org/jira/browse/OFBIZ-8121?focusedCommentId=15501193&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15501193
> A specific title applied processes faster than none applied.
>
> How much ? For display i guess it's not significant.
>
>
> Also, applying specific labels reduces the total number of labels, when one
> takes the context into consideration.
>
> Labels for products or others object could be different in each component,
> thus i don't like replacing all with CommonXXX
>
> Regards,
>
> Gil
>
>
> E.g.
>
> CommonProduct
>
> vs
>
> AccountingProduct
>
> ManufacturingProduct
>
> OrderProduct
>
> WorkEffortProduct
> PartyProduct
>
> FormFieldTitle_Product
>
> ScrumProduct
>
> EtcProduct
>
>
> Best regards,
>
> Pierre Smits
> ORRTIZ.COM  
>
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplacehttp://oem.ofbizci.net/oci-2/
>
> On Wed, Sep 21, 2016 at 9:47 AM, gil portenseigne 
>  wrote:
>
>
> Hi Jacques,
> Like Nicolas said in previous Michael commit 
> answer:http://markmail.org/message/x4ulworuwgbotvrv?q=r1761332
>
> I do not understand these kind of improvements. Adding a title when and F
> ormFieldTitle_XXX properties exists is not good in my opinion (i did not
> check these ones).
>
> Moreover i liked Michael answer on this JIRA 
> :https://issues.apache.org/jira/browse/OFBIZ-8056?focusedComm
> entId=15501066&page=com.atlassian.jira.plugin.system.
> issuetabpanels:comment-tabpanel#comment-15501066
>
> Gil
>
> Le 21/09/2016 à 09:34, jler...@apache.org a écrit :
>
> Author: jleroux
> Date: Wed Sep 21 07:34:13 2016
> New Revision: 1761687
>
> URL: http://svn.apache.org/viewvc?rev=1761687&view=rev
> Log:
> Improves: Maximise the utilisation of common labels in various applications
> (OFBIZ-8110)
>
> There are many commonalities among entity field definitions. Often these field
> definitions have led to unique label definitions, where a shared (common) 
> label
> could have sufficed.
>
> As examples you can take:
> * the various Id fields (where for most label CommonId could be used)
> * the various Type fields (where for most label CommonType could be used)
>
> This is a placeholder ticket, intended to capture applicable issues as sub 
> tasks
>  to address the aspect of maximising the utilisation of labels in the
> CommonUiLabels.xml file and to track progress.
>
> Thanks: Pierre Smits
>
> Modified:
> ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml
>
> Modified: ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml
> URL: 
> http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml?rev=1761687&r1=1761686&r2=1761687&view=diff
> ==
> --- ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml (original)
> +++ ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml Wed Sep 21 
> 07:34:13 2016
> @@ -27,7 +27,7 @@ under the License.
>  
>   title="${uiLabelMap.CommonName}">
>  
> -
> + title="${uiLabelMap.CommonDescription}">
>   title="${uiLabelMap.CommonSecurityGroupId}">
>   widget-style="smallSubmit">
>  
> @@ -88,8 +88,8 @@ under the License.
>  
>  
>  
> -
> -
> + title="${uiLabelMap.CommonName}">
> + position="2">
>  
>  
>  
>
>
>
>
>
>
>
>

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

[Taher Alkhateeb]

I suggest also to revert. If we want to apply such a change in the future
then we must take a decision to stop using convention-over-configuration
for _all_ widget fields. And if we do not want to use that convention then
we should remove the related code accordingly.

On Wed, Sep 21, 2016 at 12:04 PM, Michael Brohl 
wrote:

> I'd suggest to revert this commit.
>
> Thanks,
>
> Michael
>
> Am 21.09.16 um 09:47 schrieb gil portenseigne:
>
>>
>> Hi Jacques,
>>
>> Like Nicolas said in previous Michael commit answer:
>> http://markmail.org/message/x4ulworuwgbotvrv?q=r1761332
>>
>> I do not understand these kindof improvements. Adding a title when and
>> FormFieldTitle_XXX properties exists is not good in my opinion (i did not
>> check these ones).
>>
>>
>> Moreover i liked Michael answer on this JIRA :
>> https://issues.apache.org/jira/browse/OFBIZ-8056?focusedComm
>> entId=15501066&page=com.atlassian.jira.plugin.system.
>> issuetabpanels:comment-tabpanel#comment-15501066
>>
>> Gil
>>
>> Le 21/09/2016 à 09:34, jler...@apache.org a écrit :
>>
>>> Author: jleroux
>>> Date: Wed Sep 21 07:34:13 2016
>>> New Revision: 1761687
>>>
>>> URL:http://svn.apache.org/viewvc?rev=1761687&view=rev
>>> Log:
>>> Improves: Maximise the utilisation of common labels in various
>>> applications
>>> (OFBIZ-8110)
>>>
>>> There are many commonalities among entity field definitions. Often these
>>> field
>>> definitions have led to unique label definitions, where a shared
>>> (common) label
>>> could have sufficed.
>>>
>>> As examples you can take:
>>> * the various Id fields (where for most label CommonId could be used)
>>> * the various Type fields (where for most label CommonType could be used)
>>>
>>> This is a placeholder ticket, intended to capture applicable issues as
>>> sub tasks
>>>   to address the aspect of maximising the utilisation of labels in the
>>> CommonUiLabels.xml file and to track progress.
>>>
>>> Thanks: Pierre Smits
>>>
>>> Modified:
>>>  ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml
>>>
>>> Modified: ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml
>>> URL:http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/
>>> myportal/widget/PortalAdmForms.xml?rev=1761687
>>> &r1=1761686&r2=1761687&view=diff
>>> 
>>> ==
>>> --- ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml
>>> (original)
>>> +++ ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml Wed
>>> Sep 21 07:34:13 2016
>>> @@ -27,7 +27,7 @@ under the License.
>>>   >> position="2">
>>>   
>>>   >> ld>
>>> -
>>> +
>>>   >> title="${uiLabelMap.CommonSecurityGroupId}">
>>>   >> widget-style="smallSubmit">
>>>   
>>> @@ -88,8 +88,8 @@ under the License.
>>>   
>>>   
>>>   
>>> -
>>> -
>>> +
>>> +>> position="2">
>>>   
>>>   
>>>   
>>>
>>>
>>>
>>
>
>

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

[Michael Brohl]

Hi Gil,

Am 21.09.16 um 11:25 schrieb gil portenseigne:
Labels for products or others object could be different in each 
component, thus i don't like replacing all with CommonXXX


I agree, this would be an unwanted regression.

Regards,

Michael





smime.p7s
Description: S/MIME Cryptographic Signature

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

[gil portenseigne]

Hi Pierre,

I do not agree that FormFieldTitle_XXX is *only* for lazy programmer 
(and i remember a teacher that used to tell that to be good, you have to 
be smartly lazy :) ).


The fact that this label contains default translation for XXX fields 
allow speed developpmentand is far more readable thanhaving 
title="uiLabelMap.MyComponent/CommonX" everywhere in your form 
file... And if you want to overload this label its very easy. Idon't see 
the problem here.



inline
Le 21/09/2016 à 11:03, Pierre Smits a écrit :

FormFieldTitle_XXX is for lazy programmers, only considering the OFBiz Demo
implementation as the only adopter of the product. Who use
{code}{code}
as their means to display entity elements (fields) in forms.

Unfortunately that doesn't work for all.

Furthermore, like I said in
https://issues.apache.org/jira/browse/OFBIZ-8121?focusedCommentId=15501193&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15501193
A specific title applied processes faster than none applied.

How much ? For display i guess it's not significant.


Also, applying specific labels reduces the total number of labels, when one
takes the context into consideration.
Labels for products or others object could be different in each 
component, thus i don't like replacing all with CommonXXX


Regards,

Gil

E.g.

CommonProduct

vs

AccountingProduct

ManufacturingProduct

OrderProduct

WorkEffortProduct
PartyProduct

FormFieldTitle_Product

ScrumProduct

EtcProduct


Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Wed, Sep 21, 2016 at 9:47 AM, gil portenseigne <
gil.portensei...@nereide.fr> wrote:


Hi Jacques,
Like Nicolas said in previous Michael commit answer:
http://markmail.org/message/x4ulworuwgbotvrv?q=r1761332

I do not understand these kind of improvements. Adding a title when and F
ormFieldTitle_XXX properties exists is not good in my opinion (i did not
check these ones).

Moreover i liked Michael answer on this JIRA :
https://issues.apache.org/jira/browse/OFBIZ-8056?focusedComm
entId=15501066&page=com.atlassian.jira.plugin.system.
issuetabpanels:comment-tabpanel#comment-15501066

Gil

Le 21/09/2016 à 09:34, jler...@apache.org a écrit :

Author: jleroux
Date: Wed Sep 21 07:34:13 2016
New Revision: 1761687

URL: http://svn.apache.org/viewvc?rev=1761687&view=rev
Log:
Improves: Maximise the utilisation of common labels in various applications
(OFBIZ-8110)

There are many commonalities among entity field definitions. Often these field
definitions have led to unique label definitions, where a shared (common) label
could have sufficed.

As examples you can take:
* the various Id fields (where for most label CommonId could be used)
* the various Type fields (where for most label CommonType could be used)

This is a placeholder ticket, intended to capture applicable issues as sub tasks
  to address the aspect of maximising the utilisation of labels in the
CommonUiLabels.xml file and to track progress.

Thanks: Pierre Smits

Modified:
 ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

Modified: ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml?rev=1761687&r1=1761686&r2=1761687&view=diff
==
--- ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml (original)
+++ ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml Wed Sep 21 
07:34:13 2016
@@ -27,7 +27,7 @@ under the License.
  
  
  
-
+
  
  
  
@@ -88,8 +88,8 @@ under the License.
  
  
  
-
-
+
+
  
  
  

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

[Michael Brohl]

I'd suggest to revert this commit.

Thanks,

Michael

Am 21.09.16 um 09:47 schrieb gil portenseigne:


Hi Jacques,

Like Nicolas said in previous Michael commit answer: 
http://markmail.org/message/x4ulworuwgbotvrv?q=r1761332


I do not understand these kindof improvements. Adding a title when and 
FormFieldTitle_XXX properties exists is not good in my opinion (i did 
not check these ones).


Moreover i liked Michael answer on this JIRA : 
https://issues.apache.org/jira/browse/OFBIZ-8056?focusedCommentId=15501066&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15501066


Gil

Le 21/09/2016 à 09:34, jler...@apache.org a écrit :

Author: jleroux
Date: Wed Sep 21 07:34:13 2016
New Revision: 1761687

URL:http://svn.apache.org/viewvc?rev=1761687&view=rev
Log:
Improves: Maximise the utilisation of common labels in various applications
(OFBIZ-8110)

There are many commonalities among entity field definitions. Often these field
definitions have led to unique label definitions, where a shared (common) label
could have sufficed.

As examples you can take:
* the various Id fields (where for most label CommonId could be used)
* the various Type fields (where for most label CommonType could be used)

This is a placeholder ticket, intended to capture applicable issues as sub tasks
  to address the aspect of maximising the utilisation of labels in the
CommonUiLabels.xml file and to track progress.

Thanks: Pierre Smits

Modified:
 ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

Modified: ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml
URL:http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml?rev=1761687&r1=1761686&r2=1761687&view=diff
==
--- ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml (original)
+++ ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml Wed Sep 21 
07:34:13 2016
@@ -27,7 +27,7 @@ under the License.
  
  
  
-
+
  
  
  
@@ -88,8 +88,8 @@ under the License.
  
  
  
-
-
+
+
  
  
  









smime.p7s
Description: S/MIME Cryptographic Signature

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

[Pierre Smits]

FormFieldTitle_XXX is for lazy programmers, only considering the OFBiz Demo
implementation as the only adopter of the product. Who use
{code}{code}
as their means to display entity elements (fields) in forms.

Unfortunately that doesn't work for all.

Furthermore, like I said in
https://issues.apache.org/jira/browse/OFBIZ-8121?focusedCommentId=15501193&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15501193
A specific title applied processes faster than none applied.

Also, applying specific labels reduces the total number of labels, when one
takes the context into consideration.
E.g.

CommonProduct

vs

AccountingProduct

ManufacturingProduct

OrderProduct

WorkEffortProduct
PartyProduct

FormFieldTitle_Product

ScrumProduct

EtcProduct


Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Wed, Sep 21, 2016 at 9:47 AM, gil portenseigne <
gil.portensei...@nereide.fr> wrote:

> Hi Jacques,
> Like Nicolas said in previous Michael commit answer:
> http://markmail.org/message/x4ulworuwgbotvrv?q=r1761332
>
> I do not understand these kind of improvements. Adding a title when and F
> ormFieldTitle_XXX properties exists is not good in my opinion (i did not
> check these ones).
>
> Moreover i liked Michael answer on this JIRA :
> https://issues.apache.org/jira/browse/OFBIZ-8056?focusedComm
> entId=15501066&page=com.atlassian.jira.plugin.system.
> issuetabpanels:comment-tabpanel#comment-15501066
>
> Gil
>
> Le 21/09/2016 à 09:34, jler...@apache.org a écrit :
>
> Author: jleroux
> Date: Wed Sep 21 07:34:13 2016
> New Revision: 1761687
>
> URL: http://svn.apache.org/viewvc?rev=1761687&view=rev
> Log:
> Improves: Maximise the utilisation of common labels in various applications
> (OFBIZ-8110)
>
> There are many commonalities among entity field definitions. Often these field
> definitions have led to unique label definitions, where a shared (common) 
> label
> could have sufficed.
>
> As examples you can take:
> * the various Id fields (where for most label CommonId could be used)
> * the various Type fields (where for most label CommonType could be used)
>
> This is a placeholder ticket, intended to capture applicable issues as sub 
> tasks
>  to address the aspect of maximising the utilisation of labels in the
> CommonUiLabels.xml file and to track progress.
>
> Thanks: Pierre Smits
>
> Modified:
> ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml
>
> Modified: ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml
> URL: 
> http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml?rev=1761687&r1=1761686&r2=1761687&view=diff
> ==
> --- ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml (original)
> +++ ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml Wed Sep 21 
> 07:34:13 2016
> @@ -27,7 +27,7 @@ under the License.
>  
>   title="${uiLabelMap.CommonName}">
>  
> -
> + title="${uiLabelMap.CommonDescription}">
>   title="${uiLabelMap.CommonSecurityGroupId}">
>   widget-style="smallSubmit">
>  
> @@ -88,8 +88,8 @@ under the License.
>  
>  
>  
> -
> -
> + title="${uiLabelMap.CommonName}">
> + position="2">
>  
>  
>  
>
>
>
>
>

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

[gil portenseigne]

Hi Jacques,

Like Nicolas said in previous Michael commit answer: 
http://markmail.org/message/x4ulworuwgbotvrv?q=r1761332


I do not understand these kindof improvements. Adding a title when and 
FormFieldTitle_XXX properties exists is not good in my opinion (i did 
not check these ones).


Moreover i liked Michael answer on this JIRA : 
https://issues.apache.org/jira/browse/OFBIZ-8056?focusedCommentId=15501066&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15501066


Gil

Le 21/09/2016 à 09:34, jler...@apache.org a écrit :

Author: jleroux
Date: Wed Sep 21 07:34:13 2016
New Revision: 1761687

URL: http://svn.apache.org/viewvc?rev=1761687&view=rev
Log:
Improves: Maximise the utilisation of common labels in various applications
(OFBIZ-8110)

There are many commonalities among entity field definitions. Often these field
definitions have led to unique label definitions, where a shared (common) label
could have sufficed.

As examples you can take:
* the various Id fields (where for most label CommonId could be used)
* the various Type fields (where for most label CommonType could be used)

This is a placeholder ticket, intended to capture applicable issues as sub tasks
  to address the aspect of maximising the utilisation of labels in the
CommonUiLabels.xml file and to track progress.

Thanks: Pierre Smits

Modified:
 ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

Modified: ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml?rev=1761687&r1=1761686&r2=1761687&view=diff
==
--- ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml (original)
+++ ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml Wed Sep 21 
07:34:13 2016
@@ -27,7 +27,7 @@ under the License.
  
  
  
-
+
  
  
  
@@ -88,8 +88,8 @@ under the License.
  
  
  
-
-
+
+