See comments inline..
[PS:
Because it's hard to read and hard to reply to.
Why is top-posting bad?]
Mike Kienenberger wrote:
No, I hadn't realized that. Thanks.
But it is a hack. I'm more interested in seeing a formal solution.
I'd hate to write an application, and have another developer or design
tool break it by not maintaining the ordering.
I've checked the JSF spec. The section titled "The Managed Bean
Facility" explicitly states that:
<quote>
Properties are assigned in the order that their <managed-property>
elements are listed in the application configuration resource.
</quote>
So there's no worry about other tools or implementations failing to
respect that. If you have to worry about other developers messing it up,
you have more important worries :-)
So, apart from the fact that a dummy parameter needs to be passed, this
solution seems quite reasonable to me.
having a class implement a special interface for lifecycle stuff is going out
of fashion
Well, with all due respect, that's your opinion :)
Mind you, I'm stuck at Spring 1.2RC2, and I don't follow the spring
mailing lists, but it still seems in fashion there according to 1.2RC2
:) For myself, I'd rather implement an interface than configure
another xml file. There's little to be gained by making it an xml
configuration option.
An interface is compatible with JSF 1.1 and 1.2. Extending the xml is
not compatible as it breaks the dtd spec.
That said, I'd prefer an xml extension over nothing :)
Annotations are not a reasonable option at this point, and I don't
seem them as being better than an interface.
The reason that special interfaces are being phased out in many cases is
so that POJO (plain old java objects) can be used. This means that a
class can be used in multiple contexts rather than being wired for a
specific purpose. In particular, EJB classes can often make sense
standalone, or can be used in Spring if they aren't required to
implement EJB-specific interfaces. Avoiding implementing interfaces also
makes compilation easier, and can simplify unit testing.
It's a real trend, based on experience with building and maintaining
real-world projects.
And DTDs are also obsolete :-). The upcoming version of JSF uses schemas
instead to specify its config file constraints. And schemas have a
feature where you can declare that an element is allowed to have
additional xml attributes with any namespace *not* matching the schema's
namespace. This is very nice for exactly the reasons we are talking
about here; custom extensions to standard schema definitions.
Regards,
Simon
