Cross-posting to forge dev.<br><br><div class="gmail_quote">On Tue, Sep 20, 2011 at 13:54, Dan Allen <span dir="ltr">&lt;<a href="mailto:dan.j.allen@gmail.com">dan.j.allen@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

xsalefter,<div><br></div><div>Thanks, this is valuable feedback and certainly usage patterns to keep in mind when designing the new iteration of these components.</div><div><br></div><div>In numerous conversations that I&#39;ve had with developers familiar with Seam 2, the common theme is that *Home and *Query components are not the ideal design. They lead developers into tight corners exactly in the way you are describing. Thus, we likely won&#39;t be following the status quo (though, it&#39;s not too big of an effort to port the existing functionality to CDI, so if someone would like to work on that, we won&#39;t discourage it).</div>


<div><br></div><div>Instead, I think these components should provide boilerplate functionality, yet be flexible and easily tuned to the needs of the developer. I think you&#39;re right in that going back to a generic DAO design might be a more reasonable strategy. I don&#39;t think developer expect to code entirely in XML, they simply don&#39;t want to type the same boilerplate over and over again.</div>


<div><br></div><div>I like Jason&#39;s idea of using named queries. Keep in mind we could read the queries as a suggestion and produce more sophisticated queries in an extension...so we aren&#39;t limited to what named queries support today. We&#39;ve also been considering supporting finder &quot;missing&quot; methods that build a query from the name of the method (or a set of annotations on the method).</div>


<div><br></div><div>Whatever we decide, this should be the framework code that forge uses when generating CRUD applications. Let&#39;s make it something that we aren&#39;t ashamed of having in our projects ;)</div><div><br>


</div><div>-Dan</div><div><br></div><div>p.s. I also recommend renaming SAF, because it&#39;s a really confusing term. Something like &quot;entity framework&quot; is far more sensible.</div><div><br><div class="gmail_quote">

