On Oct 25, 2007, at 8:48 PM, Adam Heath wrote:
David E Jones wrote:
Transaction processing is wrong. There are error conditions that
will
not cause a rollback to occur; namely, Runtime or Errors. The
proper
way to do this, is to set a flag to true right before the inner
block is
done
David E Jones wrote:
>
>> Transaction processing is wrong. There are error conditions that will
>> not cause a rollback to occur; namely, Runtime or Errors. The proper
>> way to do this, is to set a flag to true right before the inner block is
>> done processing, then checking that flag in the f
On Oct 25, 2007, at 10:20 AM, Adam Heath wrote:
David E Jones wrote:
Yeah, I'm not sure I like having all of these little methods
ANYWHERE,
even in better organized in a special class. No matter how you
slice it,
trying to use 30 largely similar methods is a burden on the brain...
The i
David E Jones wrote:
>
> Yeah, I'm not sure I like having all of these little methods ANYWHERE,
> even in better organized in a special class. No matter how you slice it,
> trying to use 30 largely similar methods is a burden on the brain...
>
> The idea of the parameters object or a small number
Looks great!
+1
David E Jones wrote:
Yeah, I'm not sure I like having all of these little methods ANYWHERE,
even in better organized in a special class. No matter how you slice
it, trying to use 30 largely similar methods is a burden on the brain...
The idea of the parameters object or
The idea seems to be to pump all entity functions through some generic method. And then have some
"auto-configuring" methods that act as convenient "chicken", "fish", "pasta" buttons.
But isn't that the same as having methods like "findByAnd" pumped through methods like
"findListIteratorByCondi
Jonathon -- Improov wrote:
This is a very crucial point in this thread.
A heavily parameterized method is great for genericity. We can call such
a method with programmatically generated parameters. Very consistent,
very single-entry-point approach.
However, such a method will require "settin
> The idea of a query parameters object is interesting. If we do something like
> that we should look at some ways of reducing the lines of code required to
> use it. I think that's the only part of it I don't like... lots of lines of
> code.
This is a very crucial point in this thread.
A heavi
De : "David E Jones" <[EMAIL PROTECTED]>
> On Oct 19, 2007, at 9:24 AM, Adam Heath wrote:
>
> > Adrian Crum wrote:
> >> 2. Reduce all of the findByXxxx and findAll methods to a single find
> >> method that takes a FindParameters class. A separate worker class
> >> could
> >> convert all of the vari
On Oct 19, 2007, at 9:24 AM, Adam Heath wrote:
Adrian Crum wrote:
2. Reduce all of the findByXxxx and findAll methods to a single find
method that takes a FindParameters class. A separate worker class
could
convert all of the various arguments currently being sent to the
myriad
findXxxx me
Adam Heath wrote:
Adrian Crum wrote:
David,
I've been thinking about this more. Here are a couple of ideas I came up
with:
1. Move the existing delegator cache maintenance methods to a separate
interface+class. Add a method to DelegatorInterface that retrieves an
instance of the class for per
Adrian Crum wrote:
> David,
>
> I've been thinking about this more. Here are a couple of ideas I came up
> with:
>
> 1. Move the existing delegator cache maintenance methods to a separate
> interface+class. Add a method to DelegatorInterface that retrieves an
> instance of the class for periphera
David,
I've been thinking about this more. Here are a couple of ideas I came up with:
1. Move the existing delegator cache maintenance methods to a separate interface+class. Add a method
to DelegatorInterface that retrieves an instance of the class for peripheral code to work with. End
result:
David E Jones wrote:
In short lately I'm thinking that having so many methods is worse than
the convenience they offer to make life easier for "lazy" coders.
Actually, with a decent IDE having lots of parameters isn't such a big
deal.
I'm a huge fan of reducing code. The stark reality is t
David E Jones wrote:
> [snip]
Well, I have thoughts on this. Extend javac.
Basically, add default values to parameter definitions. Javac would
then auto-generate methods to see each default value. Of course, this
is something that has to be done outside of ofbiz; I've compiled
openjdk, but I
This has been discussed before, but I thought it might be a good time
to bring it up again based on Adam Heath's recent additions to the
GenericDelegator (in revs r585808, r585803, r585802, r585759).
One of the issue with the Entity Engine that has been getting worse
over the years is met
16 matches
Mail list logo
