> I think I have shared my part in writing about the pro's and
> con's I see for the @Mount annotation, and all I got in
> return was "I don't like annotations".
I guess the argument was more "we don't like new stuff when the old will
do". It works the other way around, too: all I'm hearing is that some
guys like annotations (more elegant, readeable), but I remain
unconvinced that it's the better way.
<snip...>
>
> For instance the statelessness of a page. You specify that a
> page is stateless. You now have to override a method to
> provide that logic, but it is not logic... It is a
> configuration item that should be orthogonal to the page. I
> find it much clearer to see this specified in an annotation
> rather than some obscure overridden method 10 pages
> down:
>
> @Stateless
> public class MyPage extends WebPage {
> public MyPage() {
> }
> }
>
Now when I look at the Component class, I see no indication that there
is such a thing as statelessness. I find the isStateless() method much
more discoverable. I'm all for separation of concerns, but this is
(imho) exactly not an orthogonal configuration, but an intrinsic
property of the component implementation.
On a more general level, when I speak of configuration (as opposed to
code), I mean something that can change with different uses of the same
code. For example, there could be one use of a page where it is
stateless, and another where it is not. Annotations exactly cannot do
that.
Thomas
