I think the entire set of example functionalities should be removed from the core and moved over to either the special purpose section. I also believe that the marketing/sfa application should be split up and moved to special purpose.
Regards, Pierre Op 16 maart 2012 00:47 schreef Anne <a...@cohsoft.com.au> het volgende: > Perhaps user interface project(s) would be a good fit for the proposed > Apache Extras? Our experience is that one interface does not "fit > all". Having different ones to choose from might be helpful for many > people. > > Cheers, > Anne. > > > On 15 March 2012 20:20, Nicolas Malin <malin.nico...@librenberry.net> > wrote: > > Hi, > > > > At this time, applications components embedded functional framework and > > business oriented (massively B2C) and aren't user friendly. > > I possible solution will be have a dedicate application components for > only > > Consultant or high level user that contains only the functional framework > > (with business process cleaned) and for end user an oriented business > > components > > > > Exemple : > > > > application / > > content > > humanres > > manufacturing > > marketing > > order > > party > > product > > workeffort > > > > specialpurpose : > > cms > > edm > > ecommerce > > order-b2b > > crm-b2b > > ... > > > > The business components contains (in a beautiful world) only business > > service process and simplified screen. > > We work with Apache OFBiz on hight parameter ERP with dynamic (by jquery > > through screen engine) reusable screen based on portlet and portal page. > Own > > idea is, the application components give a portlets list that business > > components use to configure their portal page. > > > > I'm not a modularity fan. For the technical framework, is great but I'm > much > > more mixed to use on functional framework. Integration problem will not > > resolve easily. > > > > Nicolas > > > > Le 14/03/2012 23:04, Tom Burns a écrit : > > > >> Adrian / Jacopo > >> > >> While thinking about a refactoring the OFBiz Architecture you > >> may want to look at http://www.aosabook.org/en/intro.html. The book is > all > >> about Open Source architecture. In particular see the chapter on > Eclipse, > >> the > >> ultimate open source component framework, Eclipse is the perfect > >> environment to > >> implement Adrian's ambitious vision. > >> However the most pressing problem in OFBiz, given the > >> available resources, is not the architecture, rearranging the components > >> or refactoring > >> of what in Moque would be the Core / Mantel (i.e. a scripting framework > >> etc.). > >> Rather the problem, as your most recent post to this thread > >> suggest, is the short comings in the OFBiz Crust. OOB the user facing > >> applications are difficult to understand, quirky and do not support > needed > >> business > >> requirements. Just ask yourself would you go into a meeting with Steve > >> Jobs ghost > >> with these applications? > >> On the OFBiz home page "What is Apache OFBiz" the > >> focus is clearly ERP. The bullet points advertise OOB application > >> functionality. The business applications should be easy to use, robust, > >> and well > >> documented. This will require more attention to business requirements, > >> providing a consistent set of defined services, adherence to documented > UI > >> best > >> practices and well written and better presented user help. > >> All of this is possible without doing more additional work > >> on the Core / Mantel. > >> I would be happy to contribute to an effort to improve the > >> user facing applications if there is support from the committers. > >> I see these applications as falling into two categories. Applications > >> that are common to most businesses and domain specific applications. > This > >> follows the pattern laid out in the two DMR Books. The former, more > >> general, > >> category should get the most attention. Those applications include: > >> Common Business - Requirements common to most businesses > >> Accounting > >> Human Resources > >> Marketing > >> Work Effort > >> Reporting > >> Document Management > >> E-Commerce > >> Others to be > >> identified > >> I would like to start with Human Resources. Is anyone interested? > >> > >> Tom > >> > >> > >> > >> ________________________________ > >> From: Pierre Smits<pierre.sm...@gmail.com> > >> To: dev@ofbiz.apache.org > >> Sent: Wednesday, March 14, 2012 5:53 PM > >> Subject: Re: Rethinking the structure of the OFBiz Applications > Components > >> > >> Hi Adrian, > >> > >> Could you list the applications you comment out in your production > >> implementations? I think that would help creating insight. > >> > >> Regards, > >> > >> Pierre > >> > >> Op 14 maart 2012 18:33 schreef Adrian Crum< > >> adrian.c...@sandglass-software.com> het volgende: > >> > >>> Understood. > >>> > >>> As a service provider, I regularly comment out unused applications and > >>> build hot-deploy components to replace OOTB OFBiz components. I > override > >>> service definitions, redefine entity definitions, etc - all in an > effort > >>> to > >>> take what's good in OFBiz, and replace what's not-so-good. I seem to be > >>> doing a lot more of it lately - mostly due to components being added > that > >>> break every other component. At least with a component approach, that > >>> sort > >>> of thing can be isolated and dealt with. > >>> > >>> -Adrian > >>> > >>> > >>> On 3/14/2012 5:22 PM, Jacopo Cappellato wrote: > >>> > >>>> Thank you Adrian. > >>>> > >>>> Just to clarify that I was not talking about the architecture of the > >>>> framework (topic for another day) but only for the layout of the > >>>> applications and it is not based on what I think it is best in general > >>>> but > >>>> instead about what I think it is best to represent what we have right > >>>> now: > >>>> what we have right now is *one* big application (made of mostly all > the > >>>> components under the "applications" folder) that is split into chunks > >>>> (the > >>>> components) where each chunk is not built to be used alone. > >>>> I would be really interested to know from the users of the > >>>> "applications" > >>>> how many of them are removing (or not deploying) the components they > do > >>>> not > >>>> need in their business. > >>>> > >>>> All in all I am trying to better represent (in a more convenient, > >>>> cheaper, easier to maintain way) what we already have, not to suggest > >>>> how > >>>> the perfect application built on OFBiz should be. The approach that > you > >>>> are > >>>> suggesting on the other hand, that is inspiring, implies a complete > >>>> refactoring and redesign (also in terms of features) of the > >>>> applications. > >>>> > >>>> Jacopo > >>>> > >>>> On Mar 14, 2012, at 6:09 PM, Adrian Crum wrote: > >>>> > >>>> That approach sounds very monolithic, and I tend to avoid monoliths. > >>>>> > >>>>> I gave this subject a lot of thought about a year ago when I was > >>>>> working > >>>>> on a vision for a new framework (https://cwiki.apache.org/** > >>>>> > >>>>> confluence/display/OFBADMIN/**Another+Framework+Vision< > https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision > >). > >>>>> In particular, I was trying to devise a way for us to build a new > >>>>> architecture for OFBiz out of well-defined and self-contained parts - > >>>>> with > >>>>> the ultimate goal of using OSGI to connect them all together. > >>>>> > >>>>> That goal led to only one pattern that seemed to work: Hub-and-spoke. > >>>>> Hubs can be suspended, replaced, and restarted without too much > >>>>> disruption > >>>>> because they affect only the spokes connected to them. > >>>>> > >>>>> It sounds like what you're proposing is a layered pattern - like a > wall > >>>>> built up of many bricks, but with an all-covering capstone on top. > >>>>> > >>>>> I don't have a strong opinion on which approach is best, but I tend > to > >>>>> favor modularity. > >>>>> > >>>>> The discussion is worthwhile, and I appreciate you starting it. > >>>>> > >>>>> -Adrian > >>>>> > >>>>> On 3/14/2012 2:37 PM, Jacopo Cappellato wrote: > >>>>> > >>>>>> In the eraly days of the project, the OFBiz applications have been > >>>>>> designed as independent components to make them more reusable and > >>>>>> because > >>>>>> they were designed to be a set of reusable and generic artifacts, > each > >>>>>> of > >>>>>> them based on a specific domain of the data model (order, party, > >>>>>> product > >>>>>> etc...). > >>>>>> They were not intended to be ready to be used out of the box; they > >>>>>> were > >>>>>> not intended to implement complete ERP workflows (mostly all > complete > >>>>>> real > >>>>>> World workflows encompass several domains) but rather to provide > some > >>>>>> common artifacts (screens, forms, basic business rules) to > facilitate > >>>>>> the > >>>>>> implementation of custom applications. > >>>>>> However over the years, they have been implemented to be used as > being > >>>>>> part of the same big suite of ERP applications: i.e. the building > >>>>>> blocks of > >>>>>> a specific instance of an ERP system. > >>>>>> Some (parts) of them have become "ready to be used" out of the box > >>>>>> (for > >>>>>> certain specific business models) by implementing more specific > >>>>>> workflows > >>>>>> (based on some real World requirements coming from companies): > because > >>>>>> of > >>>>>> the fact that there was not a central design and coordination (which > >>>>>> industry/business to implement etc...) and because for the same task > >>>>>> (shipping, receiving etc...) there are thousands of different valid > >>>>>> worflows we have now several workflows in OFBiz that implement > similar > >>>>>> features but in different alternative ways. > >>>>>> It is off topic here to say if this is good (the company user can > >>>>>> choose between a series of choices based on the nature of its > business > >>>>>> and > >>>>>> then customize/clean/complete them) or bad (a lot of duplicated > code, > >>>>>> the > >>>>>> applications seem to deal with everything but they are not really > >>>>>> really > >>>>>> good for anything): however it is a reality that the applications > are > >>>>>> now > >>>>>> more a suite of ERP application (one application) rather than > reusable > >>>>>> generic artifacts that can be plugged together. > >>>>>> In fact the OFBiz Applications are now a set of OFBiz components > that > >>>>>> are strictly interdependent at several layers (data model, service, > >>>>>> ui). > >>>>>> > >>>>>> In their current status I believe that it would be better to merge > >>>>>> them > >>>>>> into one big component, the "Apache OFBiz ERP" (or a better name). > >>>>>> The component will contain: > >>>>>> * the complete data model for the OFBiz application > >>>>>> * all the services (Java, Minilang) > >>>>>> * all data > >>>>>> * one web application (merged from the existing ones); even if > >>>>>> initially we could do this in steps and keep them separated as they > >>>>>> are now > >>>>>> but under the same component > >>>>>> * one aggregated and consolidated set of ui labels > >>>>>> > >>>>>> Even in one component we will have several mechanisms to categorize > >>>>>> our > >>>>>> artifacts (file names, folders) even if I would suggest to rethink > >>>>>> them > >>>>>> based on new rules (and only if we need the categorization). > >>>>>> We could merge a lot of files (data preparation scripts, screen > >>>>>> definitions, service definitions etc...) to make them more > consistent. > >>>>>> We > >>>>>> would also resolve some of the issues with inter-application links > and > >>>>>> navigation. > >>>>>> I am pretty sure that we could end up with less code and easier to > >>>>>> organize and maintain. > >>>>>> > >>>>>> It will also be more practical to reuse this component and extend it > >>>>>> from an external hot deploy component: you will have to extend one > >>>>>> webapp > >>>>>> and then reuse from the official component what you like. > >>>>>> > >>>>>> This is just the rough ideas and there could be some variants to it: > >>>>>> we > >>>>>> could isolate all the data model and services into one component and > >>>>>> all > >>>>>> the applications (ui, screens, controllers, data prep scripts and > >>>>>> templates) into another one. etc. etc. etc... > >>>>>> > >>>>>> It is a lot of work but we are a big community and we like to keep > us > >>>>>> busy. > >>>>>> > >>>>>> What do you think? > >>>>>> > >>>>>> Jacopo > >>>>>> > >>>>>> > > > > > > -- > > Nicolas MALIN > > Consultant > > Tél : 06.17.66.40.06 > > Site projet : http://www.neogia.org/ > > ------- > > Société LibrenBerry > > Tél : 02.48.02.56.12 > > Site : http://www.librenberry.net/ > > > > > > -- > Coherent Software Australia Pty Ltd > PO Box 2773 > Cheltenham Vic 3192 > Phone: (03) 9585 6788 > Fax: (03) 9585 1086 > Web: http://www.cohsoft.com.au/ > Email: sa...@cohsoft.com.au > > Bonsai ERP, the all-inclusive ERP system > http://www.bonsaierp.com.au/ >
