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]
-- 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
