Re: [forge-dev] Data access logic used by scaffold code

On Tue, Jan 24, 2012 at 17:19, Richard Kennard <richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com>> wrote: Dan, > 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'd actually be against this. 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/s... So it'll need to be properly documented. Plus frameworks have a habit of growing. They'll need bug fixes, feature requests, examples etc. After I laid down last night, this thought (i.e, fear) came rushing into my head. Shading in framework code is no good (like a bad hangover tells you about that last shot you did the night before). ^ The beginning of Hangover 2 just came to mind :) 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. Ah, just wait for it. DeltaSpike Qu... ;) Coming soon to a git repository. 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?" Very true. As I said in my other e-mail, we can sort of agree to disagree in part. The pure Java EE approach will likely invoke the reaction of "I could improve that", and they would be correct. But the output is not doing anything cryptic, so it fills a void of showing them what Java EE has, for better or for worse. I'm guessing you would agree that using a few frameworks would dramatically improve the elegance of the output, for example Query and MetaWidget. Therefore it's worth the community (at least) exploring a second scaffold that does make use of a palatable set of extension libraries. -Dan -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://google.com/profiles/dan.j.allen http://mojavelinux.com http://mojavelinux.com/seaminaction _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev