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

[Dan Allen]

On Tue, Jan 24, 2012 at 17:19, Richard Kennard <
richard at 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/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.
>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20120124/0bb91560/attachment.html