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 <jacques.le.r...@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" <jacques.le.r...@les7arts.com> >> From: "Jacopo Cappellato" <jacopo.cappell...@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
