I think inherited jwc configurations are part of the 4.1 wishlist.
http://wiki.apache.org/tapestry/Tapestry41WishList Besides that, annotations are definitely the way to go to get inheritance today. I would love nothing more than to be able to use them exclusively - but I don't think I'd be able to get away with it yet... I don't think jwc inheritance should be very hard to implement, but I worry about what kind of unexpected behaviour would come about as a result of doing this. (for people relying on it ~not~ happening) Maybe I should pause on my other things and tackle this really quick? (besides bugs of course) On 8/27/06, Pedro Viegas <[EMAIL PROTECTED]> wrote:
Hi all, Been creating a component lybrary that is composed of several tapestry components with some add-ons or default customizations and a bunch of new ones. Been having a very repeating anoyance in doing this and would like to get opinions on how to do this the best way, or if this is really something we sould think about for the Tapestry wish list. If we get say for instance the Form component and want to basically add a few funcionallity to it. Say a new parameter or two with some work in the backstages (java class! :-D). The normal approuch would be to subclass the org.apache.tapestry.form.Formand build the .jwc companion file. This is the problem, it's very anoying to have to copy several parameters and injection and other Form Component needed recourses that are defined in the jwc to our own jwc. If for instance in Tap4.2 the component suffers an enhancement, or even in the current Tap version a BUG is detected and corrected in the jwc file one has to correct it in our code as well. Basically we're subclassing part of the code and copy-pasting another part of the code... the one witch is done declarativly and not in the Java class. Is there a nother way of doing this better? Of couse I could build a component witch wraped the tapestry component inside it. That's what I have done at the moment, but it looks like an unnecessary "layer" for tapestry to run through when rendering the page. One more layer of code to deel with in every AJAX refresh of a form, and so on and so on. Seems like the more I use the JWC files the more I want to take every bit of information from them. Anoying little things aren't they? Long live the annotation in the Javaclass. (Witch I think are not the answer here, are they?) Another painfull example is, for instance, if one needed to build a component for example to accept number input. Simply a spin-off of the TextField with the default translator to number. Sonds very simple, a class that subclasses the org.apache.tapestry.form.TextField and a... jwc component that is a full copy-paste of the original TextField one with the changed translator. Very ugly is it not? When we're talking of simples parameter definition, no problem, it's even nice to reduce to what we want the unneeded parameter list, but when we're talking of injections, beans, JS scripts, and so on, well in these cases we're going deep in the heart of the component implementation and are asking for refactors (new copy-paste) when new releases of tapestry are released. Any thoughts on this will be welcomed. -- Pedro Viegas
-- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
