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.
