> So, yeah, it was intentional to have separate operations for things like (all
> of these are just for creates, different combinations for different things):
Overly tight coupling of any of the building-block functions will mean less
flexibility.
Quick example. I decide to create a class called MyGUI. Then I thought I would subclass that and
create AnotherGUI. Before I know it, MyGUI and AnotherGUI drift apart and become less common. But
because both classes use common methods, I have to be careful when changing MyGUI. At some point,
possibly due to time constraints, I give up, and I create AnotherGUI from scratch, completely
decoupled from MyGUI. When I do have time, I will refactor MyGUI and AnotherGUI, and possibly
create BaseGUI as a parent for both classes. On hindsight, it was probably better to have started
out with separate classes MyGUI and AnotherGUI, and then spot commonalities along the way.
Hindsight is always better and cheaper than foresight.
> We could identify a few variations and have single operations,
We could identify commonalities on hindsight, yes. Still, the basic building-block codes must be
available, just so users and their myriad of use cases can still be served. On really clear
hindsight in future, we may decide that 2 or more building-block codes simply CANNOT be split up
or be called in any other than 1 order. Then we cobble those together for good.
> It does us no good to create something that supports super fast development
> if it makes ongoing maintenance and extension/customization more difficult
The Widget framework is already "shrink-wrapped" enough to make certain customizations difficult.
Maybe we shouldn't "shrink-wrap" the CRUD-related minilang functions and shouldn't make
customizations just that bit more difficult?
> but rest assured that if I shut up others will fill in because lots of people
> in the ofbiz community have experience with this and know what kind of a
> difference it makes.
I don't mind additive changes. If functions need to be removed, deprecate obsolete usages and give
us time to move!
Jonathon
David E Jones wrote:
On Oct 16, 2007, at 12:51 PM, Jacques Le Roux wrote:
De : "Adam Heath" <[EMAIL PROTECTED]>
Another point; in lots of simple method definitions, there are blocks
for doing CRUD to entities; in the vast majority of cases, these method
definitions are *identical*, except for the entity name and property to
pull error messages from. This points to a need to refactor.
IMHO, this point is very interesting, but of course need some work...
These were designed VERY specifically to be this way. It is true there
are only a few common variations for different data structures and
corresponding create/updated/delete operations.
The point of having simple-methods exist for this instead of just have
"call create variation A" in the service definition is to make it easy
to customize and enhance. As functionality around certain entities grows
these methods do tend to grow beyond the base 2-4 operations that the
typical minimal methods include.
So, yeah, it was intentional to have separate operations for things like
(all of these are just for creates, different combinations for different
things):
1. make a value object
2. put a sequenced id in a single pk field for the object
3. move all primary key fields from the parameters or other Map into the
value
4. move non-pk fields from a Map into the value
5. set individual fields on the value
6. and so on...
We could identify a few variations and have single operations, or avoid
writing simple-methods altogether with the service def thing I mentioned
above, but that would just reduce consistency between different
simple-methods and make customization and extension more difficult.
It seems like some recent comments stem from a disagreement that
consistency and ease of customization are important... that might be an
interesting thing to talk about explicitly. Much of the OFBiz framework
is meant for help just those things, where necessary sacrificing other
priorities, all part of optimizing the development experience at the XML
file level.
The driving factor behind that priority is that in most large software
it is complexity that kills projects and causes budgets to spiral out of
control. As complexity increases the time and cost tends to increase in
a non-linear way, ie something like exponentially or logarithmically
instead of linearly. When I say complexity I mean general solution
complexity across hundreds of entities and services and screens, and not
the complexity of a single service. The point of defining the scope and
purpose of a service is to limit the complexity of that one piece to
make it possible to write and maintain it with a reasonable volume of
requirements.
For OFBiz (both the framework and the applications) it is critical that
we all keep this in mind. It does us no good to create something that
supports super fast development if it makes ongoing maintenance and
extension/customization more difficult (including other people's code or
years later when you've forgotten and it might as well be something
someone else wrote). The point is to be as clear and consistent as
possible across a variety of data structures and business processes.
When talking about framework improvements that should be the first thing
considered and written about when presenting ideas. Ideas that don't
help with that will be fought pretty hard by various people, me being
the most vocal, but rest assured that if I shut up others will fill in
because lots of people in the ofbiz community have experience with this
and know what kind of a difference it makes.
-David
