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 > >
