Olivier called me tonight, and we had a short discussion about the new help and the merge of the portlet branch. We agreed that we should commit the new help (OFBIZ-4941) before the merge of the portlet branch back to trunk. It should be easier to merge the new help (committed in trunk) in the branch than other side, because there are new help data in the portlet branch (and more stuff related to help).
Tom said it would be hard (but possible) to get data/helpdata/docbookhelp out of content to a new specialpurpose help component. And this could be a 2nd step. All the rest, apart very few new small files in template/docbook/webhelp/, is an update of Doocbook (already in content) and generated new help files. So, to get ahead, I'd like to 1) commit all in content 2) let Tom finishes to transform the current help into new 3) merge the portlet branch 4) move data/helpdata/docbookhelp to a new specialpurpose help component (which will stay OOTB and will not get to extra) (Note: maybe think more about "very few new small files in template/docbook/webhelp"...) What do you think? Thanks Jacques From: "Scott Gray" <scott.g...@hotwaxmedia.com> > Hi Olivier, > > Where can I find some information about this effort? i.e. goals, design, > implementation etc. > > I assume it was discussed or documented somewhere at some point. > > Thanks > Scott > > On 14/11/2012, at 11:09 PM, Olivier Heintz wrote: > >> Hi, >> >> are you ok with this proposition ? >> Erwan is waiting feed back from community before starting Merge. >> >> Olivier >> >> Le 04/11/2012 09:58, Olivier Heintz a écrit : >>> Hi, >>> >>> Most of previously planned job is done on portletWidget. >>> >>> Detail of what is done is in the JIRA sub-task of >>> https://issues.apache.org/jira/browse/OFBIZ-4742 >>> >>> Currently, most of code modifications are prefixed by << #Bam# >>> LabelOfModification >> and suffixed by << #Eam# LabelOfModification >> >>> These comments have been added to facilitate code review or debug if >>> regression is detected for tester. >>> >>> At the user level, it's possible to test >>> A) in the example component, to show portlet works and the "classical >>> Portal page" proposed and by reading help to having detailed on howto >>> use portlet and new show-portlet link. >>> B) in Party, I have migrate all Party Profile screenlet to "new" >>> portlet to give a clear usage of it. There is a new menu entry which is >>> PartyMgmt PortalPage >>> The goal is to replace the current Party Profile Portal page and so >>> remove all screens and forms associated to current screenlet. >>> >>> To be able to have a correct test phase, I propose : >>> 1) to merge branch to trunk >>> 2) users, contributors, maintainers and others use example and Party >>> (and so test) during 1,2 or more weeks >>> 3) corrections and change are done if needed >>> 4) when it seems ok for all I proposed, I will do some JIRA >>> 4.1) to clean all #Bam# and #Eam# >>> 4.2) to clean Screens, Forms, Menus of no more used ofbiz screenlet (to >>> be sure to continue to slim-down ;-) >>> >>> During the test period, I continue some task, like cleaning code related >>> to genericPortlet which is not used >>> >>> Olivier >>> >> > >
