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.alak...@gmail.com>
To: dev@ofbiz.apache.org; Prince Sewani <princesew...@ymail.com>
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 <princesew...@ymail.com> 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.nico...@librenberry.net>
To: dev@ofbiz.apache.org
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/
