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
Thanks for the clarification, Jacques. Co
Sent from my iPhone
On 13 sep. 2013, at 23:49, Jacques Le Roux jacques.le.r...@les7arts.com 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
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
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 http://www.orrtiz.com*
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
Jacopo Cappellato wrote:
is a general issue caused by a wrong design in the generation of help links;
specifically, the issue is that in
set field=helpTopic value=${groovy:
parameters.componentName.toUpperCase() + '_' +
requestAttributes._CURRENT_VIEW_}/
the name of the help file
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
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
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
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
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
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 jacques.le.r...@les7arts.com
wrote:
No
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:
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
14 matches
Mail list logo
