On Oct 16, 2008, at 22:55 , Gavin King wrote:
We now really need to get going on the RI. I've attached the
latest
draft.
Comments up to chapter 2 - I might be completely wrong with my
questions because of something that I might find in a later chapter,
so ignore if that is the case:
Chapter 1
@Model is not used on model components in the example, they are
actually controllers and it probably should be called @Action. Or you
need to write different examples that actually put @Model on the model.
(Minor) Remove the System.out.println("Well, read the exception
name...") and re-throwing exception pattern in the examples. It's
embarrassing and if even one user copies that pattern, you've made
many peoples lives more difficult. Either log, or re-throw, never both.
I like the decorators, great stuff.
Chapter 2
Seems all good, I like what I'm seeing with XML namespaces in the
descriptor. A first for Sun?
2.5.3: I can easily imagine a component I want deployed in two
scenarios, so we should allow multiple deployment type declarations on
a web bean or producer method and only validate the highest precedence.
2.5.7: What's the value in enforcing that the <Standard/> deployment
type always be declared? Just enable it.
2.6: I understand that nobody cares about EJB names but why can't it
be a web beans name? At least it would be useful for something.
2.7: Inheritance of stereotypes is probably not needed. I can't see an
application having more than a few stereotypes and 2.7.2 already
defines composition of stereotypes.
2.7.5: Going back to my first comment about chapter 1, I recommend
removing the built-in @Model stereotype. I have no idea what I would
ever use it for. A typical conversational MVC application certainly
has not many request-scoped model instances...
2.8: The whole section and functionality of explicit specialization
seems unnecessary. Why can't I just put @Inherited on my binding type
declaration? If, in the example, I would put @Inherited on the
declaration of @Asynchronous, the same specialization rules for
binding and naming could be derived.