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

+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