OK then - "F**K backwards compatibility!" ;)
Competition in java web framework area is so harsh that taking too much care
of backward compatibility, and not exposing latest and greatest possible,
can turn people to look elsewhere.
Maybe it's because I don't have such huge Tapestry apps that I should be
concerned about porting them to new Tap versions. Last one didn't take much
work.
-Vjeran
----- Original Message -----
From: "Howard Lewis Ship" <[EMAIL PROTECTED]>
To: "Tapestry users" <[email protected]>
Sent: Wednesday, November 02, 2005 12:55 AM
Subject: Re: "Why I Like Annotations"
Well, if we can get enough of the community to say "Howard! Build us
something better, and F**K backwards compatibility!" then I can do
that, and maybe just a little bit more :-)
The reality is that I'm percolating with ideas of how to make Tapestry
better, or make something Tapestry-like better, but probably can't or
won't do them because that would totally fracture the community, way
worse than the 3.0 -> 4.0 upgrade ... which, in fact, is not too bad.
On 11/1/05, Scott Russell <[EMAIL PROTECTED]> wrote:
Personally I think I would prefer to have the annotations define the
default
situation, and the xml overrides the annotations. That would more useful
overall in deploying to clients and only modifying the xml files if
necessary, without recompiling the source code.
-Scott
On Wed 2 November 2005 01:26, Howard Lewis Ship wrote:
> Actually, that's not how it works in Tapestry; the annotations
> override the XML, not the other way around.
>
> I was discussing a more general case of frameworks where annotations
> define configuration values (such as the name of a table) without
> providing recourse to override that value for a particular deployment
> environment. Those frameworks need a way to override the annoation
> values, such as an auxillary XML file.
>
> On 11/1/05, Kevin Menard <[EMAIL PROTECTED]> wrote:
> > In a recent blog post, Howard mentioned that in Tapestry 4 annotation
> > values can be overridden via XML too. Has anyone been able to get
> > this
> > to work? I've found that in a few cases, I'd prefer to use
> > annotations
> > since they get inherited and can be easily overridden by subclasses.
> > However, I tend to have that odd page that really doesn't need a page
> > class, so I'd like to just use a page spec (indeed, I may already have
> > a
> > page spec for that page). The page spec defines the page class as my
> > base class, so within the spec, I'd like to be able to override the
> > annotation value. Thus far, I haven't been able to do it without
> > Tapestry
> > complaining that the property in question already exists.
> >
> > So, have I just been doing something wrong? The blog posts seems to
> > indicate that I ought to be able to do this.
> >
> > Thanks,
> > Kevin
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Jakarta Tapestry
> Creator, Jakarta HiveMind
>
> Professional Tapestry training, mentoring, support
> and project work. http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.362 / Virus Database: 267.12.6/152 - Release Date: 31.10.2005
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
