Stepahnos,
>>We do have to take you to the woodshed :)
I really must be missing something. Maybe we could step out of the
woodshed and you could explain this a little more.
>>Protected methods are available to all subclasses regardless of
package.
>>You are confusing them with "package private" methods (this is the
default
>>protection level, i.e. if no public/protected/private keyword is used)
>>that are available only to members of the same package.
>>Completely different thing :)
Sure, visibility rules . . . yada yada yada ;) However, how would an
inheritance hierarchy help me output a MultiplePropertySelections
informal parameters?
I see three approaches of using inheritance to gain access to the
AbstractForm.renderInformalParameters() method.
OPTION 1 - SUBCLASS MultiplePropertySelection WITHOUT USING A
IMultiplePropertySelectionRenderer
OPTION 2 - SUBCLASS MultiplePropertySelection AND USE A
IMultiplePropertySelectionRenderer
OPTION 3 - HAVE IMultiplePropertySelectionRenderer SUBCLASS
AbstractFormComponent
#1 & #2 seem too convoluted/too coupled/duplicate too much code to seem
like good candidates. #3 is moot, because you still can't call
AbstractForm.renderInformalParameters(). (details of all three below my
signature)
Currently, my renderer has an "attributes" property (map<String,
String>). When beginRender() is invoked, the renderer will output all
of the entries in the "attributes" map (unless they are marked as
reserved - such as for "name").
Since supporting a multi select list would require a custom renderer, I
might as well make that renderer responsible for all of the HTML.
Including HTML attributes oftentimes considered as informal parameters.
Carlos
OPTION DETAILS
OPTION 1 - SUBCLASS MultiplePropertySelection WITHOUT USING A
IMultiplePropertySelectionRenderer
MultiplePropertySelection rendering is handled by the
IMultiplePropertySelectionRenderer.
The relevant lines in MultiplePropertySelection.renderFormComponent()
are:
IMultiplePropertySelectionRenderer renderer = getRenderer();
// Start rendering
renderer.beginRender(this, writer, cycle);
The existing impl of MultiplePropertySelection.renderFormComponent()
never renders any HTML - and as such cannot output its informal params.
In order for a subclass of MultiplePropertySelection to take advantage
of renderInformalParameter() I would have to, in essence, rewrite most,
if not all of the renderFormComponent(). (e.g. unless I play some tricks
with the IMultiplePropertySelectionRenderer, I cannot call the baseclass
impl because it will render the beginning and ending on the form input).
I would basically be rewriting half of the class in order to output a
few HTML attributes. This is work that the HTML renderering
IMultiplePropertySelectionRenderer seems best suited to take care of.
OPTION 2 - SUBCLASS MultiplePropertySelection AND USE A
IMultiplePropertySelectionRenderer
I could subclass MultiplePropertySelection (and duplicate the component
specification), place that in the same package as my renderer. I would
then have to cast the MultiplePropertySelection argument in the various
XXXrender() methods to my CustomMultiplePropertySelection() class in
order to call renderInformalParameters(). I now have completely coupled
the impl of my renderer to my component. That doesn't seem very
palatable
The case is the same if my custom MultiplePropertySelection class also
impl IMultiplePropertySelectionRenderer -- so it is responsible for
rendering itself without overriding the renderFormComponent() method.
OPTION 3 - HAVE IMultiplePropertySelectionRenderer SUBCLASS
AbstractFormComponent
So that leaves us with using inheritance to provide
IMultiplePropertySelectionRenderer access to the superclasses
renderInformalParameter() method. The first alarm that rings is that
IMultiplePropertySelectionRenderer is not a "form component", and should
never be thought of or treated as such.
The second alarm is that even if IMultiplePropertySelectionRenderer
extends AbstractFormComponent, it still can't call the protected method
on MultiplePropertySelection. Why? Because my impl and
MultiplePropertySelection are in separate packages. If I cast the
MultiplePropertySelection as an AbstractForm, they are still in separate
packages. And since the MultiplePropertySelection does not inherit from
my renderer, I cannot cast the MultiplePropertySelection to my renderer.
Which I think makes this option moot.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
