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, hans...@apache.org 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);