<div><div></div><div class="h5">
On Tue, Sep 20, 2011 at 03:47, xsalefter <span dir="ltr">&lt;<a href="mailto:xsalefter@yahoo.com" target="_blank">xsalefter@yahoo.com</a>&gt;</span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><div></div><div class="h5">
<div><div style="color:#000;background-color:#fff;font-family:tahoma, new york, times, serif;font-size:10pt"><div><span><font size="2">Hi all.. I know that I never involved on this mailing-list so much, nor contribute things to the community. But because I have an experience with seam 2 and used seam gen extensively (and thus use seam&#39;s EntityQuery and EntityHome a lot) in some project, I have a thought about this.</font></span></div>


<div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px">EntityQuery anda EntityHome is perfect in case you want to creating an simple CRUD application. Well, not as simple as is. I ever involved in a project with 40 more database tables with quite extensive financial transaction, and use an EntityQuery and EntityHome a lot. The main problem with these classes is that, It&#39;s hard (well, at least, for me) to
 make your code consistent. </span><span style="font-size:13px">What I mean by consistent is that, i</span><span style="font-size:13px">t is confusing to determine whether the classes is a part of your UI layer, or service/domain-model layer. Or where you add new functionality to satisfied a specifics requirement. The study case is maybe like this:</span></div>


<div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px">Let say that we have a module named accounting transaction. And we want to create a input transaction page, thus we have a TransactionHome.xhtml backed with TransactionHome.java. Now the problems occurs. Because we want a chart of account list in the TransactionHome.xhtml, where is better place to put the logic to call the chart of account list? In the TransactionHome.java, or
 ChartOfAccountList.java? </span></div><div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px">In the beginning I put it in the ChartOfAccountList.java, and start to realize that seam&#39;s EntityList is specialized class to create a page with contains a rich datatable search option, paging, and sorting. It will be strange to the code if try to add non searching/sorting/paging on it. Then I think to back to good-old DAO object, and thinking again about the backing bean: I need to call/inject the DAO in some backing-bean, but where? TransactionHome.java? Well, TransactionHome already have getEntityManager(), so if I put the DAO in the ***Home, it will looks overlapping, and bit odd. Then when I thinking again about the EntityHome, I&#39;m not sure whether I need to treat this class as UI or Service class. </span><span style="font-size:13px">You see, this is simple case study (don&#39;t get me start with &quot;The list of Chart Of Account need to aligning with the logged in user&#39;s departments and user&#39;s role. And make sure that an user with level A have a $xxx limit transaction, where level B have $xxx limit&quot;). </span></div>


<div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px">My purpose is not to blame something or rant to something, but instead, give an idea whether is it good enough to leave ***Home and ***Query concept, and back to at least </span></div>


<div><font size="2">Entity-Service-BackingBean-View model? It looks &quot;verbose&quot;, I know, but at least we have a &quot;service&quot; layer, which is &quot;centralized&quot; place to write a business logic in our application. We could treat the &quot;service&quot; as just-plain-stateless classes (EJB 3.1 classes or only seam-persistence classes with minimal
 coupled with the front-end layer), and put the richness of Weld and Seam 3 maybe in the UI and view layer.</font></div><div><font size="2"><br></font></div><div><font size="2">Well, I know this is personal view, from me, and my experience. Thus, just ignore if in case this is annoying and not fit with your purpose/target.</font></div>


<div><font size="2"><br></font></div><div><font size="2">Thanks,</font></div><div><font size="2">xsalefter</font></div><div><div><blockquote style="border-left-width:2px;border-left-style:solid;border-left-color:rgb(16, 16, 255);margin-left:5px;padding-left:5px">


<div style="font-family:tahoma, &#39;new york&#39;, times, serif"><div style="font-family:&#39;times new roman&#39;, &#39;new york&#39;, times, serif"><b><font face="tahoma, &#39;new york&#39;, times, serif" size="2"><br>


</font></b><div><div><font face="tahoma, &#39;new york&#39;, times, serif" size="2">The Home idea</font></div><font face="tahoma, &#39;new york&#39;, times, serif" size="2"><a rel="nofollow" href="https://github.com/seam/seam-example-confbuzz/blob/develop/src/main/java/seam/example/confbuzz/ConferenceInstance.java" target="_blank">https://github.com/seam/seam-example-confbuzz/blob/develop/src/main/java/seam/example/confbuzz/ConferenceInstance.java</a><br clear="all">




</font><div><font face="tahoma, &#39;new york&#39;, times, serif" size="2"><br></font></div><div><font face="tahoma, &#39;new york&#39;, times, serif" size="2">The Query idea</font></div><div><a rel="nofollow" href="https://github.com/seam/seam-example-confbuzz/blob/develop/src/main/java/seam/example/confbuzz/TodaysConferencesQuery.java" target="_blank"><font face="tahoma, &#39;new york&#39;, times, serif" size="2">https://github.com/seam/seam-example-confbuzz/blob/develop/src/main/java/seam/example/confbuzz/TodaysConferencesQuery.java</font></a></div>




<div><font face="tahoma, &#39;new york&#39;, times, serif" size="2"><br></font></div><div><font face="tahoma, &#39;new york&#39;, times, serif" size="2">The main thing that I would change with the Query class above is to use named queries, thus espousing the generally accepted best practice in default applications. I understand this doesn&#39;t fill all the gaps of the older SAF from Seam 2, but I think it works for the majority of cases, and it also helps people understand the best way to do things instead of relying on the magic of SAF from Seam 2 (which I have found to be a major problem in projects and teams I have worked with over the last three years).</font></div>




<div><font face="tahoma, &#39;new york&#39;, times, serif" size="2"><br></font></div><div><font face="tahoma, &#39;new york&#39;, times, serif" size="2">I&#39;ve spoken with Lincoln about this and there are two JIRAs (<a rel="nofollow" href="https://issues.jboss.org/browse/SEAMFORGE-280" target="_blank">https://issues.jboss.org/browse/SEAMFORGE-280</a> and <a rel="nofollow" href="https://issues.jboss.org/browse/SEAMFORGE-279" target="_blank">https://issues.jboss.org/browse/SEAMFORGE-279</a>) to have Forge generate this via the JPA plugin or perhaps Seam Persistence plugin.</font></div>




<div><font face="tahoma, &#39;new york&#39;, times, serif" size="2"><br></font></div><div><font face="tahoma, &#39;new york&#39;, times, serif" size="2">Discuss.</font></div></div></div></div></blockquote></div></div></div>


</div><br></div></div>_______________________________________________<br>
seam-dev mailing list<br>
<a href="mailto:seam-dev@lists.jboss.org" target="_blank">seam-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/seam-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/seam-dev</a><br>
<br></blockquote></div><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div>Dan Allen</div>Principal Software Engineer, Red Hat | Author of Seam in Action<br>Registered Linux User #231597<br><br><div><a href="http://www.google.com/profiles/dan.j.allen#about" target="_blank">http://www.google.com/profiles/dan.j.allen#about</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></div><br>
</font></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Dan Allen</div>Principal Software Engineer, Red Hat | Author of Seam in Action<br>Registered Linux User #231597<br><br><div><a href="http://www.google.com/profiles/dan.j.allen#about" target="_blank">http://www.google.com/profiles/dan.j.allen#about</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></div><br>