Re: [forge-dev] Data access logic used by scaffold code
On Tue, Jan 24, 2012 at 17:19, Richard Kennard <
richard(a)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
Attachments:
- attachment.html (text/html — 3.9 KB)