I love annotations, but I think inheritance is an issue with them as well, even if in a different way.
For components I generally have a one-to-one relationship between class and component, but for pages I would like to retain the ability to share the class somehow. I suspect there are a couple of issues relating to this that would best be solved as a whole. Henrik "Jesse Kuhnert" <[EMAIL PROTECTED]> skrev i en meddelelse news:[EMAIL PROTECTED] >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 > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
