Re: svn commit: r1518777 - in /ofbiz/trunk: applications/accounting/webapp/accounting/WEB-INF/ applications/order/webapp/ordermgr/WEB-INF/ applications/product/webapp/facility/WEB-INF/ framework/base/

[Adrian Crum]

I would prefer an attribute name like "optional" - indicating the 
include is optional and the missing configuration file will not prevent 
the webapp from loading.


-Adrian

On 8/29/2013 12:37 PM, jler...@apache.org wrote:

Author: jleroux
Date: Thu Aug 29 19:37:44 2013
New Revision: 1518777

URL: http://svn.apache.org/r1518777
Log:
This fixes "Net before overhead report generates an error" 
https://issues.apache.org/jira/browse/OFBIZ-5267

This is related with r1361130, where the birt component was moved from 
framework to specialpurpose.

The fix is to create the possibility of a loose coupling from applications 
controllers to specialpurpose controllers. For that an if-present attribute is 
added to the include element. When used, if the included controller does not 
exist, instead of an error and a stack trace, a warning is thrown (only in 
English, for developers) suggesting to checkout the component from trunk. 
Indeed, in the current case, this situation should only arise in release after 
12.04 where the birt component, like all others but the ecommerce component, 
had been removed. This can be used in other cases, but for now only the 
component level is covered.

Modified:
 
ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/controller.xml
 ofbiz/trunk/applications/order/webapp/ordermgr/WEB-INF/controller.xml
 ofbiz/trunk/applications/product/webapp/facility/WEB-INF/controller.xml
 
ofbiz/trunk/framework/base/src/org/ofbiz/base/location/ComponentLocationResolver.java
 ofbiz/trunk/framework/base/src/org/ofbiz/base/util/FileUtil.java
 ofbiz/trunk/framework/webapp/dtd/site-conf.xsd
 
ofbiz/trunk/framework/webapp/src/org/ofbiz/webapp/control/ConfigXMLReader.java
 ofbiz/trunk/specialpurpose/birt/ofbiz-component.xml
 ofbiz/trunk/specialpurpose/birt/webapp/accounting/WEB-INF/controller.xml
 ofbiz/trunk/specialpurpose/birt/webapp/facility/WEB-INF/controller.xml
 ofbiz/trunk/specialpurpose/birt/webapp/ordermgr/WEB-INF/controller.xml

Modified: 
ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/controller.xml
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/controller.xml?rev=1518777&r1=1518776&r2=1518777&view=diff
==
--- 
ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/controller.xml 
(original)
+++ 
ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/controller.xml 
Thu Aug 29 19:37:44 2013
@@ -22,6 +22,7 @@ under the License.
  
xsi:noNamespaceSchemaLocation="http://ofbiz.apache.org/dtds/site-conf.xsd";>
  
  
+
  Accounting Manager Module Site Configuration 
File
  
  


Modified: ofbiz/trunk/applications/order/webapp/ordermgr/WEB-INF/controller.xml
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/applications/order/webapp/ordermgr/WEB-INF/controller.xml?rev=1518777&r1=1518776&r2=1518777&view=diff
==
--- ofbiz/trunk/applications/order/webapp/ordermgr/WEB-INF/controller.xml 
(original)
+++ ofbiz/trunk/applications/order/webapp/ordermgr/WEB-INF/controller.xml Thu 
Aug 29 19:37:44 2013
@@ -23,6 +23,7 @@ under the License.
  
  
  
+
  Order Manager Module Site Configuration File
  
  


Modified: 
ofbiz/trunk/applications/product/webapp/facility/WEB-INF/controller.xml
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/applications/product/webapp/facility/WEB-INF/controller.xml?rev=1518777&r1=1518776&r2=1518777&view=diff
==
--- ofbiz/trunk/applications/product/webapp/facility/WEB-INF/controller.xml 
(original)
+++ ofbiz/trunk/applications/product/webapp/facility/WEB-INF/controller.xml Thu 
Aug 29 19:37:44 2013
@@ -22,6 +22,8 @@ under the License.
  
xsi:noNamespaceSchemaLocation="http://ofbiz.apache.org/dtds/site-conf.xsd";>
  
  
+
+
  Facility Manager Module Site Configuration File
  
  


Modified: 
ofbiz/trunk/framework/base/src/org/ofbiz/base/location/ComponentLocationResolver.java
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/framework/base/src/org/ofbiz/base/location/ComponentLocationResolver.java?rev=1518777&r1=1518776&r2=1518777&view=diff
==
--- 
ofbiz/trunk/framework/base/src/org/ofbiz/base/location/ComponentLocationResolver.java
 (original)
+++ 
ofbiz/trunk/framework/base/src/org/ofbiz/base/location/ComponentLocationResolver.java
 Thu Aug 29 19:37:44 2013
@@ -38,7 +38,7 @@ public class ComponentLocationResolver i
  public static final String module = 
