hi BJ, To give an example. Let say if i wanted to hide some menu items, i comment them out. When i upgrade this implementation, i need to make sure the modification is not overriden by newer codes. If i can hide the menu items just by changing some data in the database, future upgrades will be easier as less codes need to be checked.
Also applies to the screenlets. If I wanted to hide them, it is better to be able to made the change by modifying the database. Regards, James BJ Freeman wrote: > > not sure where you coming from james > I have stated that all customization is done outside of the SVN image, > by either hot-deploy or a seperate folder(which is what I use) of > components the either override or access the svn image. > > and that a automated way to check those customization against the > changes in the svn image to see if there are any changes necessary to > the customization would greatly reduce the cost of maintenance. > > I have not said that any Customization should be in the svn image or > part of the svn. > > > > > ========================= > BJ Freeman > Strategic Power Office with Supplier Automation > <http://www.businessesnetwork.com/automation/viewforum.php?f=52> > Specialtymarket.com <http://www.specialtymarket.com/> > Systems Integrator-- Glad to Assist > > Chat Y! messenger: bjfr33man > > > james_sg sent the following on 9/22/2010 6:59 PM: >> >> Hi BJ, >> >> If we customize an application by configuration, upgrades are easier. >> If we customize by replacing the codes, upgrades will not be possible. >> This means functions / features in OFBiz should be able to turn on / off. >> >> Regards, >> James >> >> >> BJ Freeman wrote: >>> >>> I disagree. every complicated process is made up of simple processes. >>> the level you approach it, is what makes it complicated. >>> An I believe the process can be modeled and implemented. >>> >>> just as the tests are now, as limited as they are. >>> >>> what it takes is a commitment by each one that changes the code base to >>> put their smarts in the direction of what does it take to get from here >>> to there as far as migration. >>> >>> one way for instance is to use Diffs or even the patch itself as a basis >>> for driving the migration. >>> >>> then is it a matter of tools to use the diffs and patches to run a check >>> on customization. >>> >>> I do maintain my own SVN, I would not be this far if I did not. >>> however it does not help to compare code that outside that of the ofbiz >>> svn(component that are customized but not part of the code base of >>> ofbiz) >>> >>> The bottom line, for a business, is overhead to maintain it hard cash. >>> >>> >>> >>> >>> Jonatan Soto sent the following on 9/22/2010 5:00 PM: >>>> What I see here is that it is not as easy to create an upgrade system >>>> for >>>> this kind of project. Perhaps the nature of it, it's a good reason. >>>> Remember >>>> that Ofbiz is an ERP system and tries to cover as much as it can >>>> different >>>> businesses, so IMO it's not like a proprietary product or another kind >>>> of >>>> open source project where it is not a common practice to change the >>>> trunk >>>> code by everyone and also allows to easily install plugins, mods, >>>> extensions, etc. >>>> >>>> IMO, I can say that one good chance to achieve this is to separate the >>>> framework from the apps, already discussed in a lot of posts and I >>>> think >>>> it >>>> is strongly accepted by the community. This will get the ability to >>>> extract >>>> an important piece of code which I think is not regularly altered, at >>>> least >>>> in my case, I've modified some apps but never the framework. >>>>> From my point of view, the hot-deploy works fine and it's fairly >>>>> enough >>>>> for >>>> a lot of customization purposes and maintain the trunk code untouched. >>>> But >>>> it seems to me that sometimes is not enough mostly when an adaptation >>>> of >>>> an >>>> existing app, concretely i18n enters the scene. For example I found to >>>> be >>>> very complicated to move the entire Accounting module, IMO the one that >>>> requires more i18n, since it is related with a lot of modules. In this >>>> case >>>> I have had to customize in-place. I have some ideas about that, but I >>>> prefer >>>> to discuss this in a proper post. >>>> >>>> BJ, I believe that your problem is related with the number of >>>> installations >>>> do you have/maintain so a little solution may be (if you aren't doing >>>> yet) >>>> the vendor drop technique ( >>>> http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html). But I >>>> suppose it's only valid if you decided to use the trunk version from >>>> the >>>> beginning and kept up to date so often... >>>> >>>> On Thu, Sep 23, 2010 at 12:44 AM, Jacques Le Roux< >>>> jacques.le.r...@les7arts.com> wrote: >>>> >>>>> From: "Adam Heath"<doo...@brainfood.com> >>>>> >>>>> On 09/22/2010 03:33 PM, BJ Freeman wrote: >>>>>> >>>>>>> Am it to gather by this that you can do a direct SVN update and all >>>>>>> your >>>>>>> customization continue to work? >>>>>>> say from 9.04 to 10.04 >>>>>>> >>>>>> >>>>>> Ofbiz has never supported upgrades. I agree with BJ here. >>>>>> >>>>>> Database tables can change. Not all changes are automatic. Such >>>>>> changes >>>>>> are not listed in a simple place(in the source). >>>>>> >>>>>> Values in tables can change. No upgrade conversions are >>>>>> provided(again, >>>>>> in a simple place). >>>>>> >>>>> >>>>> Is this useless? >>>>> >>>>> https://cwiki.apache.org/confluence/display/OFBTECH/Revisions+Requiring+Data+Migration >>>>> >>>>> Jacques >>>>> >>>>> >>>>> To solve this, requires running older ofbiz on older database, >>>>> doing a >>>>>> test upgrade to each and every new version, and then seeing what is >>>>>> different. This is a *very* hard problem, not easy to automate, and >>>>>> takes >>>>>> smart people lots of time. This is not something you can just force >>>>>> on >>>>>> the >>>>>> community. No one has sat down to do this very busy, hard work, so >>>>>> it >>>>>> hasn't yet been done. >>>>>> >>>>>> If you run trunk, then it is up to you to solve any per-version >>>>>> upgrade >>>>>> problems. >>>>>> >>>>>> However, official releases should really have appropriate, detailed, >>>>>> upgrade instructions. >>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> >>> >> > > > -- View this message in context: http://ofbiz.135035.n4.nabble.com/Design-improvements-tp2550130p2551369.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
