You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Kevin Menard <km...@servprise.com> on 2005/11/01 14:45:27 UTC
"Why I Like Annotations"
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
Re: "Why I Like Annotations"
Posted by Scott Russell <sc...@hotmail.com>.
On Wed 2 November 2005 09:55, Howard Lewis Ship wrote:
> 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.
>
I wasn't actually complaining, because I like using the new system with the
annotations and all. I was just making the point that, given a preference, I
would see that as the superior path. But of course you do have to ensure that
upgrading to Tapestry4 is fairly painless, and you obviously are more aware
than I what design decisions will impact upon that.
Nor would I say "this is urgent", but perhaps by suggesting these ideas they
might eventually get considered along with future plans for the evolution.
regards,
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: "Why I Like Annotations"
Posted by Vjeran Marcinko <vj...@email.t-com.hr>.
Not just migration documentation... Documentation in general is extremely
important, and though it is not so bad, Tapestry could also improve that
piece a lot. Like so many OS projects out there. Especially because it has
reputation of not being so easy to grip at first.
It would be best if there was some always updated single PDF manual, like
Spring and Hibernate have. Just thinking how many times I came to some
developer's desk and found Spring/Hibernate printed manual lying on it... No
wonder they are so loved within developers.
And then, there's so many people wanting some kind of Tapestry's component
repository flourishing.
And then, there's so many work to be done in the core, as Howard mentioned.
But, as always, it comes down to developer (with help from user) community
enthusiasm and will to do so much stuff. And it's well known that in OS
projects, developers are usually most productive in the beginning, when they
join the project. Enthusiasm then usually fade by time. Or simply life takes
you to some other areas. This is perfectly natural. I'm explaining this
since I hope no developer will get offended when I say that developer
community is a bit weaker than needed.
As far as I see, there are mostly Howard's, MindBridge's and some Paul's
commits in last 1-2 years. And recalling that Paul is a fresh one so
enthusiasm is expected as said, and Howard has personal bond/interest with
Tapestry. Geoff is active, but he has more than enough work around Spindle,
let alone Tapestry. Everything said, it's normal that release cycles are so
long.
Hope I'm not giving impressions that I'm not grateful for this wonderful
project.
Cheers,
Vjeran
----- Original Message -----
From: "Henri Dupre" <he...@gmail.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Wednesday, November 02, 2005 7:40 PM
Subject: Re: "Why I Like Annotations"
And I second Michael... the most important would be documentation for
migration... I don't really care changing the inheritance of my
classes or moving properties and code somewhere else until it is
documented.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: "Why I Like Annotations"
Posted by Henri Dupre <he...@gmail.com>.
On 11/2/05, Howard Lewis Ship <hl...@gmail.com> wrote:
> My thoughts along these lines and the future fall along these lines:
Those changes don't sound to me any worse than 3.0 to 4 migration.
I really like the ideas of SPI and XPI. Also since tapestry has tons
of test, I'm sure we can imagine that tapestry would include ways of
testing the services and extensions.
And I second Michael... the most important would be documentation for
migration... I don't really care changing the inheritance of my
classes or moving properties and code somewhere else until it is
documented.
Thanks,
Henri.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re[2]: "Why I Like Annotations"
Posted by Alexandr Kundirenko <ak...@gmail.com>.
Vjeran,
Why do you want spec to go away?
F.e. we have some FormPage. It has some concrete DAO injected (f.e.
AddressDao) and some TextFields.
If we put them into annotations - all extending forms will have
this garbage. Specifications give us a possibility to have
page-specific data which we don't want to be extended.
Alex
VM> Beside noding to all below ... my addition to "I want" statements: ;)
VM> - I want confusing "abstract" keyword to go away, though from what I've read
VM> on your blog some time ago about some benefits of that, it may never even
VM> happen.... :-(
VM> - I want page/component specifications to go away/optional since with 4.0
VM> and annotations I mostly only have page/component class specified in it
VM> -V.
VM> ----- Original Message -----
VM> From: "Howard Lewis Ship" <hl...@gmail.com>
VM> To: "Tapestry users" <ta...@jakarta.apache.org>
VM> Sent: Wednesday, November 02, 2005 4:16 PM
VM> Subject: Re: "Why I Like Annotations"
VM> My thoughts along these lines and the future fall along these lines:
VM> Tapestry has too much API. I hope to tackle the worst offender,
VM> extending from base classes, in 4.1. Even so, with teh tools we now
VM> have (annotations, bytecode enhancement, IoC, OGNL, aspects), many of
VM> the design decisions I made in January 2000 are out of date. Many
VM> more work, luckily, pretty spot on and have stretched and grown with
VM> the framework.
VM> I want the Tapestry API to disappear as much as possible, using a mix
VM> of annoations and conventions.
VM> In fact, I want three levels of API:
VM> API exposed to typical developers, with real backwards compatibility
VM> XPI (Extension API) used more rarely by developers, to extend core
VM> framework functionality.
VM> SPI (Service Providider API) used internally, never exposed to the
VM> user code, and subject to change on each release.
VM> The first two would have strict backwards compatibility; the last
VM> level would be internal and allowed to change from release to release.
VM> The API and XPI should be as minimal as possible: interfaces, events
VM> and event interfaces, a handful of exceptions, maybe a couple of
VM> convienience base classes. The
VM> Ultimately, I'd like to turn what is, today, a product into a specification.
VM> I would like things to be more code-oriented; I would like XML to be
VM> an add-on, used only in rare cases.
VM> I would like a way of having libraries without namespaces.
VM> I want templates to be XML documents (so that the parser can handle
VM> encoding!) using namespaces for Tapestry elements and attributes. I
VM> want how components are used to determine what they do more.
VM> I want page names and component ids to be class names, or directly
VM> mapped to classes. The current Rube Goldberg machine that is giving
VM> Geoff fits is an artifact of an earlier and, I think, invalid version
VM> of Tapestry. It makes Hello World code-free at the expense of causing
VM> some chaos for real apps.
VM> More than that, I'm thinking that the framework needs to embrace Ajax
VM> and Ajax-techniques head on.
VM> I'm still working my head around how you can keep a Tapestry like
VM> approach, including Block/RenderBlock and other highly dynamic things,
VM> but be able to easily render just portions of a page.
VM> .... but right now, I just want to get 4.0 finished and out the door.
VM> On 11/2/05, Geoff Longman <gl...@gmail.com> wrote:
>> My opinion is that the decision to F&$K backwards compatibility is
>> moot at this point for Tap4. We are too far down the road to RC now.
>> Any migration tool development that may need to begin would be
>> starting many many months (a year?) behind the development of T4. T4
>> has benefitted greatly from months of user feedback, any migration
>> tool built now would be greatly disadvantaged by not having the same
>> benefit.
>>
>> Make the decision and announce that fact for T 4.1 or 5.0 or whatever
>> the next version will be called. Then it's up front and plain to see
>> before coding even starts and the discussion/development of migration
>> strategies, tools, whatever can proceed in parallel.
>>
>> I think that T both benefits from, and is hurt by it's free form
>> development methodology. The benefits are obvious as T can change much
>> faster than the "spec'ed" frameworks can. And that is no barrier to
>> adoption for the coding junkies like me. But widespread adoption is
>> hurt if compatibility is broken without a clearly defined way, in
>> place and bulletproof, to migrate because bigger shops will be loathe
>> to move to T if they are not sure that they can move with T in the
>> future.
>>
>> Make plan, stan, and mitigate the risks to adoption.
>>
>> Geoff
>>
>> On 11/2/05, Richard Clark <rd...@nextquestion.net> wrote:
>> >
>> > On Nov 1, 2005, at 15:55, Howard Lewis Ship wrote:
>> >
>> > > 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 if you want to keep serious commercial customers
>> > (those showcase apps that drive adoption), you need a fairly
>> > straightforward way to migrate to new platform releases. That could
>> > be by building a compatibility layer, by keeping "backward
>> > compatibility", or by a source-to-source translation mechanism.
>> >
>> > Right now, the update for the largest app I'm working on would be a
>> > bit of a stretch, but is doable (and there are aspects of T4 that we
>> > could use to clean up some inelegant code.) But if the answer was "we
>> > can't upgrade, and there's no support anymore for what we are using",
>> > there'd be trouble.
>> >
>> > ...R
>> >
>> >
>> >
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail:
>> tapestry-user-unsubscribe@jakarta.apache.org
>> > For additional commands, e-mail:
>> tapestry-user-help@jakarta.apache.org
>> >
>> >
>>
>>
>> --
>> The Spindle guy. http://spindle.sf.net
>> Get help with Spindle:
>> http://lists.sourceforge.net/mailman/listinfo/spindle-user
>> Announcement Feed:
>> http://www.jroller.com/rss/glongman?catname=/Announcements
>> Feature Updates: http://spindle.sf.net/updates
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> tapestry-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail:
>> tapestry-user-help@jakarta.apache.org
>>
>>
VM> --
VM> Howard M. Lewis Ship
VM> Independent J2EE / Open-Source Java Consultant
VM> Creator, Jakarta Tapestry
VM> Creator, Jakarta HiveMind
VM> Professional Tapestry training, mentoring, support
VM> and project work. http://howardlewisship.com
VM> ---------------------------------------------------------------------
VM> To unsubscribe, e-mail:
VM> tapestry-user-unsubscribe@jakarta.apache.org
VM> For additional commands, e-mail:
VM> 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
Re: Pat vs. the toolbar (was Re: "Why I Like Annotations")
Posted by Richard Clark <rd...@nextquestion.net>.
Perfect encapsulation says "my internal mechanisms are hidden and all
external dependancies are made explicit." So, any perfectly
encapsulated code will need all of its dependencies specified
everywhere it's used. There's not really a way to say "I'm using it
in 20 places but only want to document the dependency in one place"
without breaking that encapsulation at some level. (Even an #include
file would break encapsulation.)
The trend of late has been away from encapsulation and more toward
defaults and "convention" -- cf. Ruby on Rails, the way Tapestry
assumes that abstract accessors on a page represent transient
properties (to be initialized to null on load) unless otherwise
specified, etc. It works, when well documented.
Personally, I prefer high encapsulation and clearly specifying
dependancies to low encapsulation and implicit dependencies. (I was
asking how to do this with a vallidator the other day (hoping to
inject something it needs), and it turns out I couldn't.) But, as
pages proliferate with the same boilerplate specifications, I'm
finding it best to collapse the common case into one place and only
specify the exceptions.
I find that encapsulation is like a good raincoat -- it keeps you
warm and safe in shifting weather. Apply it too stringently and it
becomes a straitjacket. If it leads to an excess of duplicate code,
you'll have a serious maintenance nightmare.
As the Pragmatic Programmers say, "Don't Repeat Yourself". as test
driven developers say "when you're doing something 3 times in
different places, it's time to refactor (to one)."
...Richard
On Nov 2, 2005, at 11:14, Patrick Casey wrote:
>
> I could, but I always get the heebie-geebies when I drive stakes
> through component encapsulation like that, it kind of feels like I'm
> defeating the purpose of using a component based framework at all.
>
>> -----Original Message-----
>> From: Richard Clark [mailto:rdclark@nextquestion.net]
>> Sent: Wednesday, November 02, 2005 9:58 AM
>> To: Tapestry users
>> Subject: Pat vs. the toolbar (was Re: "Why I Like Annotations")
>>
>> Maybe I'm missing something, but you can define a parameter as
>> optional and give it a default value. Why not declare "listener" as
>> optional and default it to the listener in your root page class?
>>
>> I realize this doesn't make your toolbar class 100% reusable across
>> all projects, unless you document it as "calls listener
>> listenToTheMusic(allTheTime...), unless overridden by a listener=...
>> parameter".
>>
>> ...Richard
>>
>>
>> On Nov 2, 2005, at 9:30, Patrick Casey wrote:
>>
>>>
>>> My latest "I want" is a bit different from my earlier "I wants":
>>>
>>> I want to reduce the number of little pieces parts I have to change
>>> to alter the product. Lets say, for example, I want to add a new
>>> toolbar
>>> button to one of my forms:
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Pat vs. the toolbar (was Re: "Why I Like Annotations")
Posted by Patrick Casey <pa...@adelphia.net>.
I could, but I always get the heebie-geebies when I drive stakes
through component encapsulation like that, it kind of feels like I'm
defeating the purpose of using a component based framework at all.
> -----Original Message-----
> From: Richard Clark [mailto:rdclark@nextquestion.net]
> Sent: Wednesday, November 02, 2005 9:58 AM
> To: Tapestry users
> Subject: Pat vs. the toolbar (was Re: "Why I Like Annotations")
>
> Maybe I'm missing something, but you can define a parameter as
> optional and give it a default value. Why not declare "listener" as
> optional and default it to the listener in your root page class?
>
> I realize this doesn't make your toolbar class 100% reusable across
> all projects, unless you document it as "calls listener
> listenToTheMusic(allTheTime...), unless overridden by a listener=...
> parameter".
>
> ...Richard
>
>
> On Nov 2, 2005, at 9:30, Patrick Casey wrote:
>
> >
> > My latest "I want" is a bit different from my earlier "I wants":
> >
> > I want to reduce the number of little pieces parts I have to change
> > to alter the product. Lets say, for example, I want to add a new
> > toolbar
> > button to one of my forms:
>
>
> ---------------------------------------------------------------------
> 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
Pat vs. the toolbar (was Re: "Why I Like Annotations")
Posted by Richard Clark <rd...@nextquestion.net>.
Maybe I'm missing something, but you can define a parameter as
optional and give it a default value. Why not declare "listener" as
optional and default it to the listener in your root page class?
I realize this doesn't make your toolbar class 100% reusable across
all projects, unless you document it as "calls listener
listenToTheMusic(allTheTime...), unless overridden by a listener=...
parameter".
...Richard
On Nov 2, 2005, at 9:30, Patrick Casey wrote:
>
> My latest "I want" is a bit different from my earlier "I wants":
>
> I want to reduce the number of little pieces parts I have to change
> to alter the product. Lets say, for example, I want to add a new
> toolbar
> button to one of my forms:
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: "Why I Like Annotations"
Posted by Patrick Casey <pa...@adelphia.net>.
My latest "I want" is a bit different from my earlier "I wants":
I want to reduce the number of little pieces parts I have to change
to alter the product. Lets say, for example, I want to add a new toolbar
button to one of my forms:
1) Step 1: Add the toolbar gif to the .jwc for the toolbar.
2) Step 2: Put @ImageSubmit on toolbar to reference button.
3) Step 3: Add listener to root page class.
4) Step 4: Modify toolbar .jwc to accept new listener as input.
5) Step 5: Modify all 20 forms where I use this toolbar component to
add the new listener to the input parameters.
That's a lot of pieces-parts I have to tweak to accomplish something
fairly trivial. Each individual step is easy (one of the benefits of
Tapestry), but the sum total is time consuming and error prone e.g. "doh, I
forgot to add the new listener to form x".
Maybe 4.0 offers some relief on this front, but for the last few
weeks, this has been the itch that's I've been scratching the most :).
--- Pat
> -----Original Message-----
> From: Vjeran Marcinko [mailto:vjeran.marcinko@email.t-com.hr]
> Sent: Wednesday, November 02, 2005 7:50 AM
> To: Tapestry users
> Subject: Re: "Why I Like Annotations"
>
> Beside noding to all below ... my addition to "I want" statements: ;)
> - I want confusing "abstract" keyword to go away, though from what I've
> read
> on your blog some time ago about some benefits of that, it may never even
> happen.... :-(
> - I want page/component specifications to go away/optional since with 4.0
> and annotations I mostly only have page/component class specified in it
>
> -V.
>
> ----- Original Message -----
> From: "Howard Lewis Ship" <hl...@gmail.com>
> To: "Tapestry users" <ta...@jakarta.apache.org>
> Sent: Wednesday, November 02, 2005 4:16 PM
> Subject: Re: "Why I Like Annotations"
>
>
> My thoughts along these lines and the future fall along these lines:
>
> Tapestry has too much API. I hope to tackle the worst offender,
> extending from base classes, in 4.1. Even so, with teh tools we now
> have (annotations, bytecode enhancement, IoC, OGNL, aspects), many of
> the design decisions I made in January 2000 are out of date. Many
> more work, luckily, pretty spot on and have stretched and grown with
> the framework.
>
> I want the Tapestry API to disappear as much as possible, using a mix
> of annoations and conventions.
>
> In fact, I want three levels of API:
>
> API exposed to typical developers, with real backwards compatibility
> XPI (Extension API) used more rarely by developers, to extend core
> framework functionality.
> SPI (Service Providider API) used internally, never exposed to the
> user code, and subject to change on each release.
>
> The first two would have strict backwards compatibility; the last
> level would be internal and allowed to change from release to release.
>
> The API and XPI should be as minimal as possible: interfaces, events
> and event interfaces, a handful of exceptions, maybe a couple of
> convienience base classes. The
>
> Ultimately, I'd like to turn what is, today, a product into a
> specification.
>
> I would like things to be more code-oriented; I would like XML to be
> an add-on, used only in rare cases.
>
> I would like a way of having libraries without namespaces.
>
> I want templates to be XML documents (so that the parser can handle
> encoding!) using namespaces for Tapestry elements and attributes. I
> want how components are used to determine what they do more.
>
> I want page names and component ids to be class names, or directly
> mapped to classes. The current Rube Goldberg machine that is giving
> Geoff fits is an artifact of an earlier and, I think, invalid version
> of Tapestry. It makes Hello World code-free at the expense of causing
> some chaos for real apps.
>
> More than that, I'm thinking that the framework needs to embrace Ajax
> and Ajax-techniques head on.
>
> I'm still working my head around how you can keep a Tapestry like
> approach, including Block/RenderBlock and other highly dynamic things,
> but be able to easily render just portions of a page.
>
>
> .... but right now, I just want to get 4.0 finished and out the door.
>
>
> On 11/2/05, Geoff Longman <gl...@gmail.com> wrote:
> > My opinion is that the decision to F&$K backwards compatibility is
> > moot at this point for Tap4. We are too far down the road to RC now.
> > Any migration tool development that may need to begin would be
> > starting many many months (a year?) behind the development of T4. T4
> > has benefitted greatly from months of user feedback, any migration
> > tool built now would be greatly disadvantaged by not having the same
> > benefit.
> >
> > Make the decision and announce that fact for T 4.1 or 5.0 or whatever
> > the next version will be called. Then it's up front and plain to see
> > before coding even starts and the discussion/development of migration
> > strategies, tools, whatever can proceed in parallel.
> >
> > I think that T both benefits from, and is hurt by it's free form
> > development methodology. The benefits are obvious as T can change much
> > faster than the "spec'ed" frameworks can. And that is no barrier to
> > adoption for the coding junkies like me. But widespread adoption is
> > hurt if compatibility is broken without a clearly defined way, in
> > place and bulletproof, to migrate because bigger shops will be loathe
> > to move to T if they are not sure that they can move with T in the
> > future.
> >
> > Make plan, stan, and mitigate the risks to adoption.
> >
> > Geoff
> >
> > On 11/2/05, Richard Clark <rd...@nextquestion.net> wrote:
> > >
> > > On Nov 1, 2005, at 15:55, Howard Lewis Ship wrote:
> > >
> > > > 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 if you want to keep serious commercial customers
> > > (those showcase apps that drive adoption), you need a fairly
> > > straightforward way to migrate to new platform releases. That could
> > > be by building a compatibility layer, by keeping "backward
> > > compatibility", or by a source-to-source translation mechanism.
> > >
> > > Right now, the update for the largest app I'm working on would be a
> > > bit of a stretch, but is doable (and there are aspects of T4 that we
> > > could use to clean up some inelegant code.) But if the answer was "we
> > > can't upgrade, and there's no support anymore for what we are using",
> > > there'd be trouble.
> > >
> > > ...R
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> > >
> > >
> >
> >
> > --
> > The Spindle guy. http://spindle.sf.net
> > Get help with Spindle:
> > http://lists.sourceforge.net/mailman/listinfo/spindle-user
> > Announcement Feed:
> > http://www.jroller.com/rss/glongman?catname=/Announcements
> > Feature Updates: http://spindle.sf.net/updates
> >
> > ---------------------------------------------------------------------
> > 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
>
>
>
> --
> 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: 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
Re: "Why I Like Annotations"
Posted by Vjeran Marcinko <vj...@email.t-com.hr>.
Beside noding to all below ... my addition to "I want" statements: ;)
- I want confusing "abstract" keyword to go away, though from what I've read
on your blog some time ago about some benefits of that, it may never even
happen.... :-(
- I want page/component specifications to go away/optional since with 4.0
and annotations I mostly only have page/component class specified in it
-V.
----- Original Message -----
From: "Howard Lewis Ship" <hl...@gmail.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Wednesday, November 02, 2005 4:16 PM
Subject: Re: "Why I Like Annotations"
My thoughts along these lines and the future fall along these lines:
Tapestry has too much API. I hope to tackle the worst offender,
extending from base classes, in 4.1. Even so, with teh tools we now
have (annotations, bytecode enhancement, IoC, OGNL, aspects), many of
the design decisions I made in January 2000 are out of date. Many
more work, luckily, pretty spot on and have stretched and grown with
the framework.
I want the Tapestry API to disappear as much as possible, using a mix
of annoations and conventions.
In fact, I want three levels of API:
API exposed to typical developers, with real backwards compatibility
XPI (Extension API) used more rarely by developers, to extend core
framework functionality.
SPI (Service Providider API) used internally, never exposed to the
user code, and subject to change on each release.
The first two would have strict backwards compatibility; the last
level would be internal and allowed to change from release to release.
The API and XPI should be as minimal as possible: interfaces, events
and event interfaces, a handful of exceptions, maybe a couple of
convienience base classes. The
Ultimately, I'd like to turn what is, today, a product into a specification.
I would like things to be more code-oriented; I would like XML to be
an add-on, used only in rare cases.
I would like a way of having libraries without namespaces.
I want templates to be XML documents (so that the parser can handle
encoding!) using namespaces for Tapestry elements and attributes. I
want how components are used to determine what they do more.
I want page names and component ids to be class names, or directly
mapped to classes. The current Rube Goldberg machine that is giving
Geoff fits is an artifact of an earlier and, I think, invalid version
of Tapestry. It makes Hello World code-free at the expense of causing
some chaos for real apps.
More than that, I'm thinking that the framework needs to embrace Ajax
and Ajax-techniques head on.
I'm still working my head around how you can keep a Tapestry like
approach, including Block/RenderBlock and other highly dynamic things,
but be able to easily render just portions of a page.
.... but right now, I just want to get 4.0 finished and out the door.
On 11/2/05, Geoff Longman <gl...@gmail.com> wrote:
> My opinion is that the decision to F&$K backwards compatibility is
> moot at this point for Tap4. We are too far down the road to RC now.
> Any migration tool development that may need to begin would be
> starting many many months (a year?) behind the development of T4. T4
> has benefitted greatly from months of user feedback, any migration
> tool built now would be greatly disadvantaged by not having the same
> benefit.
>
> Make the decision and announce that fact for T 4.1 or 5.0 or whatever
> the next version will be called. Then it's up front and plain to see
> before coding even starts and the discussion/development of migration
> strategies, tools, whatever can proceed in parallel.
>
> I think that T both benefits from, and is hurt by it's free form
> development methodology. The benefits are obvious as T can change much
> faster than the "spec'ed" frameworks can. And that is no barrier to
> adoption for the coding junkies like me. But widespread adoption is
> hurt if compatibility is broken without a clearly defined way, in
> place and bulletproof, to migrate because bigger shops will be loathe
> to move to T if they are not sure that they can move with T in the
> future.
>
> Make plan, stan, and mitigate the risks to adoption.
>
> Geoff
>
> On 11/2/05, Richard Clark <rd...@nextquestion.net> wrote:
> >
> > On Nov 1, 2005, at 15:55, Howard Lewis Ship wrote:
> >
> > > 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 if you want to keep serious commercial customers
> > (those showcase apps that drive adoption), you need a fairly
> > straightforward way to migrate to new platform releases. That could
> > be by building a compatibility layer, by keeping "backward
> > compatibility", or by a source-to-source translation mechanism.
> >
> > Right now, the update for the largest app I'm working on would be a
> > bit of a stretch, but is doable (and there are aspects of T4 that we
> > could use to clean up some inelegant code.) But if the answer was "we
> > can't upgrade, and there's no support anymore for what we are using",
> > there'd be trouble.
> >
> > ...R
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> >
>
>
> --
> The Spindle guy. http://spindle.sf.net
> Get help with Spindle:
> http://lists.sourceforge.net/mailman/listinfo/spindle-user
> Announcement Feed:
> http://www.jroller.com/rss/glongman?catname=/Announcements
> Feature Updates: http://spindle.sf.net/updates
>
> ---------------------------------------------------------------------
> 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
--
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: "Why I Like Annotations"
Posted by Howard Lewis Ship <hl...@gmail.com>.
My thoughts along these lines and the future fall along these lines:
Tapestry has too much API. I hope to tackle the worst offender,
extending from base classes, in 4.1. Even so, with teh tools we now
have (annotations, bytecode enhancement, IoC, OGNL, aspects), many of
the design decisions I made in January 2000 are out of date. Many
more work, luckily, pretty spot on and have stretched and grown with
the framework.
I want the Tapestry API to disappear as much as possible, using a mix
of annoations and conventions.
In fact, I want three levels of API:
API exposed to typical developers, with real backwards compatibility
XPI (Extension API) used more rarely by developers, to extend core
framework functionality.
SPI (Service Providider API) used internally, never exposed to the
user code, and subject to change on each release.
The first two would have strict backwards compatibility; the last
level would be internal and allowed to change from release to release.
The API and XPI should be as minimal as possible: interfaces, events
and event interfaces, a handful of exceptions, maybe a couple of
convienience base classes. The
Ultimately, I'd like to turn what is, today, a product into a specification.
I would like things to be more code-oriented; I would like XML to be
an add-on, used only in rare cases.
I would like a way of having libraries without namespaces.
I want templates to be XML documents (so that the parser can handle
encoding!) using namespaces for Tapestry elements and attributes. I
want how components are used to determine what they do more.
I want page names and component ids to be class names, or directly
mapped to classes. The current Rube Goldberg machine that is giving
Geoff fits is an artifact of an earlier and, I think, invalid version
of Tapestry. It makes Hello World code-free at the expense of causing
some chaos for real apps.
More than that, I'm thinking that the framework needs to embrace Ajax
and Ajax-techniques head on.
I'm still working my head around how you can keep a Tapestry like
approach, including Block/RenderBlock and other highly dynamic things,
but be able to easily render just portions of a page.
.... but right now, I just want to get 4.0 finished and out the door.
On 11/2/05, Geoff Longman <gl...@gmail.com> wrote:
> My opinion is that the decision to F&$K backwards compatibility is
> moot at this point for Tap4. We are too far down the road to RC now.
> Any migration tool development that may need to begin would be
> starting many many months (a year?) behind the development of T4. T4
> has benefitted greatly from months of user feedback, any migration
> tool built now would be greatly disadvantaged by not having the same
> benefit.
>
> Make the decision and announce that fact for T 4.1 or 5.0 or whatever
> the next version will be called. Then it's up front and plain to see
> before coding even starts and the discussion/development of migration
> strategies, tools, whatever can proceed in parallel.
>
> I think that T both benefits from, and is hurt by it's free form
> development methodology. The benefits are obvious as T can change much
> faster than the "spec'ed" frameworks can. And that is no barrier to
> adoption for the coding junkies like me. But widespread adoption is
> hurt if compatibility is broken without a clearly defined way, in
> place and bulletproof, to migrate because bigger shops will be loathe
> to move to T if they are not sure that they can move with T in the
> future.
>
> Make plan, stan, and mitigate the risks to adoption.
>
> Geoff
>
> On 11/2/05, Richard Clark <rd...@nextquestion.net> wrote:
> >
> > On Nov 1, 2005, at 15:55, Howard Lewis Ship wrote:
> >
> > > 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 if you want to keep serious commercial customers
> > (those showcase apps that drive adoption), you need a fairly
> > straightforward way to migrate to new platform releases. That could
> > be by building a compatibility layer, by keeping "backward
> > compatibility", or by a source-to-source translation mechanism.
> >
> > Right now, the update for the largest app I'm working on would be a
> > bit of a stretch, but is doable (and there are aspects of T4 that we
> > could use to clean up some inelegant code.) But if the answer was "we
> > can't upgrade, and there's no support anymore for what we are using",
> > there'd be trouble.
> >
> > ...R
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> >
>
>
> --
> The Spindle guy. http://spindle.sf.net
> Get help with Spindle:
> http://lists.sourceforge.net/mailman/listinfo/spindle-user
> Announcement Feed:
> http://www.jroller.com/rss/glongman?catname=/Announcements
> Feature Updates: http://spindle.sf.net/updates
>
> ---------------------------------------------------------------------
> 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
Re: "Why I Like Annotations"
Posted by Geoff Longman <gl...@gmail.com>.
Me too. Let's make it expicit though.
I wonder if reaching a consensus now on completely breaking backwards
compatibility will impact adoption of T4. Of course the discussion has
started and you can't stop it now.
On a personal note I know that I'm not going to kill myself on a
Spindle impl for T4 if I have to throw it all out for T5. And if it's
done right T5 is much more attractive to me than T4. On another note,
I know that the company I work for will never migrate to T4 if the
whole shootin match will change in T5. Everybody know that support for
old versions quickly fades when a new version comes out.
Perhaps any planning for migration strategies for 'T5' should include
migration from T3 to T5.
Geoff
On 11/2/05, Massimo Lusetti <ml...@gmail.com> wrote:
> On 11/2/05, Geoff Longman <gl...@gmail.com> wrote:
>
> > Make the decision and announce that fact for T 4.1 or 5.0 or whatever
> > the next version will be called. Then it's up front and plain to see
> > before coding even starts and the discussion/development of migration
> > strategies, tools, whatever can proceed in parallel.
>
> Sure, I'm thinking that was the way also Howard thought when talk
> about breaking backward compatibility, at least i was thinking that
> way.
>
> --
> Massimo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
--
The Spindle guy. http://spindle.sf.net
Get help with Spindle:
http://lists.sourceforge.net/mailman/listinfo/spindle-user
Announcement Feed:
http://www.jroller.com/rss/glongman?catname=/Announcements
Feature Updates: http://spindle.sf.net/updates
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: "Why I Like Annotations"
Posted by Massimo Lusetti <ml...@gmail.com>.
On 11/2/05, Geoff Longman <gl...@gmail.com> wrote:
> Make the decision and announce that fact for T 4.1 or 5.0 or whatever
> the next version will be called. Then it's up front and plain to see
> before coding even starts and the discussion/development of migration
> strategies, tools, whatever can proceed in parallel.
Sure, I'm thinking that was the way also Howard thought when talk
about breaking backward compatibility, at least i was thinking that
way.
--
Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: "Why I Like Annotations"
Posted by Geoff Longman <gl...@gmail.com>.
My opinion is that the decision to F&$K backwards compatibility is
moot at this point for Tap4. We are too far down the road to RC now.
Any migration tool development that may need to begin would be
starting many many months (a year?) behind the development of T4. T4
has benefitted greatly from months of user feedback, any migration
tool built now would be greatly disadvantaged by not having the same
benefit.
Make the decision and announce that fact for T 4.1 or 5.0 or whatever
the next version will be called. Then it's up front and plain to see
before coding even starts and the discussion/development of migration
strategies, tools, whatever can proceed in parallel.
I think that T both benefits from, and is hurt by it's free form
development methodology. The benefits are obvious as T can change much
faster than the "spec'ed" frameworks can. And that is no barrier to
adoption for the coding junkies like me. But widespread adoption is
hurt if compatibility is broken without a clearly defined way, in
place and bulletproof, to migrate because bigger shops will be loathe
to move to T if they are not sure that they can move with T in the
future.
Make plan, stan, and mitigate the risks to adoption.
Geoff
On 11/2/05, Richard Clark <rd...@nextquestion.net> wrote:
>
> On Nov 1, 2005, at 15:55, Howard Lewis Ship wrote:
>
> > 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 if you want to keep serious commercial customers
> (those showcase apps that drive adoption), you need a fairly
> straightforward way to migrate to new platform releases. That could
> be by building a compatibility layer, by keeping "backward
> compatibility", or by a source-to-source translation mechanism.
>
> Right now, the update for the largest app I'm working on would be a
> bit of a stretch, but is doable (and there are aspects of T4 that we
> could use to clean up some inelegant code.) But if the answer was "we
> can't upgrade, and there's no support anymore for what we are using",
> there'd be trouble.
>
> ...R
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
--
The Spindle guy. http://spindle.sf.net
Get help with Spindle:
http://lists.sourceforge.net/mailman/listinfo/spindle-user
Announcement Feed:
http://www.jroller.com/rss/glongman?catname=/Announcements
Feature Updates: http://spindle.sf.net/updates
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: "Why I Like Annotations"
Posted by Richard Clark <rd...@nextquestion.net>.
On Nov 1, 2005, at 15:55, Howard Lewis Ship wrote:
> 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 if you want to keep serious commercial customers
(those showcase apps that drive adoption), you need a fairly
straightforward way to migrate to new platform releases. That could
be by building a compatibility layer, by keeping "backward
compatibility", or by a source-to-source translation mechanism.
Right now, the update for the largest app I'm working on would be a
bit of a stretch, but is doable (and there are aspects of T4 that we
could use to clean up some inelegant code.) But if the answer was "we
can't upgrade, and there's no support anymore for what we are using",
there'd be trouble.
...R
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: "Why I Like Annotations"
Posted by Leonardo Quijano Vincenzi <le...@dtqsoftware.com>.
Howard Lewis Ship wrote:
> 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 :-)
>
+1 on that! I don't have any problems on even rewriting some of the Tap
4 components, if it's worth it.
> 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.
>
Maybe, IMO, 3.0 -> 4.0 it's like something of a 'halfway approach'. It
breaks compatibility, but not enough to warrant being a whole new
framework (for which we can always sketch up a migration plan), and it's
neither an evolutionary framework.
Then again, I don't have much experience with 3.0. Just that if you're
going to break compatibility, then break it all and provide a plugin for
old components.
My 2 cents...
--
Ing. Leonardo Quijano Vincenzi
Director Técnico
DTQ Software
> On 11/1/05, Scott Russell <sc...@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
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: "Why I Like Annotations"
Posted by Massimo Lusetti <ml...@gmail.com>.
On 11/2/05, Howard Lewis Ship <hl...@gmail.com> wrote:
> 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 :-)
Well... Howard! Build us something better, and F**K backwards compatibility!
I'm all for it!
--
Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: "Why I Like Annotations"
Posted by Shawn Church <sh...@boxity.com>.
I personally am not bothered too much by a lack of backward compatibility.
I have many applications running in various environments, including not only
Tapestry 3 and 4, but also legacy Java and non-Java apps. I know I will
never have the time to go back and refactor everything to a common platform
without a compelling reason. Tapestry 4 is great, but Tapestry 3 works. I
would love to see a new "something better", even if it deviated
significantly from the existing Tapestry model.
Shawn
-----Original Message-----
From: Howard Lewis Ship [mailto:hlship@gmail.com]
Sent: Tuesday, November 01, 2005 5: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 <sc...@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 <km...@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
RE: "Why I Like Annotations"
Posted by Patrick Casey <pa...@adelphia.net>.
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:hlship@gmail.com]
> 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 <sc...@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 <km...@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
Re: "Why I Like Annotations"
Posted by Jesse Kuhnert <jk...@gmail.com>.
And I wonder why it was so easy to move to tap4 ;)
On 11/2/05, Vjeran Marcinko <vj...@email.t-com.hr> wrote:
>
> 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" <hl...@gmail.com>
> To: "Tapestry users" <ta...@jakarta.apache.org>
> 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 <sc...@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 <km...@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
>
>
>
> --
> 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: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
Re: "Why I Like Annotations"
Posted by Vjeran Marcinko <vj...@email.t-com.hr>.
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" <hl...@gmail.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
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 <sc...@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 <km...@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
--
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: "Why I Like Annotations"
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <sc...@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 <km...@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
Re: "Why I Like Annotations"
Posted by Scott Russell <sc...@hotmail.com>.
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 <km...@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
Re: "Why I Like Annotations"
Posted by Ron Piterman <rp...@gmx.net>.
me too...
I remember having such an exception when defining an injection in both
annotations and xml.
Cheers,
Ron
ציטוט Kevin Menard:
> On Tue, 01 Nov 2005 10:26:03 -0500, Howard Lewis Ship
> <hl...@gmail.com> wrote:
>
>> Actually, that's not how it works in Tapestry; the annotations
>> override the XML, not the other way around.
>
>
> Ahh, do they actually override or simply complement? While the
> semantics may be different than I thought they were, I still seem to
> get an error when having both an XML entry and an annotation for the
> the same property.
>
>> 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.
>
>
> Okay. I thought your primary beef was that while changes to annotation
> values require a recompilation, allowing the values to be overridden by
> XML makes that point moot. Seems I was off a bit there.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: "Why I Like Annotations"
Posted by Ron Piterman <rp...@gmx.net>.
So they do not override but conurent or alternative to eachother...
What do you mean then by override?
("the annotations override the XML, not the other way around.")
Cheers,
Ron
ציטוט Howard Lewis Ship:
>>Ahh, do they actually override or simply complement? While the semantics
>>may be different than I thought they were, I still seem to get an error
>>when having both an XML entry and an annotation for the the same property.
>>
>
>
> It's kind of evolutionary; the annoation logic adds additional
> information to the parsed component specification, adding in objects
> as if they were in the XML. There's conflict checking logic in there
> already, so you can mix and match but each property must be either in
> the XML or in an annotation; doing both will cause a runtime error.
>
> --
> 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
Re: "Why I Like Annotations"
Posted by Howard Lewis Ship <hl...@gmail.com>.
> Ahh, do they actually override or simply complement? While the semantics
> may be different than I thought they were, I still seem to get an error
> when having both an XML entry and an annotation for the the same property.
>
It's kind of evolutionary; the annoation logic adds additional
information to the parsed component specification, adding in objects
as if they were in the XML. There's conflict checking logic in there
already, so you can mix and match but each property must be either in
the XML or in an annotation; doing both will cause a runtime error.
--
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
Re: "Why I Like Annotations"
Posted by Kevin Menard <km...@servprise.com>.
On Tue, 01 Nov 2005 10:26:03 -0500, Howard Lewis Ship <hl...@gmail.com>
wrote:
> Actually, that's not how it works in Tapestry; the annotations
> override the XML, not the other way around.
Ahh, do they actually override or simply complement? While the semantics
may be different than I thought they were, I still seem to get an error
when having both an XML entry and an annotation for the the same property.
> 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.
Okay. I thought your primary beef was that while changes to annotation
values require a recompilation, allowing the values to be overridden by
XML makes that point moot. Seems I was off a bit there.
--
Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
"unset" ASO
Posted by Alexey Romanchuk <ui...@gorodok.net>.
Hello community!
May be its newbie question, but how i have "unset" ASO? like logout
action.
Thanks!
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: "Why I Like Annotations"
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <km...@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