On Tue, Jan 24, 2012 at 17:19, Richard Kennard <richard@kennardconsulting.com> wrote:
Dan,
I'd actually be against this.
> Can we agree to at least try to move some of the boilerplate into an embedded framework rather than have the common logic duplicated in each view bean
I don't think we can have an embedded framework without it being non-trivial. It's probably going to use unusual methods like 'getGenericSuperClass', or
declare proprietary interfaces like 'EntityWithId', or use non-obvious tricks like
https://github.com/seam/faces/blob/develop/impl/src/main/java/org/jboss/seam/faces/conversion/ObjectConverter.java
So it'll need to be properly documented. Plus frameworks have a habit of growing. They'll need bug fixes, feature requests, examples etc.
I don't think we should try and 'slip something like this past' as part of Forge. I'd be 100% behind creating something that is run as a top-level project:
a Seam CRUD framework (like CDI Query) or something. And Forge could use that. But I think it's too big to be part of Forge itself.
I agree that many developers, when they first see the Forge output, are going to immediately think "oh I could improve this, I could refactor that, oh look
I could push that into a base class". There's something implicit in that, which is that they've immediately grok'ed the output and are moving on to better
things. That's not such a bad achievement. In my opinion it's better than a lot of code generators (like, say, Roo) where your first thought is "so where
is the code that actually saves my entity? How does that get called? What plumbing is this?"