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/
