Jacques, thank you for encouraging me to contribute. I will discuss new ideas when I know I can apply them. I have a firm believe that the value of any idea, becomes useless when the idea can not become real, and remain an idea.
I will be wasting everyone else time, if I discuss something, I can not complete. Thank you. On Fri, Mar 23, 2012 at 2:56 PM, Jacques Le Roux <[email protected]> wrote: > Mansour, > > You are welcome to provide patches with test cases and explanations for all > your ideas. > But to no get frustrated by rejects, it's better before to discuss each > point in details in this ML. > > The more brains, the better > > Jacques > > > Mansour Al Akeel wrote: >> >> Ok, >> let's be clear about what I mean here, and explain a bit about what I >> think. >> I think it's better to keep the entity engine as is, with regard to >> handling data, where it return records and not objects. >> >> However, OO can be done in the framework level. Cleaning the code a >> bit, removing deprecated methods, rely less on static methods, >> and use dependency injection. For example: >> >> public static DelegatorInfo getDelegatorInfo(String name) { >> return configRef.get().delegatorInfos.get(name); >> } >> >> can be replace by a little more verbose, but more readable: >> >> public static DelegatorInfo getDelegatorInfo(String name) { >> EntityConfigUtil configUtil = configRef.get(); >> Map<String, DelegatorInfo> map = configUtil.delegatorInfos; >> DelegatorInfo tmp = map.get(name); >> return tmp; >> } >> >> And really, instead of using static methods to lookup objects by name, >> a container can used to track all this and >> lookup those instances when needed. For example, >> org.ofbiz.entity.model.ModelReader doesn't have to provide a static >> method to be used a factory, so it can keep on tracking instances >> created of itself. It's the job of the container. >> Same thing applies to caching. We see caching code all over the place. >> Code that does the lookup, but checking a >> hashtable used as a cache before deciding to create an object. >> >> Cleaning the code, a bit and make it OO, will allow using Aspects for >> things like this. >> >> This is what I meant by making the code more OO. >> >> Back again to the subject of ORMs. MyBatis, may be the fastest ORM I >> have worked with, compared to JPA (hibernate, EclipseLink, ..etc). >> While I didn't do a practical comparison with OfBiz entity engine, I >> think ofbiz entity engine is the most optimized, and fastest, >> because it's closer to JDBC than any other ORM framework. I am not >> sure if any optimization can be with the EE beside cleaning the code >> a bit, and refactoring. >> >> >> >> On Fri, Mar 23, 2012 at 9:27 AM, Prince Sewani <[email protected]> >> wrote: >>> >>> Yeah making it more OO is what I'm actually referring to, OFBiz >>> entity-engine is >>> a different architecture altogether if we compare it to other existing >>> counter-parts like hibernate and >>> >>> Ibatis, I haven't really looked at the query generation code, but does >>> anyone thinks that it needs a >>> >>> bit more optimization? I know I'm talking at a very high level despite of >>> checking out the >>> implementation, Also for cases where we need to plug-in our queries (And >>> I really mean SQL Queries) there should be additional >>> methods in >>> >>> GenericDelegator to achieve it, in the current scenario we've to make an >>> instace of SQLProcessor to get that done, >>> I'm not sure, but it must be a singleton as per my understanding, Is >>> there any way to get that existing Singleton >>> >>> in our code using some method, If not we should think of that too, it >>> would make OFBiz Entity Engine >>> >>> superior to its counterparts and that idea of permissions at the entity >>> level is awesome!! >>> >>> P.S. : Anything IOC and Anything JAVA, I'm on it, just let me know what >>> to be done. >>> >>> Regards >>> Prince >>> >>> >>> >>> ________________________________ >>> From: Mansour Al Akeel <[email protected]> >>> To: [email protected]; Prince Sewani <[email protected]> >>> Sent: Friday, March 23, 2012 6:37 PM >>> Subject: Re: Some ideas to prepare our first community roadmap >>> >>> For me +1 to refactor. >>> >>> I am not sure the ORM needs any work. May be I am missing something. >>> Please let me know what part ? >>> >>> Just cleaning the entity engine code a bit, and make it more OO, will >>> make it easier to work with. >>> For example, I like to add a custom Delegator that will append some >>> fields to each query and will enforce Row Level Security. >>> For example, adding something like "acl.xml" next to the entity >>> definitions, which contains the rules about the access. >>> I know Oracle database has what is called virtual Private Database, >>> and will be nice to have something similar instead of checking for >>> access control in each service call. >>> Just looking at the code currently there, makes the idea goes away. >>> Refactoring the code will make things a bit easier. >>> >>> Ofbiz currently uses its own container to load all it's component. I >>> was not able to find a lot of docs. May be missed them. >>> I don't know if using alternative container is a reasonable suggestion. >>> >>> I see a lot of documentations and examples about using IoC containers >>> with tomcat/jetty/geronimo and OSGI. >>> >>> >>> On Fri, Mar 23, 2012 at 8:18 AM, Prince Sewani <[email protected]> >>> wrote: >>>> >>>> >>>> >>>> +1 to the Refractor, Have a few questions and a few suggestions : >>>> Questions : >>>> >>>> >>>> Are we looking to improve upon the ORM as well ? >>>> >>>> And what about the OSGI stuff, are we planning something on that to >>>> enhance the plug-in approach? >>>> >>>> What's all about the extra stuff? are we just gonna keep 'em separately >>>> and maintain 'em separately or are we >>>> really commercializing? >>>> >>>> Also, What all is that we're thinking to add on to the existing >>>> application or are we just looking to reduce/resize and enhance >>>> what all >>>> is there? >>>> >>>> >>>> Suggestions : >>>> >>>> Google Base Component : Google has upgraded to Google Content API long >>>> back so the one in 10.04 no more works to upload >>>> products to Google merchant haven't checked 11.04 yet. >>>> >>>> eBay and eBay Store could be merged together and there's also no >>>> functionality to post variants to eBay, I wrote some custom >>>> code as >>>> >>>> part of a POC for that, also customer grievances from eBay is something >>>> that's missing. >>>> >>>> Integration with Amazon using Amazon MWS will be cool. >>>> >>>> Upgrade for Fedex API as they're retiring the SOAP API that is currently >>>> used, on 31st may 2012. >>>> >>>> Also I'm ready to volunteer any component at any level, be it a >>>> committer or not. >>>> I'm very much excited about the massive change that we're about to bring >>>> as a community to >>>> >>>> the application. >>>> >>>> Regards >>>> Prince >>>> >>>> >>>> >>>> >>>> ________________________________ >>>> From: Nicolas Malin <[email protected]> >>>> To: [email protected] >>>> Sent: Friday, March 23, 2012 4:21 PM >>>> Subject: Re: Some ideas to prepare our first community roadmap >>>> >>>> +1 a greate roadmap with lot of works >>>> >>>> On refactoring idea : >>>> * review/improve best pratice screen (to manage icons, strong table >>>> line, ...), I had started on this subject but not finalize. >>>> >>>> Nicolas >>>> >>>> Le 23/03/2012 11:07, Scott Gray a écrit : >>>>> >>>>> I'm in favor of all of those things so +1 from me. >>>>> >>>>> For a JIRA version, how about 13.04? :-) >>>>> >>>>> One other topic that's been on my mind, payment gateway >>>>> implementations: >>>>> - Move the test implementation into it's own class so that it isn't >>>>> overcrowding PaymentGatewayServices and is consistent with >>>>> the others >>>>> - Refactor the test implementation so that you can use the CVV code to >>>>> test different behaviors instead of having a bunch of >>>>> different methods like alwaysDecline, randomlyDecline, alwaysApprove >>>>> etc. etc. >>>>> - Ensure consistency between the implementations and better document >>>>> the gateway interfaces. Also remove virtually all >>>>> database calls from the implementations (they run in their own >>>>> transaction which can be painful when querying new data). >>>>> - After cleaning them up, consider moving some of the implementations >>>>> to Extras, I would prefer all of them except test but we >>>>> could start with some of the more obscure ones at least >>>>> >>>>> Oh and another one on my wish list: >>>>> - Finish the query builder implementation that I started a year or two >>>>> ago and deprecate the bulk of the delegator find >>>>> methods. >>>>> >>>>> Regards >>>>> Scott >>>>> >>>>> On 23/03/2012, at 12:06 AM, Jacopo Cappellato wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> now that the great community discussion about the "Lose Weight >>>>>> Program" for OFBiz is settling down (thanks to all of you for >>>>>> the great ideas, enthusiasm and participation) we can start to wrap up >>>>>> a roadmap (it would be nice to set it up in Jira, >>>>>> using a specific "Jira version" so that we can keep track of progress >>>>>> together... any ideas for a good name for it?) by >>>>>> listing the actionable items and also by considering other topics that >>>>>> may be of interest to the community. >>>>>> This thread is an attempt to integrate the roadmap with some >>>>>> additional tasks if the community will consider them a priority. >>>>>> >>>>>> But first of all, here is the list with a categorization/summary of >>>>>> the tasks being discussed so far: >>>>>> >>>>>> (MOSTLY) ACTIONABLE ITEMS (currently under discussion - once finalized >>>>>> we will create tasks in Jira for each): >>>>>> * setup a nice page in the OFBiz website to describe the OFBiz Extras >>>>>> ecosystem (external project names will be added there); >>>>>> the OFBiz PMC will have to work on this (also check if there is >>>>>> additional paperwork to do) >>>>>> * move some of the component/code to Extras: we will create individual >>>>>> Jira tasks for each component and then design details >>>>>> (how to move) will be discussed in the task; we will need volunteers >>>>>> (committers and not) to contribute patches/commits and >>>>>> also at least one maintainer (OFBiz committer or not) for each >>>>>> component >>>>>> * move some of the component/code to Attic: we will create individual >>>>>> Jira tasks for each removal and then design details >>>>>> (how to remove) will be discussed in the tasks; we will need >>>>>> volunteers (committers and not) to contribute patches/commits >>>>>> >>>>>> The above will form the first part of the roadmap. >>>>>> >>>>>> ==== >>>>>> >>>>>> The following list is simply my personal attempt to propose some >>>>>> priorities for the community; some of them are based on >>>>>> comments from people on the dev list, some of them are personal ideas >>>>>> based on some reviews I did to the OFBiz codebase. >>>>>> Feel free to add/remove items to the list but please while doing this >>>>>> consider that we are discussing candidate tasks for an >>>>>> OFBiz roadmap shared by the community: when the list will be >>>>>> discussed, approved and finalized the community will have a >>>>>> clear roadmap to focus on (with all contributions/commits going in >>>>>> this direction); but this also means that the tasks/goals >>>>>> need to be enough generic to gather consensus on a larger group of >>>>>> people (otherwise each individual committer will end up >>>>>> proposing her own specific item to the list, of less interest to the >>>>>> community, and then she will start working on it... >>>>>> instead of better spending the time that she decided to "contribute" >>>>>> to tasks that the community really considers important) >>>>>> and they shouldn't be too big (gathering consensus and implementing as >>>>>> a community will take a lot of time). If we will not >>>>>> find an agreement on some items or a large consensus then it will be >>>>>> fine: the roadmap will be >>>> >>>> lighter and will be completed earlier; at that point we will discuss >>>> again what we want to do next. >>>>>> >>>>>> Even if no big tasks will be added to the roadmap, I think it will >>>>>> still be an interesting one focused on "maintenance" and >>>>>> "quality". >>>>>> >>>>>> BIG TASKS (these are potentially big tasks that may be difficult to >>>>>> plan in this first roadmap... but it may make sense to >>>>>> try to see if we can find an agreement for some actionable tasks) >>>>>> * resolving framework dependencies on applications (this is *not* >>>>>> about "refactoring" the framework, simply to resolve its >>>>>> dependencies on applications) >>>>>> * gather requirements (from existing applications), design and >>>>>> implement JCR/Jackrabbit and replace parts of the existing >>>>>> Content Framework with it >>>>>> * discuss, design and implement (if needed) or define best practices >>>>>> for a plug in architecture >>>>>> * discuss, design and implement (if needed) or define best practices >>>>>> for an integrated reporting tool for OFBiz >>>>>> >>>>>> MAINTENANCE, REFACTORING AND CLEANUP (these are task categories that >>>>>> should be easy to include in the roadmap because they >>>>>> don't require big design and discussions and are mostly all >>>>>> actionable) >>>>>> * bug fixes >>>>>> * automated tests >>>>>> * migration from Beanshell to Groovy (i.e. continue in the trunk the >>>>>> work started in the branch) >>>>>> * check proper handling of EntityListIterators >>>>>> * check proper handling of errors and exceptions in services, events, >>>>>> scripts >>>>>> * check proper handling of events/services messages >>>>>> * replace simple CRUD services with entity-auto services >>>>>> * refactor security handling in services to declare the security >>>>>> service in the service definition >>>>>> * identify all view-entity definitions that are only used in one place >>>>>> (or never used): they may be good candidates for >>>>>> removal and reimplementation using DynamicEntityView API >>>>>> * identify all services that are used only in one place (or never >>>>>> used): they may be removed and inlined (especially if they >>>>>> look very specific) >>>>>> * cleanup (following some best practices - to be defined- for names) >>>>>> and improve service names and descriptions >>>>>> * review old events and verify if they can be converted into services >>>>>> * review old code and refactor/rewrite >>>>>> * review existing events/services >>>>>> >>>>>> Kind regards, >>>>>> >>>>>> 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/
