What I fear of is this: we already have @Table uses class org.apache.tapestry.contrib.table.components.Table
Now, assume a library offers @CoolerTable also uses class org.apache.tapestry.contrib.table.components.Table which has better html, perhaps additional assets, e.t.c. What would now happen if user creates @UserTable uses class com.app.Table that extends org.apache.tapestry.contrib.table.components.Table ? Which parameters/properties/assets would get copied? Jesse Kuhnert wrote: > But java only supports single inheritance. > > On 8/27/06, andyhot <[EMAIL PROTECTED]> wrote: >> >> Hmmm... >> >> I may be totally wrong, I just have the feeling that having something >> like >> <component-specification inherits="TextField" >> would be easier both for the users and to implement... >> >> Perhaps i'm also misunderstanding your approach but it seems to me >> that knowing a component class doesn't really mean that one knows >> which component we have in mind... component classes can be shared... >> >> >> >> Jesse Kuhnert 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.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 >> >> >> > > > > >> >> >> > > > > >> >> >> > > > >> >> >> > > > >> >> >> > > > -- >> >> >> > > > 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] >> >> >> >> >> > >> > >> >> >> -- >> 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] >> >> > > -- 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]
