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

[Richard Kennard]

+1 for a second scaffold.

Clearly the current scaffold is not doing much to further my clandestine goal of runtime UI generation. I'd definitely want to explore a second scaffold 
that depends on a runtime Metawidget (much as Forge Beta 3 did). And probably something like CDI Query, RichFaces, PrettyFaces etc. as well.

On 25/01/2012 11:34 AM, Dan Allen wrote:
> On Tue, Jan 24, 2012 at 17:19, Richard Kennard <richard at kennardconsulting.com <mailto: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
>
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev