I think it's important to consider the direction Tap is heading, ie annotations tied to the class. It would be a bad idea to introduce concepts that sits badly with the annotations in the name of flexibility you can live without.
So forcing a tight relationship between the extended jwc & class seems like a good thing to me. Henrik "D&J Gredler" <[EMAIL PROTECTED]> skrev i en meddelelse news:[EMAIL PROTECTED] > If I'm following Andy correctly, his point was that the JWC inheritance > tree > can be different from the Java inheritance tree, so you don't want to try > to > base one off of the other. > > My real-world example is BeanForm, an enhanced Form component. I had to > copy/paste the parameters from Form.jwc in order to extend its JWC API, > but > the BeanForm component class itself does not extend Form -- its JWC/HTML > just contains a Form component to which it passes the > method/listener/delegate/etc parameters. > > On 8/28/06, Pedro Viegas <[EMAIL PROTECTED]> wrote: >> >> Just one more thing on this subject. >> Is is really a good ideia to set the default of the inherit-specification >> to >> true? >> Like you said Jesse... >> >> "...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)" >> >> I'm thinking out loud here. I myself think it's obviously the desired >> bahaviour, since it's only logical to inherit the whole >> information/resources when we subclass a component, but like you said, >> for >> those who are not expecting this and since the old Tap 4.0 dis not behave >> this way... is it not dangerous? I can just imagine the mail list spam >> with >> this question over and over again... :-) On the other hand it's only >> natural >> that such a feature would be inteligent enough to know that since an >> inhetitance took place the correct behaviour would be to inherit the spec >> also... humm... >> >> I don't know, just thinking... maybe if nobody else makes any remark on >> this >> it means everybody agrees on the course described and it is in fact the >> best >> one! ;-) >> >> Regards, >> >> >> On 8/28/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: >> > >> > I've already created it, it's called "inherit-specification"... >> > >> > Description: >> > >> > If yes (the default), all elements contained in any superclass >> components >> > will be >> > directly inherited in this specification.(this includes >> > parameters/properties/assets/etc..) >> > >> > No one should get their hopes up too much yet...(in case I'm setting >> > myself >> > up for some unknown blocking reason for this not to be possible...) >> > >> > On 8/27/06, andyhot <[EMAIL PROTECTED]> wrote: >> > > >> > > Are you thinking about a new 'inherits' or 'extends' attribute in the >> > > <component-specification> element ? >> > > >> > > >> > > Jesse Kuhnert wrote: >> > > > Ok...I'm giving the whole "inheritance" thing a go..We'll see how >> that >> > > > works >> > > > out ;) >> > > > >> > > > On 8/27/06, Pedro Viegas <[EMAIL PROTECTED]> wrote: >> > > >> >> > > >> Humm, so the inheritance is actually easyer that the inclusion of >> an >> > > >> external .xml... ok, the inheritance is the best solution by far >> > > >> so >> > > good >> > > >> news! >> > > >> Has for the .xml and so on... thanks for the tip. :-D >> > > >> >> > > >> On 8/28/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: >> > > >> > >> > > >> > I don't think it needs to be as complicated as you think. >> > > >> > >> > > >> > There is a whole set of classes people don't normally see that >> > > >> encapsulate >> > > >> > all of the information parsed from templates. It wouldn't be >> > > >> > very >> > > hard >> > > >> to >> > > >> > walk up the class heirarchy and create a "union" view of a >> > template. >> > > >> > >> > > >> > As for filename extensions, it only takes a second or two to go >> > into >> > > >> > eclipse >> > > >> > -> window -> preferences -> editor -> content types -> to >> > > >> associated all >> > > >> > *.jwc/*.page/*.application/etc.. with wtp xml.. >> > > >> > >> > > >> > I've been using autocompleting xsd/dtd stuff with wtp for a >> pretty >> > > >> long >> > > >> > time >> > > >> > now and have found it mostly sufficient for my needs, especially >> > when >> > > >> > tapestry is able to dynamically see my changes made to them. >> > > >> > >> > > >> > On 8/27/06, Pedro Viegas <[EMAIL PROTECTED]> wrote: >> > > >> > > >> > > >> > > By the way... since we're diging into this... >> > > >> > > Again from the wiki... >> > > >> > > >> > > >> > > *"Rename the template page from *.page to *.xml or *.page.xml* >> > This >> > > >> > > feature >> > > >> > > would allow the IDE to provide some completion and validate >> > > >> > > the >> > > >> > template" >> > > >> > > >> > > >> > > If we didn't break compatibility with the use of the previous >> > > >> excception >> > > >> > > simply allowing the use of normal .xml exception this would by >> > just >> > > >> > > trivial... and the IDE validation and autocompletion would be >> > VERY >> > > >> > > welcome! >> > > >> > > Sorry, this was me trying to compensate Geoff's decision >> somehow! >> > > >> :-( >> > > >> > > >> > > >> > > What do you say? >> > > >> > > >> > > >> > > On 8/28/06, Pedro Viegas <[EMAIL PROTECTED]> wrote: >> > > >> > > > >> > > >> > > > Don't you sleep Jesse? :-D >> > > >> > > > Another lightning fast response, thanks! >> > > >> > > > >> > > >> > > > Gathering the bullet item from the wiki... >> > > >> > > > * >> > > >> > > > * >> > > >> > > > >> > > >> > > > * "Default Page/JWC Files and/or Page/JWC Inheritance* Often >> > > there >> > > >> is >> > > >> > a >> > > >> > > > need to use the exact same services/beans/etc one multiple >> > pages. >> > > >> The >> > > >> > > > current solution is to add them to all the page/jwc files. >> > There >> > > >> > should >> > > >> > > be a >> > > >> > > > way to inherit another page/jwc file and/or simply import >> > another >> > > >> > > page/jwc >> > > >> > > > file's settings. (Note that this is already possible with >> > > >> > annotations.)" >> > > >> > > > >> > > >> > > > >> > > >> > > > Of course the simple class inheritance would be just >> > > >> > > > perfect. >> > But >> > > >> that >> > > >> > > may >> > > >> > > > be veeeery hard to implement at this point right? So many >> > > >> component >> > > >> to >> > > >> > > > refactor. >> > > >> > > > One thing pops up in my mind like a very handy and not so >> hard >> > to >> > > >> > > > implement feature from the item above... "or simply import >> > > another >> > > >> > > page/jwc >> > > >> > > > file's settings". A new Tag to import another jwc/page (or >> > > another >> > > >> > > extension >> > > >> > > > since it would be a section of the specification and not a >> > > >> complete >> > > >> > > one... >> > > >> > > > say like .spec or something like that) would be relay simple >> > > >> right? >> > > >> > And >> > > >> > > that >> > > >> > > > would be veeery handy! >> > > >> > > > The "There should be a way to inherit another page/jwc file" >> > > would >> > > >> > also >> > > >> > > > not be a problem to other users if it were not the default >> > > >> behaviour >> > > >> > > right? >> > > >> > > > Something like... >> > > >> > > > >> > > >> > > > <component-specification >> > > >> > > > class="Some class..." >> > > >> > > > inherits="/org/apache/tapestry/form/Form.jwc"> >> > > >> > > > (...) >> > > >> > > > >> > > >> > > > ...would be heaven right now, even if it would still let all >> > > >> the not >> > > >> > > > wanted page and jwc files endure a while longer! :-D >> > > >> > > > >> > > >> > > > So, if implementing these two little wishes... >> > > >> > > > >> > > >> > > > 1. Import a .spec or something else file into a page/jwc >> > (for >> > > >> > > > recurring resources) >> > > >> > > > 2. Inherit from another jwc/page >> > > >> > > > >> > > >> > > > ...are quick to do... please Jesse, feel absolutely free to >> do >> > > >> so! I >> > > >> > for >> > > >> > > > one think it would benefit much the complexity of defining >> > > >> > > components/pages, >> > > >> > > > along with the move to annotations we are already able to do >> > > since >> > > >> > Tap4! >> > > >> > > > >> > > >> > > > Of course one should also think, if it is worth to keep >> > > >> building on >> > > >> > top >> > > >> > > > the the page/jwc reality or simply eradicate it for good and >> > > >> build a >> > > >> > > > different approach full annotations all way long? So much >> > > >> > > > has >> > > >> allready >> > > >> > > been >> > > >> > > > done in this direction! OK, I could not resist... shame on >> me, >> > I >> > > >> will >> > > >> > > > quietly punish myself for that previous remark! :-D >> > > >> > > > >> > > >> > > > Regards, >> > > >> > > > >> > > >> > > > 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.TextFieldand >> > > >> 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 >> > > >> > > > > >> > > >> > > > > >> > > >> > > > >> > > >> > > > >> > > >> > > > -- >> > > >> > > > Pedro Viegas >> > > >> > > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > -- >> > > >> > > 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 >> > > >> > >> > > >> > >> > > >> >> > > >> >> > > >> -- >> > > >> Pedro Viegas >> > > >> >> > > >> >> > > > >> > > > >> > > >> > > >> > > -- >> > > Andreas Andreou - [EMAIL PROTECTED] - http://andyhot.di.uoa.gr >> > > Tapestry / Tacos developer >> > > Open Source / J2EE Consulting >> > > >> > > >> > > --------------------------------------------------------------------- >> > > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > > For additional commands, e-mail: [EMAIL PROTECTED] >> > > >> > > >> > >> > >> > -- >> > 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 >> > >> > >> >> >> -- >> Pedro Viegas >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
