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

*Some* will do that. Those people that are decent programmers will. Many people, or just programmers at outsourced companies will just follow along and do whatever they're presented with (I have horror stories, as I'm sure many of us do). I think what Richard has done is great and it works decently. I'm simply not 100% convinced that having this EE purist view is the best for us in the long run. After all, if we're going all purist, then we shouldn't need anything like Seam, or all the Hibernate extensions, or PrettyFaces, RichFaces, etc. I'm just wondering if this CRUD stuff, which we all know vanilla EE doesn't do very well, would be best to off load to something else. Same thing with Security, if the scaffolding will do anything with security. On Tue, Jan 24, 2012 at 15:19, Richard Kennard < richard(a)kennardconsulting.com&gt; 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. > > 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 > -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev