I'm not too concerned about backward compatibility. From what I can
tell, the delta is already big enough that I won't be migrating any existing
code to 4.0. I'd rather see either A) perfect backward compatibility or B)
the latest greatest newest thing. Being only "a little" not backward
compatible is like being only a little pregnant.
--- Pat
> -----Original Message-----
> From: Howard Lewis Ship [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 01, 2005 3:56 PM
> To: Tapestry users
> 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: tapestry-user-
> [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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