ComponentLocationResolver.class.getName();
  
  public URL resolveLocation(String location) throws MalformedURLException {

-String baseLocation = getBaseLocation(location).toString();
+String baseLocat

Re: svn commit: r1518777 - in /ofbiz/trunk: applications/accounting/webapp/accounting/WEB-INF/ applications/order/webapp/ordermgr/WEB-INF/ applications/product/webapp/facility/WEB-INF/ framework/base/

[Jacques Le Roux]

No problems with me, you can change if you want. Note though that, for now, 
it's not "the missing configuration file" which "will not prevent the webapp 
from loading" but only if the whole component is absent.

Jacques

Adrian Crum wrote:
> I would prefer an attribute name like "optional" - indicating the
> include is optional and the missing configuration file will not prevent
> the webapp from loading.
> 
> -Adrian
> 
> On 8/29/2013 12:37 PM, jler...@apache.org wrote:
>> Author: jleroux
>> Date: Thu Aug 29 19:37:44 2013
>> New Revision: 1518777
>> 
>> URL: http://svn.apache.org/r1518777
>> Log:
>> This fixes "Net before overhead report generates an error" 
>> https://issues.apache.org/jira/browse/OFBIZ-5267
>> 
>> This is related with r1361130, where the birt component was moved from 
>> framework to specialpurpose.
>> 
>> The fix is to create the possibility of a loose coupling from applications 
>> controllers to specialpurpose controllers. For that
>> an if-present attribute is added to the include element. When used, if the 
>> included controller does not exist, instead of an
>> error and a stack trace, a warning is thrown (only in English, for 
>> developers) suggesting to checkout the component from trunk.
>> Indeed, in the current case, this situation should only arise in release 
>> after 12.04 where the birt component, like all others
>> but the ecommerce component, had been removed. This can be used in other 
>> cases, but for now only the component level is covered.
>> 
>> Modified:
>>  
>> ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/controller.xml
>>  ofbiz/trunk/applications/order/webapp/ordermgr/WEB-INF/controller.xml
>>  ofbiz/trunk/applications/product/webapp/facility/WEB-INF/controller.xml
>>  
>> ofbiz/trunk/framework/base/src/org/ofbiz/base/location/ComponentLocationResolver.java
>>  ofbiz/trunk/framework/base/src/org/ofbiz/base/util/FileUtil.java
>>  ofbiz/trunk/framework/webapp/dtd/site-conf.xsd
>>  
>> ofbiz/trunk/framework/webapp/src/org/ofbiz/webapp/control/ConfigXMLReader.java
>>  ofbiz/trunk/specialpurpose/birt/ofbiz-component.xml
>>  ofbiz/trunk/specialpurpose/birt/webapp/accounting/WEB-INF/controller.xml
>>  ofbiz/trunk/specialpurpose/birt/webapp/facility/WEB-INF/controller.xml
>>  ofbiz/trunk/specialpurpose/birt/webapp/ordermgr/WEB-INF/controller.xml
>> 
>> Modified: 
>> ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/controller.xml
>> URL:
>> http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/controller.xml?rev=1518777&r1=1518776&r2=1518777&view=diff
>> ==
>>  ---
>> ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/controller.xml 
>> (original) +++
>> ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/controller.xml 
>> Thu Aug 29 19:37:44 2013 @@ -22,6 +22,7 @@ under
>>   the License. 
>> xsi:noNamespaceSchemaLocation="http://ofbiz.apache.org/dtds/site-conf.xsd";>
>>   > location="component://common/webcommon/WEB-INF/common-controller.xml"/>
>>   > location="component://commonext/webapp/WEB-INF/controller.xml"/>
>> +> location="component://birt/webapp/accounting/WEB-INF/controller.xml" 
>> if-present="true"/>
>>   Accounting Manager Module Site Configuration 
>> File
>> 
>>   
>> 
>> Modified: 
>> ofbiz/trunk/applications/order/webapp/ordermgr/WEB-INF/controller.xml
>> URL:
>> http://svn.apache.org/viewvc/ofbiz/trunk/applications/order/webapp/ordermgr/WEB-INF/controller.xml?rev=1518777&r1=1518776&r2=1518777&view=diff
>> ==
>>  ---
>> ofbiz/trunk/applications/order/webapp/ordermgr/WEB-INF/controller.xml 
>> (original) +++
>> ofbiz/trunk/applications/order/webapp/ordermgr/WEB-INF/controller.xml Thu 
>> Aug 29 19:37:44 2013 @@ -23,6 +23,7 @@ under the
>>   License. > location="component://common/webcommon/WEB-INF/common-controller.xml"/>
>>   > location="component://commonext/webapp/WEB-INF/controller.xml"/>
>>   > location="component://content/webapp/content/WEB-INF/controller.xml"/>
>> +> location="component://birt/webapp/ordermgr/WEB-INF/controller.xml" 
>> if-present="true"/>
>>   Order Manager Module Site Configuration File
>> 
>>   
>> 
>> Modified: 
>> ofbiz/trunk/applications/product/webapp/facility/WEB-INF/controller.xml
>> URL:
>> http://svn.apache.org/viewvc/ofbiz/trunk/applications/product/webapp/facility/WEB-INF/controller.xml?rev=1518777&r1=1518776&r2=1518777&view=diff
>> ==
>>  ---
>> ofbiz/trunk/applications/product/webapp/facility/WEB-INF/controller.xml 
>> (original) +++
>> ofbiz/trunk/applications/product/webapp/facility/WEB-INF/controller.xml Thu 
>> Aug 29 19:37:44 2013 @@ -22,6 +22,8 @@ under the
>>   License. 
>> xsi:noNamespaceSch

Re: svn commit: r1518777 - in /ofbiz/trunk: applications/accounting/webapp/accounting/WEB-INF/ applications/order/webapp/ordermgr/WEB-INF/ applications/product/webapp/facility/WEB-INF/ framework/base/

[Jacopo Cappellato]

It is annoying to see that we are still adding these references (or loose 
dependencies) from applications to specialpurpose... it is ugly.
I will try to find some time to think to a better solution.

Jacopo

On Aug 29, 2013, at 11:39 PM, Jacques Le Roux  
wrote:

> No problems with me, you can change if you want. Note though that, for now, 
> it's not "the missing configuration file" which "will not prevent the webapp 
> from loading" but only if the whole component is absent.
> 
> Jacques
> 
> Adrian Crum wrote:
>> I would prefer an attribute name like "optional" - indicating the
>> include is optional and the missing configuration file will not prevent
>> the webapp from loading.
>> 
>> -Adrian
>> 
>> On 8/29/2013 12:37 PM, jler...@apache.org wrote:
>>> Author: jleroux
>>> Date: Thu Aug 29 19:37:44 2013
>>> New Revision: 1518777
>>> 
>>> URL: http://svn.apache.org/r1518777
>>> Log:
>>> This fixes "Net before overhead report generates an error" 
>>> https://issues.apache.org/jira/browse/OFBIZ-5267
>>> 
>>> This is related with r1361130, where the birt component was moved from 
>>> framework to specialpurpose.
>>> 
>>> The fix is to create the possibility of a loose coupling from applications 
>>> controllers to specialpurpose controllers. For that
>>> an if-present attribute is added to the include element. When used, if the 
>>> included controller does not exist, instead of an
>>> error and a stack trace, a warning is thrown (only in English, for 
>>> developers) suggesting to checkout the component from trunk.
>>> Indeed, in the current case, this situation should only arise in release 
>>> after 12.04 where the birt component, like all others
>>> but the ecommerce component, had been removed. This can be used in other 
>>> cases, but for now only the component level is covered.
>>> 
>>> Modified:
>>> 
>>> ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/controller.xml
>>> ofbiz/trunk/applications/order/webapp/ordermgr/WEB-INF/controller.xml
>>> ofbiz/trunk/applications/product/webapp/facility/WEB-INF/controller.xml
>>> 
>>> ofbiz/trunk/framework/base/src/org/ofbiz/base/location/ComponentLocationResolver.java
>>> ofbiz/trunk/framework/base/src/org/ofbiz/base/util/FileUtil.java
>>> ofbiz/trunk/framework/webapp/dtd/site-conf.xsd
>>> 
>>> ofbiz/trunk/framework/webapp/src/org/ofbiz/webapp/control/ConfigXMLReader.java
>>> ofbiz/trunk/specialpurpose/birt/ofbiz-component.xml
>>> ofbiz/trunk/specialpurpose/birt/webapp/accounting/WEB-INF/controller.xml
>>> ofbiz/trunk/specialpurpose/birt/webapp/facility/WEB-INF/controller.xml
>>> ofbiz/trunk/specialpurpose/birt/webapp/ordermgr/WEB-INF/controller.xml
>>> 
>>> Modified: 
>>> ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/controller.xml
>>> URL:
>>> http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/controller.xml?rev=1518777&r1=1518776&r2=1518777&view=diff
>>> ==
>>>  ---
>>> ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/controller.xml
>>>  (original) +++
>>> ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/controller.xml
>>>  Thu Aug 29 19:37:44 2013 @@ -22,6 +22,7 @@ under
>>>  the License. 
>>> xsi:noNamespaceSchemaLocation="http://ofbiz.apache.org/dtds/site-conf.xsd";>
>>>  >> location="component://common/webcommon/WEB-INF/common-controller.xml"/>
>>>  >> location="component://commonext/webapp/WEB-INF/controller.xml"/>
>>> +>> location="component://birt/webapp/accounting/WEB-INF/controller.xml" 
>>> if-present="true"/>
>>>  Accounting Manager Module Site Configuration 
>>> File
>>> 
>>>  
>>> 
>>> Modified: 
>>> ofbiz/trunk/applications/order/webapp/ordermgr/WEB-INF/controller.xml
>>> URL:
>>> http://svn.apache.org/viewvc/ofbiz/trunk/applications/order/webapp/ordermgr/WEB-INF/controller.xml?rev=1518777&r1=1518776&r2=1518777&view=diff
>>> ==
>>>  ---
>>> ofbiz/trunk/applications/order/webapp/ordermgr/WEB-INF/controller.xml 
>>> (original) +++
>>> ofbiz/trunk/applications/order/webapp/ordermgr/WEB-INF/controller.xml Thu 
>>> Aug 29 19:37:44 2013 @@ -23,6 +23,7 @@ under the
>>>  License. >> location="component://common/webcommon/WEB-INF/common-controller.xml"/>
>>>  >> location="component://commonext/webapp/WEB-INF/controller.xml"/>
>>>  >> location="component://content/webapp/content/WEB-INF/controller.xml"/>
>>> +>> location="component://birt/webapp/ordermgr/WEB-INF/controller.xml" 
>>> if-present="true"/>
>>>  Order Manager Module Site Configuration File
>>> 
>>>  
>>> 
>>> Modified: 
>>> ofbiz/trunk/applications/product/webapp/facility/WEB-INF/controller.xml
>>> URL:
>>> http://svn.apache.org/viewvc/ofbiz/trunk/applications/product/webapp/facility/WEB-INF/controller.xml?rev=1518777&r1=1518776&r2=1518777&view=diff
>>> =

Re: svn commit: r1518777 - in /ofbiz/trunk: applications/accounting/webapp/accounting/WEB-INF/ applications/order/webapp/ordermgr/WEB-INF/ applications/product/webapp/facility/WEB-INF/ framework/base/

[Jacopo Cappellato]

Jacques,

I have spent a lot of time reviewing the whole history behind these changes and 
also all the comments in the Jira ticket OFBIZ-5267.
Now I think that you should revert this change.

Here is a summary of what happened:

1) in rev. 1361130 I have moved the "birt" component to specialpurpose; I have 
also moved all the Birt reports from the applications to the webapp I have 
defined in the specialpurpose/birt component, leveraging the ability of the 
framework to override existing applications: in this way the birt component was 
adding to the applications the birt reports; when you remove the birt component 
then the reports disappear nicely; this design is based on best practices and I 
spent a lot of time to follow it properly when I have separated the birt 
component
2) then it was reported that in the overriden webapps the contextual help links 
didn't work any more; this issue is not limited to the applications overriden 
by the specialpurpose/birt component but it is a general issue caused by a 
wrong design in the generation of help links; specifically, the issue is that in



