My ideas to leverage JDNC
To whom it may please,
I am doing some development in parallel and plan to release an O/S product that use JDNC and offer public commercial training and mentoring in JDNC before year end.
I wrote down ideas that I will follow, related to http://jdnc.dev.java.net/documentation/roadmap.html :
#0. The " You should *not* install the app" splash screen should be relaxed and made more user friendly for non techie users of our applications - from JNLP. This screen is "sales prevention" for developers of JDNC.
#1. Main component must be javax.swing.text.html.HTMLDocument extension. That is how people will enter any comments fields, or text field, and the weak point of Swing. If evertying works, but not this, we lose, and vice versa; if this works and evertying else is so-so, we win.
#2. Tools should be done later, in V2 of JDNC. It is dangerous to automate, until clear best practices are there of how this is used manually 1st. Then the DTD can be crafted of how we should be writing code; which is what the tools will leverage. For V2, a JSR could be formed.
#3. Good architecture is key for project that are quick turnaround and need high efficiency. For example metadata and binding and validation will be locked to the model and not UI. (Ex: High End OO referenced in roadmap are guaranteed to use good architecture (even if they have to rewrite parts of JDNC) unlike what was stated in the roadmap, that sometimes they might not do good arcitecture! For example MVC)
#4. RowSet and JavaBeans should be avoided and collections should be used!. It is more effective to represent a row of columns as a Map. (No need for get/set, I used to do beans and found many wekanesses relative to collections). It is more effective to represent a resultset as a List (of Map/columns).
This way you can work effectively with Lucene and non SQL DAOâ€™s.
#5. Layout will be based on Jgoodies, no automated layout is ever useful, itâ€™s just a gadget.
#6. Sample application will be Master Detail CMS â€“ that is realistic. For example based on Struts jRoller Data.
#7. Caching of model can be done in V2 â€“ based on SoftHashMap and timeout.
#8. Async will be based on actions that extend Swing worker. Messages will be passed via methods.
#9. Occasionaly offline application can be V2. This will need data persistance to a local file of some sorts, maybe .DBF. Related to #7.
#10. See #1.
#11. A service dispatcher component will be implemented on server side to handle JDNC requests.