--> Hence the lack of extensibility, at least in the direction you want to go.
So far, I think using the MultiplePropertySelection with a custom renderer has been relatively straight forward. I just wanted to see what other avenues others have explored. --> Come to think of it, wouldn't it be easier to extend the Select component so you can bind an IPropertySelectionModel to it and have it automagically render options? (Or, putting the horse before the cart, just use Select and Option?) :) With the select component I would essentially recreate the logic in PropertySelection/MultiplePropertySelection. Validation, HTML rendering, param extraction etc. So far this seems simpler . . . So far. I know there is a MultiSelect available from tassel . . . But I prefer using something a bit more mainstream and likely to keep up to date with the framework. Carlos -----Original Message----- From: Stephanos Piperoglou [mailto:[EMAIL PROTECTED] Sent: Monday, November 20, 2006 1:21 PM To: Tapestry users Subject: RE: MultiplePropertySelection - informal params - best practice <[EMAIL PROTECTED]> wrote on 20/11/2006 17:57:38: > 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) >From the framework doc for MultiplePropertySelection: A component which uses <input type=checkbox> to set a property of some object So using the same component to display a <select multiple="multiple"> list would be a bit of a stretch as from the doc I envisage that the original author didn't expect it to have such functionality. Hence the lack of extensibility, at least in the direction you want to go. I understand your admirable reluctance to duplicate code already written for MultiplePropertySelection, but trying to shoehorn abstraction in where there is none might be the wrong approach. If you're dead set on sharing code then why not write an abstract superclass? This is, after all, an open source project, and Eclipse's "Source > Pull up..." works wonders :) Come to think of it, wouldn't it be easier to extend the Select component so you can bind an IPropertySelectionModel to it and have it automagically render options? (Or, putting the horse before the cart, just use Select and Option?) :) --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
