Does this help at all? http://jumpstart.doublenegative.com.au/jumpstart/examples/select/varied/$N/$N/$N/$N
Cheers, Geoff On 14/05/2010, at 12:11 AM, Benny Law wrote: > We are talking about subclassing a Tapestry component here. To give you an > example, I wanted to subclass the Select component to override how > BlankOption.AUTO is interpreted. I wanted the logic to not just look at the > required property but also to consider how many options are available and > whether there is a current value. (I find the current logic lacking because, > for example, the first option will always be selected as default if required > is true, but there may not be a meaningful default for the field.) All I > needed to do was to override the showBlankOption() method, but I couldn't > because it's a private method. I ended up making a duplicate of the Select > component with a modified showBlankOption() method. It just didn't feel > right. I don't think all this talk about capturing common logic in a base > class or creating a service for it applies here. > > In my opinion, a good framework should provide the option for extending its > components easily. I believe that with proper design and careful > consideration, inheritance can still be very useful. Developers should > understand any potential risks involved in subclassing, but closing the door > to subclassing for the sake of backward-compatibility may be an overkill > IMHO. Everything has pros and cons, and the developer is ultimately > responsible for weighing them and choosing what's best for their situation. > > BTW, if anyone can think of a clean way to solve my problem with the Select > component, please let me know. Thanks. > > Benny > > > On Thu, May 13, 2010 at 8:58 AM, Christian Riedel > <cr.ml...@googlemail.com>wrote: > >> Why should you have the same rendering code in two different components? >> When I have common code for several components I create an abstract base >> component and put it into the base package. The template is not mandatory >> for components or abstract base components/pages btw. You can use >> subclassing whenever you want but that doesn't always makes your code >> better. >> >> If you have common logic in different components you should move it into a >> service... >> >> Well, and I think tapestry can't free you from your dirtyness, you should >> try soap :) >> >> >> Am 13.05.2010 um 14:28 schrieb Benny Law: >> >>> I also wish component subclassing was at least an option. What I don't >> like >>> about copying and pasting from a Tapestry component is that I end up >> relying >>> on some internal packages and classes. That makes me feel dirty. >>> >>> Benny >>> >>> >>> On Thu, May 13, 2010 at 7:47 AM, Andreas Bohnert <a...@weberhofer.at> >> wrote: >>> >>>> I agree. >>>> I'm upgrading a big project from tapestry 3 to 5. >>>> As I looked into the documentation and sources of tapestry 5 I thought: >>>> wow, this is really great. it could not be any better! >>>> >>>> But if components are no meant to be subclassed this seems like a >> drawback >>>> for me. You have to copy and adjust the code which does not fit into the >>>> tapestry world (DRY principle) >>>> If you use embedded components to extend a component you need an >> additional >>>> (more or less useless) template file and you come in trouble if you use >> this >>>> component multiple times in a page (because of the embedded components >> id >>>> binding) >>>> >>>> Anyway, even if there is way to get around these problems with embedded >>>> components I described, it would feel more natural for me if I just >> could >>>> subclass a component. >>>> >>>> Andreas >>>> >>>> >>>> >>>> I ended up copying >>>> >>>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org