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, 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);
