Hi Mansour,
There is perhaps a code smell in your example, but IMHO your example is no
improvement at all, and not more object oriented.
A variable that is set once and read once like the three in your example is
not pulling its weight, and it should be eliminated, so the original code is
the better of the two. Neither approach is more or less object oriented.
On the other hand, a series of dots is a code smell. It's a symptom of
excessive coupling. The fix for that is not to introduce temporary
variables. They just move the problem, add noise, obscure the fact that
there is excessive coupling, and fractionally slow things down. A better
fix, in principle, is to write a method to hide detail: "don't ask for data,
ask for help".
So a possible improvement might be to add a method getDelegatorInfos to the
EntityConfigUtil class. Once again, that only makes sense if the method will
be used several times. I've just done a quick search, and it seems to me
that delegatorInfos is private to EntityConfigUtil and used on a total of
three lines of code. If I'm right, I would live with the original code.
Cheers
Paul Foxworthy
Mansour 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 <princesewani@>
> 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 <mansour.alakeel@>
>> To: [email protected]; Prince Sewani <princesewani@>
>> 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 <princesewani@>
>> 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 <malin.nicolas@>
>>> 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 C V V 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/
>
-----
--
Coherent Software Australia Pty Ltd
http://www.cohsoft.com.au/
Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/
--
View this message in context:
http://ofbiz.135035.n4.nabble.com/Some-ideas-to-prepare-our-first-community-roadmap-tp4495191p4500883.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
