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

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

On Tue, Jan 24, 2012 at 02:15, Lincoln Baxter, III <lincolnbaxter(a)gmail.com <mailto:lincolnbaxter@gmail.com>> wrote: On Tue, Jan 24, 2012 at 1:59 AM, Dan Allen <dan.j.allen(a)gmail.com <mailto:dan.j.allen@gmail.com>> wrote: On Tue, Jan 24, 2012 at 01:27, Jason Porter <lightguard.jp(a)gmail.com <mailto:lightguard.jp@gmail.com>> wrote: As for the non dep idea, I can certainly understand where Lincoln and Pete are coming from. I don't. This is a support-driven requirement. There was a good deal of concern as to what kind of libraries we wanted to "commit" to for a 5-7 year support plan. This is why Seam and the other libraries were removed. Again, I can stand see the point being made standing in those shoes. You do have to admit that it looks a bit bipolar that we are working hard to grow a CDI ecosystem with one face, then telling developers they don't need it (and we don't want to support it) with another face. When did we become so fearful of supporting open source software, whether it's invented "here" or not. I'm not saying your wrong, I'm just encouraging you to take another look. I do wonder though if that would preclude us from creating a CDI extension for rolling our own simple CRUD framework The one reasonable path I see here is working out the framework and then having Forge just spit it out into the project. (I know that will turn Richard's stomach). But then, it's easy to nuke that package and add the dep...likely update the imports to use the right package too. In fact, *that* could be a Forge plugin. It would be called There are always multiple paths, just like we can always have multiple scaffold providers. Agreed. We want to avoid the paradox of choice, but 2 - 3 strong options is fair. Open to extension - We can't, and I would argue that we shouldn't, drop the pure EE scaffold, but we can certainly add more, and enhance the way in which plugins can inter-operate with the generated scaffold. 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? Does that fit within the requirements. After all, we want to make sure the code is as maintainable as possible given these constraints. That's the area where I think we should be focusing, instead of thinking "straight up replacement." What we have is a good foundation. Let's build onto it, not bulldoze and rebuild it :) I'm not suggesting bulldoze. Simply refactor a small portion. forge> leave-javaee-purist-mode Also remember that what Richard has done with purist java EE is very impressive! +100 Perhaps I should have started with "I was noticeably impressed during my demo last week at the JBUG when I first saw the sophistication of the UI forms and use of conversations." It's looking great. The main thing that's missing is security, and that's something that's just not there in EE. (And wasn't a requirement for the scaffold.) <sarcasm> Yeah, because security one of those nice to have extras. </sarcasm> Sarcasm aside, I understand that this is just a general problem. Being reminded of that, Jason and I recognized we should raise this as an early task in DeltaSpike, perhaps integrating with another Apache library to start, Shiro. Anyway, OT. -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