Adam Lally wrote:
On 3/6/07, Michael Baessler <[EMAIL PROTECTED]> wrote:
Adam Lally wrote:
> Your custom flow controller in its intialization can query the
> <flowContraints> and find out that the sequence is supposed to be a1,
> a2; and it can act accordingly.
But is this not a little bit confusing for our users when using a
fixedFlow constraint just to configure a custom flow?
I think it would be better to have an additional flowConstraint tag like
<customFlow> to specify the order of the custom flow. So that fixedFlow
and capabilityLanguageFlow must only be used when
these flows are used.
Perhaps it is a little confusing... but we have to find the path of
least-confusion. :)
To me it is also confusing to define a new tag <customFlow> and then
say that the only thing you're allowed to have in it is a flat list of
nodes. The general idea of a custom flow is that it can make any kind
of flow decisions it wants.
Others, any opinions on what is the least confusing thing to do here?
We had some user confusion about this also when using the custom flow
controller - because of
the CDE operations. In the CDE, there is an option when you add a
delegate, to also
"automatically" add it to the flow. And there are buttons to reorder
this, and also to "remove"
items from the flow. The CDE builds a <fixed flow> element to contain
this spec,
when using the custom flow, just like Adam's example in this thread.
So, the model exposed in the CDE is that there is a flow section which
has an ordered
list of delegates, and it can be used for any of the built-in flows or
the custom one.
As Adam said, the flow order part is not required to be used by the
custom flow controller.
If I had it to do over again, I'd refactor the XML descriptors along
more orthogonal axis
(putting all the flow sequencing lists into one standard XML element,
used by all the
flows), but because of a desire to limit user impact, I'm OK with the
way it is now, especially
because the CDE hides this bit of verboseness.
-Marshall
