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

[Richard Kennard]

And don't forget Ryan Bradley is working hard on a Spring scaffold too.

On 25/01/2012 11:44 AM, Richard Kennard wrote:
> +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
>