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 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
--
Pedro Viegas
