Last week I read a nice article of my con-colleague Lucas Jellema about “PL/SQL Table-to-Java Bean (and Data to Java Bean Manager) generator - useful for data driven demos without database ” at the AMIS-blog on:http://technology.amis.nl/blog/?p=3272.
In this blog Lucas writes how he generated java-code from Pl/Sql. It drew me back to a little project I did for myself and my former employer as a BusinessDevelopment-job. I wanted to make a simple method to enable a convential custom development application, like a Designer/Developer Forms application, like we build a million times in the past. Since it is primarly aimed for the hundreds of Forms applications at our customers that are primarly build with Designer and Headstart, I could do it in pl/sql also or even create a Headstart utility for it. But for the latter option I would learn myself Headstart-utility principals again, that did not look to useful for me. Pl/Sql would do. But I would have it flexible having the ability to generate several pieces of code from one source.
The problem with the code of Lucas, that is when you see it as a problem, is that all the code generation is in pl/sql. To change the outcome would mean that you should change your pl/sql code. I would like to have a more template-based solution.
A few years ago I wrote an article on “XML using Sql” for our monthly consulting paper at Oracle. See my post: http://darwin-it.blogspot.com/2008/07/xml-using-sql.html. With this knowledge it is easy to generate XML out of the datadictionary of the database. Then based on this xml you can generate all you want using ... XSLT.
Read further (pdf).
1 comment :
Very interesting article. It reminds me of the PHP Object Generator I've used a few years ago (http://www.phpobjectgenerator.com/). Aside a simple PHP object (much like a POJO in Java or the Oracle Object Types you create with your XSLT) it adds:
- the SQL to generate the table itself from the form you fill in on its website (or local version if you prefer that); this is not needed in the situation you write about but can be very handy
- the necessary getters and setters for each attribute
- attributes could easily be other objects or collections; not sure if that would work with the system you described
- the necessary methods to 'persist' the object (load, save, update etc)
Obviously you're article is a proof of concept and extensible for whatever situation or use case other developers are challenged with. Great job and I'm already thinking about ways to use it myself.
Wim
Post a Comment