@Sean / Shale ViewController: Thanks. I'll take a look at that. I need to verify that it's compatible with Facelets.
@Simon / property ordering: I've given this more thought, and you're probably correct. IDE tools should be maintaining the order, and using comments should handle any issues with other developers. Unfortunately, I now realize that I am also using the DisposableBean.destroy() method for one of my backing beans, but I may switch the rest over to using a property initializer. @Simon / fashions & /trends My apologies for the way I answered you earlier. I asked for comments and then refused to listen to yours :) @Simon / DTDs The problem is that I'm looking for solutions that work with JSF 1.1. That means annotations are out, and the solution has to work with the existing DTDs. In summary, I think property setting will work for the majority of the use cases. If Shale is compatible with my project, that will solve the rest of the issues. I'd still like to see this supported natively and cleanly by JSF bean management, though. -Mike On 10/26/05, Simon Kitching <[EMAIL PROTECTED]> wrote: > 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 > >