the name of the help file is composed using the component name; this is a wrong 
approach and could be solved, for instance, by using  the webapp name instead 
of the component name;

3) instead of fixing the help link creation (e.g., as suggested above) you 
simply, in rev. 1400463, commented out the webapp declarations in 
specialpurpose/birt (WRONG), canceling a relevant part of my initial work (#1); 
with this change you have disabled all Birt reports

4) then it was reported (in OFBIZ-5267) that a Birt report was not available 
(this because of your change in #3): after a lot of confusion (see history of 
comments) you wrote it was caused by my commit at #1 and you implemented in 
r1518777 an ugly mechanism where birt webapp controllers are included in the 
applications controllers but with a new attribute (requiring framework 
modifications) to avoid errors if the birt component is missing (WRONG)

I am now asking you to revert all the work you did in #3 and #4; we will then 
focus on improving the help system, whose design is ugly, to make it work 
properly with the overriden webapp mechanism that OFBiz supports.

In the future, please pay more attention in making changes that increase 
entropy in the project.

Regards, 

Jacopo
 
On Aug 30, 2013, at 8:17 AM, Jacopo Cappellato 
 wrote:

> It is annoying to see that we are still adding these references (or loose 
> dependencies) from applications to specialpurpose... it is ugly.
> I will try to find some time to think to a better solution.
> 
> Jacopo
> 
> On Aug 29, 2013, at 11:39 PM, Jacques Le Roux  
> wrote:
> 
>> No problems with me, you can change if you want. Note though that, for now, 
>> it's not "the missing configuration file" which "will not prevent the webapp 
>> from loading" but only if the whole component is absent.
>> 
>> Jacques
>> 
>> Adrian Crum wrote:
>>> I would prefer an attribute name like "optional" - indicating the
>>> include is optional and the missing configuration file will not prevent
>>> the webapp from loading.
>>> 
>>> -Adrian
>>> 
>>> On 8/29/2013 12:37 PM, jler...@apache.org wrote:
 Author: jleroux
 Date: Thu Aug 29 19:37:44 2013
 New Revision: 1518777
 
 URL: http://svn.apache.org/r1518777
 Log:
 This fixes "Net before overhead report generates an error" 
 https://issues.apache.org/jira/browse/OFBIZ-5267
 
 This is related with r1361130, where the birt component was moved from 
 framework to specialpurpose.
 
 The fix is to create the possibility of a loose coupling from applications 
 controllers to specialpurpose controllers. For that
 an if-present attribute is added to the include element. When used, if the 
 included controller does not exist, instead of an
 error and a stack trace, a warning is thrown (only in English, for 
 developers) suggesting to checkout the component from trunk.
 Indeed, in the current case, this situation should only arise in release 
 after 12.04 where the birt component, like all others
 but the ecommerce component, had been removed. This can be used in other 
 cases, but for now only the component level is covered.
 
 Modified:

 ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/controller.xml
ofbiz/trunk/applications/order/webapp/ordermgr/WEB-INF/controller.xml
ofbiz/trunk/applications/product/webapp/facility/WEB-INF/controller.xml

 ofbiz/trunk/framework/base/src/org/ofbiz/base/location/ComponentLocationResolver.java
ofbiz/trunk/framework/base/src/org/ofbiz/base/util/FileUtil.java
ofbiz/trunk/framework/webapp/dtd/site-conf.xsd

 ofbiz/trunk/framework/webapp/src/org/ofbiz/webapp/control/ConfigXMLReader.java
ofbiz/trunk/specialpurpose/birt/ofbiz-component.xml
ofbiz/trunk/specialpurpose/birt/webapp/account

Re: svn commit: r1518777 - in /ofbiz/trunk: applications/accounting/webapp/accounting/WEB-INF/ applications/order/webapp/ordermgr/WEB-INF/ applications/product/webapp/facility/WEB-INF/ framework/base/

[Jacques Le Roux]

Jacopo,

I think you are right. I will revert and test again with the suggestion you 
made for the generation of help links

Jacques

