Re: JWC anoyance: Creating component based on existing ones
I love annotations, but I think inheritance is an issue with them as well, even if in a different way. For components I generally have a one-to-one relationship between class and component, but for pages I would like to retain the ability to share the class somehow. I suspect there are a couple of issues relating to this that would best be solved as a whole. Henrik Jesse Kuhnert [EMAIL PROTECTED] skrev i en meddelelse news:[EMAIL PROTECTED] 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JWC anoyance: Creating component based on existing ones
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 DJ 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
Re: JWC anoyance: Creating component based on existing ones
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 vry 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...
Re: JWC anoyance: Creating component based on existing ones
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 vry hard to implement at this point right? So many component to refactor. One thing pops up in my mind like a very
JWC anoyance: Creating component based on existing ones
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
Re: JWC anoyance: Creating component based on existing ones
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
Re: JWC anoyance: Creating component based on existing ones
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 vry 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
Re: JWC anoyance: Creating component based on existing ones
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 vry 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
Re: JWC anoyance: Creating component based on existing ones
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 vry 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
Re: JWC anoyance: Creating component based on existing ones
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 vry 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
Re: JWC anoyance: Creating component based on existing ones
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 vry 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
Re: JWC anoyance: Creating component based on existing ones
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 vry 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
Re: JWC anoyance: Creating component based on existing ones
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 vry 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
Re: JWC anoyance: Creating component based on existing ones
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 vry 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...
Re: JWC anoyance: Creating component based on existing ones
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 vry hard to
Re: JWC anoyance: Creating component based on existing ones
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
Re: JWC anoyance: Creating component based on existing ones
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
Re: JWC anoyance: Creating component based on existing ones
Jesse Kuhnert wrote: 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? Yea, that was what i had in mind when i suggested component-specification inherits=TextField I feel inherit-specification=true/false is not needed at all Either way it will work the same way, once we know who gets what, it's the same thing - i'm pretty sure you got a working prototype as we speak :) 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...) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
