I will do some more for point 3, but I'm not sure when since I have to merge the CommonEntityLabels with changes Marco did (the next
time I will commit changes - done by a 3rd person - as is before commiting any other changes, and will review later in a RTC way,
lesson learned !)
Jacques
From: "David E Jones" <david.jo...@hotwaxmedia.com>
What do we still have that is up in the air for refactoring, cleanups, and enhancements? I know quite a few have been worked on
recently but I'm not sure of their exact status, but here are some that come to mind:
1. UI label cleanups: Marco/Jacques, mostly done except for a couple of
specialpurpose components?
2. Double -> BigDecimal: Scott/David, good chunk done but not the whole
project yet
3. simple-method, widget attribute consistency: David/Jacques, all XSDs and Java updated, still a few app files that need
cleaning up but the framework is mostly done
4. portal framework and my portal: Bruno/Hans, this seems to be pretty far along but some refinement and decisions about how to
work with framework versus apps needs to be done including the possibility of having a MyPortal webapp that is part of the
framework and that applications, specialpurpose, and hot-deploy components can make portlets available for, plus pre-build
portlet sets by role too, so that end-users can pick and choose based on what is deployed with inherent support in the framework
(by the way, I think this is cool, it is kind of like a new framework feature with a common tool applications can use, kind of
like many of the nicer OS X features where there is a clear line between the OS and apps but the OS provides many things to
allow a consistent user experience between multiples apps, etc)
5. visual themes in manager apps and ecommerce: Bruno/Adrian/others, pretty far along, basics done yet? this is another cool
feature and I like the UI enhancement experiments that are starting to go along with this and will hopefully lead is do a very
nice default theme at some point in the near future
Other things? I know I must be missing a few...
On a side note, below is a running wish list I've been keeping and slowly working on for the last year or so. We don't need to
wait for these for a framework release, and most of the ones related to cleanups are complete now and so off the list
(GenericDelegator stuff, simple-method/widget stuff, etc). Just some food for thought that I suppose is on this topic. Still,
these are just ideas and things I'd like to work on (because I'd like to have them for use in day-to-day work or I think they
are important in some way) and without actual work going on they are fairly meaningless (ideas are cheap and easy to come by,
actualization of them is not).
That said... we may want to work on some security issues before another
release branch...
-David
=========================================
- ETL tool for mapping relational and Map/List/etc data, probably as operations in simple-methods (it is already pretty good for
this, but more need to more in abstract and then apply to simple-methods and see if/what changes are needed)
- XML consume operations for simple-method (and possibly XML produce too, though perhaps not because data prep can be done in
simple-method and then FTL is a great way to template out the XML to produce)
- Drools support
- XSS prevention tools:
https://issues.apache.org/jira/browse/OFBIZ-260
http://jira.undersunconsulting.com/browse/OFBIZ-559
https://issues.apache.org/jira/browse/OFBIZ-1193
https://issues.apache.org/jira/browse/OFBIZ-1476
Perhaps use service engine filters for ALL incoming data and by default do not allow HTML; all service in fields that should
allow HTML will have to disable this filter manually, so it will require a bit of work.
- other security issues:
https://issues.apache.org/jira/browse/OFBIZ-1959
- IDE plugin for eclipse that uses artifact info stuff
- artifact info stuff for ftl files, groovy scripts
- AJAX form/etc widget stuff, especially a dynamic tree for the tree widget and better dynamic widgets in the form widget for
various things
- docs: reference (based on training videos), "support", training, example
narration
=========================================
On Jan 15, 2009, at 7:51 AM, Adrian Crum wrote:
I agree with much of what David said.
Personally, I feel the R4 branch timing was too early. There were some major refactorings going on at the time, and those
refactorings were completed shortly after the R4 branch - which made R4 obsolete almost immediately. At the time I didn't have
much interest in maintaining the R4 branch.
Things are different this time around. As David mentioned, there has been a lot of commit activity lately. Much of the work I've
done in the last few months has been making preparations for a new release branch. From my perspective, if we hold off a bit on
new major changes and let the dust settle a little, the current trunk would be ready for another release branch. This time
around I'm committed to help maintain it.
-Adrian
David E Jones wrote:
Thanks for your comments Scott. I was going to write something almost as fatalistic. The reality really is that there were very
few fixes that went directly into the release4.0 branch, and I don't think any of those made it into the trunk. There were lots
of fixes from the trunk that went into the release branch thanks to (as Scott mentioned) a few committers who kept an eye on
that. Those who are interested in a release branch seem to have different motives and intents than those using the trunk,
which is fine, but is not very self-sustaining, hence my comments here:
http://docs.ofbiz.org/display/OFBADMIN/Apache+OFBiz+Getting+Started
So, let's get real: release branches attract users but don't attract committers or contributions. Some of those users may
eventually become committers or contributors and move to the trunk in order to do so. So, really (to use a cliche: I've said it
before and I'll say it again) doing releases in any form is mostly a marketing activity.
Releases are certainly of value to the project, and of course to the people and organizations who use the releases, and those
who get an introduction to OFBiz and are attracted to it because of a release of some form. Back to reality though, in a
community driven project there is no central organization to fund the effort, and most OFBiz contributors and committers
contribute based on what clients request or on issues they want to help with.
Not to say that it is impossible, there are certainly many open source projects that do so on a regular basis. As I've thought
about this over the years the only feeble conclusion I can come up with is that those projects have defined functionality sets
that they can target and plan for. This is something that is easier to do with framework level tools, which is one of the
reasons I've been trying to push for a focus on the framework. However, even there it has been tough to get people to propose
things and plan... however significant cleanups and enhancements have happened and it actually is getting into pretty good
shape for release so it can stand on its own.
For the applications and such it's a bit tougher... the scope is large and difficult to agree on, especially given the variety
of organizations and individuals that use OFBiz and contribute back and by doing so make OFBiz what it is. To help everyone
get on the same page I've started an effort to define some business processes that can drive more requirements and designs to
help the refine OFBiz and give us some targets to shoot for:
http://docs.ofbiz.org/display/OFBREQDES/Universal+Business+Process+Library+Index Now, stepping back a little, we don't HAVE to
do this in order to do a release. And again being honest with ourselves, without such a thing it doesn't matter too much
_when_ we create the release branch... it's really quite arbitrary.
So yes, a lot of thought and planning and numerous attempts (many just going very slowly...) to move in this direction are
happening.
For the next release branch, there was recent discussion about it and a decision to do it as I recall, it's now a question of
when and not if. And the when (also from memory, sorry) was intended to be about 2 years from the date of the release4.0
branch, and that is just a few weeks from now. There are lots of great cleanup efforts going on and unless something serious
is up in the air in a few weeks, the release branch will happen.
I only hope it will be of value to a number of people and that good will come
from it.
This is one aspect of OFBiz that I don't think is terribly successful, and past trends are somewhat frustrating, but I still
think it is a good thing and so we work for it and keep trying. Someday I'm hoping various people from the community will rally
and create a really great stable release that shines and works like it's supposed to.
Comments from volunteers and pundits (ie the peanut gallery) welcome.
-David
On Jan 14, 2009, at 8:12 PM, Scott Gray wrote:
Hi Bruno
It sounds reasonable in theory but the reality is that merging bug fixes
into a branch takes a great deal of time on an ongoing basis. I don't
recall seeing a single bug fixing patch being contributed by any of the
community at large, the work was maintained by a couple of committers and NO
ONE else.
The whole reason IMO that the v4 release branch never became an actual
release was because virtually no one in the community showed any real
interest in it.
Personally I think the best thing for the project right now would be remove
any mention of the v4 branch from the main page and any other docs, so that
people don't mistakenly get the impression that it is the best path for them
to take.
Regards
Scott
2009/1/14 Bruno Busco <bruno.bu...@gmail.com>
oops,
sorry to have posted this to the USER ML, I apologize, it was
intended, of course, as a DEV discussion.
-Bruno
---------- Forwarded message ----------
From: Bruno Busco <bruno.bu...@gmail.com>
Date: 2009/1/14
Subject: Re: locale error in simple method
To: u...@ofbiz.apache.org
I think that Vince's situation is very common.
Whenever you get your ofbiz put in production (or a sort of) you get
really "apprensive" and try to not update your working box.
This makes hard also to get bug fixes only from the trunk.
Could we think to try to have a new release branch?
I mean a branch where only bug fix are merged from the trunk?
I know that this has been discussed many times but we should give it a
try. The framework-only release could be still something in the agenda
and should not be affected by the existence of the new complete
release branch.
The last release branch (4.0) seems now too far from the trunk head
and we often suggest not to use it any more. This is fine because we
want people on the "living edge" of the code but then we will get them
in the "should I update or not?" situation.
Having a new release branch we will have most people living there and
contributing back bug-fix patch or bug reports that will still be used
in the trunk.
I see many new features coming into the trunk and this is really great
but, may be, many more would come if who is going to commit them knows
that the community could always rely on an unaffetced "stable" branch.
-Bruno
2009/1/14 Vince M. Clark <vcl...@globalera.com>:
I don't waste my time with 4.0.
Preaching doesn't bother me. I'm used to it and have done a bit myself.
But to be clear, I'm very collaborative, and am not holding anything back
from the community. This particular instance I have not upgraded because it
is production (sort of) and I have had difficulty upgrading other instances
recently because of some seed data issues, and possibly other reasons.
Basically related to some of the new stuff like visual themes.
I will try my custom service against a current download of trunk to
verify that it isn't just a version issue.
----- Original Message -----
From: "David E Jones" <david.jo...@hotwaxmedia.com>
To: u...@ofbiz.apache.org
Sent: Tuesday, January 13, 2009 6:06:06 PM (GMT-0700) America/ Denver
Subject: Re: locale error in simple method
Is that the trunk rev or in the release4.0 branch?
Either way it's a few months old (looks like 23 Jul 2008)... it would
take a fair amount of time for someone to go back and try to reproduce
the error on that revision. Have you considered updating to a newer
version of OFBiz?
Just as an FYI, I usually recommend that people working from the trunk
really collaborate with the community, an that usually means needing
to update at least once per day (or at the _very_ least a couple of
times per week) until the development part of each cycle is done (ie
before doing integration or business level testing, if that means
anything for your process).
There are lots of reasons for this, and what you're running into is
perhaps the most important: by sticking with that revision you're
basically going it alone and choosing not to collaborate with the
community, which makes it hard for others in the community to
collaborate with you. The same is true for the practice of changing
things in the OFBiz framework or core parts of different applications
and not contributing it back to the project. The project suffers a
little, but the project will do fine as there are LOTS of people
contributing back. Who really suffers is the end-user organization
that has to foot the bill of maintaining these things instead of
sharing that with the community.
Sorry for the preaching, but on the other hand thanks for the soap box
to stand on for a little sermon.
-David
On Jan 13, 2009, at 4:34 PM, Vince M. Clark wrote:
Thanks David. Rev is 679168
----- Original Message -----
From: "David E Jones" <david.jo...@hotwaxmedia.com>
To: u...@ofbiz.apache.org
Sent: Tuesday, January 13, 2009 5:36:35 PM (GMT-0700) America/ Denver
Subject: Re: locale error in simple method
Stepping back even more... which version/revision of OFBiz are you
using?
Based on what you wrote, with the browser submitting a form to the
OFBiz web server, as long as it is going through the ControlServlet
and you are calling the service you described through a request- map ->
event tag, then it should work the same way as anything else in OFBiz.
Unless something is broken somewhere then OFBiz should be getting a
locale no matter what, even if it is the system default locale. It
looks like somehow that isn't making it into the service call (you
could verify that by adding a log tag in your simple-method to print
the ${locale} string). That's part of the reason I'm about the
revision you are using... it could be a real issue that most of us
aren't seeing if you're not using a recent trunk revision.
Of, if the assumptions in the 2nd paragraph above are not correct (ie
you are calling things differently) then there could be issues there
as well.
-David
On Jan 13, 2009, at 3:59 PM, Vince M. Clark wrote:
First a disclaimer (plea for mercy). I am an ERP person, not a web
or UI person. So all this http, session, context stuff is rather
confusing to me.
I've been digging on this issue and want to make sure something is
very clear because I think it may have something to do with the
problem.
OfBiz is NOT rendering any screens for me. I'm using it as kind of a
"cheap" web service. I have a static html web form served by Apache
web server. The form action calls OfBiz, and then I redirect back to
a static html page. So OfBiz just accepts the request, processes it,
and redirects. No screen rendering whatsoever by OfBiz.
I'm pointing this out because of one of the comments I found in a
java class (which of course I cannot find now) that said something
about if locale was not in the context then the browser (or maybe
session) default would be used.
So to simplify (or maybe over simplify) my question, is there
something I should be doing in my simple method to put locale in the
context before I call createLead. Also, can someone give me a tip on
how to iterate through whatever is in the context and write it out
to the log so I can see it.
