JWC inheritance would be very cool. I know this is one wall I've run up against in the past.
On 8/28/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
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
