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