Jacopo Cappellato wrote:
> Jacques,
> 
> I have spent a lot of time reviewing the whole history behind these changes 
> and also all the comments in the Jira ticket
> OFBIZ-5267. 
> Now I think that you should revert this change.
> 
> Here is a summary of what happened:
> 
> 1) in rev. 1361130 I have moved the "birt" component to specialpurpose; I 
> have also moved all the Birt reports from the
> applications to the webapp I have defined in the specialpurpose/birt 
> component, leveraging the ability of the framework to
> override existing applications: in this way the birt component was adding to 
> the applications the birt reports; when you remove
> the birt component then the reports disappear nicely; this design is based on 
> best practices and I spent a lot of time to follow
> it properly when I have separated the birt component 2) then it was reported 
> that in the overriden webapps the contextual help
> links didn't work any more; this issue is not limited to the applications 
> overriden by the specialpurpose/birt component but it
> is a general issue caused by a wrong design in the generation of help links; 
> specifically, the issue is that in 
> 
> 
> 
> the name of the help file is composed using the component name; this is a 
> wrong approach and could be solved, for instance, by
> using  the webapp name instead of the component name; 
> 
> 3) instead of fixing the help link creation (e.g., as suggested above) you 
> simply, in rev. 1400463, commented out the webapp
> declarations in specialpurpose/birt (WRONG), canceling a relevant part of my 
> initial work (#1); with this change you have
> disabled all Birt reports  
> 
> 4) then it was reported (in OFBIZ-5267) that a Birt report was not available 
> (this because of your change in #3): after a lot of
> confusion (see history of comments) you wrote it was caused by my commit at 
> #1 and you implemented in r1518777 an ugly mechanism
> where birt webapp controllers are included in the applications controllers 
> but with a new attribute (requiring framework
> modifications) to avoid errors if the birt component is missing (WRONG)   
> 
> I am now asking you to revert all the work you did in #3 and #4; we will then 
> focus on improving the help system, whose design is
> ugly, to make it work properly with the overriden webapp mechanism that OFBiz 
> supports. 
> 
> In the future, please pay more attention in making changes that increase 
> entropy in the project.
> 
> Regards,
> 
> Jacopo
> 
> On Aug 30, 2013, at 8:17 AM, Jacopo Cappellato 
>  wrote:
> 
>> It is annoying to see that we are still adding these references (or loose 
>> dependencies) from applications to specialpurpose...
>> it is ugly. I will try to find some time to think to a better solution.
>> 
>> Jacopo
>> 
>> On Aug 29, 2013, at 11:39 PM, Jacques Le Roux  
>> wrote:
>> 
>>> No problems with me, you can change if you want. Note though that, for now, 
>>> it's not "the missing configuration file" which
>>> "will not prevent the webapp from loading" but only if the whole component 
>>> is absent. 
>>> 
>>> Jacques
>>> 
>>> Adrian Crum wrote:
 I would prefer an attribute name like "optional" - indicating the
 include is optional and the missing configuration file will not prevent
 the webapp from loading.
 
 -Adrian
 
 On 8/29/2013 12:37 PM, jler...@apache.org wrote:
> Author: jleroux
> Date: Thu Aug 29 19:37:44 2013
> New Revision: 1518777
> 
> URL: http://svn.apache.org/r1518777
> Log:
> This fixes "Net before overhead report generates an error" 
> https://issues.apache.org/jira/browse/OFBIZ-5267
> 
> This is related with r1361130, where the birt component was moved from 
> framework to specialpurpose.
> 
> The fix is to create the possibility of a loose coupling from 
> applications controllers to specialpurpose controllers. For that
> an if-present attribute is added to the include element. When used, if 
> the included controller does not exist, instead of an
> error and a stack trace, a warning is thrown (only in English, for 
> developers) suggesting to checkout the component from
> trunk. Indeed, in the current case, this situation should only arise in 
> release after 12.04 where the birt component, like
> all others but the ecommerce component, had been removed. This can be 
> used in other cases, but for now only the component
> level is covered. 
> 
> Modified:
>
> ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/controller.xml
>ofbiz/trunk/applications/order/webapp/ordermgr/WEB-INF/controller.xml
>ofbiz/trunk/applications/product/webapp/facility/WEB-INF/controller.xml
>
> ofbiz/trunk/framework/base/src/org/ofbiz/base/location/ComponentLocationRes

Re: svn commit: r1518777 - in /ofbiz/trunk: applications/accounting/webapp/accounting/WEB-INF/ applications/order/webapp/ordermgr/WEB-INF/ applications/product/webapp/facility/WEB-INF/ framework/base/

[Jacques Le Roux]

Jacopo Cappellato wrote:
> is a general issue caused by a wrong design in the generation of help links; 
> specifically, the issue is that in 
> 
> 
> 
> the name of the help file is composed using the component name; this is a 
> wrong approach and could be solved, for instance, by
> using  the webapp name instead of the component name; 

As it is now, it should not be the webapp name but the component name or the 
overriden component name.

We could do it like this (both cases will be covered as long as the web.xml 
file of the overriding webapp is correct)

Index: applications/commonext/widget/CommonScreens.xml
===
--- applications/commonext/widget/CommonScreens.xml (revision 1522780)
+++ applications/commonext/widget/CommonScreens.xml (working copy)
@@ -45,8 +45,7 @@
 
 
 
-
-
+
 
 
 
Index: framework/widget/src/org/ofbiz/widget/screen/ScreenRenderer.java
===
--- framework/widget/src/org/ofbiz/widget/screen/ScreenRenderer.java (revision 
1522780)
+++ framework/widget/src/org/ofbiz/widget/screen/ScreenRenderer.java (working 
copy)
@@ -220,6 +220,8 @@
 if (servletContext != null) {
 String rootDir = (String) context.get("rootDir");
 String webSiteId = (String) context.get("webSiteId");
+String localDispatcherName = (String) 
servletContext.getAttribute("localDispatcherName");
+context.put("applicationName", localDispatcherName);
 String https = (String) context.get("https");
 if (UtilValidate.isEmpty(rootDir)) {
 rootDir = servletContext.getRealPath("/");

Thanks for your help Jacopo, I really went on a wrong track, my apologies


Jacques

Re: svn commit: r1518777 - in /ofbiz/trunk: applications/accounting/webapp/accounting/WEB-INF/ applications/order/webapp/ordermgr/WEB-INF/ applications/product/webapp/facility/WEB-INF/ framework/base/

[Jacopo Cappellato]

Hi Jacques,

thanks, what you propose is an interesting approach, but it would be better to 
use the webapp name or its mount point; however I am not sure there is an easy 
way to do this from that decorator... I will too try to think to a solution for 
this.

Regards,

Jacopo

On Sep 13, 2013, at 12:02 PM, Jacques Le Roux  
wrote:

> Jacopo Cappellato wrote:
>> is a general issue caused by a wrong design in the generation of help links; 
>> specifically, the issue is that in 
>> 
>> 
>> 
>> the name of the help file is composed using the component name; this is a 
>> wrong approach and could be solved, for instance, by
>> using  the webapp name instead of the component name; 
> 
> As it is now, it should not be the webapp name but the component name or the 
> overriden component name.
> 
> We could do it like this (both cases will be covered as long as the web.xml 
> file of the overriding webapp is correct)
> 
> Index: applications/commonext/widget/CommonScreens.xml
> ===
> --- applications/commonext/widget/CommonScreens.xml (revision 1522780)
> +++ applications/commonext/widget/CommonScreens.xml (working copy)
> @@ -45,8 +45,7 @@
>  value="${lastSystemInfoNote2.moreInfoUrl}${groovy: if 
> (lastSystemInfoNote2&&lastSystemInfoNote2.moreInfoItemName&&lastSystemInfoNote2.moreInfoItemId)"?"
>  + lastSystemInfoNote2.moreInfoItemName + "=" + 
> lastSystemInfoNote2.moreInfoItemId + "&id=" + 
> lastSystemInfoNote2.moreInfoItemId;}"/>
>  value="${lastSystemInfoNote3.moreInfoUrl}${groovy: if 
> (lastSystemInfoNote3&&lastSystemInfoNote3.moreInfoItemName&&lastSystemInfoNote3.moreInfoItemId)"?"
>  + lastSystemInfoNote3.moreInfoItemName + "=" + 
> lastSystemInfoNote3.moreInfoItemId + "&id=" + 
> lastSystemInfoNote3.moreInfoItemId;}"/>
> 
> -
> -
> +
> 
> 
> 
> Index: framework/widget/src/org/ofbiz/widget/screen/ScreenRenderer.java
> ===
> --- framework/widget/src/org/ofbiz/widget/screen/ScreenRenderer.java 
> (revision 1522780)
> +++ framework/widget/src/org/ofbiz/widget/screen/ScreenRenderer.java (working 
> copy)
> @@ -220,6 +220,8 @@
> if (servletContext != null) {
> String rootDir = (String) context.get("rootDir");
> String webSiteId = (String) context.get("webSiteId");
> +String localDispatcherName = (String) 
> servletContext.getAttribute("localDispatcherName");
> +context.put("applicationName", localDispatcherName);
> String https = (String) context.get("https");
> if (UtilValidate.isEmpty(rootDir)) {
> rootDir = servletContext.getRealPath("/");
> 
> Thanks for your help Jacopo, I really went on a wrong track, my apologies
> 
> 
> Jacques

Re: svn commit: r1518777 - in /ofbiz/trunk: applications/accounting/webapp/accounting/WEB-INF/ applications/order/webapp/ordermgr/WEB-INF/ applications/product/webapp/facility/WEB-INF/ framework/base/

[Pierre Smits]

Hi Jacques,

Why not use the  '_WEBAPP_NAME'  variable. That is already available in the
parameter list. You could even avoid transforming it to upper case. A one
time conversion of the data to the appropriate case would then align the
data.

Regards,

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com


On Fri, Sep 13, 2013 at 12:02 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Jacopo Cappellato wrote:
> > is a general issue caused by a wrong design in the generation of help
> links; specifically, the issue is that in
> >
> > 
> >
> > the name of the help file is composed using the component name; this is
> a wrong approach and could be solved, for instance, by
> > using  the webapp name instead of the component name;
>
> As it is now, it should not be the webapp name but the component name or
> the overriden component name.
>
> We could do it like this (both cases will be covered as long as the
> web.xml file of the overriding webapp is correct)
>
> Index: applications/commonext/widget/CommonScreens.xml
> ===
> --- applications/commonext/widget/CommonScreens.xml (revision 1522780)
> +++ applications/commonext/widget/CommonScreens.xml (working copy)
> @@ -45,8 +45,7 @@
>   value="${lastSystemInfoNote2.moreInfoUrl}${groovy: if
> (lastSystemInfoNote2&&lastSystemInfoNote2.moreInfoItemName&&lastSystemInfoNote2.moreInfoItemId)"?"
> + lastSystemInfoNote2.moreInfoItemName + "=" +
> lastSystemInfoNote2.moreInfoItemId + "&id=" +
> lastSystemInfoNote2.moreInfoItemId;}"/>
>   value="${lastSystemInfoNote3.moreInfoUrl}${groovy: if
> (lastSystemInfoNote3&&lastSystemInfoNote3.moreInfoItemName&&lastSystemInfoNote3.moreInfoItemId)"?"
> + lastSystemInfoNote3.moreInfoItemName + "=" +
> lastSystemInfoNote3.moreInfoItemId + "&id=" +
> lastSystemInfoNote3.moreInfoItemId;}"/>
>  
> -
> -
> +
>  
>   from-field="helpTopic"/>
>  
> Index: framework/widget/src/org/ofbiz/widget/screen/ScreenRenderer.java
> ===
> --- framework/widget/src/org/ofbiz/widget/screen/ScreenRenderer.java
> (revision 1522780)
> +++ framework/widget/src/org/ofbiz/widget/screen/ScreenRenderer.java
> (working copy)
> @@ -220,6 +220,8 @@
>  if (servletContext != null) {
>  String rootDir = (String) context.get("rootDir");
>  String webSiteId = (String) context.get("webSiteId");
> +String localDispatcherName = (String)
> servletContext.getAttribute("localDispatcherName");
> +context.put("applicationName", localDispatcherName);
>  String https = (String) context.get("https");
>  if (UtilValidate.isEmpty(rootDir)) {
>  rootDir = servletContext.getRealPath("/");
>
> Thanks for your help Jacopo, I really went on a wrong track, my apologies
>
>
> Jacques
>

Re: svn commit: r1518777 - in /ofbiz/trunk: applications/accounting/webapp/accounting/WEB-INF/ applications/order/webapp/ordermgr/WEB-INF/ applications/product/webapp/facility/WEB-INF/ framework/base/

[Jacques Le Roux]

Hi Pierre,

The same reason that made me pick the (possibly overriden) component name. 
Jacopo also suggested the webapp name (we miss a part of the thread here, refer 
to it if needed)
But that's not how the HELP is coded at the moment. It uses the component name.

Also to use _WEBAPP_NAME_ (note the _ at end), since it's not in parameters but 
is a session attribute, we would also need to put it in context in 
ScreenRenderer.java using something like
context.put("webappName", session.getAttribute("_WEBAPP_NAME_")
or
context.put("webappName", UtilHttp.getApplicationName(request))
I don't see a plus compared to my solution. 

The only drawback of my solution is that the localDispatcherName *MUST* be 
named after the component name. 
But it's the case for all webapps so far. And I don't see a need to change this 
(very useful) convention.

Disclaimer: I did not look yet at how the helpTopic var is used to render the 
help, just followed the trend. Maybe using the webapp is possible...

Jacques

Pierre Smits wrote:
> Hi Jacques,
> 
> Why not use the  '_WEBAPP_NAME'  variable. That is already available in the
> parameter list. You could even avoid transforming it to upper case. A one
> time conversion of the data to the appropriate case would then align the
> data.
> 
> Regards,
> 
> Pierre Smits
> 
> *ORRTIZ.COM *
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
> 
> 
> On Fri, Sep 13, 2013 at 12:02 PM, Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
> 
>> Jacopo Cappellato wrote:
>>> is a general issue caused by a wrong design in the generation of help
>> links; specifically, the issue is that in
>>> 
>>> 
>>> 
>>> the name of the help file is composed using the component name; this is
>> a wrong approach and could be solved, for instance, by
>>> using  the webapp name instead of the component name;
>> 
>> As it is now, it should not be the webapp name but the component name or
>> the overriden component name.
>> 
>> We could do it like this (both cases will be covered as long as the
>> web.xml file of the overriding webapp is correct)
>> 
>> Index: applications/commonext/widget/CommonScreens.xml
>> ===
>> --- applications/commonext/widget/CommonScreens.xml (revision 1522780)
>> +++ applications/commonext/widget/CommonScreens.xml (working copy)
>> @@ -45,8 +45,7 @@
>>  > value="${lastSystemInfoNote2.moreInfoUrl}${groovy: if
>> (lastSystemInfoNote2&&lastSystemInfoNote2.moreInfoItemName&&lastSystemInfoNote2.moreInfoItemId)"?"
>> + lastSystemInfoNote2.moreInfoItemName + "=" +
>> lastSystemInfoNote2.moreInfoItemId + "&id=" +
>> lastSystemInfoNote2.moreInfoItemId;}"/>
>>  > value="${lastSystemInfoNote3.moreInfoUrl}${groovy: if
>> (lastSystemInfoNote3&&lastSystemInfoNote3.moreInfoItemName&&lastSystemInfoNote3.moreInfoItemId)"?"
>> + lastSystemInfoNote3.moreInfoItemName + "=" +
>> lastSystemInfoNote3.moreInfoItemId + "&id=" +
>> lastSystemInfoNote3.moreInfoItemId;}"/>
>>  
>> -
>> -
>> +
>>  
>>  > from-field="helpTopic"/>
>>  
>> Index: framework/widget/src/org/ofbiz/widget/screen/ScreenRenderer.java
>> ===
>> --- framework/widget/src/org/ofbiz/widget/screen/ScreenRenderer.java
>> (revision 1522780)
>> +++ framework/widget/src/org/ofbiz/widget/screen/ScreenRenderer.java
>> (working copy)
>> @@ -220,6 +220,8 @@
>>  if (servletContext != null) {
>>  String rootDir = (String) context.get("rootDir");
>>  String webSiteId = (String) context.get("webSiteId");
>> +String localDispatcherName = (String)
>> servletContext.getAttribute("localDispatcherName");
>> +context.put("applicationName", localDispatcherName);
>>  String https = (String) context.get("https");
>>  if (UtilValidate.isEmpty(rootDir)) {
>>  rootDir = servletContext.getRealPath("/");
>> 
>> Thanks for your help Jacopo, I really went on a wrong track, my apologies
>> 
>> 
>> Jacques

Re: svn commit: r1518777 - in /ofbiz/trunk: applications/accounting/webapp/accounting/WEB-INF/ applications/order/webapp/ordermgr/WEB-INF/ applications/product/webapp/facility/WEB-INF/ framework/base/

[Pierre @GMail]

Thanks for the clarification, Jacques. Co

Sent from my iPhone

On 13 sep. 2013, at 23:49, Jacques Le Roux  wrote:

> Hi Pierre,
> 
> The same reason that made me pick the (possibly overriden) component name. 
> Jacopo also suggested the webapp name (we miss a part of the thread here, 
> refer to it if needed)
> But that's not how the HELP is coded at the moment. It uses the component 
> name.
> 
> Also to use _WEBAPP_NAME_ (note the _ at end), since it's not in parameters 
> but is a session attribute, we would also need to put it in context in 
> ScreenRenderer.java using something like
> context.put("webappName", session.getAttribute("_WEBAPP_NAME_")
> or
> context.put("webappName", UtilHttp.getApplicationName(request))
> I don't see a plus compared to my solution. 
> 
> The only drawback of my solution is that the localDispatcherName *MUST* be 
> named after the component name. 
> But it's the case for all webapps so far. And I don't see a need to change 
> this (very useful) convention.
> 
> Disclaimer: I did not look yet at how the helpTopic var is used to render the 
> help, just followed the trend. Maybe using the webapp is possible...
> 
> Jacques
> 
> Pierre Smits wrote:
>> Hi Jacques,
>> 
>> Why not use the  '_WEBAPP_NAME'  variable. That is already available in the
>> parameter list. You could even avoid transforming it to upper case. A one
>> time conversion of the data to the appropriate case would then align the
>> data.
>> 
>> Regards,
>> 
>> Pierre Smits
>> 
>> *ORRTIZ.COM *
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>> 
>> 
>> On Fri, Sep 13, 2013 at 12:02 PM, Jacques Le Roux <
>> jacques.le.r...@les7arts.com> wrote:
>> 
>>> Jacopo Cappellato wrote:
 is a general issue caused by a wrong design in the generation of help
>>> links; specifically, the issue is that in
 
 
 
 the name of the help file is composed using the component name; this is
>>> a wrong approach and could be solved, for instance, by
 using  the webapp name instead of the component name;
>>> 
>>> As it is now, it should not be the webapp name but the component name or
>>> the overriden component name.
>>> 
>>> We could do it like this (both cases will be covered as long as the
>>> web.xml file of the overriding webapp is correct)
>>> 
>>> Index: applications/commonext/widget/CommonScreens.xml
>>> ===
>>> --- applications/commonext/widget/CommonScreens.xml (revision 1522780)
>>> +++ applications/commonext/widget/CommonScreens.xml (working copy)
>>> @@ -45,8 +45,7 @@
>>> >> value="${lastSystemInfoNote2.moreInfoUrl}${groovy: if
>>> (lastSystemInfoNote2&&lastSystemInfoNote2.moreInfoItemName&&lastSystemInfoNote2.moreInfoItemId)"?"
>>> + lastSystemInfoNote2.moreInfoItemName + "=" +
>>> lastSystemInfoNote2.moreInfoItemId + "&id=" +
>>> lastSystemInfoNote2.moreInfoItemId;}"/>
>>> >> value="${lastSystemInfoNote3.moreInfoUrl}${groovy: if
>>> (lastSystemInfoNote3&&lastSystemInfoNote3.moreInfoItemName&&lastSystemInfoNote3.moreInfoItemId)"?"
>>> + lastSystemInfoNote3.moreInfoItemName + "=" +
>>> lastSystemInfoNote3.moreInfoItemId + "&id=" +
>>> lastSystemInfoNote3.moreInfoItemId;}"/>
>>> 
>>> -
>>> -
>>> +
>>> 
>>> >> from-field="helpTopic"/>
>>> 
>>> Index: framework/widget/src/org/ofbiz/widget/screen/ScreenRenderer.java
>>> ===
>>> --- framework/widget/src/org/ofbiz/widget/screen/ScreenRenderer.java
>>> (revision 1522780)
>>> +++ framework/widget/src/org/ofbiz/widget/screen/ScreenRenderer.java
>>> (working copy)
>>> @@ -220,6 +220,8 @@
>>> if (servletContext != null) {
>>> String rootDir = (String) context.get("rootDir");
>>> String webSiteId = (String) context.get("webSiteId");
>>> +String localDispatcherName = (String)
>>> servletContext.getAttribute("localDispatcherName");
>>> +context.put("applicationName", localDispatcherName);
>>> String https = (String) context.get("https");
>>> if (UtilValidate.isEmpty(rootDir)) {
>>> rootDir = servletContext.getRealPath("/");
>>> 
>>> Thanks for your help Jacopo, I really went on a wrong track, my apologies
>>> 
>>> 
>>> Jacques

Re: svn commit: r1518777 - in /ofbiz/trunk: applications/accounting/webapp/accounting/WEB-INF/ applications/order/webapp/ordermgr/WEB-INF/ applications/product/webapp/facility/WEB-INF/ framework/base/

[Jacques Le Roux]

Mmm, let's clarify further, it's about conventions here.

Because the names used to retrieve the help files are in contents records of 
*HelpData.xml files, see notably the mapKey attributes which relate requests to 
HELP_*.xml filenames.
So you can use there either the component name or the webapps names since the 
mapping done with contents records is open. It's what is currently done, which 
leads to confusion.

I agree, using the webapp names makes more sense. So we should follow this 
convention and change the mappings in *HelpData.xml files and the HELP_*.xml 
filenames when needed.

If I did not miss anything, putting
context.put("webappName", context.put("webappName", 
session.getAttribute("_WEBAPP_NAME_")));in ScreenRenderer.java 
and using

in CommonScreens.xml, will be enough on Framework side.

I will open a Jira... 

Jacques
PS: note for myself: add webbappName in wiki page on parameters

Pierre @GMail wrote:
> Thanks for the clarification, Jacques. Co
> 
> Sent from my iPhone
> 
> On 13 sep. 2013, at 23:49, Jacques Le Roux  
> wrote:
> 
>> Hi Pierre,
>> 
>> The same reason that made me pick the (possibly overriden) component name. 
>> Jacopo also suggested the webapp name (we miss a part
>> of the thread here, refer to it if needed) 
>> But that's not how the HELP is coded at the moment. It uses the component 
>> name.
>> 
>> Also to use _WEBAPP_NAME_ (note the _ at end), since it's not in parameters 
>> but is a session attribute, we would also need to
>> put it in context in ScreenRenderer.java using something like 
>> context.put("webappName", session.getAttribute("_WEBAPP_NAME_")
>> or
>> context.put("webappName", UtilHttp.getApplicationName(request))
>> I don't see a plus compared to my solution.
>> 
>> The only drawback of my solution is that the localDispatcherName *MUST* be 
>> named after the component name.
>> But it's the case for all webapps so far. And I don't see a need to change 
>> this (very useful) convention.
>> 
>> Disclaimer: I did not look yet at how the helpTopic var is used to render 
>> the help, just followed the trend. Maybe using the
>> webapp is possible... 
>> 
>> Jacques
>> 
>> Pierre Smits wrote:
>>> Hi Jacques,
>>> 
>>> Why not use the  '_WEBAPP_NAME'  variable. That is already available in the
>>> parameter list. You could even avoid transforming it to upper case. A one
>>> time conversion of the data to the appropriate case would then align the
>>> data.
>>> 
>>> Regards,
>>> 
>>> Pierre Smits
>>> 
>>> *ORRTIZ.COM *
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>> 
>>> 
>>> On Fri, Sep 13, 2013 at 12:02 PM, Jacques Le Roux <
>>> jacques.le.r...@les7arts.com> wrote:
>>> 
 Jacopo Cappellato wrote:
> is a general issue caused by a wrong design in the generation of help
 links; specifically, the issue is that in
> 
> 
> 
> the name of the help file is composed using the component name; this is
 a wrong approach and could be solved, for instance, by
> using  the webapp name instead of the component name;
 
 As it is now, it should not be the webapp name but the component name or
 the overriden component name.
 
 We could do it like this (both cases will be covered as long as the
 web.xml file of the overriding webapp is correct)
 
 Index: applications/commonext/widget/CommonScreens.xml
 ===
 --- applications/commonext/widget/CommonScreens.xml (revision 1522780)
 +++ applications/commonext/widget/CommonScreens.xml (working copy)
 @@ -45,8 +45,7 @@
 >>> value="${lastSystemInfoNote2.moreInfoUrl}${groovy: if
 (lastSystemInfoNote2&&lastSystemInfoNote2.moreInfoItemName&&lastSystemInfoNote2.moreInfoItemId)"?"
 + lastSystemInfoNote2.moreInfoItemName + "=" +
 lastSystemInfoNote2.moreInfoItemId + "&id=" +
 lastSystemInfoNote2.moreInfoItemId;}"/>
 >>> value="${lastSystemInfoNote3.moreInfoUrl}${groovy: if
 (lastSystemInfoNote3&&lastSystemInfoNote3.moreInfoItemName&&lastSystemInfoNote3.moreInfoItemId)"?"
 + lastSystemInfoNote3.moreInfoItemName + "=" +
 lastSystemInfoNote3.moreInfoItemId + "&id=" +
 lastSystemInfoNote3.moreInfoItemId;}"/>
 
 -
 -
 +
 
 >>> from-field="helpTopic"/>
 
 Index: framework/widget/src/org/ofbiz/widget/screen/ScreenRenderer.java
 ===
 --- framework/widget/src/org/ofbiz/widget/screen/ScreenRenderer.java
 (revision 1522780)
 +++ framework/widget/src/org/ofbiz/widget/screen/ScreenRenderer.java
 (working copy)
 @@ -220,6 +220,8 @@
 if (servletContext != null) {
 String roo

Re: svn commit: r1518777 - in /ofbiz/trunk: applications/accounting/webapp/accounting/WEB-INF/ applications/order/webapp/ordermgr/WEB-INF/ applications/product/webapp/facility/WEB-INF/ framework/base/

[Pierre Smits]

Jacques,

Could it also be so that current way of retrieving the appropriate help
file (in accordance with the language of the user) is flawed somewhere?
Specifically when there is a file for locale="en" and the user has "en_US"?

With kind regards,

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com


On Sat, Sep 14, 2013 at 1:40 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Mmm, let's clarify further, it's about conventions here.
>
> Because the names used to retrieve the help files are in contents records
> of *HelpData.xml files, see notably the mapKey attributes which relate
> requests to HELP_*.xml filenames.
> So you can use there either the component name or the webapps names since
> the mapping done with contents records is open. It's what is currently
> done, which leads to confusion.
>
> I agree, using the webapp names makes more sense. So we should follow this
> convention and change the mappings in *HelpData.xml files and the
> HELP_*.xml filenames when needed.
>
> If I did not miss anything, putting
> context.put("webappName", context.put("webappName",
> session.getAttribute("_WEBAPP_NAME_")));in ScreenRenderer.java
> and using
> 
> in CommonScreens.xml, will be enough on Framework side.
>
> I will open a Jira...
>
> Jacques
> PS: note for myself: add webbappName in wiki page on parameters
>
> Pierre @GMail wrote:
> > Thanks for the clarification, Jacques. Co
> >
> > Sent from my iPhone
> >
> > On 13 sep. 2013, at 23:49, Jacques Le Roux 
> wrote:
> >
> >> Hi Pierre,
> >>
> >> The same reason that made me pick the (possibly overriden) component
> name. Jacopo also suggested the webapp name (we miss a part
> >> of the thread here, refer to it if needed)
> >> But that's not how the HELP is coded at the moment. It uses the
> component name.
> >>
> >> Also to use _WEBAPP_NAME_ (note the _ at end), since it's not in
> parameters but is a session attribute, we would also need to
> >> put it in context in ScreenRenderer.java using something like
> context.put("webappName", session.getAttribute("_WEBAPP_NAME_")
> >> or
> >> context.put("webappName", UtilHttp.getApplicationName(request))
> >> I don't see a plus compared to my solution.
> >>
> >> The only drawback of my solution is that the localDispatcherName *MUST*
> be named after the component name.
> >> But it's the case for all webapps so far. And I don't see a need to
> change this (very useful) convention.
> >>
> >> Disclaimer: I did not look yet at how the helpTopic var is used to
> render the help, just followed the trend. Maybe using the
> >> webapp is possible...
> >>
> >> Jacques
> >>
> >> Pierre Smits wrote:
> >>> Hi Jacques,
> >>>
> >>> Why not use the  '_WEBAPP_NAME'  variable. That is already available
> in the
> >>> parameter list. You could even avoid transforming it to upper case. A
> one
> >>> time conversion of the data to the appropriate case would then align
> the
> >>> data.
> >>>
> >>> Regards,
> >>>
> >>> Pierre Smits
> >>>
> >>> *ORRTIZ.COM *
> >>> Services & Solutions for Cloud-
> >>> Based Manufacturing, Professional
> >>> Services and Retail & Trade
> >>> http://www.orrtiz.com
> >>>
> >>>
> >>> On Fri, Sep 13, 2013 at 12:02 PM, Jacques Le Roux <
> >>> jacques.le.r...@les7arts.com> wrote:
> >>>
>  Jacopo Cappellato wrote:
> > is a general issue caused by a wrong design in the generation of help
>  links; specifically, the issue is that in
> >
> > 
> >
> > the name of the help file is composed using the component name; this
> is
>  a wrong approach and could be solved, for instance, by
> > using  the webapp name instead of the component name;
> 
>  As it is now, it should not be the webapp name but the component name
> or
>  the overriden component name.
> 
>  We could do it like this (both cases will be covered as long as the
>  web.xml file of the overriding webapp is correct)
> 
>  Index: applications/commonext/widget/CommonScreens.xml
>  ===
>  --- applications/commonext/widget/CommonScreens.xml (revision 1522780)
>  +++ applications/commonext/widget/CommonScreens.xml (working copy)
>  @@ -45,8 +45,7 @@
>    value="${lastSystemInfoNote2.moreInfoUrl}${groovy: if
> 
> (lastSystemInfoNote2&&lastSystemInfoNote2.moreInfoItemName&&lastSystemInfoNote2.moreInfoItemId)"?"
>  + lastSystemInfoNote2.moreInfoItemName + "=" +
>  lastSystemInfoNote2.moreInfoItemId + "&id=" +
>  lastSystemInfoNote2.moreInfoItemId;}"/>
>    value="${lastSystemInfoNote3.moreInfoUrl}${groovy: if
> 
> (lastSystemInfoNote3&&lastSystemInfoNote3.moreInfoItemName&&lastSystemInfoNote3.moreInfoItemId)"?"
>  + lastSystemInfoNote3.moreInfoItemName + "=" +
>  lastSystemInfoNote3.moreInfoItemId 

Re: svn commit: r1518777 - in /ofbiz/trunk: applications/accounting/webapp/accounting/WEB-INF/ applications/order/webapp/ordermgr/WEB-INF/ applications/product/webapp/facility/WEB-INF/ framework/base/

[Jacques Le Roux]

Pierre,

I don't know, did you try already?

Jacques

Pierre Smits wrote:
> Jacques,
> 
> Could it also be so that current way of retrieving the appropriate help
> file (in accordance with the language of the user) is flawed somewhere?
> Specifically when there is a file for locale="en" and the user has "en_US"?
> 
> With kind regards,
> 
> Pierre Smits
> 
> *ORRTIZ.COM *
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
> 
> 
> On Sat, Sep 14, 2013 at 1:40 PM, Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
> 
>> Mmm, let's clarify further, it's about conventions here.
>> 
>> Because the names used to retrieve the help files are in contents records
>> of *HelpData.xml files, see notably the mapKey attributes which relate
>> requests to HELP_*.xml filenames.
>> So you can use there either the component name or the webapps names since
>> the mapping done with contents records is open. It's what is currently
>> done, which leads to confusion.
>> 
>> I agree, using the webapp names makes more sense. So we should follow this
>> convention and change the mappings in *HelpData.xml files and the
>> HELP_*.xml filenames when needed.
>> 
>> If I did not miss anything, putting
>> context.put("webappName", context.put("webappName",
>> session.getAttribute("_WEBAPP_NAME_")));in ScreenRenderer.java
>> and using
>> 
>> in CommonScreens.xml, will be enough on Framework side.
>> 
>> I will open a Jira...
>> 
>> Jacques
>> PS: note for myself: add webbappName in wiki page on parameters
>> 
>> Pierre @GMail wrote:
>>> Thanks for the clarification, Jacques. Co
>>> 
>>> Sent from my iPhone
>>> 
>>> On 13 sep. 2013, at 23:49, Jacques Le Roux  
>>> wrote:
>>> 
 Hi Pierre,
 
 The same reason that made me pick the (possibly overriden) component
>> name. Jacopo also suggested the webapp name (we miss a part
 of the thread here, refer to it if needed)
 But that's not how the HELP is coded at the moment. It uses the component 
 name.
 
 Also to use _WEBAPP_NAME_ (note the _ at end), since it's not in
>> parameters but is a session attribute, we would also need to
 put it in context in ScreenRenderer.java using something like
>> context.put("webappName", session.getAttribute("_WEBAPP_NAME_")
 or
 context.put("webappName", UtilHttp.getApplicationName(request))
 I don't see a plus compared to my solution.
 
 The only drawback of my solution is that the localDispatcherName *MUST*
>> be named after the component name.
 But it's the case for all webapps so far. And I don't see a need to
>> change this (very useful) convention.
 
 Disclaimer: I did not look yet at how the helpTopic var is used to
>> render the help, just followed the trend. Maybe using the
 webapp is possible...
 
 Jacques
 
 Pierre Smits wrote:
> Hi Jacques,
> 
> Why not use the  '_WEBAPP_NAME'  variable. That is already available in 
> the
> parameter list. You could even avoid transforming it to upper case. A one
> time conversion of the data to the appropriate case would then align the
> data.
> 
> Regards,
> 
> Pierre Smits
> 
> *ORRTIZ.COM *
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
> 
> 
> On Fri, Sep 13, 2013 at 12:02 PM, Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
> 
>> Jacopo Cappellato wrote:
>>> is a general issue caused by a wrong design in the generation of help
>> links; specifically, the issue is that in
>>> 
>>> 
>>> 
>>> the name of the help file is composed using the component name; this is 
>>> a wrong approach and could be solved, for instance,
>>> by using  the webapp name instead of the component name;
>> 
>> As it is now, it should not be the webapp name but the component name or
>> the overriden component name.
>> 
>> We could do it like this (both cases will be covered as long as the
>> web.xml file of the overriding webapp is correct)
>> 
>> Index: applications/commonext/widget/CommonScreens.xml
>> ===
>> --- applications/commonext/widget/CommonScreens.xml (revision 1522780)
>> +++ applications/commonext/widget/CommonScreens.xml (working copy)
>> @@ -45,8 +45,7 @@
>> > value="${lastSystemInfoNote2.moreInfoUrl}${groovy: if
>> 
>> (lastSystemInfoNote2&&lastSystemInfoNote2.moreInfoItemName&&lastSystemInfoNote2.moreInfoItemId)"?"
>> + lastSystemInfoNote2.moreInfoItemName + "=" +
>> lastSystemInfoNote2.moreInfoItemId + "&id=" +
>> lastSystemInfoNote2.moreInfoItemId;}"/>
>> > value="${lastSystemInfoNote3.moreInfoUrl}${groovy: if
>> 
>> (lastSystemI

Re: svn commit: r1518777 - in /ofbiz/trunk: applications/accounting/webapp/accounting/WEB-INF/ applications/order/webapp/ordermgr/WEB-INF/ applications/product/webapp/facility/WEB-INF/ framework/base/

[Jacques Le Roux]

Done at https://issues.apache.org/jira/browse/OFBIZ-5320

It's better now, but there are still issues to fix, and I guess, more to 
discover 

While reviewing related things I stumbled upon the discussion at 
https://issues.apache.org/jira/browse/OFBIZ-2133
I will re-read it, there seems to have some good ideas

It's a pity we don't use the online help more. It's really a great way to keep 
the documentation in sync with changes if we carefully update it.
Once you get it, it's not that hard to maintain, not more than a wiki page (and 
we got bitten many times by wikis)

Jacques

Jacques Le Roux wrote:
> Mmm, let's clarify further, it's about conventions here.
> 
> Because the names used to retrieve the help files are in contents records of 
> *HelpData.xml files, see notably the mapKey
> attributes which relate requests to HELP_*.xml filenames. So you can use 
> there either the component name or the webapps names
> since the mapping done with contents records is open. It's what is currently 
> done, which leads to confusion. 
> 
> I agree, using the webapp names makes more sense. So we should follow this 
> convention and change the mappings in *HelpData.xml
> files and the HELP_*.xml filenames when needed. 
> 
> If I did not miss anything, putting
> context.put("webappName", context.put("webappName", 
> session.getAttribute("_WEBAPP_NAME_")));in ScreenRenderer.java
> and using
> 
> in CommonScreens.xml, will be enough on Framework side.
> 
> I will open a Jira...
> 
> Jacques
> PS: note for myself: add webbappName in wiki page on parameters
> 
> Pierre @GMail wrote:
>> Thanks for the clarification, Jacques. Co
>> 
>> Sent from my iPhone
>> 
>> On 13 sep. 2013, at 23:49, Jacques Le Roux  
>> wrote:
>> 
>>> Hi Pierre,
>>> 
>>> The same reason that made me pick the (possibly overriden) component name. 
>>> Jacopo also suggested the webapp name (we miss a part
>>> of the thread here, refer to it if needed)
>>> But that's not how the HELP is coded at the moment. It uses the component 
>>> name.
>>> 
>>> Also to use _WEBAPP_NAME_ (note the _ at end), since it's not in parameters 
>>> but is a session attribute, we would also need to
>>> put it in context in ScreenRenderer.java using something like 
>>> context.put("webappName", session.getAttribute("_WEBAPP_NAME_")
>>> or
>>> context.put("webappName", UtilHttp.getApplicationName(request))
>>> I don't see a plus compared to my solution.
>>> 
>>> The only drawback of my solution is that the localDispatcherName *MUST* be 
>>> named after the component name.
>>> But it's the case for all webapps so far. And I don't see a need to change 
>>> this (very useful) convention.
>>> 
>>> Disclaimer: I did not look yet at how the helpTopic var is used to render 
>>> the help, just followed the trend. Maybe using the
>>> webapp is possible...
>>> 
>>> Jacques
>>> 
>>> Pierre Smits wrote:
 Hi Jacques,
 
 Why not use the  '_WEBAPP_NAME'  variable. That is already available in the
 parameter list. You could even avoid transforming it to upper case. A one
 time conversion of the data to the appropriate case would then align the
 data.
 
 Regards,
 
 Pierre Smits
 
 *ORRTIZ.COM *
 Services & Solutions for Cloud-
 Based Manufacturing, Professional
 Services and Retail & Trade
 http://www.orrtiz.com
 
 
 On Fri, Sep 13, 2013 at 12:02 PM, Jacques Le Roux <
 jacques.le.r...@les7arts.com> wrote:
 
> Jacopo Cappellato wrote:
>> is a general issue caused by a wrong design in the generation of help
> links; specifically, the issue is that in
>> 
>> 
>> 
>> the name of the help file is composed using the component name; this is
> a wrong approach and could be solved, for instance, by
>> using  the webapp name instead of the component name;
> 
> As it is now, it should not be the webapp name but the component name or
> the overriden component name.
> 
> We could do it like this (both cases will be covered as long as the
> web.xml file of the overriding webapp is correct)
> 
> Index: applications/commonext/widget/CommonScreens.xml
> ===
> --- applications/commonext/widget/CommonScreens.xml (revision 1522780)
> +++ applications/commonext/widget/CommonScreens.xml (working copy)
> @@ -45,8 +45,7 @@
>  value="${lastSystemInfoNote2.moreInfoUrl}${groovy: if
> (lastSystemInfoNote2&&lastSystemInfoNote2.moreInfoItemName&&lastSystemInfoNote2.moreInfoItemId)"?"
> + lastSystemInfoNote2.moreInfoItemName + "=" +
> lastSystemInfoNote2.moreInfoItemId + "&id=" +
> lastSystemInfoNote2.moreInfoItemId;}"/>
>  value="${lastSystemInfoNote3.moreInfoUrl}${groovy: if
> (lastSystemInfoNote3&&lastSystemInfoNote3.moreInfoItemName&&lastSystemInfoNote3.moreInfoItemId)"?"
> + lastSystemInfoNote3.mor