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
