Hi David, about the status of point 1 is really mostly done but I think at maximum next week we will have all cleaned.
Thanks Marco > > 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. > >>>>>>> >
