Re: specialpurpose in R13.07 demo
Is it a good thing to not regard the ofbiz user as a customer? Regards, Pierre Sent from my iPhone On 23 okt. 2014, at 17:33, Jacques Le Roux jacques.le.r...@les7arts.com wrote: Le 23/10/2014 17:11, Ron Wheeler a écrit : On 23/10/2014 10:39 AM, Jacques Le Roux wrote: Le 23/10/2014 15:01, Jacopo Cappellato a écrit : On Oct 23, 2014, at 2:07 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: I agree about the idea, but this applies only to releases or checked out code. Because there are no ways for users to enable/disable a component in demos, moreover demos are shared. Could you please explain the above sentence? I don't understand the meaning of it. Your idea of disabling some specialpurpose component can't be applied in R13.07 demo until we decide which component should be disabled in trunk. In the meantime we should keep the current state (ie all specialpurpose components present in trunk should be available in R13.07 demo) If they are in the demo they should be in the release. Actually the specialpurpose components are in the R13.07 demos because they can be there. But they are not maintained in the R13.07 branch (but ecommerce) only in trunk. As you can guess, I am troubled about the relation between releases and the trunk and demos in OFBiz. Would you prefer to not have the specialpurpose components in R13.07 demo? It is a bit odd and certainly goes against most product release strategies wherein the current release is the recommended download and carries whatever warranty that the project offers in terms of testing and rapidity of bug fixes and the trunk is usually called something that includesnightly build and unstable in the name and comes with no warranty and a warning about using it at your own risk. Demos should be of the latest release and should be stable and have a fixed functionality that can be documented in the wiki and marketing pages. They are, just that they use the branch instead of the packaged releases. For R13.07 (current stable) there is an exception, because I thought it was better to have the specialpurpose components available. This is what Jacopo contests It could be maintained by the documentation team once it is set up since it should not require any technical skills to keep working and fed with demo data. If the developers need a test site based on the nightly build, they should be free to set up as many combinations of configurations as they require and can support to be sure that the trunk still works but this should not be the public demo or even be called a demo. It's also, there are no official mention of the trunk demo, it's only a developers thing. Of course, this only works if a release is actually a Release and the team stands behind it and uses it when establishing new customers. We have no customers, only users Jacques Does anyone have an opinion about the gap between 13.07.01 and what the main SI companies are getting from using the trunk instead. Would a monthly release pattern reduce this gap to a point where it would be possible to use the official Release as the actual release? I hope it's more clear Jacques Thanks, Jacopo
Re: specialpurpose in R13.07 demo
The others participating in this project ( with and without customers are of no importance? Regards, Pierre Sent from my iPhone On 23 okt. 2014, at 18:04, Ron Wheeler rwhee...@artifact-software.com wrote: On 23/10/2014 11:33 AM, Jacques Le Roux wrote: Le 23/10/2014 17:11, Ron Wheeler a écrit : On 23/10/2014 10:39 AM, Jacques Le Roux wrote: Le 23/10/2014 15:01, Jacopo Cappellato a écrit : On Oct 23, 2014, at 2:07 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: I agree about the idea, but this applies only to releases or checked out code. Because there are no ways for users to enable/disable a component in demos, moreover demos are shared. Could you please explain the above sentence? I don't understand the meaning of it. Your idea of disabling some specialpurpose component can't be applied in R13.07 demo until we decide which component should be disabled in trunk. In the meantime we should keep the current state (ie all specialpurpose components present in trunk should be available in R13.07 demo) If they are in the demo they should be in the release. Actually the specialpurpose components are in the R13.07 demos because they can be there. But they are not maintained in the R13.07 branch (but ecommerce) only in trunk. As you can guess, I am troubled about the relation between releases and the trunk and demos in OFBiz. Would you prefer to not have the specialpurpose components in R13.07 demo? It is a bit odd and certainly goes against most product release strategies wherein the current release is the recommended download and carries whatever warranty that the project offers in terms of testing and rapidity of bug fixes and the trunk is usually called something that includesnightly build and unstable in the name and comes with no warranty and a warning about using it at your own risk. Demos should be of the latest release and should be stable and have a fixed functionality that can be documented in the wiki and marketing pages. They are, just that they use the branch instead of the packaged releases. For R13.07 (current stable) there is an exception, because I thought it was better to have the specialpurpose components available. This is what Jacopo contests It could be maintained by the documentation team once it is set up since it should not require any technical skills to keep working and fed with demo data. If the developers need a test site based on the nightly build, they should be free to set up as many combinations of configurations as they require and can support to be sure that the trunk still works but this should not be the public demo or even be called a demo. It's also, there are no official mention of the trunk demo, it's only a developers thing. Of course, this only works if a release is actually a Release and the team stands behind it and uses it when establishing new customers. We have no customers, only users The PMC members have the customers to whom I was referring. Jacques Does anyone have an opinion about the gap between 13.07.01 and what the main SI companies are getting from using the trunk instead. Would a monthly release pattern reduce this gap to a point where it would be possible to use the official Release as the actual release? I hope it's more clear Jacques Thanks, Jacopo -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: Discussion: Service Engine Refactoring
That is a nice piece of explanation. Should be part of the documentation, if it is not already. Regards, Pierre Sent from my iPhone On 31 aug. 2014, at 11:56, Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com wrote: On Aug 31, 2014, at 11:36 AM, Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com wrote: a) what is the original concern of DispatchContext and of GenericDispatcher This comes from this old but still interesting document: http://ofbiz.apache.org/docs/services.html *Service Dispatcher* The Service Dispatcher handles dispatching services to the appropriate Service Engine where it is then invoked. There is exactly one ServiceDispatcher for each Entity Delegator. If there are multiple delegators in an application there will also be multiple dispatchers. The ServiceDispatcher is accessed via a LocalDispatcher. There can be many LocalDispatchers associated with a ServiceDispatcher. Each LocalDispatcher is uniquely named and contains its own list of service definitions. When creating an instance of a LocalDispatcher, a DispatchContext is also created and passed to the ServiceEngine. A LocalDispatcher is associated with an application. Applications never talk directly to the ServiceDispatcher. The LocalDispatcher contains an API for invoking services, which are routed through the ServiceDispather. However, applications may be running in different threads than the actual ServiceDispatcher, so it is left to the LocalDispatcher to keep a DispatchContext which among other things keeps a reference to the applications classloader. *Dispatch Context* The DispatchContext is created by the LocalDispatcher upon instantiation. This is the runtime dispatcher context. It contains necessary information to process services for each dispatcher. This context contains the reference to each of the service definition files, the classloader which should be used for invocation, a reference to the delegator and its dispatcher along with a 'bag' of user defined attributes. This context is passed on to each service when invoked and is used by the dispatcher to determine the service's model. Jacopo
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/
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 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 http://www.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
set field=helpTopic value=${groovy:
parameters.componentName.toUpperCase() + '_' +
requestAttributes._CURRENT_VIEW_}/
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 @@
set field=layoutSettings.middleTopLink2
value=${lastSystemInfoNote2.moreInfoUrl}${groovy: if
(lastSystemInfoNote2amp;amp;lastSystemInfoNote2.moreInfoItemNameamp;amp;lastSystemInfoNote2.moreInfoItemId)quot;?quot;
+ lastSystemInfoNote2.moreInfoItemName + quot;=quot; +
lastSystemInfoNote2.moreInfoItemId + quot;amp;id=quot; +
lastSystemInfoNote2.moreInfoItemId;}/
set field=layoutSettings.middleTopLink3
value=${lastSystemInfoNote3.moreInfoUrl}${groovy: if
(lastSystemInfoNote3amp;amp;lastSystemInfoNote3.moreInfoItemNameamp;amp;lastSystemInfoNote3.moreInfoItemId)quot;?quot;
+ lastSystemInfoNote3.moreInfoItemName + quot;=quot; +
lastSystemInfoNote3.moreInfoItemId + quot;amp;id=quot; +
lastSystemInfoNote3.moreInfoItemId;}/
!-- Help link actions --
-!--set field=helpTopic value=${groovy: webSiteId +
'_' + requestAttributes._CURRENT_VIEW_}/--
-set field=helpTopic value=${groovy:
parameters.componentName.toUpperCase() + '_' +
requestAttributes._CURRENT_VIEW_}/
+set field=helpTopic value=${groovy:
applicationName.toUpperCase() + '_' + requestAttributes._CURRENT_VIEW_}/
entity-and list=pageAvail entity-name=ContentAssoc
field-map field-name=mapKey
from-field=helpTopic/
/entity-and
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: [jira] [Closed] (OFBIZ-4898) Complete Help screens in Manufacturing in NL language
Thanks Jacques, You're the best. Regards, Pierre Sent from my iPhone On 26 mei 2012, at 12:13, Jacques Le Roux (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/OFBIZ-4898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-4898. -- Resolution: Fixed Fix Version/s: Release Branch 12.04 SVN trunk Release Branch 11.04 Release Branch 10.04 Thanks Pierre, You patch is (finally ;o) in trunk r1342875 R12.04 r1342876 R11.04 r1342877 R10.04 r1342878 Complete Help screens in Manufacturing in NL language - Key: OFBIZ-4898 URL: https://issues.apache.org/jira/browse/OFBIZ-4898 Project: OFBiz Issue Type: Sub-task Components: manufacturing Affects Versions: SVN trunk Reporter: Jacques Le Roux Assignee: Jacques Le Roux Priority: Trivial Labels: Help, Manufacturing Fix For: Release Branch 10.04, Release Branch 11.04, SVN trunk, Release Branch 12.04 Attachments: OFBIZ-4802-MFG-Help-NL-v2.patch, OFBIZ-4802-MFG-Help-NL-v3.patch, OFBIZ-4802-MFG-Help-NL-v5.patch This is related and sequel of OFBIZ-4802 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Lose Weight Program for OFBiz - guiapp and pos
Hi Olivier, I would love to exchange thoughts regarding migration to portlets. Regards, Pierre Sent from my iPhone On 21 mrt. 2012, at 17:26, Olivier Heintz holivier.lis...@nereide.biz wrote: Le 21/03/2012 11:50, Pierre Smits a écrit : A) removal of framework/guiapp out of framework: +1 B) move specialpurpose/pos to 'Extras' +1 I am not in favour of moving ProjectMgr out of specialpurpose to 'Extras' as the majority of my customers use this. However, if it goes to 'Extras' I would like to assist in maintaining it. +1 for ProjectMgr as a Apache-OFBiz plug-in, not out of Apache-OFBiz ps: most of our(the company I'm working for) future contribution will be complete Projectmgr migration to portlet ;-) Regards, Pierre Op 20 maart 2012 12:47 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: A) move framework/guiapp out of the framework; after all these years no code made advantage of it being part of the framework and it is only used by the specialpurpose/pos component (which was the component for which it was built for); so guiapp can go in the pos component B) specialpurpose/pos: move to Extras No one objected so far; Jacques offered his help for #A. Should we focus on #A for now (it is an actionable item) and then discuss #B also based on the outcome of similar discussions for other specialpurpose components?
Variations of documents
Hi all, In a multi-tenant setup it might be required that per tenant the layout of documents (like invoice, order, packing slip, etc) differ from current trunk versions. My question is this: what is the best approach to achieve this? Reards, Pierre Sent from my iPhone
