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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
18 matches
Mail list logo
