I convinced the Woodstock team to reverse their position on this issue.
This is good news. :)
Ken
attached mail follows:
Attached. As always, the guy writing the minutes gets to interpret the
discussion,
so please feel free to add to, correct, and/or criticize the notes.
Woodstock - Minutes of architecture meeting of 06/28/2007
---------------------------------------------------------
From: Bill Edwards
Date: 06/28/2007
The meeting was devoted to discussing and resolving the issue
raised by Ken Paulsen. Basically, some of the Woodstock complex
components do NOT render all their child components, but rather
selectively render children based upon the type of child component.
Examples include Tree, PropertySheet, Accordian, Table, etc.
Ken's applications have the need to include child components
within the complex component (at the immediate child component level)
to extend application behavior. For example, an "event generating"
component or some form of "conditional state" component. There could
be cases of child component implementations that do not necessarily
subclass the specific child component class (expected by the
complex component), thus would also not be rendered. Another
case is adding a Dynafaces Zone child inside a Tree (allowing
Ajax behavior to be added at that point).
This is not a requirement to open the barn door and allow
any arbitrary child components to be used in these complex
components. There will be cases where a complex component must
control the children in order to fulfill the "contract" with
the children to achieve the component's expected look, layout,
and behaviors. An example of this is the Table, which expects
to see only TableRows as children. Other types of components
would likely break the table at this level.
There was discussion about unexpected child components that
did render html that was unexpected or inappropriate for the
(html generated by) the complex containing component. Such
cases cannot be supported, and Ken has no such requirements.
It is believed that supporting the rendering of all children
by (at least some) complex components is not a technical
problem; that is, its a pretty easy code change to do this.
However, the results of allowing this capability could be
quite unpredictable, and thus could result in increased
problem reports and maintainence work (if nothing else,
analyzing that a web developer did something stupid and
convincing them its not our problem!).
There was a more detailed discussion of the issue related
to the JSON interface that now exists between server side
renderers and client side widgets, and whether imposing
arbitrary child components (which might generate unexpected
and inappropriate JSON values for the widget) would be a problem.
It was suggested that the widget's client side rendering
would likely ignore those "extra" JSON properties.
This could result in the child components seeming to not
render, thus not meeting some developers expectations
(and generating more problem issues and maintainence work).
There seem to be a couple of solutions here:
1. Open up the complex component renderers to accept (and
render) arbitrary child components; basically, buyer
beware. Add appropriate documentation about how the
complex component executes its renderer. Continue to
publicly document that the complex component "expects"
specific types of child components in order to behave
correctly. This allows the less sophisticated developer
to stay out of trouble, and the more sophisticated
developer to add these extra, but appropriate children.
2. Continue to support restrictive checking/rendering of
child components in the complex component renderers.
This essentially forces the sophisticated developer to
extend the component to achive this desired "extra"
behavior (we are open source!), albeit at a potentially
difficult implementation (possibly rewriting the
complex component renderer).
There seemed to be no inbetween solution where a complex
component might allow some subset of child components, but
not others. This would be much too fragile a solution
(we cannot always predict which camp new components might
fall into). We should not try to "police" this behavior
in the component implementations.
We have decided to try solution (1) above, but retain the
restrictions to the types of child components on some
complex components where it makes sense (e.g., Table).
We will add documentation to the Renderer classes to specify
exactly how the rendering takes place. We will NOT
add documentation to the public documents (such as the
TLD doc) about supporting arbitrary child components so as
to not encourage this approach. We will continue to
support more restrictive child component checking in the
VWP designer (under the belief this is for the less
sophisticated developers who could easily get into trouble
dragging/dropping arbitrary components onto complex components).
From a practical point, this means removing the restriction
in Tree's child component processing. Table will likely
remain as is (expecting TableRows children). Accordian was
less clear to me, as I'm not that up on the "contract" between
it and its tabContents children (or whether the ability to add
arbirary components within the tabContents container would
suffice).
In the future, we should consider very carefully when designing
new complex components whether it is really necessary to
impose restrictions on the type of child components it can
render, and lean toward the more open case where possible.