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

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(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 > _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev