Hi everyone,<div><br></div><div>its not just a matter of using different ScaffoldProviders in generateFromEntity plugin? </div><div><br></div><div>if you want vanilla javaEE code generation use FacesScaffold, if you want CDI Quey use CDIQueryBasedScafold and so on...</div>
<div><br></div><div>or its not that simple? </div><div><br></div><div><br><br><div class="gmail_quote">2012/1/24 Jason Porter <span dir="ltr"><<a href="mailto:lightguard.jp@gmail.com">lightguard.jp@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">*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.<div class="HOEnZb">
<div class="h5"><br>
<br><div class="gmail_quote">On Tue, Jan 24, 2012 at 15:19, Richard Kennard <span dir="ltr"><<a href="mailto:richard@kennardconsulting.com" target="_blank">richard@kennardconsulting.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Dan,<br>
<div><br>
> 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<br>
<br>
</div>I'd actually be against this.<br>
<br>
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<br>
declare proprietary interfaces like 'EntityWithId', or use non-obvious tricks like<br>
<a href="https://github.com/seam/faces/blob/develop/impl/src/main/java/org/jboss/seam/faces/conversion/ObjectConverter.java" target="_blank">https://github.com/seam/faces/blob/develop/impl/src/main/java/org/jboss/seam/faces/conversion/ObjectConverter.java</a><br>
<br>
So it'll need to be properly documented. Plus frameworks have a habit of growing. They'll need bug fixes, feature requests, examples etc.<br>
<br>
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:<br>
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.<br>
<br>
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<br>
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<br>
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<br>
is the code that actually saves my entity? How does that get called? What plumbing is this?"<br>
<br>
Regards,<br>
<br>
Richard.<br>
<br>
On 25/01/2012 1:34 AM, Dan Allen wrote:<br>
> On Tue, Jan 24, 2012 at 02:15, Lincoln Baxter, III <<a href="mailto:lincolnbaxter@gmail.com" target="_blank">lincolnbaxter@gmail.com</a> <mailto:<a href="mailto:lincolnbaxter@gmail.com" target="_blank">lincolnbaxter@gmail.com</a>>> wrote:<br>
><br>
> On Tue, Jan 24, 2012 at 1:59 AM, Dan Allen <<a href="mailto:dan.j.allen@gmail.com" target="_blank">dan.j.allen@gmail.com</a> <mailto:<a href="mailto:dan.j.allen@gmail.com" target="_blank">dan.j.allen@gmail.com</a>>> wrote:<br>
<div><div>><br>
> On Tue, Jan 24, 2012 at 01:27, Jason Porter <<a href="mailto:lightguard.jp@gmail.com" target="_blank">lightguard.jp@gmail.com</a> <mailto:<a href="mailto:lightguard.jp@gmail.com" target="_blank">lightguard.jp@gmail.com</a>>> wrote:<br>
><br>
><br>
> As for the non dep idea, I can certainly understand where Lincoln and Pete are coming from.<br>
><br>
><br>
> I don't.<br>
><br>
><br>
> 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<br>
> plan. This is why Seam and the other libraries were removed.<br>
><br>
><br>
> Again, I can stand see the point being made standing in those shoes.<br>
><br>
> 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<br>
> it (and we don't want to support it) with another face.<br>
><br>
> 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<br>
> you to take another look.<br>
><br>
><br>
> I do wonder though if that would preclude us from creating a CDI extension for rolling our own simple CRUD framework<br>
><br>
><br>
> 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<br>
> 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,<br>
> *that* could be a Forge plugin. It would be called<br>
><br>
><br>
> There are always multiple paths, just like we can always have multiple scaffold providers.<br>
><br>
><br>
> Agreed. We want to avoid the paradox of choice, but 2 - 3 strong options is fair.<br>
><br>
> 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<br>
> which plugins can inter-operate with the generated scaffold.<br>
><br>
><br>
> 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?<br>
> Does that fit within the requirements. After all, we want to make sure the code is as maintainable as possible given these constraints.<br>
><br>
> 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<br>
> onto it, not bulldoze and rebuild it :)<br>
><br>
><br>
> I'm not suggesting bulldoze. Simply refactor a small portion.<br>
><br>
><br>
> forge> leave-javaee-purist-mode<br>
><br>
><br>
> Also remember that what Richard has done with purist java EE is very impressive!<br>
><br>
><br>
> +100<br>
><br>
> 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<br>
> and use of conversations." It's looking great.<br>
><br>
> 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.)<br>
><br>
><br>
> <sarcasm> Yeah, because security one of those nice to have extras. </sarcasm><br>
><br>
> 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<br>
> DeltaSpike, perhaps integrating with another Apache library to start, Shiro. Anyway, OT.<br>
><br>
> -Dan<br>
><br>
> --<br>
> Dan Allen<br>
> Principal Software Engineer, Red Hat | Author of Seam in Action<br>
> Registered Linux User #231597<br>
><br>
> <a href="http://google.com/profiles/dan.j.allen" target="_blank">http://google.com/profiles/dan.j.allen</a><br>
> <a href="http://mojavelinux.com" target="_blank">http://mojavelinux.com</a><br>
> <a href="http://mojavelinux.com/seaminaction" target="_blank">http://mojavelinux.com/seaminaction</a><br>
><br>
><br>
><br>
</div></div><div><div>> _______________________________________________<br>
> forge-dev mailing list<br>
> <a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
<br>
_______________________________________________<br>
forge-dev mailing list<br>
<a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br>Jason Porter<br><a href="http://lightguard-jp.blogspot.com" target="_blank">http://lightguard-jp.blogspot.com</a><br>
<a href="http://twitter.com/lightguardjp" target="_blank">http://twitter.com/lightguardjp</a><br>
<br>Software Engineer<br>Open Source Advocate<br>Author of Seam Catch - Next Generation Java Exception Handling<br><br>PGP key id: 926CCFF5<br>PGP key available at: <a href="http://keyserver.net" target="_blank">keyserver.net</a>, <a href="http://pgp.mit.edu" target="_blank">pgp.mit.edu</a><br>
</font></span><br>_______________________________________________<br>
forge-dev mailing list<br>
<a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><a href="http://www.advancedit.com.br/" target="_blank"><span style="color:black;text-decoration:none"></span></a><span></span><span><span style="color:rgb(192,192,192)">Att, </span><br style="color:rgb(192,192,192)">
<br style="color:rgb(192,192,192)"><span style="color:rgb(192,192,192)">Rafael M. Pestano</span><br style="color:rgb(192,192,192)"><br style="color:rgb(192,192,192)"><span style="color:rgb(192,192,192)">Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande do Sul</span><br style="color:rgb(192,192,192)">
<span style="color:rgb(192,192,192)">Graduando em Ciência da Computação UFRGS</span></span><div><span><span style="color:rgb(192,192,192)">@realpestano</span></span></div><div><a rel="nofollow" href="http://code.google.com/p/jsf-conventions-framework/" style="color:rgb(35,71,134);outline-width:0px;outline-style:initial;outline-color:initial;font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)" target="_blank"><font color="#b9b9b9">http://code.google.com/p/jsf-conventions-framework/</font></a></div>
<br>
</div>