Re: [RT] Connecting databases with Cocoon
* Daniel Fagerstrom <[EMAIL PROTECTED]> [2004-03-01 13:37]: > Reinhard Poetz wrote: > >From: Daniel Fagerstrom [mailto:[EMAIL PROTECTED] > >>Reinhard Poetz wrote: > I think it is a fairly complete picture. > > So we need: > > * SQL queries (inbeded in XML) -> XML, this is handled by ESQL and > SQLTransformer, and by USQL in the future. Do we need some special > component for doing SQL-level update and insert, or is this also the > task of USQL? > > * XML <-> RDB mapping - possibly based on XML-DBMS As I said in a another thread, you'd be better off with an SQL update language expressed as XML than a "mapping". A "mapping" is a boondogggle. Want do see the example again? SQL splits itself neatly into update and query. They are two different problems. SQL has a clean query solution for XML already. The update part is all that is missing. -- Alan / [EMAIL PROTECTED] / http://engrm.com/ aim/yim: alanengrm - icq: 228631855 - msn: [EMAIL PROTECTED]
Re: [RT] Connecting databases with Cocoon
Reinhard Poetz wrote: From: Daniel Fagerstrom [mailto:[EMAIL PROTECTED] Reinhard Poetz wrote: After using Cocoon for years I still think we are not very clear in telling our users what is the right tool for their needs. Of course this depends on their use cases and their skills. I see three different "Cocoon & databases" szenarios: 1. Use Cocoon in enterprise szenarios which are highly interactive (--> many forms) + data which has to be saved in databases --> use CocoonForms, controlled by the Flow, a business facade written in Java, O/R-mapping as persistence layer --> or use a tool like XML-DBMS (see Mail from Daniel) as CocoonForms - database binding tool. 2. Use Cocoon as 'pure' publishing engine --> use ESQL or SQL Transformer (or sooner or later USQL ...) 3. Use Cocoon 'mainly' for publishing and there are only a few interactive pages that have to be persistent in a database and the user is not familiar with Java (this is for many people a reason why to use Cocoon because they can use XML everywhere and don't need to learn a programming language) As you can see szenario 1 and 2 have clear solutions, scenario 3 doesn't have. Some use ESQL with the drawback of mixing concers, some use SQLTransformer which doesn't make it easy to make create/update/delete-applications and some use DatabaseActions which are IMO the simplest way but they are not supported by flow and which are hidden in the depth of Cocoon (IMHO). IMO we should make the DatabaseActions more general components (... shouldn't be too difficult) which can be used from within flow or from actions and we should make clear statements what we as developer consider as 'best practices' and what are the pros and cons of each technology. WDYT? -- Reinhard I give some philosophical background to my opinion about this in [RT] Cocoon Input Model. My opinion is that Cocoons concern are for relational db (RDB) connections is for going form the RDB to XML and in the opposite direction. 1a. I think O/R mappings are cool and great for having persistence in enterprize applications with Cocoon frontend. I wonder however if they are within Cocoons concern area, isn't this more about the communication between the Java objects and the RDB? Of course. If you have enterprise applications you have a service layer without knowing from the existence of Cocoon at all. The connection back and forth beween Java and XML definitly is part of Cocoons concern area, IMHO. Yes, or in other words, the mapping between CocoonForms and Java is Cocoon's concern. I added this first point because I just wanted to complete the picture and to show that the two other points are used in different szenarios and from a different user group. 2. Yes, one definitely needs a SQL-level connection from querys to XML data. 3. I agree that we need a simple to use bidirrectional form/RDB connection like the DatabaseActions, but in my opinion they should go between XML and RDB and not between hashmaps and RDB. My main intension with the XML-DBMS proposal is to start a discussion about finding an easy way to go between XML and RDBS. What is the target group of this approach? IMO there are two groups: a) if you want to use CocoonForms without an explicit service layer because it is either overkill or the programmer isn't a Java programmer (definitly a reason why many people like Cocoon!) b) if you don't want to use CocoonForms at all and you want to map the information from the client directly to a database WDYT? Is this a complete picture or am I missing something? -- Reinhard I think it is a fairly complete picture. So we need: * SQL queries (inbeded in XML) -> XML, this is handled by ESQL and SQLTransformer, and by USQL in the future. Do we need some special component for doing SQL-level update and insert, or is this also the task of USQL? * XML <-> RDB mapping - possibly based on XML-DBMS /Daniel
RE: [RT] Connecting databases with Cocoon
From: Daniel Fagerstrom [mailto:[EMAIL PROTECTED] > Reinhard Poetz wrote: > > >After using Cocoon for years I still think we are not very clear in > >telling our users what is the right tool for their needs. Of course > >this depends on their use cases and their skills. > > > >I see three different "Cocoon & databases" szenarios: > > > >1. Use Cocoon in enterprise szenarios which are > > highly interactive (--> many forms) + data which > > has to be saved in databases > > > > --> use CocoonForms, controlled by the Flow, a > > business facade written in Java, > > O/R-mapping as persistence layer > > > > --> or use a tool like XML-DBMS (see Mail from > > Daniel) as CocoonForms - database binding > > tool. > > > >2. Use Cocoon as 'pure' publishing engine > > --> use ESQL or SQL Transformer (or sooner or > > later USQL ...) > > > > > >3. Use Cocoon 'mainly' for publishing and there are > > only a few interactive pages that have to be > > persistent in a database and the user is not > > familiar with Java (this is for many people > > a reason why to use Cocoon because they can > > use XML everywhere and don't need to learn > > a programming language) > > > >As you can see szenario 1 and 2 have clear solutions, scenario 3 > >doesn't have. Some use ESQL with the drawback of mixing > concers, some > >use SQLTransformer which doesn't make it easy to make > >create/update/delete-applications and some use DatabaseActions which > >are IMO the simplest way but they are not supported by flow > and which > >are hidden in the depth of Cocoon (IMHO). > > > >IMO we should make the DatabaseActions more general components (... > >shouldn't be too difficult) which can be used from within > flow or from > >actions and we should make clear statements what we as developer > >consider as 'best practices' and what are the pros and cons of each > >technology. > > > >WDYT? > > > >-- > >Reinhard > > > I give some philosophical background to my opinion about this in [RT] > Cocoon Input Model. My opinion is that Cocoons concern are for > relational db (RDB) connections is for going form the RDB to > XML and in > the opposite direction. > > 1a. I think O/R mappings are cool and great for having persistence in > enterprize applications with Cocoon frontend. I wonder > however if they > are within Cocoons concern area, isn't this more about the > communication > between the Java objects and the RDB? Of course. If you have enterprise applications you have a service layer without knowing from the existence of Cocoon at all. > The connection back and forth > beween Java and XML definitly is part of Cocoons concern area, IMHO. Yes, or in other words, the mapping between CocoonForms and Java is Cocoon's concern. I added this first point because I just wanted to complete the picture and to show that the two other points are used in different szenarios and from a different user group. > 2. Yes, one definitely needs a SQL-level connection from > querys to XML data. > > 3. I agree that we need a simple to use bidirrectional form/RDB > connection like the DatabaseActions, but in my opinion they should go > between XML and RDB and not between hashmaps and RDB. My main > intension > with the XML-DBMS proposal is to start a discussion about finding an > easy way to go between XML and RDBS. What is the target group of this approach? IMO there are two groups: a) if you want to use CocoonForms without an explicit service layer because it is either overkill or the programmer isn't a Java programmer (definitly a reason why many people like Cocoon!) b) if you don't want to use CocoonForms at all and you want to map the information from the client directly to a database WDYT? Is this a complete picture or am I missing something? -- Reinhard
Re: [RT] Connecting databases with Cocoon
Reinhard Poetz wrote: After using Cocoon for years I still think we are not very clear in telling our users what is the right tool for their needs. Of course this depends on their use cases and their skills. I see three different "Cocoon & databases" szenarios: 1. Use Cocoon in enterprise szenarios which are highly interactive (--> many forms) + data which has to be saved in databases --> use CocoonForms, controlled by the Flow, a business facade written in Java, O/R-mapping as persistence layer --> or use a tool like XML-DBMS (see Mail from Daniel) as CocoonForms - database binding tool. 2. Use Cocoon as 'pure' publishing engine --> use ESQL or SQL Transformer (or sooner or later USQL ...) 3. Use Cocoon 'mainly' for publishing and there are only a few interactive pages that have to be persistent in a database and the user is not familiar with Java (this is for many people a reason why to use Cocoon because they can use XML everywhere and don't need to learn a programming language) As you can see szenario 1 and 2 have clear solutions, scenario 3 doesn't have. Some use ESQL with the drawback of mixing concers, some use SQLTransformer which doesn't make it easy to make create/update/delete-applications and some use DatabaseActions which are IMO the simplest way but they are not supported by flow and which are hidden in the depth of Cocoon (IMHO). IMO we should make the DatabaseActions more general components (... shouldn't be too difficult) which can be used from within flow or from actions and we should make clear statements what we as developer consider as 'best practices' and what are the pros and cons of each technology. WDYT? -- Reinhard I give some philosophical background to my opinion about this in [RT] Cocoon Input Model. My opinion is that Cocoons concern are for relational db (RDB) connections is for going form the RDB to XML and in the opposite direction. 1a. I think O/R mappings are cool and great for having persistence in enterprize applications with Cocoon frontend. I wonder however if they are within Cocoons concern area, isn't this more about the communication between the Java objects and the RDB? The connection back and forth beween Java and XML definitly is part of Cocoons concern area, IMHO. 2. Yes, one definitely needs a SQL-level connection from querys to XML data. 3. I agree that we need a simple to use bidirrectional form/RDB connection like the DatabaseActions, but in my opinion they should go between XML and RDB and not between hashmaps and RDB. My main intension with the XML-DBMS proposal is to start a discussion about finding an easy way to go between XML and RDBS. /Daniel
USQL candidate? [Was Re: [RT] Connecting databases with Cocoon]
Here's an idea I've been kicking around. Let's see what folks think of it. I'm only covering the non-Java-programmer crowd here. Programmatic access via EJB/Component is and should be done through Flow IMHO. For others, especially those with a more publishing and/or simple in-out requirements, this is my proposal. - Have mapping like with XML-DBMS but not via a RelaxNG/XMLSchema wannabe. No offense intended toward the XML-DBMS folks, but the task didn't seem all that inviting to me. I've seen similar approaches via DTD annotation. This aversion is on multiple levels. First and foremost, the mapping file is yet another file to create and maintain. Sure it's not Java, but the layer-specific syntax might as well be another programming language. "Just" XML is a misnomer. After all, is XSLT just another document schema or is it a programming language? (Didn't someone find it to Turing-complete some time back?) I also have concerns over complexity which I will cover later. Most relevant to me, I am tired of doing the same old thing over and over again. This is what computers are for: to take the burden of repetitive, tedious tasks from us and to do these task faster than we can. And in my book that includes writing yet another set of SQL statements. To be perfectly honest, I do not consider knowledge of SQL syntax to be a significant enhancement to my life. Don't get me wrong. It has come in very handy over the years, but it is simply an obscure (albeit relatively simple) syntax to reference an ephemeral data organization pattern. I might say the same about XML were it not for the fact that XML is just the data structure without much in the way of syntax; XML is a serialization and processing format and serves that function far better than any alternative I can dream up. This brings me to my point. A relational database is a largely interrelated data structure. XML is a largely interrelated data structure. SQL is simply the convenient middleman. Others have seen this fact as is evidenced by the number of relational-to-XML tools out there. But where these tool strive desperately to solve all issues that many come up with data structure synchronization, I just wanted my common cases to go away. If greater than ninety percent of my cases can be solved with a simple syntax and less than ten percent of my cases require more difficult roads, I would be satisfied. Let's face it, we've all been confronted with the ninety percent case more times than we care to speak about. It is the corner case that intrigues us so much that we enjoy spending time to solve it. The less time the common case takes, the more time we can spend in enjoyable problem solving. I'm tired of spending time on getting an integer out of a result set and explicitly converting it to a string representation of the hex value. Frankly, I'm tired of having to remind the computer that I'm working with an integer. My database knows what type the field is. I'm the one who told it when setting up the database schema. My application server knows where my database is. I'm the one who specified the datasource. I don't see the need to tell my servers over and over again when they have things called "memory" and "processing power." So here's my proposal for a syntax that's as simple as possible but no simpler. Step 1: Let's assume we have a table called "books" in a database with the following structure and information. To make the example as simple as possible, we'll keep the number of items in the table small. It should be trivial to imagine a larger dataset. Table "books" id [serial] isbn [integer] title [varchar(100)] subtitle [varchar(100)] author [vachar(50)] pubdate [date] -- 1 764543555 Professional XML Development with Apache Tools Xerces, Xalan, FOP, Cocoon, Axis, Xindice Theodore W. Leung 1 Dec 2000 -- 2 735712352 Cocoon Building XML Applications Carsten Ziegeler, Matthew Langham 24 July 2002 -- 3 672322579 Cocoon Developer's Handbook NULL Lajos Moczar, Jeremy Aston 10 Dec 2002 -- Step 2: Create the Cocoon (or EJB?) datasource that points to the above. In this case, we'll call it "library." Step 3: Create a simple XML file that reflects the structure and what we want the output to look like. Step 4: Add a few "extra" attributes to that XML file. Adding the attributes "table" and "datasource" signal a context point. All results from this query will be relative to this XML element. http://geekspeak.org/datasource/1.0"; ds:datasource="library"
Re: [RT] Connecting databases with Cocoon
My way is use SQLTransformer to get data,mapping with woody form,using flow send the data to a pipeline,using database action to do update,add,delete work. But I write an inputmodule to get the data from flow passing to pipeline and set to database action.It seems you can use JXPathModule to do the same,but I don't know how to configure this module. Roy Huang - Original Message - From: "Reinhard Poetz" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, February 24, 2004 11:37 PM Subject: [RT] Connecting databases with Cocoon > > After using Cocoon for years I still think we are not very clear in > telling our users what is the right tool for their needs. Of course this > depends on their use cases and their skills. > > I see three different "Cocoon & databases" szenarios: > > 1. Use Cocoon in enterprise szenarios which are >highly interactive (--> many forms) + data which >has to be saved in databases > >--> use CocoonForms, controlled by the Flow, a >business facade written in Java, >O/R-mapping as persistence layer > >--> or use a tool like XML-DBMS (see Mail from >Daniel) as CocoonForms - database binding >tool. > > 2. Use Cocoon as 'pure' publishing engine >--> use ESQL or SQL Transformer (or sooner or >later USQL ...) > > > 3. Use Cocoon 'mainly' for publishing and there are >only a few interactive pages that have to be >persistent in a database and the user is not >familiar with Java (this is for many people >a reason why to use Cocoon because they can >use XML everywhere and don't need to learn >a programming language) > > As you can see szenario 1 and 2 have clear solutions, scenario 3 doesn't > have. Some use ESQL with the drawback of mixing concers, some use > SQLTransformer which doesn't make it easy to make > create/update/delete-applications and some use DatabaseActions which are > IMO the simplest way but they are not supported by flow and which are > hidden in the depth of Cocoon (IMHO). > > IMO we should make the DatabaseActions more general components (... > shouldn't be too difficult) which can be used from within flow or from > actions and we should make clear statements what we as developer > consider as 'best practices' and what are the pros and cons of each > technology. > > WDYT? > > -- > Reinhard > >
