> Antonio Gallardo wrote: >>>On a personal note, it is unfortunate because I think your new >>>techniques will be more attractive to my Client! Even though it may >>> not be the best way to work, they will find it easier to understand, >>> being closer to what they used to do. So even though I might prefer >>> O-R Mapping, I don't think they will. >> >> I think O/R Mapping at the first sight looks a doom. But when I closer >> see it. It is the same stuff we do when we write modular Database >> Actions. The database.xml is a real O/R mapping without Beans. > > Ok, let me tell you something. I've done consulting for a company that > relies rather havily on AS/400 machines. For those of you that don't > know it, AS/400 is soooooo relational-oriented that even the filesystem > is bunch of tables. > > They rely on SQL so much thay have SQL-wizards in house that program in > RPG (think about a horrible programming language... mix it with cobol... > stir... not even close!) as you and I speak. Ah, note that AS/400 has a > 8.3 char limitation on variable names, so you have wonderful things > like > > select ASNAMEW, AWCHORD from FOCLI2 > > In short, their business logic is RPG+SQL, *that* kind of SQL. After > seven years (and millions of euros) of producing their own patches on > top of a commercial ERP, and several people hired to match that > technological needs, they have no OO in-house programmer, nor they want > it. > > The problem is they have to connect that data (and the business logic > that is connected to it) on their intranet. > > As weird as it might seem, any O/R tool will drive them nuts for two > reasons: > > 1) none of them think in terms of objects
How many of them think in terms of pipelines? This question was posted just to show that we cannot meet every request from the users. If you are really thinking to use Cocoon, there are some concepts you must learn. This apply for many technologies. Please note: When I come to Cocoon, I never before used XML, XSL. But I must learn it in order to use Cocoon. > 2) there is no E/R model of their database! I think there must be a model. Always is a model. The other question is if they already had a graphic model of the database. Maybe there are not "clear" relations between tables, but if you think a little bit about it I am sure you will find the relations. > 3) only a few people know enough of that database to really extract > something meaningful. If you dont know the database, then how they build the needed queries? Sorry Stefano but things are not to opaque as you try to point it out. ;-) > > Ok, first answer to their problem is: you are hopeless and walk away. I dont think this is the solution. > > Second answer (that would make me look nicer and them call me again) > would be something like Chris' solution. Maybe you are right.... But, I started to believe in Beans, because someone posted a mail with the convenience to have a clear data layer. The beans do this for you. Beans are not to hard to write. There are classes with just a data structure of database fields with a set of "get" and "set" methods. That is all. This trivial classes let us to separate the data from the presentation. This is the power I saw here. It does not have info about how your data are structured into your database. To do this work you need the O/R map. This map "glue" every data field of the Bean with his equivalent into the Database. Please note: Maybe I am wrong, but this is my point of view about the beans and O/R maps (called Hibernate, Torque, OJB, etc.) The Beans allow us to be scalable and to separate presentation from data layer. the use if Beans help us to win independence from propetary SQL constructions. Of course it does not comes for free, there is a performance penality when we add Beans. > > This example is to shows you a few things: > > 1) there is no clear-cut solution to every problem. Elegance is never an > absolute metric. I partially agree. I can try to find a way to build database web based applications. The old approach of Cocoon (FormValidation + Database Actions) is not complete. You need to use Javascript on the client side to handle some situations. This Javascript code is hard to mantain..... > > 2) on the other hand, SoC *IS* an absolute metric, only that concern > analysis must be performed on an 'ad-hoc' basis: it can't be done once > for every potential problem space. > > This said, O/R mapping is *ONE* of the ways to solve the problem of > connecting flow logic with business logic and assumes several things: > > - objects are easier to deal with than SQL by the people involved in the > development process. This is not always true. > > - it is possible (in terms of economical feasibility) to perform this > mapping and to keep it updated. This is not always true. I think this is true. I believe that if you change the database you ONLY need to chanhe the O/R map. You dont need to change the XForm and the Bean. > > - database abstraction and cross-database portability is seen as a > value. In most cases, it's not. Please explain your point a little more. > > - the people are willing to pay the development costs of an additional > decoupling layer between their data abstraction and their database > representation. In most cases, they aren't. You will not expend many time to do this. This is why I thinked we can build a tool that will create the Beans for us. Of course you always will need to create and manage the O/R map. > > NOTE: SQL was invented *exactly* to provide that portable abstraction. > Today, it's considered nothing different from proprietary language with > lots of similarities between products in the same market niche. > > The result is that people will use direct SQL mapping much more than any > other solution. You are right if you are build a product for a specific Database Engine. But I think people are trying to gain some independence from providers (please read OS provider, Database provider and so on.). This is the main reason to use Java instead of a tight plataform language or tool. (I strongly believe in this). They are trying to gain independence from the Database Engines too. This is why we need to use Beans too. I faced a 2 years ago a similar problem. We had a tight integrated plataform with M$. Then we will need to rewrite all the stuff again in order to change to another OS. That means that the cheap at the beginning is not alway cheap at the end. In the other way if will expend a little more at the beginning creating O/R maps and Beans then we can easily migrate to another Database Engine. What this people will do when migrate to another plataform outside OS/400? > > They will do it in flow, or in SQLTransformer, or in ESQL, it doesn't > matter where, but they will. And we can't do (nor should, if this is a > value for them) anything about it. > > Now, does this mean that there are no better alternatives? no, I don't > think so. > > Is O/R the solution? could be. > > How would O/R work? so that it is as transparent as possible. This > probably rules out Torque-like pre-compilation-based approaches, leading > to more dynamically-oriented proxy-based approaches. So OBJ seems more > advanced in this context. > > Is O/R the solution to every datamapping problem? no way! but it might > solve lots of issues with structured-data mapping. AS for > unstructure-data mappings, a JSR-170-like repository will hopefully do > the job. > > But I really don't know, I just want to see people experiment and try > things out for a while and for sure there won't be *one* > one-size-fits-all solution, but several that will hopefully reduce their > overlap to the bare minimum. To be honest I hope it will help us. Soonly I will to write a new application. This time I will try to use some O/R mapping + XForm + Flow. I hope that after creating the correct databased web-based framework. We can archieve some database block or components. For example: customers, vendors, invoices, etc. After you create this components you can simply put this stuff into your new application and it will work. Best Regards, Antonio Gallardo > > -- > Stefano Mazzocchi <[EMAIL PROTECTED]> > Pluralitas non est ponenda sine necessitate [William of Ockham] > --------------------------------------------------------------------
