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

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. 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. 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?" Regards, Richard. On 25/01/2012 1:34 AM, Dan Allen wrote: > 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&lt;mailto: dan.j.allen(a)gmail.com&gt;&gt; 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 _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev