Ahhh I see now. I think we'll have to come up with a different attribute name for that case. Probably something like the familiar <namespace>:<Component Name> syntax?
Either way it will work the same way, but thank you for bringing it up so I don't code myself into a corner for this. (other than whatever other corners I may end up in, hopefully not eventually ending up mugged or beaten by java streat thugs...) On 8/27/06, andyhot <[EMAIL PROTECTED]> wrote:
Hate to slow you down Jesse, that's what I (also) fear i'm doing here ... My question is: how will the author of @UserTable extend @CoolerTable ? CoolerTable's class is org.apache.tapestry.contrib.table.components.Table ( CoolerTable only has template enhancments) so, if he writes class UserTable extends org.apache.tapestry.contrib.table.components.Table we wouldn't know if he's refering to CoolerTable or to Table Jesse Kuhnert wrote: > 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] >> >> > > -- 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
