--- On Thu, 8/21/08, thomas kukofka <thomaskukofka(a)web.de> wrote:
the created OutputObjects should be used by the GUI to be displayed
and only reasonable filled OutputObjects should be displayed.
I'm not sure what is reasonable in your case, but if it's a simple test it might
be better handled outside of business logic rules. (i.e. a GUI controller, which might be
rules based itself, but you should segregate rules that handle business logic from those
that handle other requirements)
Furthermore an OutputObject of one type can be input for
another rule to create output of another type.
In those cases you certainly should not create the dependent output objects before hand.
I'm not sure what's better and easier to handle in
my case, lazy initialisation or insert from outside.
Is there anything more to consider using lazy initialisation?
Lazy initialization is usually only warranted if creating the resource is costly or time
consuming. (DB connections, high memory/cpu usage, things like that)
Back to the original issue, it's not all that odd to have two rules in your case.
There are two distinct phases: you haven't started gathering results, and you're
in the process of gathering results. It makes sense that you'd have two rules to
govern that. Also, if you have rules down the line that test for the
existence/nonexistence of OutputObject, then you should create it conditionally. But,
basically, having two rules for this kind of thing is not at all bad or odd.
As a side note to the dev team: this would be a great use case for an "else"
clause. Having that would collapse these two rules into one:
rule "all-in-one rule"
#do something with the object
OutputObject oo = new OutputObject();