Re: svn commit: r1517434 - in /ofbiz/trunk/framework/widget: src/org/ofbiz/widget/menu/Macr
Locked
Re: svn commit: r1517434 - in /ofbiz/trunk/framework/widget: src/org/ofbiz/widget/menu/Macr
 
|
Hans,
Normally, we report problems on the mailing list, not revert someone else's commit. This was rude and uncalled for. If I did the same thing to your buggy commits, none of your contributions would make it into the project. -Adrian On 8/25/2013 11:28 PM, [hidden email] wrote: > Author: hansbak > Date: Mon Aug 26 06:28:00 2013 > New Revision: 1517434 > > URL: http://svn.apache.org/r1517434 > Log: > revert r1517353: it makes the tomahawk theme unusable > > Removed: > ofbiz/trunk/framework/widget/src/org/ofbiz/widget/menu/MacroMenuRenderer.java > ofbiz/trunk/framework/widget/templates/htmlMenuMacroLibrary.ftl > Modified: > ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java > > Modified: ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java > URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java?rev=1517434&r1=1517433&r2=1517434&view=diff > ============================================================================== > --- ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java (original) > +++ ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java Mon Aug 26 06:28:00 2013 > @@ -38,10 +38,8 @@ import org.ofbiz.webapp.view.AbstractVie > import org.ofbiz.webapp.view.ViewHandlerException; > import org.ofbiz.widget.form.FormStringRenderer; > import org.ofbiz.widget.form.MacroFormRenderer; > -import org.ofbiz.widget.menu.MacroMenuRenderer; > -import org.ofbiz.widget.menu.MenuStringRenderer; > -import org.ofbiz.widget.tree.MacroTreeRenderer; > import org.ofbiz.widget.tree.TreeStringRenderer; > +import org.ofbiz.widget.tree.MacroTreeRenderer; > import org.xml.sax.SAXException; > > import freemarker.template.TemplateException; > @@ -92,13 +90,15 @@ public class MacroScreenViewHandler exte > ScreenStringRenderer screenStringRenderer = new MacroScreenRenderer(UtilProperties.getPropertyValue("widget", getName() + ".name"), UtilProperties.getPropertyValue("widget", getName() + ".screenrenderer")); > FormStringRenderer formStringRenderer = new MacroFormRenderer(UtilProperties.getPropertyValue("widget", getName() + ".formrenderer"), request, response); > TreeStringRenderer treeStringRenderer = new MacroTreeRenderer(UtilProperties.getPropertyValue("widget", getName() + ".treerenderer"), writer); > - MenuStringRenderer menuStringRenderer = new MacroMenuRenderer(UtilProperties.getPropertyValue("widget", getName() + ".menurenderer"), request, response); > + // TODO: uncomment these lines when the renderers are implemented > + //MenuStringRenderer menuStringRenderer = new MacroMenuRenderer(UtilProperties.getPropertyValue("widget", getName() + ".menurenderer"), writer); > > ScreenRenderer screens = new ScreenRenderer(writer, null, screenStringRenderer); > screens.populateContextForRequest(request, response, servletContext); > + // this is the object used to render forms from their definitions > screens.getContext().put("formStringRenderer", formStringRenderer); > screens.getContext().put("treeStringRenderer", treeStringRenderer); > - screens.getContext().put("menuStringRenderer", menuStringRenderer); > + //screens.getContext().put("menuStringRenderer", menuStringRenderer); > screens.getContext().put("simpleEncoder", StringUtil.getEncoder(UtilProperties.getPropertyValue("widget", getName() + ".encoder"))); > screenStringRenderer.renderScreenBegin(writer, screens.getContext()); > screens.render(page); > > |
Re: svn commit: r1517434 - in /ofbiz/trunk/framework/widget: src/org/ofbiz/widget/menu/Macr
Administrator
|
I'd add that using trunk for clients's projects should not be an excuse, you can always revert locally, waiting for a definitive solution...
Jacques Adrian Crum wrote: > Hans, > > Normally, we report problems on the mailing list, not revert someone > else's commit. > > This was rude and uncalled for. If I did the same thing to your buggy > commits, none of your contributions would make it into the project. > > -Adrian > > On 8/25/2013 11:28 PM, [hidden email] wrote: >> Author: hansbak >> Date: Mon Aug 26 06:28:00 2013 >> New Revision: 1517434 >> >> URL: http://svn.apache.org/r1517434 >> Log: >> revert r1517353: it makes the tomahawk theme unusable >> >> Removed: >> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/menu/MacroMenuRenderer.java >> ofbiz/trunk/framework/widget/templates/htmlMenuMacroLibrary.ftl >> Modified: >> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >> >> Modified: ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >> URL: >> http://svn.apache.org/viewvc/ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java?rev=1517434&r1=1517433&r2=1517434&view=diff >> ============================================================================== --- >> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java (original) +++ >> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java Mon Aug 26 06:28:00 2013 @@ -38,10 +38,8 @@ >> import org.ofbiz.webapp.view.AbstractVie import org.ofbiz.webapp.view.ViewHandlerException; >> import org.ofbiz.widget.form.FormStringRenderer; >> import org.ofbiz.widget.form.MacroFormRenderer; >> -import org.ofbiz.widget.menu.MacroMenuRenderer; >> -import org.ofbiz.widget.menu.MenuStringRenderer; >> -import org.ofbiz.widget.tree.MacroTreeRenderer; >> import org.ofbiz.widget.tree.TreeStringRenderer; >> +import org.ofbiz.widget.tree.MacroTreeRenderer; >> import org.xml.sax.SAXException; >> >> import freemarker.template.TemplateException; >> @@ -92,13 +90,15 @@ public class MacroScreenViewHandler exte >> ScreenStringRenderer screenStringRenderer = new MacroScreenRenderer(UtilProperties.getPropertyValue("widget", >> getName() + ".name"), UtilProperties.getPropertyValue("widget", getName() + ".screenrenderer")); >> FormStringRenderer formStringRenderer = new MacroFormRenderer(UtilProperties.getPropertyValue("widget", getName() >> + ".formrenderer"), request, response); TreeStringRenderer treeStringRenderer = new >> MacroTreeRenderer(UtilProperties.getPropertyValue("widget", getName() + ".treerenderer"), writer); - >> MenuStringRenderer menuStringRenderer = new MacroMenuRenderer(UtilProperties.getPropertyValue("widget", getName() + >> ".menurenderer"), request, response); + // TODO: uncomment these lines when the renderers are implemented + >> //MenuStringRenderer menuStringRenderer = new MacroMenuRenderer(UtilProperties.getPropertyValue("widget", getName() + >> ".menurenderer"), writer); >> >> ScreenRenderer screens = new ScreenRenderer(writer, null, screenStringRenderer); >> screens.populateContextForRequest(request, response, servletContext); >> + // this is the object used to render forms from their definitions >> screens.getContext().put("formStringRenderer", formStringRenderer); >> screens.getContext().put("treeStringRenderer", treeStringRenderer); >> - screens.getContext().put("menuStringRenderer", menuStringRenderer); >> + //screens.getContext().put("menuStringRenderer", menuStringRenderer); >> screens.getContext().put("simpleEncoder", StringUtil.getEncoder(UtilProperties.getPropertyValue("widget", >> getName() + ".encoder"))); screenStringRenderer.renderScreenBegin(writer, screens.getContext()); >> screens.render(page); |
Re: svn commit: r1517434 - in /ofbiz/trunk/framework/widget: src/org/ofbiz/widget/menu/Macr
|
|
In reply to this post by Adrian Crum-3
Fixed in rev 1517611.
Not only was this revert unnecessary, the commit message is false. The Tomahawk theme was entirely usable, but one drop-down menu had a slightly broken layout. -Adrian On 8/26/2013 1:47 AM, Adrian Crum wrote: > Hans, > > Normally, we report problems on the mailing list, not revert someone > else's commit. > > This was rude and uncalled for. If I did the same thing to your buggy > commits, none of your contributions would make it into the project. > > -Adrian > > On 8/25/2013 11:28 PM, [hidden email] wrote: >> Author: hansbak >> Date: Mon Aug 26 06:28:00 2013 >> New Revision: 1517434 >> >> URL: http://svn.apache.org/r1517434 >> Log: >> revert r1517353: it makes the tomahawk theme unusable >> >> Removed: >> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/menu/MacroMenuRenderer.java >> ofbiz/trunk/framework/widget/templates/htmlMenuMacroLibrary.ftl >> Modified: >> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >> >> Modified: >> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >> URL: >> http://svn.apache.org/viewvc/ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java?rev=1517434&r1=1517433&r2=1517434&view=diff >> ============================================================================== >> >> --- >> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >> (original) >> +++ >> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >> Mon Aug 26 06:28:00 2013 >> @@ -38,10 +38,8 @@ import org.ofbiz.webapp.view.AbstractVie >> import org.ofbiz.webapp.view.ViewHandlerException; >> import org.ofbiz.widget.form.FormStringRenderer; >> import org.ofbiz.widget.form.MacroFormRenderer; >> -import org.ofbiz.widget.menu.MacroMenuRenderer; >> -import org.ofbiz.widget.menu.MenuStringRenderer; >> -import org.ofbiz.widget.tree.MacroTreeRenderer; >> import org.ofbiz.widget.tree.TreeStringRenderer; >> +import org.ofbiz.widget.tree.MacroTreeRenderer; >> import org.xml.sax.SAXException; >> import freemarker.template.TemplateException; >> @@ -92,13 +90,15 @@ public class MacroScreenViewHandler exte >> ScreenStringRenderer screenStringRenderer = new >> MacroScreenRenderer(UtilProperties.getPropertyValue("widget", >> getName() + ".name"), UtilProperties.getPropertyValue("widget", >> getName() + ".screenrenderer")); >> FormStringRenderer formStringRenderer = new >> MacroFormRenderer(UtilProperties.getPropertyValue("widget", getName() >> + ".formrenderer"), request, response); >> TreeStringRenderer treeStringRenderer = new >> MacroTreeRenderer(UtilProperties.getPropertyValue("widget", getName() >> + ".treerenderer"), writer); >> - MenuStringRenderer menuStringRenderer = new >> MacroMenuRenderer(UtilProperties.getPropertyValue("widget", getName() >> + ".menurenderer"), request, response); >> + // TODO: uncomment these lines when the renderers are >> implemented >> + //MenuStringRenderer menuStringRenderer = new >> MacroMenuRenderer(UtilProperties.getPropertyValue("widget", getName() >> + ".menurenderer"), writer); >> ScreenRenderer screens = new ScreenRenderer(writer, >> null, screenStringRenderer); >> screens.populateContextForRequest(request, response, >> servletContext); >> + // this is the object used to render forms from their >> definitions >> screens.getContext().put("formStringRenderer", >> formStringRenderer); >> screens.getContext().put("treeStringRenderer", >> treeStringRenderer); >> - screens.getContext().put("menuStringRenderer", >> menuStringRenderer); >> + //screens.getContext().put("menuStringRenderer", >> menuStringRenderer); >> screens.getContext().put("simpleEncoder", >> StringUtil.getEncoder(UtilProperties.getPropertyValue("widget", >> getName() + ".encoder"))); >> screenStringRenderer.renderScreenBegin(writer, >> screens.getContext()); >> screens.render(page); >> >> > |
Re: svn commit: r1517434 - in /ofbiz/trunk/framework/widget: src/org/ofbiz/widget/menu/Macr
|
In reply to this post by Adrian Crum-3
Adrian,
Normally I would try to fix a problem and i did this pretty often. Because this was a blocking problem i saw no other way then to revert it. Very good to hear you like my commits which at least make a difference for our end users. Although i personally appreciate your framework commits, end-users, which are out bread and butter, are mostly not aware of it. good to co-operate with you, your comments are often very helpful, keep up the good work! Regards, Hans On 08/26/2013 03:47 PM, Adrian Crum wrote: > Hans, > > Normally, we report problems on the mailing list, not revert someone > else's commit. > > This was rude and uncalled for. If I did the same thing to your buggy > commits, none of your contributions would make it into the project. > > -Adrian > > On 8/25/2013 11:28 PM, [hidden email] wrote: >> Author: hansbak >> Date: Mon Aug 26 06:28:00 2013 >> New Revision: 1517434 >> >> URL: http://svn.apache.org/r1517434 >> Log: >> revert r1517353: it makes the tomahawk theme unusable >> >> Removed: >> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/menu/MacroMenuRenderer.java >> ofbiz/trunk/framework/widget/templates/htmlMenuMacroLibrary.ftl >> Modified: >> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >> >> Modified: >> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >> URL: >> http://svn.apache.org/viewvc/ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java?rev=1517434&r1=1517433&r2=1517434&view=diff >> ============================================================================== >> >> --- >> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >> (original) >> +++ >> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >> Mon Aug 26 06:28:00 2013 >> @@ -38,10 +38,8 @@ import org.ofbiz.webapp.view.AbstractVie >> import org.ofbiz.webapp.view.ViewHandlerException; >> import org.ofbiz.widget.form.FormStringRenderer; >> import org.ofbiz.widget.form.MacroFormRenderer; >> -import org.ofbiz.widget.menu.MacroMenuRenderer; >> -import org.ofbiz.widget.menu.MenuStringRenderer; >> -import org.ofbiz.widget.tree.MacroTreeRenderer; >> import org.ofbiz.widget.tree.TreeStringRenderer; >> +import org.ofbiz.widget.tree.MacroTreeRenderer; >> import org.xml.sax.SAXException; >> import freemarker.template.TemplateException; >> @@ -92,13 +90,15 @@ public class MacroScreenViewHandler exte >> ScreenStringRenderer screenStringRenderer = new >> MacroScreenRenderer(UtilProperties.getPropertyValue("widget", >> getName() + ".name"), UtilProperties.getPropertyValue("widget", >> getName() + ".screenrenderer")); >> FormStringRenderer formStringRenderer = new >> MacroFormRenderer(UtilProperties.getPropertyValue("widget", getName() >> + ".formrenderer"), request, response); >> TreeStringRenderer treeStringRenderer = new >> MacroTreeRenderer(UtilProperties.getPropertyValue("widget", getName() >> + ".treerenderer"), writer); >> - MenuStringRenderer menuStringRenderer = new >> MacroMenuRenderer(UtilProperties.getPropertyValue("widget", getName() >> + ".menurenderer"), request, response); >> + // TODO: uncomment these lines when the renderers are >> implemented >> + //MenuStringRenderer menuStringRenderer = new >> MacroMenuRenderer(UtilProperties.getPropertyValue("widget", getName() >> + ".menurenderer"), writer); >> ScreenRenderer screens = new ScreenRenderer(writer, >> null, screenStringRenderer); >> screens.populateContextForRequest(request, response, >> servletContext); >> + // this is the object used to render forms from their >> definitions >> screens.getContext().put("formStringRenderer", >> formStringRenderer); >> screens.getContext().put("treeStringRenderer", >> treeStringRenderer); >> - screens.getContext().put("menuStringRenderer", >> menuStringRenderer); >> + //screens.getContext().put("menuStringRenderer", >> menuStringRenderer); >> screens.getContext().put("simpleEncoder", >> StringUtil.getEncoder(UtilProperties.getPropertyValue("widget", >> getName() + ".encoder"))); >> screenStringRenderer.renderScreenBegin(writer, >> screens.getContext()); >> screens.render(page); >> >> > |
Re: svn commit: r1517434 - in /ofbiz/trunk/framework/widget: src/org/ofbiz/widget/menu/Macr
|
|
In reply to this post by Jacques Le Roux
Jacques,
Blocking, obvious problems like this one , should not be committed to the trunk, they upset other developers because the system becomes un-usable. Our customers do not use the trunk, so that is not a problem, but use a version which run at our staging server for a month. We call it a 'near-trunk' version. One should know that upgrading from 'official releases' is a real and expensive problem. Regards, Hans On 08/26/2013 04:40 PM, Jacques Le Roux wrote: > I'd add that using trunk for clients's projects should not be an excuse, you can always revert locally, waiting for a definitive solution... > > Jacques > > Adrian Crum wrote: >> Hans, >> >> Normally, we report problems on the mailing list, not revert someone >> else's commit. >> >> This was rude and uncalled for. If I did the same thing to your buggy >> commits, none of your contributions would make it into the project. >> >> -Adrian >> >> On 8/25/2013 11:28 PM, [hidden email] wrote: >>> Author: hansbak >>> Date: Mon Aug 26 06:28:00 2013 >>> New Revision: 1517434 >>> >>> URL: http://svn.apache.org/r1517434 >>> Log: >>> revert r1517353: it makes the tomahawk theme unusable >>> >>> Removed: >>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/menu/MacroMenuRenderer.java >>> ofbiz/trunk/framework/widget/templates/htmlMenuMacroLibrary.ftl >>> Modified: >>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>> >>> Modified: ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>> URL: >>> http://svn.apache.org/viewvc/ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java?rev=1517434&r1=1517433&r2=1517434&view=diff >>> ============================================================================== --- >>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java (original) +++ >>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java Mon Aug 26 06:28:00 2013 @@ -38,10 +38,8 @@ >>> import org.ofbiz.webapp.view.AbstractVie import org.ofbiz.webapp.view.ViewHandlerException; >>> import org.ofbiz.widget.form.FormStringRenderer; >>> import org.ofbiz.widget.form.MacroFormRenderer; >>> -import org.ofbiz.widget.menu.MacroMenuRenderer; >>> -import org.ofbiz.widget.menu.MenuStringRenderer; >>> -import org.ofbiz.widget.tree.MacroTreeRenderer; >>> import org.ofbiz.widget.tree.TreeStringRenderer; >>> +import org.ofbiz.widget.tree.MacroTreeRenderer; >>> import org.xml.sax.SAXException; >>> >>> import freemarker.template.TemplateException; >>> @@ -92,13 +90,15 @@ public class MacroScreenViewHandler exte >>> ScreenStringRenderer screenStringRenderer = new MacroScreenRenderer(UtilProperties.getPropertyValue("widget", >>> getName() + ".name"), UtilProperties.getPropertyValue("widget", getName() + ".screenrenderer")); >>> FormStringRenderer formStringRenderer = new MacroFormRenderer(UtilProperties.getPropertyValue("widget", getName() >>> + ".formrenderer"), request, response); TreeStringRenderer treeStringRenderer = new >>> MacroTreeRenderer(UtilProperties.getPropertyValue("widget", getName() + ".treerenderer"), writer); - >>> MenuStringRenderer menuStringRenderer = new MacroMenuRenderer(UtilProperties.getPropertyValue("widget", getName() + >>> ".menurenderer"), request, response); + // TODO: uncomment these lines when the renderers are implemented + >>> //MenuStringRenderer menuStringRenderer = new MacroMenuRenderer(UtilProperties.getPropertyValue("widget", getName() + >>> ".menurenderer"), writer); >>> >>> ScreenRenderer screens = new ScreenRenderer(writer, null, screenStringRenderer); >>> screens.populateContextForRequest(request, response, servletContext); >>> + // this is the object used to render forms from their definitions >>> screens.getContext().put("formStringRenderer", formStringRenderer); >>> screens.getContext().put("treeStringRenderer", treeStringRenderer); >>> - screens.getContext().put("menuStringRenderer", menuStringRenderer); >>> + //screens.getContext().put("menuStringRenderer", menuStringRenderer); >>> screens.getContext().put("simpleEncoder", StringUtil.getEncoder(UtilProperties.getPropertyValue("widget", >>> getName() + ".encoder"))); screenStringRenderer.renderScreenBegin(writer, screens.getContext()); >>> screens.render(page); |
Re: svn commit: r1517434 - in /ofbiz/trunk/framework/widget: src/org/ofbiz/widget/menu/Macr
|
|
In reply to this post by hans_bakker
No one is asking you to fix anything. All you had to do was post a
message and I would have fixed it. There was nothing blocking about my commit, and as I said there was no reason to revert it. Reverting a commit the way you did is NOT co-operation, and co-operation is a concept you consistently fail to understand. -Adrian On 8/26/2013 8:47 PM, Hans Bakker wrote: > Adrian, > Normally I would try to fix a problem and i did this pretty often. > Because this was a blocking problem i saw no other way then to revert it. > > Very good to hear you like my commits which at least make a difference > for our end users. Although i personally appreciate your framework > commits, end-users, which are out bread and butter, are mostly not > aware of it. > > good to co-operate with you, your comments are often very helpful, > keep up the good work! > > Regards, > Hans > > > On 08/26/2013 03:47 PM, Adrian Crum wrote: >> Hans, >> >> Normally, we report problems on the mailing list, not revert someone >> else's commit. >> >> This was rude and uncalled for. If I did the same thing to your buggy >> commits, none of your contributions would make it into the project. >> >> -Adrian >> >> On 8/25/2013 11:28 PM, [hidden email] wrote: >>> Author: hansbak >>> Date: Mon Aug 26 06:28:00 2013 >>> New Revision: 1517434 >>> >>> URL: http://svn.apache.org/r1517434 >>> Log: >>> revert r1517353: it makes the tomahawk theme unusable >>> >>> Removed: >>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/menu/MacroMenuRenderer.java >>> >>> ofbiz/trunk/framework/widget/templates/htmlMenuMacroLibrary.ftl >>> Modified: >>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>> >>> >>> Modified: >>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>> URL: >>> http://svn.apache.org/viewvc/ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java?rev=1517434&r1=1517433&r2=1517434&view=diff >>> ============================================================================== >>> >>> --- >>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>> (original) >>> +++ >>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>> Mon Aug 26 06:28:00 2013 >>> @@ -38,10 +38,8 @@ import org.ofbiz.webapp.view.AbstractVie >>> import org.ofbiz.webapp.view.ViewHandlerException; >>> import org.ofbiz.widget.form.FormStringRenderer; >>> import org.ofbiz.widget.form.MacroFormRenderer; >>> -import org.ofbiz.widget.menu.MacroMenuRenderer; >>> -import org.ofbiz.widget.menu.MenuStringRenderer; >>> -import org.ofbiz.widget.tree.MacroTreeRenderer; >>> import org.ofbiz.widget.tree.TreeStringRenderer; >>> +import org.ofbiz.widget.tree.MacroTreeRenderer; >>> import org.xml.sax.SAXException; >>> import freemarker.template.TemplateException; >>> @@ -92,13 +90,15 @@ public class MacroScreenViewHandler exte >>> ScreenStringRenderer screenStringRenderer = new >>> MacroScreenRenderer(UtilProperties.getPropertyValue("widget", >>> getName() + ".name"), UtilProperties.getPropertyValue("widget", >>> getName() + ".screenrenderer")); >>> FormStringRenderer formStringRenderer = new >>> MacroFormRenderer(UtilProperties.getPropertyValue("widget", >>> getName() + ".formrenderer"), request, response); >>> TreeStringRenderer treeStringRenderer = new >>> MacroTreeRenderer(UtilProperties.getPropertyValue("widget", >>> getName() + ".treerenderer"), writer); >>> - MenuStringRenderer menuStringRenderer = new >>> MacroMenuRenderer(UtilProperties.getPropertyValue("widget", >>> getName() + ".menurenderer"), request, response); >>> + // TODO: uncomment these lines when the renderers are >>> implemented >>> + //MenuStringRenderer menuStringRenderer = new >>> MacroMenuRenderer(UtilProperties.getPropertyValue("widget", >>> getName() + ".menurenderer"), writer); >>> ScreenRenderer screens = new ScreenRenderer(writer, >>> null, screenStringRenderer); >>> screens.populateContextForRequest(request, response, >>> servletContext); >>> + // this is the object used to render forms from their >>> definitions >>> screens.getContext().put("formStringRenderer", >>> formStringRenderer); >>> screens.getContext().put("treeStringRenderer", >>> treeStringRenderer); >>> - screens.getContext().put("menuStringRenderer", >>> menuStringRenderer); >>> + //screens.getContext().put("menuStringRenderer", >>> menuStringRenderer); >>> screens.getContext().put("simpleEncoder", >>> StringUtil.getEncoder(UtilProperties.getPropertyValue("widget", >>> getName() + ".encoder"))); >>> screenStringRenderer.renderScreenBegin(writer, >>> screens.getContext()); >>> screens.render(page); >>> >>> >> > |
Re: svn commit: r1517434 - in /ofbiz/trunk/framework/widget: src/org/ofbiz/widget/menu/Macr
|
|
If you would have announced this before you implemented it, i would have
known, now in first instance we think this is caused by our changes..... And only later check the svn updates.... Regards, Hans Try entering a purchase invoice: Expected collection or sequence. parameterList evaluated instead to freemarker.template.SimpleScalar on line 51, column 12 in component://widget/templates/htmlMenuMacroLibrary.ftl. The problematic instruction: ---------- ==> list parameterList as parameter [on line 51, column 5 in component://widget/templates/htmlMenuMacroLibrary.ftl] in user-directive renderLink [on line 1, column 1 in org.ofbiz.widget.menu.MacroMenuRenderer@21cc9647_1074] ---------- Java backtrace for programmers: ---------- freemarker.template.TemplateException: Expected collection or sequence. parameterList evaluated instead to freemarker.template.SimpleScalar on line 51, column 12 in component://widget/templates/htmlMenuMacroLibrary.ftl. at freemarker.core.TemplateObject.invalidTypeException(TemplateObject.java:136) at freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock. try entering a new accounting transaction: https://localhost:8443/accounting/control/createAcctgTrans Expected collection or sequence. parameterList evaluated instead to freemarker.template.SimpleScalar on line 51, column 12 in component://widget/templates/htmlMenuMacroLibrary.ftl. The problematic instruction: ---------- ==> list parameterList as parameter [on line 51, column 5 in component://widget/templates/htmlMenuMacroLibrary.ftl] in user-directive renderLink [on line 1, column 1 in org.ofbiz.widget.menu.MacroMenuRenderer@6e5faa56_1073] ---------- Java backtrace for programmers: ---------- freemarker.template.TemplateException: Expected collection or sequence. parameterList evaluated instead to freemarker.template.SimpleScalar on line 51, column 12 in component://widget/templates/htmlMenuMacroLibrary.ftl. at and at a number of other places...... Regards, Hans On 08/27/2013 11:44 AM, Adrian Crum wrote: > No one is asking you to fix anything. All you had to do was post a > message and I would have fixed it. > > There was nothing blocking about my commit, and as I said there was no > reason to revert it. > > Reverting a commit the way you did is NOT co-operation, and > co-operation is a concept you consistently fail to understand. > > -Adrian > > On 8/26/2013 8:47 PM, Hans Bakker wrote: >> Adrian, >> Normally I would try to fix a problem and i did this pretty often. >> Because this was a blocking problem i saw no other way then to revert >> it. >> >> Very good to hear you like my commits which at least make a >> difference for our end users. Although i personally appreciate your >> framework commits, end-users, which are out bread and butter, are >> mostly not aware of it. >> >> good to co-operate with you, your comments are often very helpful, >> keep up the good work! >> >> Regards, >> Hans >> >> >> On 08/26/2013 03:47 PM, Adrian Crum wrote: >>> Hans, >>> >>> Normally, we report problems on the mailing list, not revert someone >>> else's commit. >>> >>> This was rude and uncalled for. If I did the same thing to your >>> buggy commits, none of your contributions would make it into the >>> project. >>> >>> -Adrian >>> >>> On 8/25/2013 11:28 PM, [hidden email] wrote: >>>> Author: hansbak >>>> Date: Mon Aug 26 06:28:00 2013 >>>> New Revision: 1517434 >>>> >>>> URL: http://svn.apache.org/r1517434 >>>> Log: >>>> revert r1517353: it makes the tomahawk theme unusable >>>> >>>> Removed: >>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/menu/MacroMenuRenderer.java >>>> >>>> ofbiz/trunk/framework/widget/templates/htmlMenuMacroLibrary.ftl >>>> Modified: >>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>> >>>> >>>> Modified: >>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>> URL: >>>> http://svn.apache.org/viewvc/ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java?rev=1517434&r1=1517433&r2=1517434&view=diff >>>> ============================================================================== >>>> >>>> --- >>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>> (original) >>>> +++ >>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>> Mon Aug 26 06:28:00 2013 >>>> @@ -38,10 +38,8 @@ import org.ofbiz.webapp.view.AbstractVie >>>> import org.ofbiz.webapp.view.ViewHandlerException; >>>> import org.ofbiz.widget.form.FormStringRenderer; >>>> import org.ofbiz.widget.form.MacroFormRenderer; >>>> -import org.ofbiz.widget.menu.MacroMenuRenderer; >>>> -import org.ofbiz.widget.menu.MenuStringRenderer; >>>> -import org.ofbiz.widget.tree.MacroTreeRenderer; >>>> import org.ofbiz.widget.tree.TreeStringRenderer; >>>> +import org.ofbiz.widget.tree.MacroTreeRenderer; >>>> import org.xml.sax.SAXException; >>>> import freemarker.template.TemplateException; >>>> @@ -92,13 +90,15 @@ public class MacroScreenViewHandler exte >>>> ScreenStringRenderer screenStringRenderer = new >>>> MacroScreenRenderer(UtilProperties.getPropertyValue("widget", >>>> getName() + ".name"), UtilProperties.getPropertyValue("widget", >>>> getName() + ".screenrenderer")); >>>> FormStringRenderer formStringRenderer = new >>>> MacroFormRenderer(UtilProperties.getPropertyValue("widget", >>>> getName() + ".formrenderer"), request, response); >>>> TreeStringRenderer treeStringRenderer = new >>>> MacroTreeRenderer(UtilProperties.getPropertyValue("widget", >>>> getName() + ".treerenderer"), writer); >>>> - MenuStringRenderer menuStringRenderer = new >>>> MacroMenuRenderer(UtilProperties.getPropertyValue("widget", >>>> getName() + ".menurenderer"), request, response); >>>> + // TODO: uncomment these lines when the renderers are >>>> implemented >>>> + //MenuStringRenderer menuStringRenderer = new >>>> MacroMenuRenderer(UtilProperties.getPropertyValue("widget", >>>> getName() + ".menurenderer"), writer); >>>> ScreenRenderer screens = new ScreenRenderer(writer, >>>> null, screenStringRenderer); >>>> screens.populateContextForRequest(request, response, >>>> servletContext); >>>> + // this is the object used to render forms from their >>>> definitions >>>> screens.getContext().put("formStringRenderer", >>>> formStringRenderer); >>>> screens.getContext().put("treeStringRenderer", >>>> treeStringRenderer); >>>> - screens.getContext().put("menuStringRenderer", >>>> menuStringRenderer); >>>> + //screens.getContext().put("menuStringRenderer", >>>> menuStringRenderer); >>>> screens.getContext().put("simpleEncoder", >>>> StringUtil.getEncoder(UtilProperties.getPropertyValue("widget", >>>> getName() + ".encoder"))); >>>> screenStringRenderer.renderScreenBegin(writer, >>>> screens.getContext()); >>>> screens.render(page); >>>> >>>> >>> >> > |
Re: svn commit: r1517434 - in /ofbiz/trunk/framework/widget: src/org/ofbiz/widget/menu/Macr
|
Administrator
|
This is indeed a concern. I believe we should always all follow the Jira way of sharing and testing before committing any new major feature or major bug fix (not trivial ones of course).
Then, it's possible to wait few days for others to check, not bullet proof but surely better. Jacques Hans Bakker wrote: > If you would have announced this before you implemented it, i would have > known, now in first instance we think this is caused by our changes..... > And only later check the svn updates.... > > Regards, > Hans > > Try entering a purchase invoice: > > Expected collection or sequence. parameterList evaluated instead to > freemarker.template.SimpleScalar on line 51, column 12 in > component://widget/templates/htmlMenuMacroLibrary.ftl. The problematic > instruction: ---------- ==> list parameterList as parameter [on line 51, > column 5 in component://widget/templates/htmlMenuMacroLibrary.ftl] in > user-directive renderLink [on line 1, column 1 in > org.ofbiz.widget.menu.MacroMenuRenderer@21cc9647_1074] ---------- Java > backtrace for programmers: ---------- > freemarker.template.TemplateException: Expected collection or sequence. > parameterList evaluated instead to freemarker.template.SimpleScalar on > line 51, column 12 in > component://widget/templates/htmlMenuMacroLibrary.ftl. at > freemarker.core.TemplateObject.invalidTypeException(TemplateObject.java:136) > at freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock. > > try entering a new accounting transaction: > https://localhost:8443/accounting/control/createAcctgTrans > > Expected collection or sequence. parameterList evaluated instead to > freemarker.template.SimpleScalar on line 51, column 12 in > component://widget/templates/htmlMenuMacroLibrary.ftl. The problematic > instruction: ---------- ==> list parameterList as parameter [on line 51, > column 5 in component://widget/templates/htmlMenuMacroLibrary.ftl] in > user-directive renderLink [on line 1, column 1 in > org.ofbiz.widget.menu.MacroMenuRenderer@6e5faa56_1073] ---------- Java > backtrace for programmers: ---------- > freemarker.template.TemplateException: Expected collection or sequence. > parameterList evaluated instead to freemarker.template.SimpleScalar on > line 51, column 12 in > component://widget/templates/htmlMenuMacroLibrary.ftl. at > > and at a number of other places...... > > Regards, > Hans > > > > > On 08/27/2013 11:44 AM, Adrian Crum wrote: >> No one is asking you to fix anything. All you had to do was post a >> message and I would have fixed it. >> >> There was nothing blocking about my commit, and as I said there was no >> reason to revert it. >> >> Reverting a commit the way you did is NOT co-operation, and >> co-operation is a concept you consistently fail to understand. >> >> -Adrian >> >> On 8/26/2013 8:47 PM, Hans Bakker wrote: >>> Adrian, >>> Normally I would try to fix a problem and i did this pretty often. >>> Because this was a blocking problem i saw no other way then to revert >>> it. >>> >>> Very good to hear you like my commits which at least make a >>> difference for our end users. Although i personally appreciate your >>> framework commits, end-users, which are out bread and butter, are >>> mostly not aware of it. >>> >>> good to co-operate with you, your comments are often very helpful, >>> keep up the good work! >>> >>> Regards, >>> Hans >>> >>> >>> On 08/26/2013 03:47 PM, Adrian Crum wrote: >>>> Hans, >>>> >>>> Normally, we report problems on the mailing list, not revert someone >>>> else's commit. >>>> >>>> This was rude and uncalled for. If I did the same thing to your >>>> buggy commits, none of your contributions would make it into the >>>> project. >>>> >>>> -Adrian >>>> >>>> On 8/25/2013 11:28 PM, [hidden email] wrote: >>>>> Author: hansbak >>>>> Date: Mon Aug 26 06:28:00 2013 >>>>> New Revision: 1517434 >>>>> >>>>> URL: http://svn.apache.org/r1517434 >>>>> Log: >>>>> revert r1517353: it makes the tomahawk theme unusable >>>>> >>>>> Removed: >>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/menu/MacroMenuRenderer.java >>>>> >>>>> ofbiz/trunk/framework/widget/templates/htmlMenuMacroLibrary.ftl >>>>> Modified: >>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>> >>>>> >>>>> Modified: >>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>> URL: >>>>> http://svn.apache.org/viewvc/ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java?rev=1517434&r1=1517433&r2=1517434&view=diff >>>>> ============================================================================== >>>>> >>>>> --- >>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>> (original) >>>>> +++ >>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>> Mon Aug 26 06:28:00 2013 >>>>> @@ -38,10 +38,8 @@ import org.ofbiz.webapp.view.AbstractVie >>>>> import org.ofbiz.webapp.view.ViewHandlerException; >>>>> import org.ofbiz.widget.form.FormStringRenderer; >>>>> import org.ofbiz.widget.form.MacroFormRenderer; >>>>> -import org.ofbiz.widget.menu.MacroMenuRenderer; >>>>> -import org.ofbiz.widget.menu.MenuStringRenderer; >>>>> -import org.ofbiz.widget.tree.MacroTreeRenderer; >>>>> import org.ofbiz.widget.tree.TreeStringRenderer; >>>>> +import org.ofbiz.widget.tree.MacroTreeRenderer; >>>>> import org.xml.sax.SAXException; >>>>> import freemarker.template.TemplateException; >>>>> @@ -92,13 +90,15 @@ public class MacroScreenViewHandler exte >>>>> ScreenStringRenderer screenStringRenderer = new >>>>> MacroScreenRenderer(UtilProperties.getPropertyValue("widget", >>>>> getName() + ".name"), UtilProperties.getPropertyValue("widget", >>>>> getName() + ".screenrenderer")); >>>>> FormStringRenderer formStringRenderer = new >>>>> MacroFormRenderer(UtilProperties.getPropertyValue("widget", >>>>> getName() + ".formrenderer"), request, response); >>>>> TreeStringRenderer treeStringRenderer = new >>>>> MacroTreeRenderer(UtilProperties.getPropertyValue("widget", >>>>> getName() + ".treerenderer"), writer); >>>>> - MenuStringRenderer menuStringRenderer = new >>>>> MacroMenuRenderer(UtilProperties.getPropertyValue("widget", >>>>> getName() + ".menurenderer"), request, response); >>>>> + // TODO: uncomment these lines when the renderers are >>>>> implemented >>>>> + //MenuStringRenderer menuStringRenderer = new >>>>> MacroMenuRenderer(UtilProperties.getPropertyValue("widget", >>>>> getName() + ".menurenderer"), writer); >>>>> ScreenRenderer screens = new ScreenRenderer(writer, >>>>> null, screenStringRenderer); >>>>> screens.populateContextForRequest(request, response, >>>>> servletContext); >>>>> + // this is the object used to render forms from their >>>>> definitions >>>>> screens.getContext().put("formStringRenderer", >>>>> formStringRenderer); >>>>> screens.getContext().put("treeStringRenderer", >>>>> treeStringRenderer); >>>>> - screens.getContext().put("menuStringRenderer", >>>>> menuStringRenderer); >>>>> + //screens.getContext().put("menuStringRenderer", >>>>> menuStringRenderer); >>>>> screens.getContext().put("simpleEncoder", >>>>> StringUtil.getEncoder(UtilProperties.getPropertyValue("widget", >>>>> getName() + ".encoder"))); >>>>> screenStringRenderer.renderScreenBegin(writer, >>>>> screens.getContext()); >>>>> screens.render(page); |
Re: svn commit: r1517434 - in /ofbiz/trunk/framework/widget: src/org/ofbiz/widget/menu/Macr
|
|
In reply to this post by hans_bakker
Thank you for the detailed problem description. I fixed this problem in
rev 1517880. -Adrian On 8/27/2013 1:53 AM, Hans Bakker wrote: > If you would have announced this before you implemented it, i would > have known, now in first instance we think this is caused by our > changes..... > And only later check the svn updates.... > > Regards, > Hans > > Try entering a purchase invoice: > > Expected collection or sequence. parameterList evaluated instead to > freemarker.template.SimpleScalar on line 51, column 12 in > component://widget/templates/htmlMenuMacroLibrary.ftl. The problematic > instruction: ---------- ==> list parameterList as parameter [on line > 51, column 5 in component://widget/templates/htmlMenuMacroLibrary.ftl] > in user-directive renderLink [on line 1, column 1 in > org.ofbiz.widget.menu.MacroMenuRenderer@21cc9647_1074] ---------- Java > backtrace for programmers: ---------- > freemarker.template.TemplateException: Expected collection or > sequence. parameterList evaluated instead to > freemarker.template.SimpleScalar on line 51, column 12 in > component://widget/templates/htmlMenuMacroLibrary.ftl. at > freemarker.core.TemplateObject.invalidTypeException(TemplateObject.java:136) > at freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock. > > try entering a new accounting transaction: > https://localhost:8443/accounting/control/createAcctgTrans > > Expected collection or sequence. parameterList evaluated instead to > freemarker.template.SimpleScalar on line 51, column 12 in > component://widget/templates/htmlMenuMacroLibrary.ftl. The problematic > instruction: ---------- ==> list parameterList as parameter [on line > 51, column 5 in component://widget/templates/htmlMenuMacroLibrary.ftl] > in user-directive renderLink [on line 1, column 1 in > org.ofbiz.widget.menu.MacroMenuRenderer@6e5faa56_1073] ---------- Java > backtrace for programmers: ---------- > freemarker.template.TemplateException: Expected collection or > sequence. parameterList evaluated instead to > freemarker.template.SimpleScalar on line 51, column 12 in > component://widget/templates/htmlMenuMacroLibrary.ftl. at > > and at a number of other places...... > > Regards, > Hans > > > > > On 08/27/2013 11:44 AM, Adrian Crum wrote: >> No one is asking you to fix anything. All you had to do was post a >> message and I would have fixed it. >> >> There was nothing blocking about my commit, and as I said there was >> no reason to revert it. >> >> Reverting a commit the way you did is NOT co-operation, and >> co-operation is a concept you consistently fail to understand. >> >> -Adrian >> >> On 8/26/2013 8:47 PM, Hans Bakker wrote: >>> Adrian, >>> Normally I would try to fix a problem and i did this pretty often. >>> Because this was a blocking problem i saw no other way then to >>> revert it. >>> >>> Very good to hear you like my commits which at least make a >>> difference for our end users. Although i personally appreciate your >>> framework commits, end-users, which are out bread and butter, are >>> mostly not aware of it. >>> >>> good to co-operate with you, your comments are often very helpful, >>> keep up the good work! >>> >>> Regards, >>> Hans >>> >>> >>> On 08/26/2013 03:47 PM, Adrian Crum wrote: >>>> Hans, >>>> >>>> Normally, we report problems on the mailing list, not revert >>>> someone else's commit. >>>> >>>> This was rude and uncalled for. If I did the same thing to your >>>> buggy commits, none of your contributions would make it into the >>>> project. >>>> >>>> -Adrian >>>> >>>> On 8/25/2013 11:28 PM, [hidden email] wrote: >>>>> Author: hansbak >>>>> Date: Mon Aug 26 06:28:00 2013 >>>>> New Revision: 1517434 >>>>> >>>>> URL: http://svn.apache.org/r1517434 >>>>> Log: >>>>> revert r1517353: it makes the tomahawk theme unusable >>>>> >>>>> Removed: >>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/menu/MacroMenuRenderer.java >>>>> >>>>> ofbiz/trunk/framework/widget/templates/htmlMenuMacroLibrary.ftl >>>>> Modified: >>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>> >>>>> >>>>> Modified: >>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>> URL: >>>>> http://svn.apache.org/viewvc/ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java?rev=1517434&r1=1517433&r2=1517434&view=diff >>>>> ============================================================================== >>>>> >>>>> --- >>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>> (original) >>>>> +++ >>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>> Mon Aug 26 06:28:00 2013 >>>>> @@ -38,10 +38,8 @@ import org.ofbiz.webapp.view.AbstractVie >>>>> import org.ofbiz.webapp.view.ViewHandlerException; >>>>> import org.ofbiz.widget.form.FormStringRenderer; >>>>> import org.ofbiz.widget.form.MacroFormRenderer; >>>>> -import org.ofbiz.widget.menu.MacroMenuRenderer; >>>>> -import org.ofbiz.widget.menu.MenuStringRenderer; >>>>> -import org.ofbiz.widget.tree.MacroTreeRenderer; >>>>> import org.ofbiz.widget.tree.TreeStringRenderer; >>>>> +import org.ofbiz.widget.tree.MacroTreeRenderer; >>>>> import org.xml.sax.SAXException; >>>>> import freemarker.template.TemplateException; >>>>> @@ -92,13 +90,15 @@ public class MacroScreenViewHandler exte >>>>> ScreenStringRenderer screenStringRenderer = new >>>>> MacroScreenRenderer(UtilProperties.getPropertyValue("widget", >>>>> getName() + ".name"), UtilProperties.getPropertyValue("widget", >>>>> getName() + ".screenrenderer")); >>>>> FormStringRenderer formStringRenderer = new >>>>> MacroFormRenderer(UtilProperties.getPropertyValue("widget", >>>>> getName() + ".formrenderer"), request, response); >>>>> TreeStringRenderer treeStringRenderer = new >>>>> MacroTreeRenderer(UtilProperties.getPropertyValue("widget", >>>>> getName() + ".treerenderer"), writer); >>>>> - MenuStringRenderer menuStringRenderer = new >>>>> MacroMenuRenderer(UtilProperties.getPropertyValue("widget", >>>>> getName() + ".menurenderer"), request, response); >>>>> + // TODO: uncomment these lines when the renderers are >>>>> implemented >>>>> + //MenuStringRenderer menuStringRenderer = new >>>>> MacroMenuRenderer(UtilProperties.getPropertyValue("widget", >>>>> getName() + ".menurenderer"), writer); >>>>> ScreenRenderer screens = new >>>>> ScreenRenderer(writer, null, screenStringRenderer); >>>>> screens.populateContextForRequest(request, response, >>>>> servletContext); >>>>> + // this is the object used to render forms from their >>>>> definitions >>>>> screens.getContext().put("formStringRenderer", formStringRenderer); >>>>> screens.getContext().put("treeStringRenderer", treeStringRenderer); >>>>> - screens.getContext().put("menuStringRenderer", menuStringRenderer); >>>>> + //screens.getContext().put("menuStringRenderer", >>>>> menuStringRenderer); >>>>> screens.getContext().put("simpleEncoder", >>>>> StringUtil.getEncoder(UtilProperties.getPropertyValue("widget", >>>>> getName() + ".encoder"))); >>>>> screenStringRenderer.renderScreenBegin(writer, screens.getContext()); >>>>> screens.render(page); >>>>> >>>>> >>>> >>> >> > |
Re: svn commit: r1517434 - in /ofbiz/trunk/framework/widget: src/org/ofbiz/widget/menu/Macr
|
|
In reply to this post by Jacques Le Roux
That was not the case in my commit. The macro widget renderers were
proposed by Jacopo years ago and we discussed it. The implementation was incomplete however. So, I merely finished an incomplete implementation of a new feature we agreed on years ago. -Adrian On 8/27/2013 3:06 AM, Jacques Le Roux wrote: > This is indeed a concern. I believe we should always all follow the Jira way of sharing and testing before committing any new major feature or major bug fix (not trivial ones of course). > Then, it's possible to wait few days for others to check, not bullet proof but surely better. > > Jacques > > Hans Bakker wrote: >> If you would have announced this before you implemented it, i would have >> known, now in first instance we think this is caused by our changes..... >> And only later check the svn updates.... >> >> Regards, >> Hans >> >> Try entering a purchase invoice: >> >> Expected collection or sequence. parameterList evaluated instead to >> freemarker.template.SimpleScalar on line 51, column 12 in >> component://widget/templates/htmlMenuMacroLibrary.ftl. The problematic >> instruction: ---------- ==> list parameterList as parameter [on line 51, >> column 5 in component://widget/templates/htmlMenuMacroLibrary.ftl] in >> user-directive renderLink [on line 1, column 1 in >> org.ofbiz.widget.menu.MacroMenuRenderer@21cc9647_1074] ---------- Java >> backtrace for programmers: ---------- >> freemarker.template.TemplateException: Expected collection or sequence. >> parameterList evaluated instead to freemarker.template.SimpleScalar on >> line 51, column 12 in >> component://widget/templates/htmlMenuMacroLibrary.ftl. at >> freemarker.core.TemplateObject.invalidTypeException(TemplateObject.java:136) >> at freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock. >> >> try entering a new accounting transaction: >> https://localhost:8443/accounting/control/createAcctgTrans >> >> Expected collection or sequence. parameterList evaluated instead to >> freemarker.template.SimpleScalar on line 51, column 12 in >> component://widget/templates/htmlMenuMacroLibrary.ftl. The problematic >> instruction: ---------- ==> list parameterList as parameter [on line 51, >> column 5 in component://widget/templates/htmlMenuMacroLibrary.ftl] in >> user-directive renderLink [on line 1, column 1 in >> org.ofbiz.widget.menu.MacroMenuRenderer@6e5faa56_1073] ---------- Java >> backtrace for programmers: ---------- >> freemarker.template.TemplateException: Expected collection or sequence. >> parameterList evaluated instead to freemarker.template.SimpleScalar on >> line 51, column 12 in >> component://widget/templates/htmlMenuMacroLibrary.ftl. at >> >> and at a number of other places...... >> >> Regards, >> Hans >> >> >> >> >> On 08/27/2013 11:44 AM, Adrian Crum wrote: >>> No one is asking you to fix anything. All you had to do was post a >>> message and I would have fixed it. >>> >>> There was nothing blocking about my commit, and as I said there was no >>> reason to revert it. >>> >>> Reverting a commit the way you did is NOT co-operation, and >>> co-operation is a concept you consistently fail to understand. >>> >>> -Adrian >>> >>> On 8/26/2013 8:47 PM, Hans Bakker wrote: >>>> Adrian, >>>> Normally I would try to fix a problem and i did this pretty often. >>>> Because this was a blocking problem i saw no other way then to revert >>>> it. >>>> >>>> Very good to hear you like my commits which at least make a >>>> difference for our end users. Although i personally appreciate your >>>> framework commits, end-users, which are out bread and butter, are >>>> mostly not aware of it. >>>> >>>> good to co-operate with you, your comments are often very helpful, >>>> keep up the good work! >>>> >>>> Regards, >>>> Hans >>>> >>>> >>>> On 08/26/2013 03:47 PM, Adrian Crum wrote: >>>>> Hans, >>>>> >>>>> Normally, we report problems on the mailing list, not revert someone >>>>> else's commit. >>>>> >>>>> This was rude and uncalled for. If I did the same thing to your >>>>> buggy commits, none of your contributions would make it into the >>>>> project. >>>>> >>>>> -Adrian >>>>> >>>>> On 8/25/2013 11:28 PM, [hidden email] wrote: >>>>>> Author: hansbak >>>>>> Date: Mon Aug 26 06:28:00 2013 >>>>>> New Revision: 1517434 >>>>>> >>>>>> URL: http://svn.apache.org/r1517434 >>>>>> Log: >>>>>> revert r1517353: it makes the tomahawk theme unusable >>>>>> >>>>>> Removed: >>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/menu/MacroMenuRenderer.java >>>>>> >>>>>> ofbiz/trunk/framework/widget/templates/htmlMenuMacroLibrary.ftl >>>>>> Modified: >>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>>> >>>>>> >>>>>> Modified: >>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>>> URL: >>>>>> http://svn.apache.org/viewvc/ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java?rev=1517434&r1=1517433&r2=1517434&view=diff >>>>>> ============================================================================== >>>>>> >>>>>> --- >>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>>> (original) >>>>>> +++ >>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>>> Mon Aug 26 06:28:00 2013 >>>>>> @@ -38,10 +38,8 @@ import org.ofbiz.webapp.view.AbstractVie >>>>>> import org.ofbiz.webapp.view.ViewHandlerException; >>>>>> import org.ofbiz.widget.form.FormStringRenderer; >>>>>> import org.ofbiz.widget.form.MacroFormRenderer; >>>>>> -import org.ofbiz.widget.menu.MacroMenuRenderer; >>>>>> -import org.ofbiz.widget.menu.MenuStringRenderer; >>>>>> -import org.ofbiz.widget.tree.MacroTreeRenderer; >>>>>> import org.ofbiz.widget.tree.TreeStringRenderer; >>>>>> +import org.ofbiz.widget.tree.MacroTreeRenderer; >>>>>> import org.xml.sax.SAXException; >>>>>> import freemarker.template.TemplateException; >>>>>> @@ -92,13 +90,15 @@ public class MacroScreenViewHandler exte >>>>>> ScreenStringRenderer screenStringRenderer = new >>>>>> MacroScreenRenderer(UtilProperties.getPropertyValue("widget", >>>>>> getName() + ".name"), UtilProperties.getPropertyValue("widget", >>>>>> getName() + ".screenrenderer")); >>>>>> FormStringRenderer formStringRenderer = new >>>>>> MacroFormRenderer(UtilProperties.getPropertyValue("widget", >>>>>> getName() + ".formrenderer"), request, response); >>>>>> TreeStringRenderer treeStringRenderer = new >>>>>> MacroTreeRenderer(UtilProperties.getPropertyValue("widget", >>>>>> getName() + ".treerenderer"), writer); >>>>>> - MenuStringRenderer menuStringRenderer = new >>>>>> MacroMenuRenderer(UtilProperties.getPropertyValue("widget", >>>>>> getName() + ".menurenderer"), request, response); >>>>>> + // TODO: uncomment these lines when the renderers are >>>>>> implemented >>>>>> + //MenuStringRenderer menuStringRenderer = new >>>>>> MacroMenuRenderer(UtilProperties.getPropertyValue("widget", >>>>>> getName() + ".menurenderer"), writer); >>>>>> ScreenRenderer screens = new ScreenRenderer(writer, >>>>>> null, screenStringRenderer); >>>>>> screens.populateContextForRequest(request, response, >>>>>> servletContext); >>>>>> + // this is the object used to render forms from their >>>>>> definitions >>>>>> screens.getContext().put("formStringRenderer", >>>>>> formStringRenderer); >>>>>> screens.getContext().put("treeStringRenderer", >>>>>> treeStringRenderer); >>>>>> - screens.getContext().put("menuStringRenderer", >>>>>> menuStringRenderer); >>>>>> + //screens.getContext().put("menuStringRenderer", >>>>>> menuStringRenderer); >>>>>> screens.getContext().put("simpleEncoder", >>>>>> StringUtil.getEncoder(UtilProperties.getPropertyValue("widget", >>>>>> getName() + ".encoder"))); >>>>>> screenStringRenderer.renderScreenBegin(writer, >>>>>> screens.getContext()); >>>>>> screens.render(page); |
Re: svn commit: r1517434 - in /ofbiz/trunk/framework/widget: src/org/ofbiz/widget/menu/Macr
|
Administrator
|
Then maybe a few words on the dev ML would not have hurt.
Jacques Adrian Crum wrote: > That was not the case in my commit. The macro widget renderers were > proposed by Jacopo years ago and we discussed it. The implementation was > incomplete however. So, I merely finished an incomplete implementation > of a new feature we agreed on years ago. > > -Adrian > > On 8/27/2013 3:06 AM, Jacques Le Roux wrote: >> This is indeed a concern. I believe we should always all follow the Jira way of sharing and testing before committing any new >> major feature or major bug fix (not trivial ones of course). Then, it's possible to wait few days for others to check, not >> bullet proof but surely better. >> >> Jacques >> >> Hans Bakker wrote: >>> If you would have announced this before you implemented it, i would have >>> known, now in first instance we think this is caused by our changes..... >>> And only later check the svn updates.... >>> >>> Regards, >>> Hans >>> >>> Try entering a purchase invoice: >>> >>> Expected collection or sequence. parameterList evaluated instead to >>> freemarker.template.SimpleScalar on line 51, column 12 in >>> component://widget/templates/htmlMenuMacroLibrary.ftl. The problematic >>> instruction: ---------- ==> list parameterList as parameter [on line 51, >>> column 5 in component://widget/templates/htmlMenuMacroLibrary.ftl] in >>> user-directive renderLink [on line 1, column 1 in >>> org.ofbiz.widget.menu.MacroMenuRenderer@21cc9647_1074] ---------- Java >>> backtrace for programmers: ---------- >>> freemarker.template.TemplateException: Expected collection or sequence. >>> parameterList evaluated instead to freemarker.template.SimpleScalar on >>> line 51, column 12 in >>> component://widget/templates/htmlMenuMacroLibrary.ftl. at >>> freemarker.core.TemplateObject.invalidTypeException(TemplateObject.java:136) >>> at freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock. >>> >>> try entering a new accounting transaction: >>> https://localhost:8443/accounting/control/createAcctgTrans >>> >>> Expected collection or sequence. parameterList evaluated instead to >>> freemarker.template.SimpleScalar on line 51, column 12 in >>> component://widget/templates/htmlMenuMacroLibrary.ftl. The problematic >>> instruction: ---------- ==> list parameterList as parameter [on line 51, >>> column 5 in component://widget/templates/htmlMenuMacroLibrary.ftl] in >>> user-directive renderLink [on line 1, column 1 in >>> org.ofbiz.widget.menu.MacroMenuRenderer@6e5faa56_1073] ---------- Java >>> backtrace for programmers: ---------- >>> freemarker.template.TemplateException: Expected collection or sequence. >>> parameterList evaluated instead to freemarker.template.SimpleScalar on >>> line 51, column 12 in >>> component://widget/templates/htmlMenuMacroLibrary.ftl. at >>> >>> and at a number of other places...... >>> >>> Regards, >>> Hans >>> >>> >>> >>> >>> On 08/27/2013 11:44 AM, Adrian Crum wrote: >>>> No one is asking you to fix anything. All you had to do was post a >>>> message and I would have fixed it. >>>> >>>> There was nothing blocking about my commit, and as I said there was no >>>> reason to revert it. >>>> >>>> Reverting a commit the way you did is NOT co-operation, and >>>> co-operation is a concept you consistently fail to understand. >>>> >>>> -Adrian >>>> >>>> On 8/26/2013 8:47 PM, Hans Bakker wrote: >>>>> Adrian, >>>>> Normally I would try to fix a problem and i did this pretty often. >>>>> Because this was a blocking problem i saw no other way then to revert >>>>> it. >>>>> >>>>> Very good to hear you like my commits which at least make a >>>>> difference for our end users. Although i personally appreciate your >>>>> framework commits, end-users, which are out bread and butter, are >>>>> mostly not aware of it. >>>>> >>>>> good to co-operate with you, your comments are often very helpful, >>>>> keep up the good work! >>>>> >>>>> Regards, >>>>> Hans >>>>> >>>>> >>>>> On 08/26/2013 03:47 PM, Adrian Crum wrote: >>>>>> Hans, >>>>>> >>>>>> Normally, we report problems on the mailing list, not revert someone >>>>>> else's commit. >>>>>> >>>>>> This was rude and uncalled for. If I did the same thing to your >>>>>> buggy commits, none of your contributions would make it into the >>>>>> project. >>>>>> >>>>>> -Adrian >>>>>> >>>>>> On 8/25/2013 11:28 PM, [hidden email] wrote: >>>>>>> Author: hansbak >>>>>>> Date: Mon Aug 26 06:28:00 2013 >>>>>>> New Revision: 1517434 >>>>>>> >>>>>>> URL: http://svn.apache.org/r1517434 >>>>>>> Log: >>>>>>> revert r1517353: it makes the tomahawk theme unusable >>>>>>> >>>>>>> Removed: >>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/menu/MacroMenuRenderer.java >>>>>>> >>>>>>> ofbiz/trunk/framework/widget/templates/htmlMenuMacroLibrary.ftl >>>>>>> Modified: >>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>>>> >>>>>>> >>>>>>> Modified: >>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>>>> URL: >>>>>>> http://svn.apache.org/viewvc/ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java?rev=1517434&r1=1517433&r2=1517434&view=diff >>>>>>> ============================================================================== >>>>>>> >>>>>>> --- >>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>>>> (original) >>>>>>> +++ >>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>>>> Mon Aug 26 06:28:00 2013 >>>>>>> @@ -38,10 +38,8 @@ import org.ofbiz.webapp.view.AbstractVie >>>>>>> import org.ofbiz.webapp.view.ViewHandlerException; >>>>>>> import org.ofbiz.widget.form.FormStringRenderer; >>>>>>> import org.ofbiz.widget.form.MacroFormRenderer; >>>>>>> -import org.ofbiz.widget.menu.MacroMenuRenderer; >>>>>>> -import org.ofbiz.widget.menu.MenuStringRenderer; >>>>>>> -import org.ofbiz.widget.tree.MacroTreeRenderer; >>>>>>> import org.ofbiz.widget.tree.TreeStringRenderer; >>>>>>> +import org.ofbiz.widget.tree.MacroTreeRenderer; >>>>>>> import org.xml.sax.SAXException; >>>>>>> import freemarker.template.TemplateException; >>>>>>> @@ -92,13 +90,15 @@ public class MacroScreenViewHandler exte >>>>>>> ScreenStringRenderer screenStringRenderer = new >>>>>>> MacroScreenRenderer(UtilProperties.getPropertyValue("widget", >>>>>>> getName() + ".name"), UtilProperties.getPropertyValue("widget", >>>>>>> getName() + ".screenrenderer")); >>>>>>> FormStringRenderer formStringRenderer = new >>>>>>> MacroFormRenderer(UtilProperties.getPropertyValue("widget", >>>>>>> getName() + ".formrenderer"), request, response); >>>>>>> TreeStringRenderer treeStringRenderer = new >>>>>>> MacroTreeRenderer(UtilProperties.getPropertyValue("widget", >>>>>>> getName() + ".treerenderer"), writer); >>>>>>> - MenuStringRenderer menuStringRenderer = new >>>>>>> MacroMenuRenderer(UtilProperties.getPropertyValue("widget", >>>>>>> getName() + ".menurenderer"), request, response); >>>>>>> + // TODO: uncomment these lines when the renderers are >>>>>>> implemented >>>>>>> + //MenuStringRenderer menuStringRenderer = new >>>>>>> MacroMenuRenderer(UtilProperties.getPropertyValue("widget", >>>>>>> getName() + ".menurenderer"), writer); >>>>>>> ScreenRenderer screens = new ScreenRenderer(writer, >>>>>>> null, screenStringRenderer); >>>>>>> screens.populateContextForRequest(request, response, >>>>>>> servletContext); >>>>>>> + // this is the object used to render forms from their >>>>>>> definitions >>>>>>> screens.getContext().put("formStringRenderer", >>>>>>> formStringRenderer); >>>>>>> screens.getContext().put("treeStringRenderer", >>>>>>> treeStringRenderer); >>>>>>> - screens.getContext().put("menuStringRenderer", >>>>>>> menuStringRenderer); >>>>>>> + //screens.getContext().put("menuStringRenderer", >>>>>>> menuStringRenderer); >>>>>>> screens.getContext().put("simpleEncoder", >>>>>>> StringUtil.getEncoder(UtilProperties.getPropertyValue("widget", >>>>>>> getName() + ".encoder"))); >>>>>>> screenStringRenderer.renderScreenBegin(writer, >>>>>>> screens.getContext()); >>>>>>> screens.render(page); |
Re: svn commit: r1517434 - in /ofbiz/trunk/framework/widget: src/org/ofbiz/widget/menu/Macr
|
|
Stop trying to create some sort of solution to a non-existent problem. Things get refactored and sometimes it causes issues, that is the nature of the trunk and Hans can deal with it the same as anyone else, by reporting and/or fixing issues first, and then reverting if no reasonably quick actions can be taken.
It's not appropriate to revert a commit without any discussion whatsoever, he didn't even describe the problem until a day later. How is the original committer supposed to rectify the issue without any details? Regards Scott On 28/08/2013, at 7:53 AM, Jacques Le Roux wrote: > Then maybe a few words on the dev ML would not have hurt. > > Jacques > > Adrian Crum wrote: >> That was not the case in my commit. The macro widget renderers were >> proposed by Jacopo years ago and we discussed it. The implementation was >> incomplete however. So, I merely finished an incomplete implementation >> of a new feature we agreed on years ago. >> >> -Adrian >> >> On 8/27/2013 3:06 AM, Jacques Le Roux wrote: >>> This is indeed a concern. I believe we should always all follow the Jira way of sharing and testing before committing any new >>> major feature or major bug fix (not trivial ones of course). Then, it's possible to wait few days for others to check, not >>> bullet proof but surely better. >>> >>> Jacques >>> >>> Hans Bakker wrote: >>>> If you would have announced this before you implemented it, i would have >>>> known, now in first instance we think this is caused by our changes..... >>>> And only later check the svn updates.... >>>> >>>> Regards, >>>> Hans >>>> >>>> Try entering a purchase invoice: >>>> >>>> Expected collection or sequence. parameterList evaluated instead to >>>> freemarker.template.SimpleScalar on line 51, column 12 in >>>> component://widget/templates/htmlMenuMacroLibrary.ftl. The problematic >>>> instruction: ---------- ==> list parameterList as parameter [on line 51, >>>> column 5 in component://widget/templates/htmlMenuMacroLibrary.ftl] in >>>> user-directive renderLink [on line 1, column 1 in >>>> org.ofbiz.widget.menu.MacroMenuRenderer@21cc9647_1074] ---------- Java >>>> backtrace for programmers: ---------- >>>> freemarker.template.TemplateException: Expected collection or sequence. >>>> parameterList evaluated instead to freemarker.template.SimpleScalar on >>>> line 51, column 12 in >>>> component://widget/templates/htmlMenuMacroLibrary.ftl. at >>>> freemarker.core.TemplateObject.invalidTypeException(TemplateObject.java:136) >>>> at freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock. >>>> >>>> try entering a new accounting transaction: >>>> https://localhost:8443/accounting/control/createAcctgTrans >>>> >>>> Expected collection or sequence. parameterList evaluated instead to >>>> freemarker.template.SimpleScalar on line 51, column 12 in >>>> component://widget/templates/htmlMenuMacroLibrary.ftl. The problematic >>>> instruction: ---------- ==> list parameterList as parameter [on line 51, >>>> column 5 in component://widget/templates/htmlMenuMacroLibrary.ftl] in >>>> user-directive renderLink [on line 1, column 1 in >>>> org.ofbiz.widget.menu.MacroMenuRenderer@6e5faa56_1073] ---------- Java >>>> backtrace for programmers: ---------- >>>> freemarker.template.TemplateException: Expected collection or sequence. >>>> parameterList evaluated instead to freemarker.template.SimpleScalar on >>>> line 51, column 12 in >>>> component://widget/templates/htmlMenuMacroLibrary.ftl. at >>>> >>>> and at a number of other places...... >>>> >>>> Regards, >>>> Hans >>>> >>>> >>>> >>>> >>>> On 08/27/2013 11:44 AM, Adrian Crum wrote: >>>>> No one is asking you to fix anything. All you had to do was post a >>>>> message and I would have fixed it. >>>>> >>>>> There was nothing blocking about my commit, and as I said there was no >>>>> reason to revert it. >>>>> >>>>> Reverting a commit the way you did is NOT co-operation, and >>>>> co-operation is a concept you consistently fail to understand. >>>>> >>>>> -Adrian >>>>> >>>>> On 8/26/2013 8:47 PM, Hans Bakker wrote: >>>>>> Adrian, >>>>>> Normally I would try to fix a problem and i did this pretty often. >>>>>> Because this was a blocking problem i saw no other way then to revert >>>>>> it. >>>>>> >>>>>> Very good to hear you like my commits which at least make a >>>>>> difference for our end users. Although i personally appreciate your >>>>>> framework commits, end-users, which are out bread and butter, are >>>>>> mostly not aware of it. >>>>>> >>>>>> good to co-operate with you, your comments are often very helpful, >>>>>> keep up the good work! >>>>>> >>>>>> Regards, >>>>>> Hans >>>>>> >>>>>> >>>>>> On 08/26/2013 03:47 PM, Adrian Crum wrote: >>>>>>> Hans, >>>>>>> >>>>>>> Normally, we report problems on the mailing list, not revert someone >>>>>>> else's commit. >>>>>>> >>>>>>> This was rude and uncalled for. If I did the same thing to your >>>>>>> buggy commits, none of your contributions would make it into the >>>>>>> project. >>>>>>> >>>>>>> -Adrian >>>>>>> >>>>>>> On 8/25/2013 11:28 PM, [hidden email] wrote: >>>>>>>> Author: hansbak >>>>>>>> Date: Mon Aug 26 06:28:00 2013 >>>>>>>> New Revision: 1517434 >>>>>>>> >>>>>>>> URL: http://svn.apache.org/r1517434 >>>>>>>> Log: >>>>>>>> revert r1517353: it makes the tomahawk theme unusable >>>>>>>> >>>>>>>> Removed: >>>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/menu/MacroMenuRenderer.java >>>>>>>> >>>>>>>> ofbiz/trunk/framework/widget/templates/htmlMenuMacroLibrary.ftl >>>>>>>> Modified: >>>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>>>>> >>>>>>>> >>>>>>>> Modified: >>>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>>>>> URL: >>>>>>>> http://svn.apache.org/viewvc/ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java?rev=1517434&r1=1517433&r2=1517434&view=diff >>>>>>>> ============================================================================== >>>>>>>> >>>>>>>> --- >>>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>>>>> (original) >>>>>>>> +++ >>>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>>>>> Mon Aug 26 06:28:00 2013 >>>>>>>> @@ -38,10 +38,8 @@ import org.ofbiz.webapp.view.AbstractVie >>>>>>>> import org.ofbiz.webapp.view.ViewHandlerException; >>>>>>>> import org.ofbiz.widget.form.FormStringRenderer; >>>>>>>> import org.ofbiz.widget.form.MacroFormRenderer; >>>>>>>> -import org.ofbiz.widget.menu.MacroMenuRenderer; >>>>>>>> -import org.ofbiz.widget.menu.MenuStringRenderer; >>>>>>>> -import org.ofbiz.widget.tree.MacroTreeRenderer; >>>>>>>> import org.ofbiz.widget.tree.TreeStringRenderer; >>>>>>>> +import org.ofbiz.widget.tree.MacroTreeRenderer; >>>>>>>> import org.xml.sax.SAXException; >>>>>>>> import freemarker.template.TemplateException; >>>>>>>> @@ -92,13 +90,15 @@ public class MacroScreenViewHandler exte >>>>>>>> ScreenStringRenderer screenStringRenderer = new >>>>>>>> MacroScreenRenderer(UtilProperties.getPropertyValue("widget", >>>>>>>> getName() + ".name"), UtilProperties.getPropertyValue("widget", >>>>>>>> getName() + ".screenrenderer")); >>>>>>>> FormStringRenderer formStringRenderer = new >>>>>>>> MacroFormRenderer(UtilProperties.getPropertyValue("widget", >>>>>>>> getName() + ".formrenderer"), request, response); >>>>>>>> TreeStringRenderer treeStringRenderer = new >>>>>>>> MacroTreeRenderer(UtilProperties.getPropertyValue("widget", >>>>>>>> getName() + ".treerenderer"), writer); >>>>>>>> - MenuStringRenderer menuStringRenderer = new >>>>>>>> MacroMenuRenderer(UtilProperties.getPropertyValue("widget", >>>>>>>> getName() + ".menurenderer"), request, response); >>>>>>>> + // TODO: uncomment these lines when the renderers are >>>>>>>> implemented >>>>>>>> + //MenuStringRenderer menuStringRenderer = new >>>>>>>> MacroMenuRenderer(UtilProperties.getPropertyValue("widget", >>>>>>>> getName() + ".menurenderer"), writer); >>>>>>>> ScreenRenderer screens = new ScreenRenderer(writer, >>>>>>>> null, screenStringRenderer); >>>>>>>> screens.populateContextForRequest(request, response, >>>>>>>> servletContext); >>>>>>>> + // this is the object used to render forms from their >>>>>>>> definitions >>>>>>>> screens.getContext().put("formStringRenderer", >>>>>>>> formStringRenderer); >>>>>>>> screens.getContext().put("treeStringRenderer", >>>>>>>> treeStringRenderer); >>>>>>>> - screens.getContext().put("menuStringRenderer", >>>>>>>> menuStringRenderer); >>>>>>>> + //screens.getContext().put("menuStringRenderer", >>>>>>>> menuStringRenderer); >>>>>>>> screens.getContext().put("simpleEncoder", >>>>>>>> StringUtil.getEncoder(UtilProperties.getPropertyValue("widget", >>>>>>>> getName() + ".encoder"))); >>>>>>>> screenStringRenderer.renderScreenBegin(writer, >>>>>>>> screens.getContext()); >>>>>>>> screens.render(page); |
Re: svn commit: r1517434 - in /ofbiz/trunk/framework/widget: src/org/ofbiz/widget/menu/Macr
|
Administrator
|
Thanks for your opinion Scott,
Let's try to keep it productive... Yes, that I agreed on: http://markmail.org/message/2e3qo2ydna4lp5gp I'm sure you did not miss it even if it's not part of this email. I still believe that, the more we share through Jira, the better. For many reasons it's more effective than ML. For this peculiar case, I must admit, years after, it was out of mind. Here a reference to Jira issue, with even a simple sentence in description, possibly with a reference to the "aforementioned" dev ML thread (the one about "macro widget renderers") and if necessary commit/s reference/s, would have help. What we are so far discussing about in this thread is based on what we already agreed (or at least what I remember about it). First discuss on dev ML and if necessary open a Jira to collect/share opininons and keep a track on all possible info. If there is nothing let to discuss and it's a simple thing, don't create a Jira and then code and commit straight away. Let's now compare the possible flows of actions. Currently (hell) using present for a better story: Years ago, we discuss on "macro widget renderers" on dev ML and agree we can code and commit straight away (correct me if there is/are (a) Jira issue/s about it) Few days ago, Adrian directly commits changes about macro widget renderers; without noticing on dev ML, thinking everybody remember what we talked about. Hans finds few issues and reverts Adrian's commit without noticing anyone on dev ML. I guess, to do a such thing, at this point Hans did not remember about macro widget renderers and "netiquette" was a bit upset, or in a hurry. Adrian is (rightly) upset and then our current discussion begins... Possibly (heaven): Years ago, we would have discussed on "macro widget renderers" on dev ML and created (a) Jira issue/s with references (links) to the discussion and commits and all possibly shared info. Few days ago, Adrian would have committed changes, noticing others on dev ML, with just a link about the Jira (or just saying there is one, for others to look for). Possibly only with a comment/link in the commit. After Hans finds few issues he can refer to the Jira or/and the previous discussion about "macro widget renderers". He understands what and why Adrian did, and ask for help on the dev ML, instead of abruptly reverting Adrian's commit (unfair).- As I said, I agree Hans made the misconduct. But it's not a reason to put all on him and not try to get things better. This is my opinion (Jira is our friend) Jacques Scott Gray wrote: > Stop trying to create some sort of solution to a non-existent problem. Things get refactored and sometimes it causes issues, > that is the nature of the trunk and Hans can deal with it the same as anyone else, by reporting and/or fixing issues first, and > then reverting if no reasonably quick actions can be taken. > > It's not appropriate to revert a commit without any discussion whatsoever, he didn't even describe the problem until a day later. > How is the original committer supposed to rectify the issue without any details? > > Regards > Scott > > On 28/08/2013, at 7:53 AM, Jacques Le Roux wrote: > >> Then maybe a few words on the dev ML would not have hurt. >> >> Jacques >> >> Adrian Crum wrote: >>> That was not the case in my commit. The macro widget renderers were >>> proposed by Jacopo years ago and we discussed it. The implementation was >>> incomplete however. So, I merely finished an incomplete implementation >>> of a new feature we agreed on years ago. >>> >>> -Adrian >>> >>> On 8/27/2013 3:06 AM, Jacques Le Roux wrote: >>>> This is indeed a concern. I believe we should always all follow the Jira way of sharing and testing before committing any new >>>> major feature or major bug fix (not trivial ones of course). Then, it's possible to wait few days for others to check, not >>>> bullet proof but surely better. >>>> >>>> Jacques >>>> >>>> Hans Bakker wrote: >>>>> If you would have announced this before you implemented it, i would have >>>>> known, now in first instance we think this is caused by our changes..... >>>>> And only later check the svn updates.... >>>>> >>>>> Regards, >>>>> Hans >>>>> >>>>> Try entering a purchase invoice: >>>>> >>>>> Expected collection or sequence. parameterList evaluated instead to >>>>> freemarker.template.SimpleScalar on line 51, column 12 in >>>>> component://widget/templates/htmlMenuMacroLibrary.ftl. The problematic >>>>> instruction: ---------- ==> list parameterList as parameter [on line 51, >>>>> column 5 in component://widget/templates/htmlMenuMacroLibrary.ftl] in >>>>> user-directive renderLink [on line 1, column 1 in >>>>> org.ofbiz.widget.menu.MacroMenuRenderer@21cc9647_1074] ---------- Java >>>>> backtrace for programmers: ---------- >>>>> freemarker.template.TemplateException: Expected collection or sequence. >>>>> parameterList evaluated instead to freemarker.template.SimpleScalar on >>>>> line 51, column 12 in >>>>> component://widget/templates/htmlMenuMacroLibrary.ftl. at >>>>> freemarker.core.TemplateObject.invalidTypeException(TemplateObject.java:136) >>>>> at freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock. >>>>> >>>>> try entering a new accounting transaction: >>>>> https://localhost:8443/accounting/control/createAcctgTrans >>>>> >>>>> Expected collection or sequence. parameterList evaluated instead to >>>>> freemarker.template.SimpleScalar on line 51, column 12 in >>>>> component://widget/templates/htmlMenuMacroLibrary.ftl. The problematic >>>>> instruction: ---------- ==> list parameterList as parameter [on line 51, >>>>> column 5 in component://widget/templates/htmlMenuMacroLibrary.ftl] in >>>>> user-directive renderLink [on line 1, column 1 in >>>>> org.ofbiz.widget.menu.MacroMenuRenderer@6e5faa56_1073] ---------- Java >>>>> backtrace for programmers: ---------- >>>>> freemarker.template.TemplateException: Expected collection or sequence. >>>>> parameterList evaluated instead to freemarker.template.SimpleScalar on >>>>> line 51, column 12 in >>>>> component://widget/templates/htmlMenuMacroLibrary.ftl. at >>>>> >>>>> and at a number of other places...... >>>>> >>>>> Regards, >>>>> Hans >>>>> >>>>> >>>>> >>>>> >>>>> On 08/27/2013 11:44 AM, Adrian Crum wrote: >>>>>> No one is asking you to fix anything. All you had to do was post a >>>>>> message and I would have fixed it. >>>>>> >>>>>> There was nothing blocking about my commit, and as I said there was no >>>>>> reason to revert it. >>>>>> >>>>>> Reverting a commit the way you did is NOT co-operation, and >>>>>> co-operation is a concept you consistently fail to understand. >>>>>> >>>>>> -Adrian >>>>>> >>>>>> On 8/26/2013 8:47 PM, Hans Bakker wrote: >>>>>>> Adrian, >>>>>>> Normally I would try to fix a problem and i did this pretty often. >>>>>>> Because this was a blocking problem i saw no other way then to revert >>>>>>> it. >>>>>>> >>>>>>> Very good to hear you like my commits which at least make a >>>>>>> difference for our end users. Although i personally appreciate your >>>>>>> framework commits, end-users, which are out bread and butter, are >>>>>>> mostly not aware of it. >>>>>>> >>>>>>> good to co-operate with you, your comments are often very helpful, >>>>>>> keep up the good work! >>>>>>> >>>>>>> Regards, >>>>>>> Hans >>>>>>> >>>>>>> >>>>>>> On 08/26/2013 03:47 PM, Adrian Crum wrote: >>>>>>>> Hans, >>>>>>>> >>>>>>>> Normally, we report problems on the mailing list, not revert someone >>>>>>>> else's commit. >>>>>>>> >>>>>>>> This was rude and uncalled for. If I did the same thing to your >>>>>>>> buggy commits, none of your contributions would make it into the >>>>>>>> project. >>>>>>>> >>>>>>>> -Adrian >>>>>>>> >>>>>>>> On 8/25/2013 11:28 PM, [hidden email] wrote: >>>>>>>>> Author: hansbak >>>>>>>>> Date: Mon Aug 26 06:28:00 2013 >>>>>>>>> New Revision: 1517434 >>>>>>>>> >>>>>>>>> URL: http://svn.apache.org/r1517434 >>>>>>>>> Log: >>>>>>>>> revert r1517353: it makes the tomahawk theme unusable >>>>>>>>> >>>>>>>>> Removed: >>>>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/menu/MacroMenuRenderer.java >>>>>>>>> >>>>>>>>> ofbiz/trunk/framework/widget/templates/htmlMenuMacroLibrary.ftl >>>>>>>>> Modified: >>>>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>>>>>> >>>>>>>>> >>>>>>>>> Modified: >>>>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>>>>>> URL: >>>>>>>>> http://svn.apache.org/viewvc/ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java?rev=1517434&r1=1517433&r2=1517434&view=diff >>>>>>>>> ============================================================================== >>>>>>>>> >>>>>>>>> --- >>>>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>>>>>> (original) >>>>>>>>> +++ >>>>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>>>>>> Mon Aug 26 06:28:00 2013 >>>>>>>>> @@ -38,10 +38,8 @@ import org.ofbiz.webapp.view.AbstractVie >>>>>>>>> import org.ofbiz.webapp.view.ViewHandlerException; >>>>>>>>> import org.ofbiz.widget.form.FormStringRenderer; >>>>>>>>> import org.ofbiz.widget.form.MacroFormRenderer; >>>>>>>>> -import org.ofbiz.widget.menu.MacroMenuRenderer; >>>>>>>>> -import org.ofbiz.widget.menu.MenuStringRenderer; >>>>>>>>> -import org.ofbiz.widget.tree.MacroTreeRenderer; >>>>>>>>> import org.ofbiz.widget.tree.TreeStringRenderer; >>>>>>>>> +import org.ofbiz.widget.tree.MacroTreeRenderer; >>>>>>>>> import org.xml.sax.SAXException; >>>>>>>>> import freemarker.template.TemplateException; >>>>>>>>> @@ -92,13 +90,15 @@ public class MacroScreenViewHandler exte >>>>>>>>> ScreenStringRenderer screenStringRenderer = new >>>>>>>>> MacroScreenRenderer(UtilProperties.getPropertyValue("widget", >>>>>>>>> getName() + ".name"), UtilProperties.getPropertyValue("widget", >>>>>>>>> getName() + ".screenrenderer")); >>>>>>>>> FormStringRenderer formStringRenderer = new >>>>>>>>> MacroFormRenderer(UtilProperties.getPropertyValue("widget", >>>>>>>>> getName() + ".formrenderer"), request, response); >>>>>>>>> TreeStringRenderer treeStringRenderer = new >>>>>>>>> MacroTreeRenderer(UtilProperties.getPropertyValue("widget", >>>>>>>>> getName() + ".treerenderer"), writer); >>>>>>>>> - MenuStringRenderer menuStringRenderer = new >>>>>>>>> MacroMenuRenderer(UtilProperties.getPropertyValue("widget", >>>>>>>>> getName() + ".menurenderer"), request, response); >>>>>>>>> + // TODO: uncomment these lines when the renderers are >>>>>>>>> implemented >>>>>>>>> + //MenuStringRenderer menuStringRenderer = new >>>>>>>>> MacroMenuRenderer(UtilProperties.getPropertyValue("widget", >>>>>>>>> getName() + ".menurenderer"), writer); >>>>>>>>> ScreenRenderer screens = new ScreenRenderer(writer, >>>>>>>>> null, screenStringRenderer); >>>>>>>>> screens.populateContextForRequest(request, response, >>>>>>>>> servletContext); >>>>>>>>> + // this is the object used to render forms from their >>>>>>>>> definitions >>>>>>>>> screens.getContext().put("formStringRenderer", >>>>>>>>> formStringRenderer); >>>>>>>>> screens.getContext().put("treeStringRenderer", >>>>>>>>> treeStringRenderer); >>>>>>>>> - screens.getContext().put("menuStringRenderer", >>>>>>>>> menuStringRenderer); >>>>>>>>> + //screens.getContext().put("menuStringRenderer", >>>>>>>>> menuStringRenderer); >>>>>>>>> screens.getContext().put("simpleEncoder", >>>>>>>>> StringUtil.getEncoder(UtilProperties.getPropertyValue("widget", >>>>>>>>> getName() + ".encoder"))); >>>>>>>>> screenStringRenderer.renderScreenBegin(writer, >>>>>>>>> screens.getContext()); >>>>>>>>> screens.render(page); |
Re: svn commit: r1517434 - in /ofbiz/trunk/framework/widget: src/org/ofbiz/widget/menu/Macr
|
|
Keeping things productive was definitely the goal of my email. A jira just wasn't necessary in this case and requiring one adds additional burden to committers with very little real benefit. The only purpose served would have been if somebody actually applied the patch and tested it which is unlikely and would have probably taken at least a few days, no design discussion was needed. Adrian fixed the issue within a few hours of receiving a proper description of what the problem was which is fantastic.
The *only* issue here is that code was reverted without *any* discussion or notification of the problems faced. A bit rude for sure, but I don't think it is the end of the world. I would only ask that Hans be more mindful in the future and follow the process we've always followed for as long as I can remember. It only requires us to work together as a team rather than against each other. Regards Scott On 28/08/2013, at 10:10 PM, Jacques Le Roux wrote: > Thanks for your opinion Scott, > > Let's try to keep it productive... > > Yes, that I agreed on: http://markmail.org/message/2e3qo2ydna4lp5gp > I'm sure you did not miss it even if it's not part of this email. > > I still believe that, the more we share through Jira, the better. For many reasons it's more effective than ML. > For this peculiar case, I must admit, years after, it was out of mind. Here a reference to Jira issue, with even a simple sentence in description, possibly with a reference to the "aforementioned" dev ML thread (the one about "macro widget renderers") and if necessary commit/s reference/s, would have help. > > What we are so far discussing about in this thread is based on what we already agreed (or at least what I remember about it). > First discuss on dev ML and if necessary open a Jira to collect/share opininons and keep a track on all possible info. > If there is nothing let to discuss and it's a simple thing, don't create a Jira and then code and commit straight away. > > Let's now compare the possible flows of actions. > > Currently (hell) using present for a better story: > Years ago, we discuss on "macro widget renderers" on dev ML and agree we can code and commit straight away (correct me if there is/are (a) Jira issue/s about it) > Few days ago, Adrian directly commits changes about macro widget renderers; without noticing on dev ML, thinking everybody remember what we talked about. > Hans finds few issues and reverts Adrian's commit without noticing anyone on dev ML. I guess, to do a such thing, at this point Hans did not remember about macro widget renderers and "netiquette" was a bit upset, or in a hurry. > Adrian is (rightly) upset and then our current discussion begins... > > Possibly (heaven): > Years ago, we would have discussed on "macro widget renderers" on dev ML and created (a) Jira issue/s with references (links) to the discussion and commits and all possibly shared info. > Few days ago, Adrian would have committed changes, noticing others on dev ML, with just a link about the Jira (or just saying there is one, for others to look for). Possibly only with a comment/link in the commit. > After Hans finds few issues he can refer to the Jira or/and the previous discussion about "macro widget renderers". He understands what and why Adrian did, and ask for help on the dev ML, instead of abruptly reverting Adrian's commit (unfair).- > > As I said, I agree Hans made the misconduct. But it's not a reason to put all on him and not try to get things better. > > This is my opinion (Jira is our friend) > > Jacques > > Scott Gray wrote: >> Stop trying to create some sort of solution to a non-existent problem. Things get refactored and sometimes it causes issues, >> that is the nature of the trunk and Hans can deal with it the same as anyone else, by reporting and/or fixing issues first, and >> then reverting if no reasonably quick actions can be taken. >> >> It's not appropriate to revert a commit without any discussion whatsoever, he didn't even describe the problem until a day later. >> How is the original committer supposed to rectify the issue without any details? >> >> Regards >> Scott >> >> On 28/08/2013, at 7:53 AM, Jacques Le Roux wrote: >> >>> Then maybe a few words on the dev ML would not have hurt. >>> >>> Jacques >>> >>> Adrian Crum wrote: >>>> That was not the case in my commit. The macro widget renderers were >>>> proposed by Jacopo years ago and we discussed it. The implementation was >>>> incomplete however. So, I merely finished an incomplete implementation >>>> of a new feature we agreed on years ago. >>>> >>>> -Adrian >>>> >>>> On 8/27/2013 3:06 AM, Jacques Le Roux wrote: >>>>> This is indeed a concern. I believe we should always all follow the Jira way of sharing and testing before committing any new >>>>> major feature or major bug fix (not trivial ones of course). Then, it's possible to wait few days for others to check, not >>>>> bullet proof but surely better. >>>>> >>>>> Jacques >>>>> >>>>> Hans Bakker wrote: >>>>>> If you would have announced this before you implemented it, i would have >>>>>> known, now in first instance we think this is caused by our changes..... >>>>>> And only later check the svn updates.... >>>>>> >>>>>> Regards, >>>>>> Hans >>>>>> >>>>>> Try entering a purchase invoice: >>>>>> >>>>>> Expected collection or sequence. parameterList evaluated instead to >>>>>> freemarker.template.SimpleScalar on line 51, column 12 in >>>>>> component://widget/templates/htmlMenuMacroLibrary.ftl. The problematic >>>>>> instruction: ---------- ==> list parameterList as parameter [on line 51, >>>>>> column 5 in component://widget/templates/htmlMenuMacroLibrary.ftl] in >>>>>> user-directive renderLink [on line 1, column 1 in >>>>>> org.ofbiz.widget.menu.MacroMenuRenderer@21cc9647_1074] ---------- Java >>>>>> backtrace for programmers: ---------- >>>>>> freemarker.template.TemplateException: Expected collection or sequence. >>>>>> parameterList evaluated instead to freemarker.template.SimpleScalar on >>>>>> line 51, column 12 in >>>>>> component://widget/templates/htmlMenuMacroLibrary.ftl. at >>>>>> freemarker.core.TemplateObject.invalidTypeException(TemplateObject.java:136) >>>>>> at freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock. >>>>>> >>>>>> try entering a new accounting transaction: >>>>>> https://localhost:8443/accounting/control/createAcctgTrans >>>>>> >>>>>> Expected collection or sequence. parameterList evaluated instead to >>>>>> freemarker.template.SimpleScalar on line 51, column 12 in >>>>>> component://widget/templates/htmlMenuMacroLibrary.ftl. The problematic >>>>>> instruction: ---------- ==> list parameterList as parameter [on line 51, >>>>>> column 5 in component://widget/templates/htmlMenuMacroLibrary.ftl] in >>>>>> user-directive renderLink [on line 1, column 1 in >>>>>> org.ofbiz.widget.menu.MacroMenuRenderer@6e5faa56_1073] ---------- Java >>>>>> backtrace for programmers: ---------- >>>>>> freemarker.template.TemplateException: Expected collection or sequence. >>>>>> parameterList evaluated instead to freemarker.template.SimpleScalar on >>>>>> line 51, column 12 in >>>>>> component://widget/templates/htmlMenuMacroLibrary.ftl. at >>>>>> >>>>>> and at a number of other places...... >>>>>> >>>>>> Regards, >>>>>> Hans >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 08/27/2013 11:44 AM, Adrian Crum wrote: >>>>>>> No one is asking you to fix anything. All you had to do was post a >>>>>>> message and I would have fixed it. >>>>>>> >>>>>>> There was nothing blocking about my commit, and as I said there was no >>>>>>> reason to revert it. >>>>>>> >>>>>>> Reverting a commit the way you did is NOT co-operation, and >>>>>>> co-operation is a concept you consistently fail to understand. >>>>>>> >>>>>>> -Adrian >>>>>>> >>>>>>> On 8/26/2013 8:47 PM, Hans Bakker wrote: >>>>>>>> Adrian, >>>>>>>> Normally I would try to fix a problem and i did this pretty often. >>>>>>>> Because this was a blocking problem i saw no other way then to revert >>>>>>>> it. >>>>>>>> >>>>>>>> Very good to hear you like my commits which at least make a >>>>>>>> difference for our end users. Although i personally appreciate your >>>>>>>> framework commits, end-users, which are out bread and butter, are >>>>>>>> mostly not aware of it. >>>>>>>> >>>>>>>> good to co-operate with you, your comments are often very helpful, >>>>>>>> keep up the good work! >>>>>>>> >>>>>>>> Regards, >>>>>>>> Hans >>>>>>>> >>>>>>>> >>>>>>>> On 08/26/2013 03:47 PM, Adrian Crum wrote: >>>>>>>>> Hans, >>>>>>>>> >>>>>>>>> Normally, we report problems on the mailing list, not revert someone >>>>>>>>> else's commit. >>>>>>>>> >>>>>>>>> This was rude and uncalled for. If I did the same thing to your >>>>>>>>> buggy commits, none of your contributions would make it into the >>>>>>>>> project. >>>>>>>>> >>>>>>>>> -Adrian >>>>>>>>> >>>>>>>>> On 8/25/2013 11:28 PM, [hidden email] wrote: >>>>>>>>>> Author: hansbak >>>>>>>>>> Date: Mon Aug 26 06:28:00 2013 >>>>>>>>>> New Revision: 1517434 >>>>>>>>>> >>>>>>>>>> URL: http://svn.apache.org/r1517434 >>>>>>>>>> Log: >>>>>>>>>> revert r1517353: it makes the tomahawk theme unusable >>>>>>>>>> >>>>>>>>>> Removed: >>>>>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/menu/MacroMenuRenderer.java >>>>>>>>>> >>>>>>>>>> ofbiz/trunk/framework/widget/templates/htmlMenuMacroLibrary.ftl >>>>>>>>>> Modified: >>>>>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Modified: >>>>>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>>>>>>> URL: >>>>>>>>>> http://svn.apache.org/viewvc/ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java?rev=1517434&r1=1517433&r2=1517434&view=diff >>>>>>>>>> ============================================================================== >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>>>>>>> (original) >>>>>>>>>> +++ >>>>>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>>>>>>> Mon Aug 26 06:28:00 2013 >>>>>>>>>> @@ -38,10 +38,8 @@ import org.ofbiz.webapp.view.AbstractVie >>>>>>>>>> import org.ofbiz.webapp.view.ViewHandlerException; >>>>>>>>>> import org.ofbiz.widget.form.FormStringRenderer; >>>>>>>>>> import org.ofbiz.widget.form.MacroFormRenderer; >>>>>>>>>> -import org.ofbiz.widget.menu.MacroMenuRenderer; >>>>>>>>>> -import org.ofbiz.widget.menu.MenuStringRenderer; >>>>>>>>>> -import org.ofbiz.widget.tree.MacroTreeRenderer; >>>>>>>>>> import org.ofbiz.widget.tree.TreeStringRenderer; >>>>>>>>>> +import org.ofbiz.widget.tree.MacroTreeRenderer; >>>>>>>>>> import org.xml.sax.SAXException; >>>>>>>>>> import freemarker.template.TemplateException; >>>>>>>>>> @@ -92,13 +90,15 @@ public class MacroScreenViewHandler exte >>>>>>>>>> ScreenStringRenderer screenStringRenderer = new >>>>>>>>>> MacroScreenRenderer(UtilProperties.getPropertyValue("widget", >>>>>>>>>> getName() + ".name"), UtilProperties.getPropertyValue("widget", >>>>>>>>>> getName() + ".screenrenderer")); >>>>>>>>>> FormStringRenderer formStringRenderer = new >>>>>>>>>> MacroFormRenderer(UtilProperties.getPropertyValue("widget", >>>>>>>>>> getName() + ".formrenderer"), request, response); >>>>>>>>>> TreeStringRenderer treeStringRenderer = new >>>>>>>>>> MacroTreeRenderer(UtilProperties.getPropertyValue("widget", >>>>>>>>>> getName() + ".treerenderer"), writer); >>>>>>>>>> - MenuStringRenderer menuStringRenderer = new >>>>>>>>>> MacroMenuRenderer(UtilProperties.getPropertyValue("widget", >>>>>>>>>> getName() + ".menurenderer"), request, response); >>>>>>>>>> + // TODO: uncomment these lines when the renderers are >>>>>>>>>> implemented >>>>>>>>>> + //MenuStringRenderer menuStringRenderer = new >>>>>>>>>> MacroMenuRenderer(UtilProperties.getPropertyValue("widget", >>>>>>>>>> getName() + ".menurenderer"), writer); >>>>>>>>>> ScreenRenderer screens = new ScreenRenderer(writer, >>>>>>>>>> null, screenStringRenderer); >>>>>>>>>> screens.populateContextForRequest(request, response, >>>>>>>>>> servletContext); >>>>>>>>>> + // this is the object used to render forms from their >>>>>>>>>> definitions >>>>>>>>>> screens.getContext().put("formStringRenderer", >>>>>>>>>> formStringRenderer); >>>>>>>>>> screens.getContext().put("treeStringRenderer", >>>>>>>>>> treeStringRenderer); >>>>>>>>>> - screens.getContext().put("menuStringRenderer", >>>>>>>>>> menuStringRenderer); >>>>>>>>>> + //screens.getContext().put("menuStringRenderer", >>>>>>>>>> menuStringRenderer); >>>>>>>>>> screens.getContext().put("simpleEncoder", >>>>>>>>>> StringUtil.getEncoder(UtilProperties.getPropertyValue("widget", >>>>>>>>>> getName() + ".encoder"))); >>>>>>>>>> screenStringRenderer.renderScreenBegin(writer, >>>>>>>>>> screens.getContext()); >>>>>>>>>> screens.render(page); |
Re: svn commit: r1517434 - in /ofbiz/trunk/framework/widget: src/org/ofbiz/widget/menu/Macr
|
|
In reply to this post by Jacques Le Roux
Thank you Jacques, you are doing a really good job not only committing
contributions but also keeping everybody working together. I admit my action was a bit quick, but on the other hand getting a change in the system which is blocking, (this change cannot be shown to a customer) then still my action was at least understandable. It took me some time which commit did it where i was short in time anyway. Still I think that changes which are blocking in major functions like the main menu should not be committed. That said, let me make some general comments. My business would not exist and continue to exist without the help of OFBIz committers, In general, the last couple of years, Scott and Adrian did an excellent job on commenting and contributions, Jacques is the King and help line of the contributors, Jacopo more on the background making sure Apache interests are respected and I am trying to contribute requests from my customers more on the application level. The last 2 years I see the requests especially from larger companies increasing. We are expanding the activities in AntWebsystems and will move to a new building the end of the Year. Let stick together and encourage each other making this product better and refrain from sending negative statements? Thank you all, committers and contributers for the time you spend on Apache OFBiz. Regards, Hans On 08/28/2013 05:10 PM, Jacques Le Roux wrote: > Thanks for your opinion Scott, > > Let's try to keep it productive... > > Yes, that I agreed on: http://markmail.org/message/2e3qo2ydna4lp5gp > I'm sure you did not miss it even if it's not part of this email. > > I still believe that, the more we share through Jira, the better. For many reasons it's more effective than ML. > For this peculiar case, I must admit, years after, it was out of mind. Here a reference to Jira issue, with even a simple sentence in description, possibly with a reference to the "aforementioned" dev ML thread (the one about "macro widget renderers") and if necessary commit/s reference/s, would have help. > > What we are so far discussing about in this thread is based on what we already agreed (or at least what I remember about it). > First discuss on dev ML and if necessary open a Jira to collect/share opininons and keep a track on all possible info. > If there is nothing let to discuss and it's a simple thing, don't create a Jira and then code and commit straight away. > > Let's now compare the possible flows of actions. > > Currently (hell) using present for a better story: > Years ago, we discuss on "macro widget renderers" on dev ML and agree we can code and commit straight away (correct me if there is/are (a) Jira issue/s about it) > Few days ago, Adrian directly commits changes about macro widget renderers; without noticing on dev ML, thinking everybody remember what we talked about. > Hans finds few issues and reverts Adrian's commit without noticing anyone on dev ML. I guess, to do a such thing, at this point Hans did not remember about macro widget renderers and "netiquette" was a bit upset, or in a hurry. > Adrian is (rightly) upset and then our current discussion begins... > > Possibly (heaven): > Years ago, we would have discussed on "macro widget renderers" on dev ML and created (a) Jira issue/s with references (links) to the discussion and commits and all possibly shared info. > Few days ago, Adrian would have committed changes, noticing others on dev ML, with just a link about the Jira (or just saying there is one, for others to look for). Possibly only with a comment/link in the commit. > After Hans finds few issues he can refer to the Jira or/and the previous discussion about "macro widget renderers". He understands what and why Adrian did, and ask for help on the dev ML, instead of abruptly reverting Adrian's commit (unfair).- > > As I said, I agree Hans made the misconduct. But it's not a reason to put all on him and not try to get things better. > > This is my opinion (Jira is our friend) > > Jacques > > Scott Gray wrote: >> Stop trying to create some sort of solution to a non-existent problem. Things get refactored and sometimes it causes issues, >> that is the nature of the trunk and Hans can deal with it the same as anyone else, by reporting and/or fixing issues first, and >> then reverting if no reasonably quick actions can be taken. >> >> It's not appropriate to revert a commit without any discussion whatsoever, he didn't even describe the problem until a day later. >> How is the original committer supposed to rectify the issue without any details? >> >> Regards >> Scott >> >> On 28/08/2013, at 7:53 AM, Jacques Le Roux wrote: >> >>> Then maybe a few words on the dev ML would not have hurt. >>> >>> Jacques >>> >>> Adrian Crum wrote: >>>> That was not the case in my commit. The macro widget renderers were >>>> proposed by Jacopo years ago and we discussed it. The implementation was >>>> incomplete however. So, I merely finished an incomplete implementation >>>> of a new feature we agreed on years ago. >>>> >>>> -Adrian >>>> >>>> On 8/27/2013 3:06 AM, Jacques Le Roux wrote: >>>>> This is indeed a concern. I believe we should always all follow the Jira way of sharing and testing before committing any new >>>>> major feature or major bug fix (not trivial ones of course). Then, it's possible to wait few days for others to check, not >>>>> bullet proof but surely better. >>>>> >>>>> Jacques >>>>> >>>>> Hans Bakker wrote: >>>>>> If you would have announced this before you implemented it, i would have >>>>>> known, now in first instance we think this is caused by our changes..... >>>>>> And only later check the svn updates.... >>>>>> >>>>>> Regards, >>>>>> Hans >>>>>> >>>>>> Try entering a purchase invoice: >>>>>> >>>>>> Expected collection or sequence. parameterList evaluated instead to >>>>>> freemarker.template.SimpleScalar on line 51, column 12 in >>>>>> component://widget/templates/htmlMenuMacroLibrary.ftl. The problematic >>>>>> instruction: ---------- ==> list parameterList as parameter [on line 51, >>>>>> column 5 in component://widget/templates/htmlMenuMacroLibrary.ftl] in >>>>>> user-directive renderLink [on line 1, column 1 in >>>>>> org.ofbiz.widget.menu.MacroMenuRenderer@21cc9647_1074] ---------- Java >>>>>> backtrace for programmers: ---------- >>>>>> freemarker.template.TemplateException: Expected collection or sequence. >>>>>> parameterList evaluated instead to freemarker.template.SimpleScalar on >>>>>> line 51, column 12 in >>>>>> component://widget/templates/htmlMenuMacroLibrary.ftl. at >>>>>> freemarker.core.TemplateObject.invalidTypeException(TemplateObject.java:136) >>>>>> at freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock. >>>>>> >>>>>> try entering a new accounting transaction: >>>>>> https://localhost:8443/accounting/control/createAcctgTrans >>>>>> >>>>>> Expected collection or sequence. parameterList evaluated instead to >>>>>> freemarker.template.SimpleScalar on line 51, column 12 in >>>>>> component://widget/templates/htmlMenuMacroLibrary.ftl. The problematic >>>>>> instruction: ---------- ==> list parameterList as parameter [on line 51, >>>>>> column 5 in component://widget/templates/htmlMenuMacroLibrary.ftl] in >>>>>> user-directive renderLink [on line 1, column 1 in >>>>>> org.ofbiz.widget.menu.MacroMenuRenderer@6e5faa56_1073] ---------- Java >>>>>> backtrace for programmers: ---------- >>>>>> freemarker.template.TemplateException: Expected collection or sequence. >>>>>> parameterList evaluated instead to freemarker.template.SimpleScalar on >>>>>> line 51, column 12 in >>>>>> component://widget/templates/htmlMenuMacroLibrary.ftl. at >>>>>> >>>>>> and at a number of other places...... >>>>>> >>>>>> Regards, >>>>>> Hans >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 08/27/2013 11:44 AM, Adrian Crum wrote: >>>>>>> No one is asking you to fix anything. All you had to do was post a >>>>>>> message and I would have fixed it. >>>>>>> >>>>>>> There was nothing blocking about my commit, and as I said there was no >>>>>>> reason to revert it. >>>>>>> >>>>>>> Reverting a commit the way you did is NOT co-operation, and >>>>>>> co-operation is a concept you consistently fail to understand. >>>>>>> >>>>>>> -Adrian >>>>>>> >>>>>>> On 8/26/2013 8:47 PM, Hans Bakker wrote: >>>>>>>> Adrian, >>>>>>>> Normally I would try to fix a problem and i did this pretty often. >>>>>>>> Because this was a blocking problem i saw no other way then to revert >>>>>>>> it. >>>>>>>> >>>>>>>> Very good to hear you like my commits which at least make a >>>>>>>> difference for our end users. Although i personally appreciate your >>>>>>>> framework commits, end-users, which are out bread and butter, are >>>>>>>> mostly not aware of it. >>>>>>>> >>>>>>>> good to co-operate with you, your comments are often very helpful, >>>>>>>> keep up the good work! >>>>>>>> >>>>>>>> Regards, >>>>>>>> Hans >>>>>>>> >>>>>>>> >>>>>>>> On 08/26/2013 03:47 PM, Adrian Crum wrote: >>>>>>>>> Hans, >>>>>>>>> >>>>>>>>> Normally, we report problems on the mailing list, not revert someone >>>>>>>>> else's commit. >>>>>>>>> >>>>>>>>> This was rude and uncalled for. If I did the same thing to your >>>>>>>>> buggy commits, none of your contributions would make it into the >>>>>>>>> project. >>>>>>>>> >>>>>>>>> -Adrian >>>>>>>>> >>>>>>>>> On 8/25/2013 11:28 PM, [hidden email] wrote: >>>>>>>>>> Author: hansbak >>>>>>>>>> Date: Mon Aug 26 06:28:00 2013 >>>>>>>>>> New Revision: 1517434 >>>>>>>>>> >>>>>>>>>> URL: http://svn.apache.org/r1517434 >>>>>>>>>> Log: >>>>>>>>>> revert r1517353: it makes the tomahawk theme unusable >>>>>>>>>> >>>>>>>>>> Removed: >>>>>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/menu/MacroMenuRenderer.java >>>>>>>>>> >>>>>>>>>> ofbiz/trunk/framework/widget/templates/htmlMenuMacroLibrary.ftl >>>>>>>>>> Modified: >>>>>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Modified: >>>>>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>>>>>>> URL: >>>>>>>>>> http://svn.apache.org/viewvc/ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java?rev=1517434&r1=1517433&r2=1517434&view=diff >>>>>>>>>> ============================================================================== >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>>>>>>> (original) >>>>>>>>>> +++ >>>>>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>>>>>>> Mon Aug 26 06:28:00 2013 >>>>>>>>>> @@ -38,10 +38,8 @@ import org.ofbiz.webapp.view.AbstractVie >>>>>>>>>> import org.ofbiz.webapp.view.ViewHandlerException; >>>>>>>>>> import org.ofbiz.widget.form.FormStringRenderer; >>>>>>>>>> import org.ofbiz.widget.form.MacroFormRenderer; >>>>>>>>>> -import org.ofbiz.widget.menu.MacroMenuRenderer; >>>>>>>>>> -import org.ofbiz.widget.menu.MenuStringRenderer; >>>>>>>>>> -import org.ofbiz.widget.tree.MacroTreeRenderer; >>>>>>>>>> import org.ofbiz.widget.tree.TreeStringRenderer; >>>>>>>>>> +import org.ofbiz.widget.tree.MacroTreeRenderer; >>>>>>>>>> import org.xml.sax.SAXException; >>>>>>>>>> import freemarker.template.TemplateException; >>>>>>>>>> @@ -92,13 +90,15 @@ public class MacroScreenViewHandler exte >>>>>>>>>> ScreenStringRenderer screenStringRenderer = new >>>>>>>>>> MacroScreenRenderer(UtilProperties.getPropertyValue("widget", >>>>>>>>>> getName() + ".name"), UtilProperties.getPropertyValue("widget", >>>>>>>>>> getName() + ".screenrenderer")); >>>>>>>>>> FormStringRenderer formStringRenderer = new >>>>>>>>>> MacroFormRenderer(UtilProperties.getPropertyValue("widget", >>>>>>>>>> getName() + ".formrenderer"), request, response); >>>>>>>>>> TreeStringRenderer treeStringRenderer = new >>>>>>>>>> MacroTreeRenderer(UtilProperties.getPropertyValue("widget", >>>>>>>>>> getName() + ".treerenderer"), writer); >>>>>>>>>> - MenuStringRenderer menuStringRenderer = new >>>>>>>>>> MacroMenuRenderer(UtilProperties.getPropertyValue("widget", >>>>>>>>>> getName() + ".menurenderer"), request, response); >>>>>>>>>> + // TODO: uncomment these lines when the renderers are >>>>>>>>>> implemented >>>>>>>>>> + //MenuStringRenderer menuStringRenderer = new >>>>>>>>>> MacroMenuRenderer(UtilProperties.getPropertyValue("widget", >>>>>>>>>> getName() + ".menurenderer"), writer); >>>>>>>>>> ScreenRenderer screens = new ScreenRenderer(writer, >>>>>>>>>> null, screenStringRenderer); >>>>>>>>>> screens.populateContextForRequest(request, response, >>>>>>>>>> servletContext); >>>>>>>>>> + // this is the object used to render forms from their >>>>>>>>>> definitions >>>>>>>>>> screens.getContext().put("formStringRenderer", >>>>>>>>>> formStringRenderer); >>>>>>>>>> screens.getContext().put("treeStringRenderer", >>>>>>>>>> treeStringRenderer); >>>>>>>>>> - screens.getContext().put("menuStringRenderer", >>>>>>>>>> menuStringRenderer); >>>>>>>>>> + //screens.getContext().put("menuStringRenderer", >>>>>>>>>> menuStringRenderer); >>>>>>>>>> screens.getContext().put("simpleEncoder", >>>>>>>>>> StringUtil.getEncoder(UtilProperties.getPropertyValue("widget", >>>>>>>>>> getName() + ".encoder"))); >>>>>>>>>> screenStringRenderer.renderScreenBegin(writer, >>>>>>>>>> screens.getContext()); >>>>>>>>>> screens.render(page); |
Re: svn commit: r1517434 - in /ofbiz/trunk/framework/widget: src/org/ofbiz/widget/menu/Macr
|
|
That's all just lovely sentiment Hans. The point is that communication is the key, if you see a problem in the trunk due to a recent commit then report it to the committer (if you know who it was) via the dev list. If it's a blocking bug then reverting it is fine, but it really needs to come along with the report. We've always done this so I'm not sure why it's becoming an issue now.
Negative statements were merely following negatively perceived (and unusual) actions on your part. Regards Scott On 29/08/2013, at 3:28 PM, Hans Bakker wrote: > Thank you Jacques, you are doing a really good job not only committing contributions but also keeping everybody working together. > > I admit my action was a bit quick, but on the other hand getting a change in the system which is blocking, (this change cannot be shown to a customer) then still my action was at least understandable. It took me some time which commit did it where i was short in time anyway. Still I think that changes which are blocking in major functions like the main menu should not be committed. > > That said, let me make some general comments. My business would not exist and continue to exist without the help of OFBIz committers, In general, the last couple of years, Scott and Adrian did an excellent job on commenting and contributions, Jacques is the King and help line of the contributors, Jacopo more on the background making sure Apache interests are respected and I am trying to contribute requests from my customers more on the application level. > > The last 2 years I see the requests especially from larger companies increasing. We are expanding the activities in AntWebsystems and will move to a new building the end of the Year. Let stick together and encourage each other making this product better and refrain from sending negative statements? > > Thank you all, committers and contributers for the time you spend on Apache OFBiz. > > Regards, > Hans > > > On 08/28/2013 05:10 PM, Jacques Le Roux wrote: >> Thanks for your opinion Scott, >> >> Let's try to keep it productive... >> >> Yes, that I agreed on: http://markmail.org/message/2e3qo2ydna4lp5gp >> I'm sure you did not miss it even if it's not part of this email. >> >> I still believe that, the more we share through Jira, the better. For many reasons it's more effective than ML. >> For this peculiar case, I must admit, years after, it was out of mind. Here a reference to Jira issue, with even a simple sentence in description, possibly with a reference to the "aforementioned" dev ML thread (the one about "macro widget renderers") and if necessary commit/s reference/s, would have help. >> >> What we are so far discussing about in this thread is based on what we already agreed (or at least what I remember about it). >> First discuss on dev ML and if necessary open a Jira to collect/share opininons and keep a track on all possible info. >> If there is nothing let to discuss and it's a simple thing, don't create a Jira and then code and commit straight away. >> >> Let's now compare the possible flows of actions. >> >> Currently (hell) using present for a better story: >> Years ago, we discuss on "macro widget renderers" on dev ML and agree we can code and commit straight away (correct me if there is/are (a) Jira issue/s about it) >> Few days ago, Adrian directly commits changes about macro widget renderers; without noticing on dev ML, thinking everybody remember what we talked about. >> Hans finds few issues and reverts Adrian's commit without noticing anyone on dev ML. I guess, to do a such thing, at this point Hans did not remember about macro widget renderers and "netiquette" was a bit upset, or in a hurry. >> Adrian is (rightly) upset and then our current discussion begins... >> >> Possibly (heaven): >> Years ago, we would have discussed on "macro widget renderers" on dev ML and created (a) Jira issue/s with references (links) to the discussion and commits and all possibly shared info. >> Few days ago, Adrian would have committed changes, noticing others on dev ML, with just a link about the Jira (or just saying there is one, for others to look for). Possibly only with a comment/link in the commit. >> After Hans finds few issues he can refer to the Jira or/and the previous discussion about "macro widget renderers". He understands what and why Adrian did, and ask for help on the dev ML, instead of abruptly reverting Adrian's commit (unfair).- >> >> As I said, I agree Hans made the misconduct. But it's not a reason to put all on him and not try to get things better. >> >> This is my opinion (Jira is our friend) >> >> Jacques >> >> Scott Gray wrote: >>> Stop trying to create some sort of solution to a non-existent problem. Things get refactored and sometimes it causes issues, >>> that is the nature of the trunk and Hans can deal with it the same as anyone else, by reporting and/or fixing issues first, and >>> then reverting if no reasonably quick actions can be taken. >>> >>> It's not appropriate to revert a commit without any discussion whatsoever, he didn't even describe the problem until a day later. >>> How is the original committer supposed to rectify the issue without any details? >>> >>> Regards >>> Scott >>> >>> On 28/08/2013, at 7:53 AM, Jacques Le Roux wrote: >>> >>>> Then maybe a few words on the dev ML would not have hurt. >>>> >>>> Jacques >>>> >>>> Adrian Crum wrote: >>>>> That was not the case in my commit. The macro widget renderers were >>>>> proposed by Jacopo years ago and we discussed it. The implementation was >>>>> incomplete however. So, I merely finished an incomplete implementation >>>>> of a new feature we agreed on years ago. >>>>> >>>>> -Adrian >>>>> >>>>> On 8/27/2013 3:06 AM, Jacques Le Roux wrote: >>>>>> This is indeed a concern. I believe we should always all follow the Jira way of sharing and testing before committing any new >>>>>> major feature or major bug fix (not trivial ones of course). Then, it's possible to wait few days for others to check, not >>>>>> bullet proof but surely better. >>>>>> >>>>>> Jacques >>>>>> >>>>>> Hans Bakker wrote: >>>>>>> If you would have announced this before you implemented it, i would have >>>>>>> known, now in first instance we think this is caused by our changes..... >>>>>>> And only later check the svn updates.... >>>>>>> >>>>>>> Regards, >>>>>>> Hans >>>>>>> >>>>>>> Try entering a purchase invoice: >>>>>>> >>>>>>> Expected collection or sequence. parameterList evaluated instead to >>>>>>> freemarker.template.SimpleScalar on line 51, column 12 in >>>>>>> component://widget/templates/htmlMenuMacroLibrary.ftl. The problematic >>>>>>> instruction: ---------- ==> list parameterList as parameter [on line 51, >>>>>>> column 5 in component://widget/templates/htmlMenuMacroLibrary.ftl] in >>>>>>> user-directive renderLink [on line 1, column 1 in >>>>>>> org.ofbiz.widget.menu.MacroMenuRenderer@21cc9647_1074] ---------- Java >>>>>>> backtrace for programmers: ---------- >>>>>>> freemarker.template.TemplateException: Expected collection or sequence. >>>>>>> parameterList evaluated instead to freemarker.template.SimpleScalar on >>>>>>> line 51, column 12 in >>>>>>> component://widget/templates/htmlMenuMacroLibrary.ftl. at >>>>>>> freemarker.core.TemplateObject.invalidTypeException(TemplateObject.java:136) >>>>>>> at freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock. >>>>>>> >>>>>>> try entering a new accounting transaction: >>>>>>> https://localhost:8443/accounting/control/createAcctgTrans >>>>>>> >>>>>>> Expected collection or sequence. parameterList evaluated instead to >>>>>>> freemarker.template.SimpleScalar on line 51, column 12 in >>>>>>> component://widget/templates/htmlMenuMacroLibrary.ftl. The problematic >>>>>>> instruction: ---------- ==> list parameterList as parameter [on line 51, >>>>>>> column 5 in component://widget/templates/htmlMenuMacroLibrary.ftl] in >>>>>>> user-directive renderLink [on line 1, column 1 in >>>>>>> org.ofbiz.widget.menu.MacroMenuRenderer@6e5faa56_1073] ---------- Java >>>>>>> backtrace for programmers: ---------- >>>>>>> freemarker.template.TemplateException: Expected collection or sequence. >>>>>>> parameterList evaluated instead to freemarker.template.SimpleScalar on >>>>>>> line 51, column 12 in >>>>>>> component://widget/templates/htmlMenuMacroLibrary.ftl. at >>>>>>> >>>>>>> and at a number of other places...... >>>>>>> >>>>>>> Regards, >>>>>>> Hans >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 08/27/2013 11:44 AM, Adrian Crum wrote: >>>>>>>> No one is asking you to fix anything. All you had to do was post a >>>>>>>> message and I would have fixed it. >>>>>>>> >>>>>>>> There was nothing blocking about my commit, and as I said there was no >>>>>>>> reason to revert it. >>>>>>>> >>>>>>>> Reverting a commit the way you did is NOT co-operation, and >>>>>>>> co-operation is a concept you consistently fail to understand. >>>>>>>> >>>>>>>> -Adrian >>>>>>>> >>>>>>>> On 8/26/2013 8:47 PM, Hans Bakker wrote: >>>>>>>>> Adrian, >>>>>>>>> Normally I would try to fix a problem and i did this pretty often. >>>>>>>>> Because this was a blocking problem i saw no other way then to revert >>>>>>>>> it. >>>>>>>>> >>>>>>>>> Very good to hear you like my commits which at least make a >>>>>>>>> difference for our end users. Although i personally appreciate your >>>>>>>>> framework commits, end-users, which are out bread and butter, are >>>>>>>>> mostly not aware of it. >>>>>>>>> >>>>>>>>> good to co-operate with you, your comments are often very helpful, >>>>>>>>> keep up the good work! >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Hans >>>>>>>>> >>>>>>>>> >>>>>>>>> On 08/26/2013 03:47 PM, Adrian Crum wrote: >>>>>>>>>> Hans, >>>>>>>>>> >>>>>>>>>> Normally, we report problems on the mailing list, not revert someone >>>>>>>>>> else's commit. >>>>>>>>>> >>>>>>>>>> This was rude and uncalled for. If I did the same thing to your >>>>>>>>>> buggy commits, none of your contributions would make it into the >>>>>>>>>> project. >>>>>>>>>> >>>>>>>>>> -Adrian >>>>>>>>>> >>>>>>>>>> On 8/25/2013 11:28 PM, [hidden email] wrote: >>>>>>>>>>> Author: hansbak >>>>>>>>>>> Date: Mon Aug 26 06:28:00 2013 >>>>>>>>>>> New Revision: 1517434 >>>>>>>>>>> >>>>>>>>>>> URL: http://svn.apache.org/r1517434 >>>>>>>>>>> Log: >>>>>>>>>>> revert r1517353: it makes the tomahawk theme unusable >>>>>>>>>>> >>>>>>>>>>> Removed: >>>>>>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/menu/MacroMenuRenderer.java >>>>>>>>>>> >>>>>>>>>>> ofbiz/trunk/framework/widget/templates/htmlMenuMacroLibrary.ftl >>>>>>>>>>> Modified: >>>>>>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Modified: >>>>>>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>>>>>>>> URL: >>>>>>>>>>> http://svn.apache.org/viewvc/ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java?rev=1517434&r1=1517433&r2=1517434&view=diff >>>>>>>>>>> ============================================================================== >>>>>>>>>>> >>>>>>>>>>> --- >>>>>>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>>>>>>>> (original) >>>>>>>>>>> +++ >>>>>>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>>>>>>>> Mon Aug 26 06:28:00 2013 >>>>>>>>>>> @@ -38,10 +38,8 @@ import org.ofbiz.webapp.view.AbstractVie >>>>>>>>>>> import org.ofbiz.webapp.view.ViewHandlerException; >>>>>>>>>>> import org.ofbiz.widget.form.FormStringRenderer; >>>>>>>>>>> import org.ofbiz.widget.form.MacroFormRenderer; >>>>>>>>>>> -import org.ofbiz.widget.menu.MacroMenuRenderer; >>>>>>>>>>> -import org.ofbiz.widget.menu.MenuStringRenderer; >>>>>>>>>>> -import org.ofbiz.widget.tree.MacroTreeRenderer; >>>>>>>>>>> import org.ofbiz.widget.tree.TreeStringRenderer; >>>>>>>>>>> +import org.ofbiz.widget.tree.MacroTreeRenderer; >>>>>>>>>>> import org.xml.sax.SAXException; >>>>>>>>>>> import freemarker.template.TemplateException; >>>>>>>>>>> @@ -92,13 +90,15 @@ public class MacroScreenViewHandler exte >>>>>>>>>>> ScreenStringRenderer screenStringRenderer = new >>>>>>>>>>> MacroScreenRenderer(UtilProperties.getPropertyValue("widget", >>>>>>>>>>> getName() + ".name"), UtilProperties.getPropertyValue("widget", >>>>>>>>>>> getName() + ".screenrenderer")); >>>>>>>>>>> FormStringRenderer formStringRenderer = new >>>>>>>>>>> MacroFormRenderer(UtilProperties.getPropertyValue("widget", >>>>>>>>>>> getName() + ".formrenderer"), request, response); >>>>>>>>>>> TreeStringRenderer treeStringRenderer = new >>>>>>>>>>> MacroTreeRenderer(UtilProperties.getPropertyValue("widget", >>>>>>>>>>> getName() + ".treerenderer"), writer); >>>>>>>>>>> - MenuStringRenderer menuStringRenderer = new >>>>>>>>>>> MacroMenuRenderer(UtilProperties.getPropertyValue("widget", >>>>>>>>>>> getName() + ".menurenderer"), request, response); >>>>>>>>>>> + // TODO: uncomment these lines when the renderers are >>>>>>>>>>> implemented >>>>>>>>>>> + //MenuStringRenderer menuStringRenderer = new >>>>>>>>>>> MacroMenuRenderer(UtilProperties.getPropertyValue("widget", >>>>>>>>>>> getName() + ".menurenderer"), writer); >>>>>>>>>>> ScreenRenderer screens = new ScreenRenderer(writer, >>>>>>>>>>> null, screenStringRenderer); >>>>>>>>>>> screens.populateContextForRequest(request, response, >>>>>>>>>>> servletContext); >>>>>>>>>>> + // this is the object used to render forms from their >>>>>>>>>>> definitions >>>>>>>>>>> screens.getContext().put("formStringRenderer", >>>>>>>>>>> formStringRenderer); >>>>>>>>>>> screens.getContext().put("treeStringRenderer", >>>>>>>>>>> treeStringRenderer); >>>>>>>>>>> - screens.getContext().put("menuStringRenderer", >>>>>>>>>>> menuStringRenderer); >>>>>>>>>>> + //screens.getContext().put("menuStringRenderer", >>>>>>>>>>> menuStringRenderer); >>>>>>>>>>> screens.getContext().put("simpleEncoder", >>>>>>>>>>> StringUtil.getEncoder(UtilProperties.getPropertyValue("widget", >>>>>>>>>>> getName() + ".encoder"))); >>>>>>>>>>> screenStringRenderer.renderScreenBegin(writer, >>>>>>>>>>> screens.getContext()); >>>>>>>>>>> screens.render(page); > |
Re: svn commit: r1517434 - in /ofbiz/trunk/framework/widget: src/org/ofbiz/widget/menu/Macr
|
Administrator
|
In reply to this post by Scott Gray-2
Scott Gray wrote:
> Keeping things productive was definitely the goal of my email. A jira just wasn't necessary in this case and requiring one adds > additional burden to committers with very little real benefit. The only purpose served would have been if somebody actually > applied the patch and tested it which is unlikely and would have probably taken at least a few days, no design discussion was > needed. Adrian fixed the issue within a few hours of receiving a proper description of what the problem was which is fantastic. I was more thinking about a Jira creation at the initial time. After the discussion took place, year ago. The general idea is to not hesitate to create a Jira issue with as simple info as possible. I don't see it as really a burden, and it's all benefits at long term. Because you have better capabilities to categorize, historize and search than on a simple ML. > The *only* issue here is that code was reverted without *any* discussion or notification of the problems faced. A bit rude for > sure, but I don't think it is the end of the world. I would only ask that Hans be more mindful in the future and follow the > process we've always followed for as long as I can remember. It only requires us to work together as a team rather than against > each other. +1, KISS when possible, indeed Jacques > Regards > Scott > > On 28/08/2013, at 10:10 PM, Jacques Le Roux wrote: > >> Thanks for your opinion Scott, >> >> Let's try to keep it productive... >> >> Yes, that I agreed on: http://markmail.org/message/2e3qo2ydna4lp5gp >> I'm sure you did not miss it even if it's not part of this email. >> >> I still believe that, the more we share through Jira, the better. For many reasons it's more effective than ML. >> For this peculiar case, I must admit, years after, it was out of mind. Here a reference to Jira issue, with even a simple >> sentence in description, possibly with a reference to the "aforementioned" dev ML thread (the one about "macro widget >> renderers") and if necessary commit/s reference/s, would have help. >> >> What we are so far discussing about in this thread is based on what we already agreed (or at least what I remember about it). >> First discuss on dev ML and if necessary open a Jira to collect/share opininons and keep a track on all possible info. >> If there is nothing let to discuss and it's a simple thing, don't create a Jira and then code and commit straight away. >> >> Let's now compare the possible flows of actions. >> >> Currently (hell) using present for a better story: >> Years ago, we discuss on "macro widget renderers" on dev ML and agree we can code and commit straight away (correct me if there >> is/are (a) Jira issue/s about it) >> Few days ago, Adrian directly commits changes about macro widget renderers; without noticing on dev ML, thinking everybody >> remember what we talked about. >> Hans finds few issues and reverts Adrian's commit without noticing anyone on dev ML. I guess, to do a such thing, at this point >> Hans did not remember about macro widget renderers and "netiquette" was a bit upset, or in a hurry. >> Adrian is (rightly) upset and then our current discussion begins... >> >> Possibly (heaven): >> Years ago, we would have discussed on "macro widget renderers" on dev ML and created (a) Jira issue/s with references (links) >> to the discussion and commits and all possibly shared info. >> Few days ago, Adrian would have committed changes, noticing others on dev ML, with just a link about the Jira (or just saying >> there is one, for others to look for). Possibly only with a comment/link in the commit. >> After Hans finds few issues he can refer to the Jira or/and the previous discussion about "macro widget renderers". He >> understands what and why Adrian did, and ask for help on the dev ML, instead of abruptly reverting Adrian's commit (unfair).- >> >> As I said, I agree Hans made the misconduct. But it's not a reason to put all on him and not try to get things better. >> >> This is my opinion (Jira is our friend) >> >> Jacques >> >> Scott Gray wrote: >>> Stop trying to create some sort of solution to a non-existent problem. Things get refactored and sometimes it causes issues, >>> that is the nature of the trunk and Hans can deal with it the same as anyone else, by reporting and/or fixing issues first, and >>> then reverting if no reasonably quick actions can be taken. >>> >>> It's not appropriate to revert a commit without any discussion whatsoever, he didn't even describe the problem until a day >>> later. How is the original committer supposed to rectify the issue without any details? >>> >>> Regards >>> Scott >>> >>> On 28/08/2013, at 7:53 AM, Jacques Le Roux wrote: >>> >>>> Then maybe a few words on the dev ML would not have hurt. >>>> >>>> Jacques >>>> >>>> Adrian Crum wrote: >>>>> That was not the case in my commit. The macro widget renderers were >>>>> proposed by Jacopo years ago and we discussed it. The implementation was >>>>> incomplete however. So, I merely finished an incomplete implementation >>>>> of a new feature we agreed on years ago. >>>>> >>>>> -Adrian >>>>> >>>>> On 8/27/2013 3:06 AM, Jacques Le Roux wrote: >>>>>> This is indeed a concern. I believe we should always all follow the Jira way of sharing and testing before committing any new >>>>>> major feature or major bug fix (not trivial ones of course). Then, it's possible to wait few days for others to check, not >>>>>> bullet proof but surely better. >>>>>> >>>>>> Jacques >>>>>> >>>>>> Hans Bakker wrote: >>>>>>> If you would have announced this before you implemented it, i would have >>>>>>> known, now in first instance we think this is caused by our changes..... >>>>>>> And only later check the svn updates.... >>>>>>> >>>>>>> Regards, >>>>>>> Hans >>>>>>> >>>>>>> Try entering a purchase invoice: >>>>>>> >>>>>>> Expected collection or sequence. parameterList evaluated instead to >>>>>>> freemarker.template.SimpleScalar on line 51, column 12 in >>>>>>> component://widget/templates/htmlMenuMacroLibrary.ftl. The problematic >>>>>>> instruction: ---------- ==> list parameterList as parameter [on line 51, >>>>>>> column 5 in component://widget/templates/htmlMenuMacroLibrary.ftl] in >>>>>>> user-directive renderLink [on line 1, column 1 in >>>>>>> org.ofbiz.widget.menu.MacroMenuRenderer@21cc9647_1074] ---------- Java >>>>>>> backtrace for programmers: ---------- >>>>>>> freemarker.template.TemplateException: Expected collection or sequence. >>>>>>> parameterList evaluated instead to freemarker.template.SimpleScalar on >>>>>>> line 51, column 12 in >>>>>>> component://widget/templates/htmlMenuMacroLibrary.ftl. at >>>>>>> freemarker.core.TemplateObject.invalidTypeException(TemplateObject.java:136) >>>>>>> at freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock. >>>>>>> >>>>>>> try entering a new accounting transaction: >>>>>>> https://localhost:8443/accounting/control/createAcctgTrans >>>>>>> >>>>>>> Expected collection or sequence. parameterList evaluated instead to >>>>>>> freemarker.template.SimpleScalar on line 51, column 12 in >>>>>>> component://widget/templates/htmlMenuMacroLibrary.ftl. The problematic >>>>>>> instruction: ---------- ==> list parameterList as parameter [on line 51, >>>>>>> column 5 in component://widget/templates/htmlMenuMacroLibrary.ftl] in >>>>>>> user-directive renderLink [on line 1, column 1 in >>>>>>> org.ofbiz.widget.menu.MacroMenuRenderer@6e5faa56_1073] ---------- Java >>>>>>> backtrace for programmers: ---------- >>>>>>> freemarker.template.TemplateException: Expected collection or sequence. >>>>>>> parameterList evaluated instead to freemarker.template.SimpleScalar on >>>>>>> line 51, column 12 in >>>>>>> component://widget/templates/htmlMenuMacroLibrary.ftl. at >>>>>>> >>>>>>> and at a number of other places...... >>>>>>> >>>>>>> Regards, >>>>>>> Hans >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 08/27/2013 11:44 AM, Adrian Crum wrote: >>>>>>>> No one is asking you to fix anything. All you had to do was post a >>>>>>>> message and I would have fixed it. >>>>>>>> >>>>>>>> There was nothing blocking about my commit, and as I said there was no >>>>>>>> reason to revert it. >>>>>>>> >>>>>>>> Reverting a commit the way you did is NOT co-operation, and >>>>>>>> co-operation is a concept you consistently fail to understand. >>>>>>>> >>>>>>>> -Adrian >>>>>>>> >>>>>>>> On 8/26/2013 8:47 PM, Hans Bakker wrote: >>>>>>>>> Adrian, >>>>>>>>> Normally I would try to fix a problem and i did this pretty often. >>>>>>>>> Because this was a blocking problem i saw no other way then to revert >>>>>>>>> it. >>>>>>>>> >>>>>>>>> Very good to hear you like my commits which at least make a >>>>>>>>> difference for our end users. Although i personally appreciate your >>>>>>>>> framework commits, end-users, which are out bread and butter, are >>>>>>>>> mostly not aware of it. >>>>>>>>> >>>>>>>>> good to co-operate with you, your comments are often very helpful, >>>>>>>>> keep up the good work! >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Hans >>>>>>>>> >>>>>>>>> >>>>>>>>> On 08/26/2013 03:47 PM, Adrian Crum wrote: >>>>>>>>>> Hans, >>>>>>>>>> >>>>>>>>>> Normally, we report problems on the mailing list, not revert someone >>>>>>>>>> else's commit. >>>>>>>>>> >>>>>>>>>> This was rude and uncalled for. If I did the same thing to your >>>>>>>>>> buggy commits, none of your contributions would make it into the >>>>>>>>>> project. >>>>>>>>>> >>>>>>>>>> -Adrian >>>>>>>>>> >>>>>>>>>> On 8/25/2013 11:28 PM, [hidden email] wrote: >>>>>>>>>>> Author: hansbak >>>>>>>>>>> Date: Mon Aug 26 06:28:00 2013 >>>>>>>>>>> New Revision: 1517434 >>>>>>>>>>> >>>>>>>>>>> URL: http://svn.apache.org/r1517434 >>>>>>>>>>> Log: >>>>>>>>>>> revert r1517353: it makes the tomahawk theme unusable >>>>>>>>>>> >>>>>>>>>>> Removed: >>>>>>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/menu/MacroMenuRenderer.java >>>>>>>>>>> >>>>>>>>>>> ofbiz/trunk/framework/widget/templates/htmlMenuMacroLibrary.ftl >>>>>>>>>>> Modified: >>>>>>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Modified: >>>>>>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>>>>>>>> URL: >>>>>>>>>>> http://svn.apache.org/viewvc/ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java?rev=1517434&r1=1517433&r2=1517434&view=diff >>>>>>>>>>> ============================================================================== >>>>>>>>>>> >>>>>>>>>>> --- >>>>>>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>>>>>>>> (original) >>>>>>>>>>> +++ >>>>>>>>>>> ofbiz/trunk/framework/widget/src/org/ofbiz/widget/screen/MacroScreenViewHandler.java >>>>>>>>>>> Mon Aug 26 06:28:00 2013 >>>>>>>>>>> @@ -38,10 +38,8 @@ import org.ofbiz.webapp.view.AbstractVie >>>>>>>>>>> import org.ofbiz.webapp.view.ViewHandlerException; >>>>>>>>>>> import org.ofbiz.widget.form.FormStringRenderer; >>>>>>>>>>> import org.ofbiz.widget.form.MacroFormRenderer; >>>>>>>>>>> -import org.ofbiz.widget.menu.MacroMenuRenderer; >>>>>>>>>>> -import org.ofbiz.widget.menu.MenuStringRenderer; >>>>>>>>>>> -import org.ofbiz.widget.tree.MacroTreeRenderer; >>>>>>>>>>> import org.ofbiz.widget.tree.TreeStringRenderer; >>>>>>>>>>> +import org.ofbiz.widget.tree.MacroTreeRenderer; >>>>>>>>>>> import org.xml.sax.SAXException; >>>>>>>>>>> import freemarker.template.TemplateException; >>>>>>>>>>> @@ -92,13 +90,15 @@ public class MacroScreenViewHandler exte >>>>>>>>>>> ScreenStringRenderer screenStringRenderer = new >>>>>>>>>>> MacroScreenRenderer(UtilProperties.getPropertyValue("widget", >>>>>>>>>>> getName() + ".name"), UtilProperties.getPropertyValue("widget", >>>>>>>>>>> getName() + ".screenrenderer")); >>>>>>>>>>> FormStringRenderer formStringRenderer = new >>>>>>>>>>> MacroFormRenderer(UtilProperties.getPropertyValue("widget", >>>>>>>>>>> getName() + ".formrenderer"), request, response); >>>>>>>>>>> TreeStringRenderer treeStringRenderer = new >>>>>>>>>>> MacroTreeRenderer(UtilProperties.getPropertyValue("widget", >>>>>>>>>>> getName() + ".treerenderer"), writer); >>>>>>>>>>> - MenuStringRenderer menuStringRenderer = new >>>>>>>>>>> MacroMenuRenderer(UtilProperties.getPropertyValue("widget", >>>>>>>>>>> getName() + ".menurenderer"), request, response); >>>>>>>>>>> + // TODO: uncomment these lines when the renderers are >>>>>>>>>>> implemented >>>>>>>>>>> + //MenuStringRenderer menuStringRenderer = new >>>>>>>>>>> MacroMenuRenderer(UtilProperties.getPropertyValue("widget", >>>>>>>>>>> getName() + ".menurenderer"), writer); >>>>>>>>>>> ScreenRenderer screens = new ScreenRenderer(writer, >>>>>>>>>>> null, screenStringRenderer); >>>>>>>>>>> screens.populateContextForRequest(request, response, >>>>>>>>>>> servletContext); >>>>>>>>>>> + // this is the object used to render forms from their >>>>>>>>>>> definitions >>>>>>>>>>> screens.getContext().put("formStringRenderer", >>>>>>>>>>> formStringRenderer); >>>>>>>>>>> screens.getContext().put("treeStringRenderer", >>>>>>>>>>> treeStringRenderer); >>>>>>>>>>> - screens.getContext().put("menuStringRenderer", >>>>>>>>>>> menuStringRenderer); >>>>>>>>>>> + //screens.getContext().put("menuStringRenderer", >>>>>>>>>>> menuStringRenderer); >>>>>>>>>>> screens.getContext().put("simpleEncoder", >>>>>>>>>>> StringUtil.getEncoder(UtilProperties.getPropertyValue("widget", >>>>>>>>>>> getName() + ".encoder"))); >>>>>>>>>>> screenStringRenderer.renderScreenBegin(writer, >>>>>>>>>>> screens.getContext()); >>>>>>>>>>> screens.render(page); |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |