You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacques Le Roux <ja...@les7arts.com> on 2012/11/10 12:17:12 UTC
OFBIZ-4941
If nobody disagree I will commit https://issues.apache.org/jira/browse/OFBIZ-4941 soon
Jacques
Re: OFBIZ-4941
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "Tom" <tr...@yahoo.com>
> E) As Jacques noted it is transformed by ant using docbook xls. I do not
> understand his comment "So maintenance worries"
Typo, meant "So no maintenance worries"
Jacques
Re: OFBIZ-4941
Posted by Anil Patel <an...@hotwaxmedia.com>.
Tom,
On Nov 10, 2012, at 2:51 PM, Tom <tr...@yahoo.com> wrote:
> Jacopo,
>
> A) The hard code in fieldlookup.js will go away when all forms are
> documented. That will leave the code that test for locale. I'm open for
> suggestions on how that could be done in some other way but given what I see
> as the superiority of the proposed solution I do not think this should be a
> show stopper.
>
I hate to use Javascript more then needed. In this case, We can build link to help document during the screen rendering process. We need something similar to OfbizUrl transform.
> B) Code was added in ofbiz-component.xml when BIRT was moved to
> specialpurpose. That code caused the current help to break. The latest code
> for the proposed system is not effected by ofbiz-component.xml. This is
> because it is at the webapp not component level. ofbiz-component.xml can
> revert back to what it was.
>
> Note: If you do not use the proposed system you will need to go back and do
> something with the BIRT ofbiz-component.xml (which needs work in any case).
> It causes birt help to be invoked when you try to open accounting help (or
> any of the other components mounted in BIRT).
>
> C) All the help was placed in the content component because it was the home
> for a subset of the docbook xls distribution. It made sense to replace that
> code with the latest implementation and keep everything in one place rather
> then do something in special purpose or hot deploy with a duplicate xls
> code. It also makes sense since help is content and not an application. I do
> not see how moving the content to the application will make it independent.
> Are you going to duplicate the docbook distribution in each application?
I am little confused here.
How is proposed help system using Ofbiz CMS?
>
> D) Covered by Jacques
>
> E) As Jacques noted it is transformed by ant using docbook xls. I do not
> understand his comment "So maintenance worries"
>
> F) It is loaded by the docbook xsl webhelp web application which is the
> heart of the system. webhelp makes extensive use of jquery.
>
> Also
> Re: "In my opinion we can't have the luxury to maintain two help systems in
> OFBiz."
> True - when I have updated as promised the current system can and should be
> removed. That said the code will support both systems during transition.
>
> Re: "Help links should point to a URL that is retrieved from the UI labels
> file (to support i18n). That way Help content can be located anywhere -
> inside or outside OFBiz."
>
> Help is invoked using a mechanism similar to the current system (themes). It
> supports i18n in some logic in fieldlookup.js as mentioned in (A). All of
> the help files are compiled HTML (unlike the current system which is
> transformed at runtime). They could just as easily be deployed to the OFBiz
> site or any other web site. They are also easily transformed into pdf and
> can be posted anywhere.
>
> I look forward to any other questions or comments you may have.
>
> Tom
>
>
>
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/OFBIZ-4941-tp4637418p4637441.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: OFBIZ-4941
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "Tom" <tr...@yahoo.com>
> Jacopo,
>
> A) The hard code in fieldlookup.js will go away when all forms are
> documented. That will leave the code that test for locale. I'm open for
> suggestions on how that could be done in some other way but given what I see
> as the superiority of the proposed solution I do not think this should be a
> show stopper.
I agree, we already discussed this with Tom but I forgot.
> B) Code was added in ofbiz-component.xml when BIRT was moved to
> specialpurpose. That code caused the current help to break. The latest code
> for the proposed system is not effected by ofbiz-component.xml. This is
> because it is at the webapp not component level. ofbiz-component.xml can
> revert back to what it was.
>
> Note: If you do not use the proposed system you will need to go back and do
> something with the BIRT ofbiz-component.xml (which needs work in any case).
> It causes birt help to be invoked when you try to open accounting help (or
> any of the other components mounted in BIRT).
Yes, thanks for https://issues.apache.org/jira/browse/OFBIZ-5070 Tom
Jacques
Re: OFBIZ-4941
Posted by Jacques Le Roux <ja...@les7arts.com>.
Tom Burns wrote:
> Jacques,
>
> I think that's about it. Re 7 I would like to keep everything together.
>
> I assume you will take care of the ASL2 headers.
Yes, no pb.
>
> By the way there appears to be a defect in the CMS web site in the content component.
>
> https://demo-stable.ofbiz.apache.org/cmssite/cms/APACHE_OFBIZ_PDF is delivering un-formatted text in a file with an html type
> (the link promises a PDF file). Could be a browser thing but I don't think so.
I reproduce in those browsers (FF, Chrome, Opera), curiously IE8 does not respond
Jacques
>
> The content manager dataresource Object Info is "applications/content/template/docbook/fo/docbook.xsl". This problem preceded the
> update to the docbook folder.
>
> I'm not sure how the link in Object Info is used in transformation by the CMS web app. If we get it working we could add the help
> docbook files to the CMS to demonstrate alternate help deployments like
> http://fusesource.com/products/fuse-esb-enterprise/#documentation.
>
>
> Can you confirm the problem (not a browser problem) and I will open a defect in jira.
>
> Thanks,
>
> Tom
>
>
>
>
> ________________________________
> From: Jacques Le Roux <ja...@les7arts.com>
> To: dev@ofbiz.apache.org; Tom Burns <tr...@yahoo.com>
> Sent: Sunday, November 11, 2012 11:30 AM
> Subject: Re: OFBIZ-4941
>
> Thanks Tom,
>
> You don't have to apologize, this is a great post which explains/clarifies the situation.
>
> To summarize/rephrase (to be sure I understood Tom's explanations):
>
> Some committers would prefer to have a new specialpurpose help component instead of embedding in content. The idea is to prevent
> dependencies of the content component on other applications (or even framework) components.
> This is a late requirement from Tom's perspective, since Docbook is already in the content component, and Webhelp is (a new) part
> of Docbook.
> Also keeping Docbook in the content component could have some interested. Notably to use content management for help data.
>
> Actually there are 2 different things. We theoritically can keep Webhelp in content under Docbook (its right place) and have a
> help component for the help data themselves. But from point 7 below this would need (much, Tom?) more work.
> If ever we go this way, we need a clear design before changing things again...!
>
> Overriding in hot-deploy is not an issue either in content or (new) help component, but would need more work (to extend
> create-component target)
>
> Last but not least, if I have well understood, Tom used the previous help data to (partially for now) build the new help. The new
> help (will totally) replace/s the old data and have no dependencies on them.
> BTW Tom: all the xml files under applications\content\data\helpdata\docbookhelp miss the ASL2 header...
>
> Jacques
>
> Tom Burns wrote:
>> I apologize for the going on at length here but...
>>
>> The first proposal in 4941 was to use Java Help and the POC
>> was in hot deploy so content manager was not the first choice for deployment.
>> Content manager became the home for the solution through this line of thinking.
>> 1. DocBook is the preferred format for OFBiz help.
>> 2. The current system did not provide good support for
>> DocBook transformation.
>> 3. DocBook xsl is the standard for DocBook transformations.
>> 4. The license friendly webhelp component is a good solution
>> for providing context sensitive help for OFBiz using DocBook xsl.
>> 5. DocBook xsl was already in the OFBiz content component but
>> did not have the webhelp component.
>> 6. There was no compelling reason to create a new component
>> for help and have duplicate instances of DocBook xsl. Also the assumption is
>> that DocBook xsl was being used by the content component and so backward
>> compatibility needed to be considered.
>> 7. DocBook xsl is complex. The path of least resistance was
>> to extend the example webhelp inside the webhelp component folder. >From that it
>> followed to host the docbook and image files within the content component.
>>
>> I do not have a clear idea of what is being proposed as an
>> alternative deployment or why. The move however would be, as Jacques describes,
>> relatively simple. If you have a suggestion for an alternate deployment please
>> provide some additional design details.
>>
>>
>> There appears to be a requirement for developers to override
>> the current help for a custom implementation. All you need to do for that is
>> edit or replace the content in the folders in component://content/data/helpdata/docbookhelp
>> and re-run the ant task for the component. This is done only one time and can
>> be performed while ofbiz is running.
>>
>> If there is a requirement to keep your help documents in
>> your hot deployed application (separate from the content component) we could
>> extend the create-component ant task to add structure and build logic to
>> support webhelp. I think if that is the requirement it should be an improvement
>> in a separate Jira issue. In my mind it would be a lower priority then working
>> on improving the quality of the content in the help documents.
>>
>> One last note (we all hope). Currently the solution does not
>> use the content management system however I can see adding the docbook
>> documents under docbookhelp as resources and having the content entity drive PDF
>> output using fop and the docbook fo. I think that using the resources of the
>> DocBook xsl in content manager is a good argument for leaving it where it is.
>>
>> Again, I apologize for the length of these posts.
>>
>> Tom
>>
>>
>>
>>
>> ________________________________
>> From: Jacques Le Roux <ja...@les7arts.com>
>> To: dev@ofbiz.apache.org
>> Sent: Sunday, November 11, 2012 3:22 AM
>> Subject: Re: OFBIZ-4941
>>
>> FYI: I have attached a new patch with few changes in
>> LICENSE
>> NOTICE
>> applications/content/template/docbook/webhelp/LICENSE
>>
>> at https://issues.apache.org/jira/browse/OFBIZ-4941
>>
>> Jacques
>>
>> From: "Jacques Le Roux" <ja...@les7arts.com>
>>> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>>>> On Nov 10, 2012, at 8:51 PM, Tom wrote:
>>>>
>>>>> C) All the help was placed in the content component because it was the home
>>>>> for a subset of the docbook xls distribution. It made sense to replace that
>>>>> code with the latest implementation and keep everything in one place rather
>>>>> then do something in special purpose or hot deploy with a duplicate xls
>>>>> code. It also makes sense since help is content and not an application. I do
>>>>> not see how moving the content to the application will make it independent.
>>>>> Are you going to duplicate the docbook distribution in each application?
>>>>
>>>> I am talking about the content of help pages for the applications, this should go out of the "content" component (imo it should
>>>> be an hot-deploy component that can be added to add help pages at runtime).
>>>>
>>>> Jacopo
>>>
>>> I'm most inclidned to Anil's proposition in Jira
>>> https://issues.apache.org/jira/browse/OFBIZ-4941?focusedCommentId=13494790&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13494790
>>> Abstract:
>>> New specialpurpose (to keep OOTB) help component with Docbook inside. I don't think we need any of content component, Tom?
>>>
>>> With this new help component it's more logical to keep in the content of current applications\content\data\helpdata\docbookhelp.
>>>
>>> So it seems to be "just" about moving
>>> 1.
>>> applications\content\data\helpdata\docbookhelp
>>> and
>>> applications\content\template\docbook
>>>
>>> 2. Adapt the build script (not sure much is needed)
>>> applications/content/template/docbook/webhelp/build.properties
>>> applications/content/template/docbook/webhelp/build.xml
>>> What's more Tom?
>>>
>>> License:
>>> Jacopo, as I said, I already checked the license
>>> https://issues.apache.org/jira/browse/OFBIZ-4941?focusedCommentId=13471175&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13471175
>>> So we will only to add a line in LICENSE for
>>> current applications/content/template/docbook/webhelp/*
>>> and a section in NOTICE with the speficic
>>> <<Any stylesheet derived from this Software that is publicly distributed will be identified with a different name and the
>>> version strings in any derived Software will be changed so that no possibility of confusion between the derived package and this
>>> Software will exist.>> Tom, I have also changed the content of template/docbook/webhelp/LICENSE to <<See
>>> template/docbook/webhelp/docs/content/index.html>> to make things more obvious, to be adapted when moved maybe.
>>>
>>> It seems we are near an agreement with as mich as possible changes for Tom :)
>>>
>>> Jacques
Re: OFBIZ-4941
Posted by Tom Burns <tr...@yahoo.com>.
Jacques,
I think that's about it. Re 7 I would like to keep everything together.
I assume you will take care of the ASL2 headers.
By the way there appears to be a defect in the CMS web site in the content component.
https://demo-stable.ofbiz.apache.org/cmssite/cms/APACHE_OFBIZ_PDF is delivering un-formatted text in a file with an html type (the link promises a PDF file). Could be a browser thing but I don't think so.
The content manager dataresource Object Info is "applications/content/template/docbook/fo/docbook.xsl". This problem preceded the update to the docbook folder.
I'm not sure how the link in Object Info is used in transformation by the CMS web app. If we get it working we could add the help docbook files to the CMS to demonstrate alternate help deployments like http://fusesource.com/products/fuse-esb-enterprise/#documentation.
Can you confirm the problem (not a browser problem) and I will open a defect in jira.
Thanks,
Tom
________________________________
From: Jacques Le Roux <ja...@les7arts.com>
To: dev@ofbiz.apache.org; Tom Burns <tr...@yahoo.com>
Sent: Sunday, November 11, 2012 11:30 AM
Subject: Re: OFBIZ-4941
Thanks Tom,
You don't have to apologize, this is a great post which explains/clarifies the situation.
To summarize/rephrase (to be sure I understood Tom's explanations):
Some committers would prefer to have a new specialpurpose help component instead of embedding in content. The idea is to prevent dependencies of the content component on other applications (or even framework) components.
This is a late requirement from Tom's perspective, since Docbook is already in the content component, and Webhelp is (a new) part of Docbook.
Also keeping Docbook in the content component could have some interested. Notably to use content management for help data.
Actually there are 2 different things. We theoritically can keep Webhelp in content under Docbook (its right place) and have a help component for the help data themselves. But from point 7 below this would need (much, Tom?) more work.
If ever we go this way, we need a clear design before changing things again...!
Overriding in hot-deploy is not an issue either in content or (new) help component, but would need more work (to extend create-component target)
Last but not least, if I have well understood, Tom used the previous help data to (partially for now) build the new help. The new help (will totally) replace/s the old data and have no dependencies on them.
BTW Tom: all the xml files under applications\content\data\helpdata\docbookhelp miss the ASL2 header...
Jacques
Tom Burns wrote:
> I apologize for the going on at length here but...
>
> The first proposal in 4941 was to use Java Help and the POC
> was in hot deploy so content manager was not the first choice for deployment.
> Content manager became the home for the solution through this line of thinking.
> 1. DocBook is the preferred format for OFBiz help.
> 2. The current system did not provide good support for
> DocBook transformation.
> 3. DocBook xsl is the standard for DocBook transformations.
> 4. The license friendly webhelp component is a good solution
> for providing context sensitive help for OFBiz using DocBook xsl.
> 5. DocBook xsl was already in the OFBiz content component but
> did not have the webhelp component.
> 6. There was no compelling reason to create a new component
> for help and have duplicate instances of DocBook xsl. Also the assumption is
> that DocBook xsl was being used by the content component and so backward
> compatibility needed to be considered.
> 7. DocBook xsl is complex. The path of least resistance was
> to extend the example webhelp inside the webhelp component folder. From that it
> followed to host the docbook and image files within the content component.
>
> I do not have a clear idea of what is being proposed as an
> alternative deployment or why. The move however would be, as Jacques describes,
> relatively simple. If you have a suggestion for an alternate deployment please
> provide some additional design details.
>
>
> There appears to be a requirement for developers to override
> the current help for a custom implementation. All you need to do for that is
> edit or replace the content in the folders in component://content/data/helpdata/docbookhelp
> and re-run the ant task for the component. This is done only one time and can
> be performed while ofbiz is running.
>
> If there is a requirement to keep your help documents in
> your hot deployed application (separate from the content component) we could
> extend the create-component ant task to add structure and build logic to
> support webhelp. I think if that is the requirement it should be an improvement
> in a separate Jira issue. In my mind it would be a lower priority then working
> on improving the quality of the content in the help documents.
>
> One last note (we all hope). Currently the solution does not
> use the content management system however I can see adding the docbook
> documents under docbookhelp as resources and having the content entity drive PDF
> output using fop and the docbook fo. I think that using the resources of the
> DocBook xsl in content manager is a good argument for leaving it where it is.
>
> Again, I apologize for the length of these posts.
>
> Tom
>
>
>
>
> ________________________________
> From: Jacques Le Roux <ja...@les7arts.com>
> To: dev@ofbiz.apache.org
> Sent: Sunday, November 11, 2012 3:22 AM
> Subject: Re: OFBIZ-4941
>
> FYI: I have attached a new patch with few changes in
> LICENSE
> NOTICE
> applications/content/template/docbook/webhelp/LICENSE
>
> at https://issues.apache.org/jira/browse/OFBIZ-4941
>
> Jacques
>
> From: "Jacques Le Roux" <ja...@les7arts.com>
>> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>>> On Nov 10, 2012, at 8:51 PM, Tom wrote:
>>>
>>>> C) All the help was placed in the content component because it was the home
>>>> for a subset of the docbook xls distribution. It made sense to replace that
>>>> code with the latest implementation and keep everything in one place rather
>>>> then do something in special purpose or hot deploy with a duplicate xls
>>>> code. It also makes sense since help is content and not an application. I do
>>>> not see how moving the content to the application will make it independent.
>>>> Are you going to duplicate the docbook distribution in each application?
>>>
>>> I am talking about the content of help pages for the applications, this should go out of the "content" component (imo it should
>>> be an hot-deploy component that can be added to add help pages at runtime).
>>>
>>> Jacopo
>>
>> I'm most inclidned to Anil's proposition in Jira
>> https://issues.apache.org/jira/browse/OFBIZ-4941?focusedCommentId=13494790&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13494790
>> Abstract:
>> New specialpurpose (to keep OOTB) help component with Docbook inside. I don't think we need any of content component, Tom?
>>
>> With this new help component it's more logical to keep in the content of current applications\content\data\helpdata\docbookhelp.
>>
>> So it seems to be "just" about moving
>> 1.
>> applications\content\data\helpdata\docbookhelp
>> and
>> applications\content\template\docbook
>>
>> 2. Adapt the build script (not sure much is needed)
>> applications/content/template/docbook/webhelp/build.properties
>> applications/content/template/docbook/webhelp/build.xml
>> What's more Tom?
>>
>> License:
>> Jacopo, as I said, I already checked the license
>> https://issues.apache.org/jira/browse/OFBIZ-4941?focusedCommentId=13471175&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13471175
>> So we will only to add a line in LICENSE for
>> current applications/content/template/docbook/webhelp/*
>> and a section in NOTICE with the speficic
>> <<Any stylesheet derived from this Software that is publicly distributed will be identified with a different name and the
>> version strings in any derived Software will be changed so that no possibility of confusion between the derived package and this
>> Software will exist.>> Tom, I have also changed the content of template/docbook/webhelp/LICENSE to <<See
>> template/docbook/webhelp/docs/content/index.html>> to make things more obvious, to be adapted when moved maybe.
>>
>> It seems we are near an agreement with as mich as possible changes for Tom :)
>>
>> Jacques
Re: OFBIZ-4941
Posted by Jacques Le Roux <ja...@les7arts.com>.
Thanks Tom,
You don't have to apologize, this is a great post which explains/clarifies the situation.
To summarize/rephrase (to be sure I understood Tom's explanations):
Some committers would prefer to have a new specialpurpose help component instead of embedding in content. The idea is to prevent dependencies of the content component on other applications (or even framework) components.
This is a late requirement from Tom's perspective, since Docbook is already in the content component, and Webhelp is (a new) part of Docbook.
Also keeping Docbook in the content component could have some interested. Notably to use content management for help data.
Actually there are 2 different things. We theoritically can keep Webhelp in content under Docbook (its right place) and have a help component for the help data themselves. But from point 7 below this would need (much, Tom?) more work.
If ever we go this way, we need a clear design before changing things again...!
Overriding in hot-deploy is not an issue either in content or (new) help component, but would need more work (to extend create-component target)
Last but not least, if I have well understood, Tom used the previous help data to (partially for now) build the new help. The new help (will totally) replace/s the old data and have no dependencies on them.
BTW Tom: all the xml files under applications\content\data\helpdata\docbookhelp miss the ASL2 header...
Jacques
Tom Burns wrote:
> I apologize for the going on at length here but...
>
> The first proposal in 4941 was to use Java Help and the POC
> was in hot deploy so content manager was not the first choice for deployment.
> Content manager became the home for the solution through this line of thinking.
> 1. DocBook is the preferred format for OFBiz help.
> 2. The current system did not provide good support for
> DocBook transformation.
> 3. DocBook xsl is the standard for DocBook transformations.
> 4. The license friendly webhelp component is a good solution
> for providing context sensitive help for OFBiz using DocBook xsl.
> 5. DocBook xsl was already in the OFBiz content component but
> did not have the webhelp component.
> 6. There was no compelling reason to create a new component
> for help and have duplicate instances of DocBook xsl. Also the assumption is
> that DocBook xsl was being used by the content component and so backward
> compatibility needed to be considered.
> 7. DocBook xsl is complex. The path of least resistance was
> to extend the example webhelp inside the webhelp component folder. >From that it
> followed to host the docbook and image files within the content component.
>
> I do not have a clear idea of what is being proposed as an
> alternative deployment or why. The move however would be, as Jacques describes,
> relatively simple. If you have a suggestion for an alternate deployment please
> provide some additional design details.
>
>
> There appears to be a requirement for developers to override
> the current help for a custom implementation. All you need to do for that is
> edit or replace the content in the folders in component://content/data/helpdata/docbookhelp
> and re-run the ant task for the component. This is done only one time and can
> be performed while ofbiz is running.
>
> If there is a requirement to keep your help documents in
> your hot deployed application (separate from the content component) we could
> extend the create-component ant task to add structure and build logic to
> support webhelp. I think if that is the requirement it should be an improvement
> in a separate Jira issue. In my mind it would be a lower priority then working
> on improving the quality of the content in the help documents.
>
> One last note (we all hope). Currently the solution does not
> use the content management system however I can see adding the docbook
> documents under docbookhelp as resources and having the content entity drive PDF
> output using fop and the docbook fo. I think that using the resources of the
> DocBook xsl in content manager is a good argument for leaving it where it is.
>
> Again, I apologize for the length of these posts.
>
> Tom
>
>
>
>
> ________________________________
> From: Jacques Le Roux <ja...@les7arts.com>
> To: dev@ofbiz.apache.org
> Sent: Sunday, November 11, 2012 3:22 AM
> Subject: Re: OFBIZ-4941
>
> FYI: I have attached a new patch with few changes in
> LICENSE
> NOTICE
> applications/content/template/docbook/webhelp/LICENSE
>
> at https://issues.apache.org/jira/browse/OFBIZ-4941
>
> Jacques
>
> From: "Jacques Le Roux" <ja...@les7arts.com>
>> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>>> On Nov 10, 2012, at 8:51 PM, Tom wrote:
>>>
>>>> C) All the help was placed in the content component because it was the home
>>>> for a subset of the docbook xls distribution. It made sense to replace that
>>>> code with the latest implementation and keep everything in one place rather
>>>> then do something in special purpose or hot deploy with a duplicate xls
>>>> code. It also makes sense since help is content and not an application. I do
>>>> not see how moving the content to the application will make it independent.
>>>> Are you going to duplicate the docbook distribution in each application?
>>>
>>> I am talking about the content of help pages for the applications, this should go out of the "content" component (imo it should
>>> be an hot-deploy component that can be added to add help pages at runtime).
>>>
>>> Jacopo
>>
>> I'm most inclidned to Anil's proposition in Jira
>> https://issues.apache.org/jira/browse/OFBIZ-4941?focusedCommentId=13494790&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13494790
>> Abstract:
>> New specialpurpose (to keep OOTB) help component with Docbook inside. I don't think we need any of content component, Tom?
>>
>> With this new help component it's more logical to keep in the content of current applications\content\data\helpdata\docbookhelp.
>>
>> So it seems to be "just" about moving
>> 1.
>> applications\content\data\helpdata\docbookhelp
>> and
>> applications\content\template\docbook
>>
>> 2. Adapt the build script (not sure much is needed)
>> applications/content/template/docbook/webhelp/build.properties
>> applications/content/template/docbook/webhelp/build.xml
>> What's more Tom?
>>
>> License:
>> Jacopo, as I said, I already checked the license
>> https://issues.apache.org/jira/browse/OFBIZ-4941?focusedCommentId=13471175&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13471175
>> So we will only to add a line in LICENSE for
>> current applications/content/template/docbook/webhelp/*
>> and a section in NOTICE with the speficic
>> <<Any stylesheet derived from this Software that is publicly distributed will be identified with a different name and the
>> version strings in any derived Software will be changed so that no possibility of confusion between the derived package and this
>> Software will exist.>> Tom, I have also changed the content of template/docbook/webhelp/LICENSE to <<See
>> template/docbook/webhelp/docs/content/index.html>> to make things more obvious, to be adapted when moved maybe.
>>
>> It seems we are near an agreement with as mich as possible changes for Tom :)
>>
>> Jacques
Re: OFBIZ-4941
Posted by Tom Burns <tr...@yahoo.com>.
I apologize for the going on at length here but...
The first proposal in 4941 was to use Java Help and the POC
was in hot deploy so content manager was not the first choice for deployment.
Content manager became the home for the solution through this line of thinking.
1. DocBook is the preferred format for OFBiz help.
2. The current system did not provide good support for
DocBook transformation.
3. DocBook xsl is the standard for DocBook transformations.
4. The license friendly webhelp component is a good solution
for providing context sensitive help for OFBiz using DocBook xsl.
5. DocBook xsl was already in the OFBiz content component but
did not have the webhelp component.
6. There was no compelling reason to create a new component
for help and have duplicate instances of DocBook xsl. Also the assumption is
that DocBook xsl was being used by the content component and so backward
compatibility needed to be considered.
7. DocBook xsl is complex. The path of least resistance was
to extend the example webhelp inside the webhelp component folder. From that it
followed to host the docbook and image files within the content component.
I do not have a clear idea of what is being proposed as an
alternative deployment or why. The move however would be, as Jacques describes,
relatively simple. If you have a suggestion for an alternate deployment please
provide some additional design details.
There appears to be a requirement for developers to override
the current help for a custom implementation. All you need to do for that is
edit or replace the content in the folders in component://content/data/helpdata/docbookhelp
and re-run the ant task for the component. This is done only one time and can
be performed while ofbiz is running.
If there is a requirement to keep your help documents in
your hot deployed application (separate from the content component) we could
extend the create-component ant task to add structure and build logic to
support webhelp. I think if that is the requirement it should be an improvement
in a separate Jira issue. In my mind it would be a lower priority then working
on improving the quality of the content in the help documents.
One last note (we all hope). Currently the solution does not
use the content management system however I can see adding the docbook
documents under docbookhelp as resources and having the content entity drive PDF
output using fop and the docbook fo. I think that using the resources of the
DocBook xsl in content manager is a good argument for leaving it where it is.
Again, I apologize for the length of these posts.
Tom
________________________________
From: Jacques Le Roux <ja...@les7arts.com>
To: dev@ofbiz.apache.org
Sent: Sunday, November 11, 2012 3:22 AM
Subject: Re: OFBIZ-4941
FYI: I have attached a new patch with few changes in
LICENSE
NOTICE
applications/content/template/docbook/webhelp/LICENSE
at https://issues.apache.org/jira/browse/OFBIZ-4941
Jacques
From: "Jacques Le Roux" <ja...@les7arts.com>
> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>> On Nov 10, 2012, at 8:51 PM, Tom wrote:
>>
>>> C) All the help was placed in the content component because it was the home
>>> for a subset of the docbook xls distribution. It made sense to replace that
>>> code with the latest implementation and keep everything in one place rather
>>> then do something in special purpose or hot deploy with a duplicate xls
>>> code. It also makes sense since help is content and not an application. I do
>>> not see how moving the content to the application will make it independent.
>>> Are you going to duplicate the docbook distribution in each application?
>>
>> I am talking about the content of help pages for the applications, this should go out of the "content" component (imo it should be an hot-deploy component that can be added to add help pages at runtime).
>>
>> Jacopo
>
> I'm most inclidned to Anil's proposition in Jira https://issues.apache.org/jira/browse/OFBIZ-4941?focusedCommentId=13494790&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13494790
> Abstract:
> New specialpurpose (to keep OOTB) help component with Docbook inside. I don't think we need any of content component, Tom?
>
> With this new help component it's more logical to keep in the content of current applications\content\data\helpdata\docbookhelp.
>
> So it seems to be "just" about moving
> 1.
> applications\content\data\helpdata\docbookhelp
> and
> applications\content\template\docbook
>
> 2. Adapt the build script (not sure much is needed)
> applications/content/template/docbook/webhelp/build.properties
> applications/content/template/docbook/webhelp/build.xml
> What's more Tom?
>
> License:
> Jacopo, as I said, I already checked the license https://issues.apache.org/jira/browse/OFBIZ-4941?focusedCommentId=13471175&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13471175
> So we will only to add a line in LICENSE for
> current applications/content/template/docbook/webhelp/*
> and a section in NOTICE with the speficic
> <<Any stylesheet derived from this Software that is publicly distributed will be identified with a different name and the version strings in any derived Software will be changed so that no possibility of confusion between the derived package and this Software will exist.>>
> Tom, I have also changed the content of template/docbook/webhelp/LICENSE to
> <<See template/docbook/webhelp/docs/content/index.html>> to make things more obvious, to be adapted when moved maybe.
>
> It seems we are near an agreement with as mich as possible changes for Tom :)
>
> Jacques
>
Re: OFBIZ-4941
Posted by Jacques Le Roux <ja...@les7arts.com>.
FYI: I have attached a new patch with few changes in
LICENSE
NOTICE
applications/content/template/docbook/webhelp/LICENSE
at https://issues.apache.org/jira/browse/OFBIZ-4941
Jacques
From: "Jacques Le Roux" <ja...@les7arts.com>
> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>> On Nov 10, 2012, at 8:51 PM, Tom wrote:
>>
>>> C) All the help was placed in the content component because it was the home
>>> for a subset of the docbook xls distribution. It made sense to replace that
>>> code with the latest implementation and keep everything in one place rather
>>> then do something in special purpose or hot deploy with a duplicate xls
>>> code. It also makes sense since help is content and not an application. I do
>>> not see how moving the content to the application will make it independent.
>>> Are you going to duplicate the docbook distribution in each application?
>>
>> I am talking about the content of help pages for the applications, this should go out of the "content" component (imo it should be an hot-deploy component that can be added to add help pages at runtime).
>>
>> Jacopo
>
> I'm most inclidned to Anil's proposition in Jira https://issues.apache.org/jira/browse/OFBIZ-4941?focusedCommentId=13494790&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13494790
> Abstract:
> New specialpurpose (to keep OOTB) help component with Docbook inside. I don't think we need any of content component, Tom?
>
> With this new help component it's more logical to keep in the content of current applications\content\data\helpdata\docbookhelp.
>
> So it seems to be "just" about moving
> 1.
> applications\content\data\helpdata\docbookhelp
> and
> applications\content\template\docbook
>
> 2. Adapt the build script (not sure much is needed)
> applications/content/template/docbook/webhelp/build.properties
> applications/content/template/docbook/webhelp/build.xml
> What's more Tom?
>
> License:
> Jacopo, as I said, I already checked the license https://issues.apache.org/jira/browse/OFBIZ-4941?focusedCommentId=13471175&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13471175
> So we will only to add a line in LICENSE for
> current applications/content/template/docbook/webhelp/*
> and a section in NOTICE with the speficic
> <<Any stylesheet derived from this Software that is publicly distributed will be identified with a different name and the version strings in any derived Software will be changed so that no possibility of confusion between the derived package and this Software will exist.>>
> Tom, I have also changed the content of template/docbook/webhelp/LICENSE to
> <<See template/docbook/webhelp/docs/content/index.html>> to make things more obvious, to be adapted when moved maybe.
>
> It seems we are near an agreement with as mich as possible changes for Tom :)
>
> Jacques
>
Re: OFBIZ-4941
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
> On Nov 10, 2012, at 8:51 PM, Tom wrote:
>
>> C) All the help was placed in the content component because it was the home
>> for a subset of the docbook xls distribution. It made sense to replace that
>> code with the latest implementation and keep everything in one place rather
>> then do something in special purpose or hot deploy with a duplicate xls
>> code. It also makes sense since help is content and not an application. I do
>> not see how moving the content to the application will make it independent.
>> Are you going to duplicate the docbook distribution in each application?
>
> I am talking about the content of help pages for the applications, this should go out of the "content" component (imo it should be an hot-deploy component that can be added to add help pages at runtime).
>
> Jacopo
I'm most inclidned to Anil's proposition in Jira https://issues.apache.org/jira/browse/OFBIZ-4941?focusedCommentId=13494790&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13494790
Abstract:
New specialpurpose (to keep OOTB) help component with Docbook inside. I don't think we need any of content component, Tom?
With this new help component it's more logical to keep in the content of current applications\content\data\helpdata\docbookhelp.
So it seems to be "just" about moving
1.
applications\content\data\helpdata\docbookhelp
and
applications\content\template\docbook
2. Adapt the build script (not sure much is needed)
applications/content/template/docbook/webhelp/build.properties
applications/content/template/docbook/webhelp/build.xml
What's more Tom?
License:
Jacopo, as I said, I already checked the license https://issues.apache.org/jira/browse/OFBIZ-4941?focusedCommentId=13471175&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13471175
So we will only to add a line in LICENSE for
current applications/content/template/docbook/webhelp/*
and a section in NOTICE with the speficic
<<Any stylesheet derived from this Software that is publicly distributed will be identified with a different name and the version strings in any derived Software will be changed so that no possibility of confusion between the derived package and this Software will exist.>>
Tom, I have also changed the content of template/docbook/webhelp/LICENSE to
<<See template/docbook/webhelp/docs/content/index.html>> to make things more obvious, to be adapted when moved maybe.
It seems we are near an agreement with as mich as possible changes for Tom :)
Jacques
Re: OFBIZ-4941
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On Nov 10, 2012, at 8:51 PM, Tom wrote:
> C) All the help was placed in the content component because it was the home
> for a subset of the docbook xls distribution. It made sense to replace that
> code with the latest implementation and keep everything in one place rather
> then do something in special purpose or hot deploy with a duplicate xls
> code. It also makes sense since help is content and not an application. I do
> not see how moving the content to the application will make it independent.
> Are you going to duplicate the docbook distribution in each application?
I am talking about the content of help pages for the applications, this should go out of the "content" component (imo it should be an hot-deploy component that can be added to add help pages at runtime).
Jacopo
Re: OFBIZ-4941
Posted by Tom <tr...@yahoo.com>.
Jacopo,
A) The hard code in fieldlookup.js will go away when all forms are
documented. That will leave the code that test for locale. I'm open for
suggestions on how that could be done in some other way but given what I see
as the superiority of the proposed solution I do not think this should be a
show stopper.
B) Code was added in ofbiz-component.xml when BIRT was moved to
specialpurpose. That code caused the current help to break. The latest code
for the proposed system is not effected by ofbiz-component.xml. This is
because it is at the webapp not component level. ofbiz-component.xml can
revert back to what it was.
Note: If you do not use the proposed system you will need to go back and do
something with the BIRT ofbiz-component.xml (which needs work in any case).
It causes birt help to be invoked when you try to open accounting help (or
any of the other components mounted in BIRT).
C) All the help was placed in the content component because it was the home
for a subset of the docbook xls distribution. It made sense to replace that
code with the latest implementation and keep everything in one place rather
then do something in special purpose or hot deploy with a duplicate xls
code. It also makes sense since help is content and not an application. I do
not see how moving the content to the application will make it independent.
Are you going to duplicate the docbook distribution in each application?
D) Covered by Jacques
E) As Jacques noted it is transformed by ant using docbook xls. I do not
understand his comment "So maintenance worries"
F) It is loaded by the docbook xsl webhelp web application which is the
heart of the system. webhelp makes extensive use of jquery.
Also
Re: "In my opinion we can't have the luxury to maintain two help systems in
OFBiz."
True - when I have updated as promised the current system can and should be
removed. That said the code will support both systems during transition.
Re: "Help links should point to a URL that is retrieved from the UI labels
file (to support i18n). That way Help content can be located anywhere -
inside or outside OFBiz."
Help is invoked using a mechanism similar to the current system (themes). It
supports i18n in some logic in fieldlookup.js as mentioned in (A). All of
the help files are compiled HTML (unlike the current system which is
transformed at runtime). They could just as easily be deployed to the OFBiz
site or any other web site. They are also easily transformed into pdf and
can be posted anywhere.
I look forward to any other questions or comments you may have.
Tom
--
View this message in context: http://ofbiz.135035.n4.nabble.com/OFBIZ-4941-tp4637418p4637441.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: OFBIZ-4941
Posted by Anil Patel <an...@hotwaxmedia.com>.
On Nov 10, 2012, at 9:29 AM, Adrian Crum <ad...@sandglass-software.com> wrote:
> On 11/10/2012 1:48 PM, Jacopo Cappellato wrote:
>> Thank you Jacques,
>>
>> here is some quick feedback after a review of the patch.
>>
>> A) all the code in framework/images/webapp/images/fieldlookup.js is bad because contains hardcoded application/components
>>
>> B) what is this?
>>
>> Index: specialpurpose/birt/ofbiz-component.xml
>> ===================================================================
>> --- specialpurpose/birt/ofbiz-component.xml (revision 1407381)
>> +++ specialpurpose/birt/ofbiz-component.xml (working copy)
>> @@ -29,7 +29,6 @@
>> <entity-resource type="data" reader-name="seed" loader="main" location="data/OrderPortletData.xml"/>
>> <service-resource type="model" loader="main" location="servicedef/services.xml"/>
>> - <!-- use when reports need to be injected into applications Note: this will break context help for those applications.
>> <webapp name="accounting"
>> title="Accounting"
>> server="default-server"
>> @@ -50,7 +49,6 @@
>> location="webapp/ordermgr"
>> base-permission="OFBTOOLS,ORDERMGR"
>> mount-point="/ordermgr"/>
>> - -->
>> <webapp name="birt"
>> title="BIRT"
>> server="default-server"
>>
>> C) I still think it is a bad idea to add dependencies to the content component on other applications like: applications/content/webapp/ofbizhelp/catalog_en
>>
>> D) did you check the compliance with licenses? See this for example:
>>
>> +/*----------------------------------------------------------------------------
>> + * JavaScript for webhelp search
>> + *----------------------------------------------------------------------------
>> + This file is part of the webhelpsearch plugin for DocBook WebHelp
>> + Copyright (c) 2007-2008 NexWave Solutions All Rights Reserved.
>> + www.nexwave.biz Nadege Quaine
>> + http://kasunbg.blogspot.com/ Kasun Gajasinghe
>> + */
>>
>> E) how was generated the content of (for example):
>>
>> Index: applications/content/webapp/ofbizhelp/catalog_en/content/search/htmlFileInfoList.js
>>
>> ? How should we maintain it?
>>
>> F) why this:
>>
>> applications/content/webapp/ofbizhelp/catalog_en/common/jquery/jquery-1.4.2.min.js
>>
>> ?
>>
>> I think it is enough for now, but the changes are big and I couldn't review everything.
>>
>> In general, my preference would be to see this type of contribution being implemented as a pluggable feature (with data mainatined externally in Confluence or in a specialpurpose or extra component) rather than being part of the trunk.
>
> Thanks Jacopo.
>
> This has been my position all along. Help links should point to a URL that is retrieved from the UI labels file (to support i18n). That way Help content can be located anywhere - inside or outside OFBiz. If an application wants to use the OFBiz Content application to implement Help, then it is free to do so.
>
+1
We should be able to very easily override help content.
> -Adrian
>
Re: OFBIZ-4941
Posted by Jacques Le Roux <ja...@les7arts.com>.
When I look at the current state of the wiki I tend to agree with Tom...
Jacques
From: "Tom" <tr...@yahoo.com>
> Adrian,
>
> Your example may not depend on another component but is did depend on a file
> that was outside of the OFBiz app control and broke when that file changed.
> This will never happen in the proposed solution. All files for a webapp are
> generated from a single docbook file so there are no external dependencies.
>
> You can have external links in the webhelp files and there are examples in
> the current upload. In the solution each locale has it's own file and would
> point to an appropriate external reference for that locale. Naturally if
> that external reference changes the link will break.
>
> I searched the trunk for http in *UiLabels.xml and there are 120 matches. I
> found only one of them that references more then one locale
> (CommonUiLabels.xml CommonLookupAnywhoLink), so as a practical matter this
> is a solution that has not been used very much.
>
> Help in the proposed system is at the webapp level. UiLabels are more (and I
> would argue too) fine grained for screen level context help. UI labels can
> be used any where pointing to any thing. It would be very hard to maintain a
> coherent help system using all the fragmented files that could spring from
> labels.
>
> This is not to say that there is not a place for labels in cases like
> CommonLookupAnywhoLink. The two mechanisms can co-exist but I think they
> serve different purposes. A system like webhelp is better suited for
> creating help documents for which it was designed while UiLabels were
> designed for the purpose of providing i18n support for lables.
>
> Tom
>
>
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/OFBIZ-4941-tp4637418p4637442.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: OFBIZ-4941
Posted by Tom <tr...@yahoo.com>.
Adrian,
Your example may not depend on another component but is did depend on a file
that was outside of the OFBiz app control and broke when that file changed.
This will never happen in the proposed solution. All files for a webapp are
generated from a single docbook file so there are no external dependencies.
You can have external links in the webhelp files and there are examples in
the current upload. In the solution each locale has it's own file and would
point to an appropriate external reference for that locale. Naturally if
that external reference changes the link will break.
I searched the trunk for http in *UiLabels.xml and there are 120 matches. I
found only one of them that references more then one locale
(CommonUiLabels.xml CommonLookupAnywhoLink), so as a practical matter this
is a solution that has not been used very much.
Help in the proposed system is at the webapp level. UiLabels are more (and I
would argue too) fine grained for screen level context help. UI labels can
be used any where pointing to any thing. It would be very hard to maintain a
coherent help system using all the fragmented files that could spring from
labels.
This is not to say that there is not a place for labels in cases like
CommonLookupAnywhoLink. The two mechanisms can co-exist but I think they
serve different purposes. A system like webhelp is better suited for
creating help documents for which it was designed while UiLabels were
designed for the purpose of providing i18n support for lables.
Tom
--
View this message in context: http://ofbiz.135035.n4.nabble.com/OFBIZ-4941-tp4637418p4637442.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: OFBIZ-4941
Posted by Adrian Crum <ad...@sandglass-software.com>.
On 11/10/2012 6:07 PM, Jacques Le Roux wrote:
> From: "Adrian Crum" <ad...@sandglass-software.com>
>> On 11/10/2012 1:48 PM, Jacopo Cappellato wrote:
>>> Thank you Jacques,
>>>
>>> here is some quick feedback after a review of the patch.
>>>
>>> A) all the code in framework/images/webapp/images/fieldlookup.js is bad because contains hardcoded application/components
>>>
>>> B) what is this?
>>>
>>> Index: specialpurpose/birt/ofbiz-component.xml
>>> ===================================================================
>>> --- specialpurpose/birt/ofbiz-component.xml (revision 1407381)
>>> +++ specialpurpose/birt/ofbiz-component.xml (working copy)
>>> @@ -29,7 +29,6 @@
>>> <entity-resource type="data" reader-name="seed" loader="main" location="data/OrderPortletData.xml"/>
>>> <service-resource type="model" loader="main" location="servicedef/services.xml"/>
>>>
>>> - <!-- use when reports need to be injected into applications Note: this will break context help for those applications.
>>> <webapp name="accounting"
>>> title="Accounting"
>>> server="default-server"
>>> @@ -50,7 +49,6 @@
>>> location="webapp/ordermgr"
>>> base-permission="OFBTOOLS,ORDERMGR"
>>> mount-point="/ordermgr"/>
>>> - -->
>>> <webapp name="birt"
>>> title="BIRT"
>>> server="default-server"
>>>
>>> C) I still think it is a bad idea to add dependencies to the content component on other applications like: applications/content/webapp/ofbizhelp/catalog_en
>>>
>>> D) did you check the compliance with licenses? See this for example:
>>>
>>> +/*----------------------------------------------------------------------------
>>> + * JavaScript for webhelp search
>>> + *----------------------------------------------------------------------------
>>> + This file is part of the webhelpsearch plugin for DocBook WebHelp
>>> + Copyright (c) 2007-2008 NexWave Solutions All Rights Reserved.
>>> + www.nexwave.biz Nadege Quaine
>>> + http://kasunbg.blogspot.com/ Kasun Gajasinghe
>>> + */
>>>
>>> E) how was generated the content of (for example):
>>>
>>> Index: applications/content/webapp/ofbizhelp/catalog_en/content/search/htmlFileInfoList.js
>>>
>>> ? How should we maintain it?
>>>
>>> F) why this:
>>>
>>> applications/content/webapp/ofbizhelp/catalog_en/common/jquery/jquery-1.4.2.min.js
>>>
>>> ?
>>>
>>> I think it is enough for now, but the changes are big and I couldn't review everything.
>>>
>>> In general, my preference would be to see this type of contribution being implemented as a pluggable feature (with data mainatined externally in Confluence or in a specialpurpose or extra component) rather than being part of the trunk.
>> Thanks Jacopo.
>>
>> This has been my position all along. Help links should point to a URL
>> that is retrieved from the UI labels file (to support i18n). That way
>> Help content can be located anywhere - inside or outside OFBiz. If an
>> application wants to use the OFBiz Content application to implement
>> Help, then it is free to do so.
>>
>> -Adrian
> Could you elaborate a bit more Adrian? You mean to put links/URLs in UI label files?
> How this would relate to the current WIP for the new help?
See WorkEffortUiLabels.xml, key="WorkEffortICalendarHelpUrl". The link
doesn't work any more because the Wiki site changed, and I can't find
the new page. But when it was working, iCalendar help was retrieved from
the Wiki site. This arrangement did not create any dependencies on any
other components.
-Adrian
Re: OFBIZ-4941
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "Adrian Crum" <ad...@sandglass-software.com>
> On 11/10/2012 1:48 PM, Jacopo Cappellato wrote:
>> Thank you Jacques,
>>
>> here is some quick feedback after a review of the patch.
>>
>> A) all the code in framework/images/webapp/images/fieldlookup.js is bad because contains hardcoded application/components
>>
>> B) what is this?
>>
>> Index: specialpurpose/birt/ofbiz-component.xml
>> ===================================================================
>> --- specialpurpose/birt/ofbiz-component.xml (revision 1407381)
>> +++ specialpurpose/birt/ofbiz-component.xml (working copy)
>> @@ -29,7 +29,6 @@
>> <entity-resource type="data" reader-name="seed" loader="main" location="data/OrderPortletData.xml"/>
>> <service-resource type="model" loader="main" location="servicedef/services.xml"/>
>>
>> - <!-- use when reports need to be injected into applications Note: this will break context help for those applications.
>> <webapp name="accounting"
>> title="Accounting"
>> server="default-server"
>> @@ -50,7 +49,6 @@
>> location="webapp/ordermgr"
>> base-permission="OFBTOOLS,ORDERMGR"
>> mount-point="/ordermgr"/>
>> - -->
>> <webapp name="birt"
>> title="BIRT"
>> server="default-server"
>>
>> C) I still think it is a bad idea to add dependencies to the content component on other applications like: applications/content/webapp/ofbizhelp/catalog_en
>>
>> D) did you check the compliance with licenses? See this for example:
>>
>> +/*----------------------------------------------------------------------------
>> + * JavaScript for webhelp search
>> + *----------------------------------------------------------------------------
>> + This file is part of the webhelpsearch plugin for DocBook WebHelp
>> + Copyright (c) 2007-2008 NexWave Solutions All Rights Reserved.
>> + www.nexwave.biz Nadege Quaine
>> + http://kasunbg.blogspot.com/ Kasun Gajasinghe
>> + */
>>
>> E) how was generated the content of (for example):
>>
>> Index: applications/content/webapp/ofbizhelp/catalog_en/content/search/htmlFileInfoList.js
>>
>> ? How should we maintain it?
>>
>> F) why this:
>>
>> applications/content/webapp/ofbizhelp/catalog_en/common/jquery/jquery-1.4.2.min.js
>>
>> ?
>>
>> I think it is enough for now, but the changes are big and I couldn't review everything.
>>
>> In general, my preference would be to see this type of contribution being implemented as a pluggable feature (with data mainatined externally in Confluence or in a specialpurpose or extra component) rather than being part of the trunk.
>
> Thanks Jacopo.
>
> This has been my position all along. Help links should point to a URL
> that is retrieved from the UI labels file (to support i18n). That way
> Help content can be located anywhere - inside or outside OFBiz. If an
> application wants to use the OFBiz Content application to implement
> Help, then it is free to do so.
>
> -Adrian
Could you elaborate a bit more Adrian? You mean to put links/URLs in UI label files?
How this would relate to the current WIP for the new help?
Jacques
Re: OFBIZ-4941
Posted by Adrian Crum <ad...@sandglass-software.com>.
On 11/10/2012 1:48 PM, Jacopo Cappellato wrote:
> Thank you Jacques,
>
> here is some quick feedback after a review of the patch.
>
> A) all the code in framework/images/webapp/images/fieldlookup.js is bad because contains hardcoded application/components
>
> B) what is this?
>
> Index: specialpurpose/birt/ofbiz-component.xml
> ===================================================================
> --- specialpurpose/birt/ofbiz-component.xml (revision 1407381)
> +++ specialpurpose/birt/ofbiz-component.xml (working copy)
> @@ -29,7 +29,6 @@
> <entity-resource type="data" reader-name="seed" loader="main" location="data/OrderPortletData.xml"/>
> <service-resource type="model" loader="main" location="servicedef/services.xml"/>
>
> - <!-- use when reports need to be injected into applications Note: this will break context help for those applications.
> <webapp name="accounting"
> title="Accounting"
> server="default-server"
> @@ -50,7 +49,6 @@
> location="webapp/ordermgr"
> base-permission="OFBTOOLS,ORDERMGR"
> mount-point="/ordermgr"/>
> - -->
> <webapp name="birt"
> title="BIRT"
> server="default-server"
>
> C) I still think it is a bad idea to add dependencies to the content component on other applications like: applications/content/webapp/ofbizhelp/catalog_en
>
> D) did you check the compliance with licenses? See this for example:
>
> +/*----------------------------------------------------------------------------
> + * JavaScript for webhelp search
> + *----------------------------------------------------------------------------
> + This file is part of the webhelpsearch plugin for DocBook WebHelp
> + Copyright (c) 2007-2008 NexWave Solutions All Rights Reserved.
> + www.nexwave.biz Nadege Quaine
> + http://kasunbg.blogspot.com/ Kasun Gajasinghe
> + */
>
> E) how was generated the content of (for example):
>
> Index: applications/content/webapp/ofbizhelp/catalog_en/content/search/htmlFileInfoList.js
>
> ? How should we maintain it?
>
> F) why this:
>
> applications/content/webapp/ofbizhelp/catalog_en/common/jquery/jquery-1.4.2.min.js
>
> ?
>
> I think it is enough for now, but the changes are big and I couldn't review everything.
>
> In general, my preference would be to see this type of contribution being implemented as a pluggable feature (with data mainatined externally in Confluence or in a specialpurpose or extra component) rather than being part of the trunk.
Thanks Jacopo.
This has been my position all along. Help links should point to a URL
that is retrieved from the UI labels file (to support i18n). That way
Help content can be located anywhere - inside or outside OFBiz. If an
application wants to use the OFBiz Content application to implement
Help, then it is free to do so.
-Adrian
Re: OFBIZ-4941
Posted by Hans Bakker <ma...@antwebsystems.com>.
reason: moving anything to special purpose will finally move to extra's
to which i completely oppose to.
Regards,
Hans
On 11/10/2012 10:22 PM, Hans Bakker wrote:
> -1
>
> On 11/10/2012 09:27 PM, Jacopo Cappellato wrote:
>> Tom's answer doesn't really address Adrian's remark; instead of
>> adding them to "content" I would rather prefer to have a new
>> (specialpurpose/extra) component containing all the help files.
>>
>
Re: OFBIZ-4941
Posted by Hans Bakker <ma...@antwebsystems.com>.
-1
On 11/10/2012 09:27 PM, Jacopo Cappellato wrote:
> Tom's answer doesn't really address Adrian's remark; instead of adding them to "content" I would rather prefer to have a new (specialpurpose/extra) component containing all the help files.
>
Re: OFBIZ-4941
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
> On Nov 10, 2012, at 3:11 PM, Jacques Le Roux wrote:
>
>> Thanks for your help Jacopo,
>>
>> A) Indeed I did not review fieldlookup.js, same type of concern than in C)
>> B) This has been addressed by Tom and is no longer a concern
>
> Do you mean that the code will not be committed?
I commited a change with http://svn.apache.org/viewvc?view=revision&revision=1400463
<<jleroux: while checking I found also an error in birt/documents/Birt.xml and while at it I also commit a tiny part of OFBIZ-4941 in birt/ofbiz-component.xml because it breaks the help.>>
Tom's new help address this concern and we can remove the comments in this part, yes this part of the code will be committed if we finally agree about it. It already used some part of my time, but I think it's worth it on the long term...
>> C) Yes this is the moot point, Tom gave some arguments in https://issues.apache.org/jira/browse/OFBIZ-4941?focusedCommentId=13494044&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13494044
>
> Tom's answer doesn't really address Adrian's remark; instead of adding them to "content" I would rather prefer to have a new (specialpurpose/extra) component containing all the help files.
Extra does not fit: this is supposed to replace the old help and should stay as part of OFBiz OOTB. I'm not against a specialpurpose help component, if content component is not mandatory for building the help...
>> D) Yes it's totally OK from a license POV
>
> I don't see the updates to the LICENSE file in your patch... these changes will help me to better understand how the files are treated from a licensing point of view
Right, I did not address that yet, should be straightforward
Jacques
> Kind regards,
>
> Jacopo
>
>>
>> Jacques
>>
>> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>>> Thank you Jacques,
>>>
>>> here is some quick feedback after a review of the patch.
>>>
>>> A) all the code in framework/images/webapp/images/fieldlookup.js is bad because contains hardcoded application/components
>>>
>>> B) what is this?
>>>
>>> Index: specialpurpose/birt/ofbiz-component.xml
>>> ===================================================================
>>> --- specialpurpose/birt/ofbiz-component.xml (revision 1407381)
>>> +++ specialpurpose/birt/ofbiz-component.xml (working copy)
>>> @@ -29,7 +29,6 @@
>>> <entity-resource type="data" reader-name="seed" loader="main" location="data/OrderPortletData.xml"/>
>>> <service-resource type="model" loader="main" location="servicedef/services.xml"/>
>>>
>>> - <!-- use when reports need to be injected into applications Note: this will break context help for those applications.
>>> <webapp name="accounting"
>>> title="Accounting"
>>> server="default-server"
>>> @@ -50,7 +49,6 @@
>>> location="webapp/ordermgr"
>>> base-permission="OFBTOOLS,ORDERMGR"
>>> mount-point="/ordermgr"/>
>>> - -->
>>> <webapp name="birt"
>>> title="BIRT"
>>> server="default-server"
>>>
>>> C) I still think it is a bad idea to add dependencies to the content component on other applications like: applications/content/webapp/ofbizhelp/catalog_en
>>>
>>> D) did you check the compliance with licenses? See this for example:
>>>
>>> +/*----------------------------------------------------------------------------
>>> + * JavaScript for webhelp search
>>> + *----------------------------------------------------------------------------
>>> + This file is part of the webhelpsearch plugin for DocBook WebHelp
>>> + Copyright (c) 2007-2008 NexWave Solutions All Rights Reserved.
>>> + www.nexwave.biz Nadege Quaine
>>> + http://kasunbg.blogspot.com/ Kasun Gajasinghe
>>> + */
>>>
>>> E) how was generated the content of (for example):
>>>
>>> Index: applications/content/webapp/ofbizhelp/catalog_en/content/search/htmlFileInfoList.js
>>>
>>> ? How should we maintain it?
>>>
>>> F) why this:
>>>
>>> applications/content/webapp/ofbizhelp/catalog_en/common/jquery/jquery-1.4.2.min.js
>>>
>>> ?
>>>
>>> I think it is enough for now, but the changes are big and I couldn't review everything.
>>>
>>> In general, my preference would be to see this type of contribution being implemented as a pluggable feature (with data mainatined externally in Confluence or in a specialpurpose or extra component) rather than being part of the trunk.
>>>
>>> Kind regards,
>>>
>>> Jacopo
>>>
>>>
>>> On Nov 10, 2012, at 12:44 PM, Jacques Le Roux wrote:
>>>
>>>> The 4/5 last comments are enough to read, before were mostly exchange between Tom and I. Adrian's concern is addressed in those last comments.
>>>> I have just attache a OFBIZ-4941.patch corresponding to what will be actually committed. This will replace the current help system and will be completed by Tom. He clearly said that he is committed to finish the work, and I trust him: most is done already.
>>>>
>>>> In doubt, sorting attachments by date helps.
>>>>
>>>> Thanks for your comments and opinion :)
>>>>
>>>> Jacques
>>>>
>>>> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>>>>> The log history is huge and messed up and there are several files attached to the Jira task: this makes it difficult to review the work that you would like to commit.
>>>>> Having a summary of the code that is going to be contributed and a final list of files/diffs would help me to take a decision... but hopefully others have been more involved in the details to express their opinion; are you also going to remove the existing help system or this new one will be added as an alternative option? In my opinion we can't have the luxury to maintain two help systems in OFBiz.
>>>>>
>>>>> Kind regards,
>>>>>
>>>>> Jacopo
>>>>>
>>>>>
>>>>> On Nov 10, 2012, at 12:17 PM, Jacques Le Roux wrote:
>>>>>
>>>>>> If nobody disagree I will commit https://issues.apache.org/jira/browse/OFBIZ-4941 soon
>>>>>>
>>>>>> Jacques
>>>>>
>>>>>
>>>
>>>
>
>
Re: OFBIZ-4941
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On Nov 10, 2012, at 3:11 PM, Jacques Le Roux wrote:
> Thanks for your help Jacopo,
>
> A) Indeed I did not review fieldlookup.js, same type of concern than in C)
> B) This has been addressed by Tom and is no longer a concern
Do you mean that the code will not be committed?
> C) Yes this is the moot point, Tom gave some arguments in https://issues.apache.org/jira/browse/OFBIZ-4941?focusedCommentId=13494044&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13494044
Tom's answer doesn't really address Adrian's remark; instead of adding them to "content" I would rather prefer to have a new (specialpurpose/extra) component containing all the help files.
> D) Yes it's totally OK from a license POV
I don't see the updates to the LICENSE file in your patch... these changes will help me to better understand how the files are treated from a licensing point of view
Kind regards,
Jacopo
>
> Jacques
>
> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>> Thank you Jacques,
>>
>> here is some quick feedback after a review of the patch.
>>
>> A) all the code in framework/images/webapp/images/fieldlookup.js is bad because contains hardcoded application/components
>>
>> B) what is this?
>>
>> Index: specialpurpose/birt/ofbiz-component.xml
>> ===================================================================
>> --- specialpurpose/birt/ofbiz-component.xml (revision 1407381)
>> +++ specialpurpose/birt/ofbiz-component.xml (working copy)
>> @@ -29,7 +29,6 @@
>> <entity-resource type="data" reader-name="seed" loader="main" location="data/OrderPortletData.xml"/>
>> <service-resource type="model" loader="main" location="servicedef/services.xml"/>
>>
>> - <!-- use when reports need to be injected into applications Note: this will break context help for those applications.
>> <webapp name="accounting"
>> title="Accounting"
>> server="default-server"
>> @@ -50,7 +49,6 @@
>> location="webapp/ordermgr"
>> base-permission="OFBTOOLS,ORDERMGR"
>> mount-point="/ordermgr"/>
>> - -->
>> <webapp name="birt"
>> title="BIRT"
>> server="default-server"
>>
>> C) I still think it is a bad idea to add dependencies to the content component on other applications like: applications/content/webapp/ofbizhelp/catalog_en
>>
>> D) did you check the compliance with licenses? See this for example:
>>
>> +/*----------------------------------------------------------------------------
>> + * JavaScript for webhelp search
>> + *----------------------------------------------------------------------------
>> + This file is part of the webhelpsearch plugin for DocBook WebHelp
>> + Copyright (c) 2007-2008 NexWave Solutions All Rights Reserved.
>> + www.nexwave.biz Nadege Quaine
>> + http://kasunbg.blogspot.com/ Kasun Gajasinghe
>> + */
>>
>> E) how was generated the content of (for example):
>>
>> Index: applications/content/webapp/ofbizhelp/catalog_en/content/search/htmlFileInfoList.js
>>
>> ? How should we maintain it?
>>
>> F) why this:
>>
>> applications/content/webapp/ofbizhelp/catalog_en/common/jquery/jquery-1.4.2.min.js
>>
>> ?
>>
>> I think it is enough for now, but the changes are big and I couldn't review everything.
>>
>> In general, my preference would be to see this type of contribution being implemented as a pluggable feature (with data mainatined externally in Confluence or in a specialpurpose or extra component) rather than being part of the trunk.
>>
>> Kind regards,
>>
>> Jacopo
>>
>>
>> On Nov 10, 2012, at 12:44 PM, Jacques Le Roux wrote:
>>
>>> The 4/5 last comments are enough to read, before were mostly exchange between Tom and I. Adrian's concern is addressed in those last comments.
>>> I have just attache a OFBIZ-4941.patch corresponding to what will be actually committed. This will replace the current help system and will be completed by Tom. He clearly said that he is committed to finish the work, and I trust him: most is done already.
>>>
>>> In doubt, sorting attachments by date helps.
>>>
>>> Thanks for your comments and opinion :)
>>>
>>> Jacques
>>>
>>> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>>>> The log history is huge and messed up and there are several files attached to the Jira task: this makes it difficult to review the work that you would like to commit.
>>>> Having a summary of the code that is going to be contributed and a final list of files/diffs would help me to take a decision... but hopefully others have been more involved in the details to express their opinion; are you also going to remove the existing help system or this new one will be added as an alternative option? In my opinion we can't have the luxury to maintain two help systems in OFBiz.
>>>>
>>>> Kind regards,
>>>>
>>>> Jacopo
>>>>
>>>>
>>>> On Nov 10, 2012, at 12:17 PM, Jacques Le Roux wrote:
>>>>
>>>>> If nobody disagree I will commit https://issues.apache.org/jira/browse/OFBIZ-4941 soon
>>>>>
>>>>> Jacques
>>>>
>>>>
>>
>>
Re: OFBIZ-4941
Posted by Jacques Le Roux <ja...@les7arts.com>.
Oops I missed points after D), I will answer to them now
E) It's copied by the xsl transformation from applications/content/template/docbook/webhelp/docs/content/search/htmlFileInfoList.js wich is. actually part of Docbook version 1.77.1 (committed at r1395307)
So maintenance worries
F) it's also part of the Docbook version 1.77.1
From: "Jacques Le Roux" <ja...@les7arts.com>
> Thanks for your help Jacopo,
>
> A) Indeed I did not review fieldlookup.js, same type of concern than in C)
> B) This has been addressed by Tom and is no longer a concern
> C) Yes this is the moot point, Tom gave some arguments in https://issues.apache.org/jira/browse/OFBIZ-4941?focusedCommentId=13494044&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13494044
> D) Yes it's totally OK from a license POV
>
> Jacques
>
> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>> Thank you Jacques,
>>
>> here is some quick feedback after a review of the patch.
>>
>> A) all the code in framework/images/webapp/images/fieldlookup.js is bad because contains hardcoded application/components
>>
>> B) what is this?
>>
>> Index: specialpurpose/birt/ofbiz-component.xml
>> ===================================================================
>> --- specialpurpose/birt/ofbiz-component.xml (revision 1407381)
>> +++ specialpurpose/birt/ofbiz-component.xml (working copy)
>> @@ -29,7 +29,6 @@
>> <entity-resource type="data" reader-name="seed" loader="main" location="data/OrderPortletData.xml"/>
>> <service-resource type="model" loader="main" location="servicedef/services.xml"/>
>>
>> - <!-- use when reports need to be injected into applications Note: this will break context help for those applications.
>> <webapp name="accounting"
>> title="Accounting"
>> server="default-server"
>> @@ -50,7 +49,6 @@
>> location="webapp/ordermgr"
>> base-permission="OFBTOOLS,ORDERMGR"
>> mount-point="/ordermgr"/>
>> - -->
>> <webapp name="birt"
>> title="BIRT"
>> server="default-server"
>>
>> C) I still think it is a bad idea to add dependencies to the content component on other applications like: applications/content/webapp/ofbizhelp/catalog_en
>>
>> D) did you check the compliance with licenses? See this for example:
>>
>> +/*----------------------------------------------------------------------------
>> + * JavaScript for webhelp search
>> + *----------------------------------------------------------------------------
>> + This file is part of the webhelpsearch plugin for DocBook WebHelp
>> + Copyright (c) 2007-2008 NexWave Solutions All Rights Reserved.
>> + www.nexwave.biz Nadege Quaine
>> + http://kasunbg.blogspot.com/ Kasun Gajasinghe
>> + */
>>
>> E) how was generated the content of (for example):
>>
>> Index: applications/content/webapp/ofbizhelp/catalog_en/content/search/htmlFileInfoList.js
>>
>> ? How should we maintain it?
>>
>> F) why this:
>>
>> applications/content/webapp/ofbizhelp/catalog_en/common/jquery/jquery-1.4.2.min.js
>>
>> ?
>>
>> I think it is enough for now, but the changes are big and I couldn't review everything.
>>
>> In general, my preference would be to see this type of contribution being implemented as a pluggable feature (with data mainatined externally in Confluence or in a specialpurpose or extra component) rather than being part of the trunk.
>>
>> Kind regards,
>>
>> Jacopo
>>
>>
>> On Nov 10, 2012, at 12:44 PM, Jacques Le Roux wrote:
>>
>>> The 4/5 last comments are enough to read, before were mostly exchange between Tom and I. Adrian's concern is addressed in those last comments.
>>> I have just attache a OFBIZ-4941.patch corresponding to what will be actually committed. This will replace the current help system and will be completed by Tom. He clearly said that he is committed to finish the work, and I trust him: most is done already.
>>>
>>> In doubt, sorting attachments by date helps.
>>>
>>> Thanks for your comments and opinion :)
>>>
>>> Jacques
>>>
>>> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>>>> The log history is huge and messed up and there are several files attached to the Jira task: this makes it difficult to review the work that you would like to commit.
>>>> Having a summary of the code that is going to be contributed and a final list of files/diffs would help me to take a decision... but hopefully others have been more involved in the details to express their opinion; are you also going to remove the existing help system or this new one will be added as an alternative option? In my opinion we can't have the luxury to maintain two help systems in OFBiz.
>>>>
>>>> Kind regards,
>>>>
>>>> Jacopo
>>>>
>>>>
>>>> On Nov 10, 2012, at 12:17 PM, Jacques Le Roux wrote:
>>>>
>>>>> If nobody disagree I will commit https://issues.apache.org/jira/browse/OFBIZ-4941 soon
>>>>>
>>>>> Jacques
>>>>
>>>>
>>
>>
>
Re: OFBIZ-4941
Posted by Jacques Le Roux <ja...@les7arts.com>.
Thanks for your help Jacopo,
A) Indeed I did not review fieldlookup.js, same type of concern than in C)
B) This has been addressed by Tom and is no longer a concern
C) Yes this is the moot point, Tom gave some arguments in https://issues.apache.org/jira/browse/OFBIZ-4941?focusedCommentId=13494044&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13494044
D) Yes it's totally OK from a license POV
Jacques
From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
> Thank you Jacques,
>
> here is some quick feedback after a review of the patch.
>
> A) all the code in framework/images/webapp/images/fieldlookup.js is bad because contains hardcoded application/components
>
> B) what is this?
>
> Index: specialpurpose/birt/ofbiz-component.xml
> ===================================================================
> --- specialpurpose/birt/ofbiz-component.xml (revision 1407381)
> +++ specialpurpose/birt/ofbiz-component.xml (working copy)
> @@ -29,7 +29,6 @@
> <entity-resource type="data" reader-name="seed" loader="main" location="data/OrderPortletData.xml"/>
> <service-resource type="model" loader="main" location="servicedef/services.xml"/>
>
> - <!-- use when reports need to be injected into applications Note: this will break context help for those applications.
> <webapp name="accounting"
> title="Accounting"
> server="default-server"
> @@ -50,7 +49,6 @@
> location="webapp/ordermgr"
> base-permission="OFBTOOLS,ORDERMGR"
> mount-point="/ordermgr"/>
> - -->
> <webapp name="birt"
> title="BIRT"
> server="default-server"
>
> C) I still think it is a bad idea to add dependencies to the content component on other applications like: applications/content/webapp/ofbizhelp/catalog_en
>
> D) did you check the compliance with licenses? See this for example:
>
> +/*----------------------------------------------------------------------------
> + * JavaScript for webhelp search
> + *----------------------------------------------------------------------------
> + This file is part of the webhelpsearch plugin for DocBook WebHelp
> + Copyright (c) 2007-2008 NexWave Solutions All Rights Reserved.
> + www.nexwave.biz Nadege Quaine
> + http://kasunbg.blogspot.com/ Kasun Gajasinghe
> + */
>
> E) how was generated the content of (for example):
>
> Index: applications/content/webapp/ofbizhelp/catalog_en/content/search/htmlFileInfoList.js
>
> ? How should we maintain it?
>
> F) why this:
>
> applications/content/webapp/ofbizhelp/catalog_en/common/jquery/jquery-1.4.2.min.js
>
> ?
>
> I think it is enough for now, but the changes are big and I couldn't review everything.
>
> In general, my preference would be to see this type of contribution being implemented as a pluggable feature (with data mainatined externally in Confluence or in a specialpurpose or extra component) rather than being part of the trunk.
>
> Kind regards,
>
> Jacopo
>
>
> On Nov 10, 2012, at 12:44 PM, Jacques Le Roux wrote:
>
>> The 4/5 last comments are enough to read, before were mostly exchange between Tom and I. Adrian's concern is addressed in those last comments.
>> I have just attache a OFBIZ-4941.patch corresponding to what will be actually committed. This will replace the current help system and will be completed by Tom. He clearly said that he is committed to finish the work, and I trust him: most is done already.
>>
>> In doubt, sorting attachments by date helps.
>>
>> Thanks for your comments and opinion :)
>>
>> Jacques
>>
>> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>>> The log history is huge and messed up and there are several files attached to the Jira task: this makes it difficult to review the work that you would like to commit.
>>> Having a summary of the code that is going to be contributed and a final list of files/diffs would help me to take a decision... but hopefully others have been more involved in the details to express their opinion; are you also going to remove the existing help system or this new one will be added as an alternative option? In my opinion we can't have the luxury to maintain two help systems in OFBiz.
>>>
>>> Kind regards,
>>>
>>> Jacopo
>>>
>>>
>>> On Nov 10, 2012, at 12:17 PM, Jacques Le Roux wrote:
>>>
>>>> If nobody disagree I will commit https://issues.apache.org/jira/browse/OFBIZ-4941 soon
>>>>
>>>> Jacques
>>>
>>>
>
>
Re: OFBIZ-4941
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
Thank you Jacques,
here is some quick feedback after a review of the patch.
A) all the code in framework/images/webapp/images/fieldlookup.js is bad because contains hardcoded application/components
B) what is this?
Index: specialpurpose/birt/ofbiz-component.xml
===================================================================
--- specialpurpose/birt/ofbiz-component.xml (revision 1407381)
+++ specialpurpose/birt/ofbiz-component.xml (working copy)
@@ -29,7 +29,6 @@
<entity-resource type="data" reader-name="seed" loader="main" location="data/OrderPortletData.xml"/>
<service-resource type="model" loader="main" location="servicedef/services.xml"/>
- <!-- use when reports need to be injected into applications Note: this will break context help for those applications.
<webapp name="accounting"
title="Accounting"
server="default-server"
@@ -50,7 +49,6 @@
location="webapp/ordermgr"
base-permission="OFBTOOLS,ORDERMGR"
mount-point="/ordermgr"/>
- -->
<webapp name="birt"
title="BIRT"
server="default-server"
C) I still think it is a bad idea to add dependencies to the content component on other applications like: applications/content/webapp/ofbizhelp/catalog_en
D) did you check the compliance with licenses? See this for example:
+/*----------------------------------------------------------------------------
+ * JavaScript for webhelp search
+ *----------------------------------------------------------------------------
+ This file is part of the webhelpsearch plugin for DocBook WebHelp
+ Copyright (c) 2007-2008 NexWave Solutions All Rights Reserved.
+ www.nexwave.biz Nadege Quaine
+ http://kasunbg.blogspot.com/ Kasun Gajasinghe
+ */
E) how was generated the content of (for example):
Index: applications/content/webapp/ofbizhelp/catalog_en/content/search/htmlFileInfoList.js
? How should we maintain it?
F) why this:
applications/content/webapp/ofbizhelp/catalog_en/common/jquery/jquery-1.4.2.min.js
?
I think it is enough for now, but the changes are big and I couldn't review everything.
In general, my preference would be to see this type of contribution being implemented as a pluggable feature (with data mainatined externally in Confluence or in a specialpurpose or extra component) rather than being part of the trunk.
Kind regards,
Jacopo
On Nov 10, 2012, at 12:44 PM, Jacques Le Roux wrote:
> The 4/5 last comments are enough to read, before were mostly exchange between Tom and I. Adrian's concern is addressed in those last comments.
> I have just attache a OFBIZ-4941.patch corresponding to what will be actually committed. This will replace the current help system and will be completed by Tom. He clearly said that he is committed to finish the work, and I trust him: most is done already.
>
> In doubt, sorting attachments by date helps.
>
> Thanks for your comments and opinion :)
>
> Jacques
>
> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>> The log history is huge and messed up and there are several files attached to the Jira task: this makes it difficult to review the work that you would like to commit.
>> Having a summary of the code that is going to be contributed and a final list of files/diffs would help me to take a decision... but hopefully others have been more involved in the details to express their opinion; are you also going to remove the existing help system or this new one will be added as an alternative option? In my opinion we can't have the luxury to maintain two help systems in OFBiz.
>>
>> Kind regards,
>>
>> Jacopo
>>
>>
>> On Nov 10, 2012, at 12:17 PM, Jacques Le Roux wrote:
>>
>>> If nobody disagree I will commit https://issues.apache.org/jira/browse/OFBIZ-4941 soon
>>>
>>> Jacques
>>
>>
Re: OFBIZ-4941
Posted by Jacques Le Roux <ja...@les7arts.com>.
The 4/5 last comments are enough to read, before were mostly exchange between Tom and I. Adrian's concern is addressed in those last comments.
I have just attache a OFBIZ-4941.patch corresponding to what will be actually committed. This will replace the current help system and will be completed by Tom. He clearly said that he is committed to finish the work, and I trust him: most is done already.
In doubt, sorting attachments by date helps.
Thanks for your comments and opinion :)
Jacques
From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
> The log history is huge and messed up and there are several files attached to the Jira task: this makes it difficult to review the work that you would like to commit.
> Having a summary of the code that is going to be contributed and a final list of files/diffs would help me to take a decision... but hopefully others have been more involved in the details to express their opinion; are you also going to remove the existing help system or this new one will be added as an alternative option? In my opinion we can't have the luxury to maintain two help systems in OFBiz.
>
> Kind regards,
>
> Jacopo
>
>
> On Nov 10, 2012, at 12:17 PM, Jacques Le Roux wrote:
>
>> If nobody disagree I will commit https://issues.apache.org/jira/browse/OFBIZ-4941 soon
>>
>> Jacques
>
>
Re: OFBIZ-4941
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
The log history is huge and messed up and there are several files attached to the Jira task: this makes it difficult to review the work that you would like to commit.
Having a summary of the code that is going to be contributed and a final list of files/diffs would help me to take a decision... but hopefully others have been more involved in the details to express their opinion; are you also going to remove the existing help system or this new one will be added as an alternative option? In my opinion we can't have the luxury to maintain two help systems in OFBiz.
Kind regards,
Jacopo
On Nov 10, 2012, at 12:17 PM, Jacques Le Roux wrote:
> If nobody disagree I will commit https://issues.apache.org/jira/browse/OFBIZ-4941 soon
>
> Jacques