You didn't say what @CoolerTable has to do with @UserTable.
If @UserTable extends @CoolerTable and @CoolerTable hasn't set inherit-specification to no AND @UserTable also hasn't set this to no then @UserTable would: -) Get all properties/assets/etc inherited from @CoolerTable and Table, except for those most directly overriden by the most immediate component in the chain. (Ie if @UserTable defines a different set of icon assets for instance...Even if @CoolerTable also defines them @UserTable would still win because that's how java inheritance works...Which is what I'd like to mimic as it will make the most sense for people.) What part were you worried about specifically? On 8/27/06, andyhot <[EMAIL PROTECTED]> wrote:
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]
-- 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
