I think "Never" is too harsh, and "rule of thumb" a proper description. There are certainly instances where inheritance is useful. I begin all Tapestry applications with a custom BasePage because there is always some logic that applies across all pages (such as security).
In the case of security, however, I think inheritance is misused in the examples as well because there is typically a "SecuredPage" class and a "NonsecurePage" class. In this case, it makes more sense to have a MyBasePage class that has a constructor with a parameter indicating secure/insecure. Inheritance will be more powerful with annotations, say you have a group of pages that share a tab component, easier to specify this once than cut & paste the tab control into each page (panel), _and_ it makes more sense programmatically. Joel -----Original Message----- From: Robert [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 12, 2005 9:56 AM To: Tapestry users Subject: Re: Best practices: inheritance Darío Vasconcelos wrote: >Thanks for your responses, > >I noticed that in Tapestry in Action, Howard uses inheritance very >often, ie the ToDo examples. While it sounds like a desirable >approach, I still can't force my mind to think in terms of page >hierarchies. That's the reason why I asked this question... > > > Oh no! I assume Howard just used inheritance in those cases to reduce the code snippets he could put in the book. As a rule of thumb: Never inherit from a non-abstract class (or an abstract class that will be enhanced by Tapestry to a complete class). Use aggregation instead. Robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
