portletWidget branch is ready to merge to trunk
Locked
portletWidget branch is ready to merge to trunk
 
|
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 |
Re: portletWidget branch is ready to merge to trunk
|
|
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 > |
Re: portletWidget branch is ready to merge to trunk
|
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 >> > |
Re: portletWidget branch is ready to merge to trunk
Administrator
|
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" <[hidden email]> > 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 >>> >> > > |
Re: portletWidget branch is ready to merge to trunk
|
|
In reply to this post by Scott Gray-2
Le 14/11/2012 21:36, Scott Gray a écrit :
> 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. Main point are in JIRA https://issues.apache.org/jira/browse/OFBIZ-4742 and in sub Jira and there are a lot of details included in ofbiz help as development help > 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 >>> > |
Re: portletWidget branch is ready to merge to trunk
|
|
In reply to this post by Jacques Le Roux
Both of these implementations require a thorough design review before being committed IMO. I'm willing to help with this but my time is limited so I wouldn't expect it to be done very quickly. I would ask you not to commit anything until someone other than yourself or Erwan have had an opportunity to review though.
Many thanks Scott On 15/11/2012, at 11:18 AM, Jacques Le Roux wrote: > 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" <[hidden email]> >> 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 >>>> >>> >> >> |
Re: portletWidget branch is ready to merge to trunk
|
Administrator
|
Sure that seems better for the project indeed. Actually I'd expect more people to be involved in such efforts before we commit and then found it's not done the right way...
Jacques From: "Scott Gray" <[hidden email]> > Both of these implementations require a thorough design review before being committed IMO. I'm willing to help with this but my time is limited so I wouldn't expect it to be done very quickly. I would ask you not to commit anything until someone other than yourself or Erwan have had an opportunity to review though. > > Many thanks > Scott > > On 15/11/2012, at 11:18 AM, Jacques Le Roux wrote: > >> 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" <[hidden email]> >>> 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 >>>>> >>>> >>> >>> > > |
|
|
Scott,
To save you time I recommend you look at: 1. Requirements and design attached in OFBiz 4941 in helppdf.zip 2. Test implementation at https://54.243.213.35:8443/humanres/control/main where you can perform functional test against the use cases. 3. The code 4. The thread with Q&A on the implementation at http://ofbiz.135035.n4.nabble.com/OFBIZ-4941-tc4637418.html Tom ________________________________ From: Jacques Le Roux <[hidden email]> To: [hidden email] Sent: Thursday, November 15, 2012 2:27 AM Subject: Re: portletWidget branch is ready to merge to trunk Sure that seems better for the project indeed. Actually I'd expect more people to be involved in such efforts before we commit and then found it's not done the right way... Jacques From: "Scott Gray" <[hidden email]> > Both of these implementations require a thorough design review before being committed IMO. I'm willing to help with this but my time is limited so I wouldn't expect it to be done very quickly. I would ask you not to commit anything until someone other than yourself or Erwan have had an opportunity to review though. > > Many thanks > Scott > > On 15/11/2012, at 11:18 AM, Jacques Le Roux wrote: > >> 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" <[hidden email]> >>> 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 >>>>> >>>> >>> >>> > > |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |