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/
