>> I think (2) can be also be used with O/R mapping tool. Not sure what the >> DB component is. In fact (and with my respect to ESQL developers) why >> Cocoon will need to build another layer when there is OJB. Remeber OJB >> allow you to play at 4 levels: > > As a user: Of course you can. The question is whether you'd want to. Using > OJB seems to demand that you set up descriptions of the tables, then > create appropriate classes etc.
No see a problem here. We already have automation tools for that: http://druid.sf.net/ (BTW, I want to share with you, that the a new proposal for a form generator in Druid was aproved! The idea is to make it able to generate for Woody). Well there is no line of code, but we already discused inside our company about that and while the task is no simple is posible. The big picture about this enhancement is: User: 1-Define database (tables, fields, etc.) 2-Define forms (tables involved, fields, properties) Then Druid generates for you: 1-Database SQL script builder (done) 2-Java Beans (done) 3-OJB (Hibernate) O/R map (needs improvements, but it works). 4-A basic woody definition.xml, binding.xml and templates.xml? for forms. Of course this idea is in a very early development and is not our main task, but is some people want to join the effort I invite them to subscribe on the druid devel mail list. > For a user, most of whom know a bit about SQL, or can read about it in the > thousands of introductory level books, SQL is much easier, not to say more > standard. I will not be sure. Writing SQL code is always larger than using O/R mapping tools and we already know many developers have problem with SQL. They don't write optimal SQL queries. See slides 10-14: http://cvs.apache.org/viewcvs.cgi/*checkout*/db-ojb/contrib/ojb-dataccess.pdf I think the SQL does not fit well into the OO world. That was told over and over. The O/R mapping gives you the hability to work with tables as Objects. As a sample, you can use JXPath and write something like: objectA.objectB.usersList.user[1].name This is great to use this kind of Objects inside JXTG or in other places. Once you start using it, you will see there is not way back to plain SQL. > Furthermore, creating a query based on form input is just the > concatenation of Strings. > How much more easy can it get? As an added bonus, you can > just log the queries in the developer phase and cut-and-paste them in > the command line database tool to see why they would not work. If you > use an added layer that power would either be lost or more difficult > accessible. See above... > I fully see that OJB is more beatifull. But not all people who wish > to write a simple flowscript app wish to start learning two major > technologies at once; they would fall back on a familiar technology > where possible to decrease the chance of failure. Partially agree, but just because someone is not able to follow the best practices this means we will drop them. > I think more of providing an easy migration path from CRUD to OJB, > using a MigrateFromCRUDToOJB Wiki page in which a simple CRUD flowscript > is moved to the OJB framework, and a sketch of a situation where OJB > is clearly easier to use that any other way. Good idea, but this is a documentation issue. I never used the CRUD flowscript. I even today never saw at the code inside the petstore sample. I cannot comment about it. > I think that, if you are familiar with OJB it is hard to see that things > like hibernate and OJB seem daunting; :-D Yes yo are right. > even the name promisses sleepless nights. The contrary is true. you will be able to sleep more, because you will make more in lees time. > And who on earth needs a bridge or relational mapping for > Select username, password from authentication where username = 'foo';? > If you already have OJB up and running it is logical to use that, but > to start learning OJB just for that??? I wonder if when SQL was a top technology, people had the same arguments as you against SQL. As I pointed before, the "time" is a good teacher and it will tell us who was right (Note, I am not assuming I am right). I believe we are still trying some paths and some good practices. In that way, we cannot discard nothing now. It is too early. Best Regards, Antonio Gallardo.
