tapestry-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gentry, Michael \(Contractor\)" <michael_gen...@fanniemae.com>
Subject RE: "Why I Like Annotations"
Date Wed, 02 Nov 2005 15:01:51 GMT
I'm not opposed to breaking backwards compatibility when there are good
reasons for doing so, but some things to consider are:

- Is there a well-defined checklist?  It would be very helpful for
developers doing an upgrade to have a clear checklist of steps needing
to be done as part of the upgrade.

- How hard is the upgrade path?  NeXT/Apple would always include an
upgrade script/application which would try to convert your WebObjects
application from one revision to the next.  It wasn't perfect, but
assuming you hadn't done anything extremely whacky, it would get you
most, if not all, of the way there.  They even provided this for
converting Objective-C to Java (not entirely trivial).

- What is the learning curve?  If you are already a master of the
current version, how much more will you have to un/learn to master the
new version?  If this curve is too steep, it would seem more of a new
framework than an upgrade.

- What about tools?  Tapestry, unlike WO which provides
EOF/WOBuilder/etc, is only the web framework.  How are existing tools
(Cayenne/Hibernate, Spindle, Tapestry Palette, etc) effected by the
changes.  Obviously the ones that integrate more tightly with Tapestry
(such as Spindle) will require the most work.  If it starts becoming too
much work, Geoff/etc may no longer have time to work on them and might
even abandon them, which would be bad.

Perhaps it's not totally fair to compare Tapestry to WO, since the
latter is not open-source, but I do feel the points are basically valid.
I'm really not trying to sound too negative, but there is a point where
changes (which can be quite good) help a framework/community continue to
build momentum, excitement, and thrive, or if too drastic/disruptive can
suddenly cause a rift.

/dev/mrg


-----Original Message-----
From: Howard Lewis Ship [mailto:hlship@gmail.com] 
Sent: Tuesday, November 01, 2005 6: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 <scottami72@hotmail.com> 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 <kmenard@servprise.com> 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:
tapestry-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
tapestry-user-help@jakarta.apache.org
> >
> > --
> > 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: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
tapestry-user-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>


--
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org


Mime
View raw message