cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Ball <ba...@webslingerZ.com>
Subject Re: R:MS-Access and ColumnFormatter issues ... & solutions
Date Thu, 03 Feb 2000 19:31:23 GMT
On Thu, 3 Feb 2000, Interesse Michelangelo wrote:

> Send me a context diff patch and I'll go ahead and include it in the
> processor. I've rewritten SQLProcessor as an XSP taglib and am reworking
> the syntax; I have some issues left to resolve with the way cocoon
> associates XSP namespaces with XSP logicsheets, but I'm working on that.

[patch snipped]
 
> That's just  a patch, not the final solution !

Committed. Btw, you can generate a context diff like so:

cvs diff -c [filename.java]

that's much easier for me to apply since I can just feed it to patch.

> One question I've got for you - I was also under the impression that
> calling rs.getString(i) on a numeric column could cause problems when
> using Access via the JDBC-ODBC bridge. Is that in fact the case? If so, do
> you see a simple patch to clean up that behavior?
> 
> <<<---------------------------------------------------------------
> 
> Sorry, You are not right ! In fact, the first call rs.getString(i) is
> performed inside the SQLProcessor class and it really works. The problem is
> to call the same method on the same element twice that goes wrong ! (I guess
> some JDBC-ODBC leak, at least in JDK 1.1.8)
> 
> --------------------------------------------------------------->>>

Like Stefano, I'm happy to be wrong. :)

> >   2) about the SQLProcessor class, did somebody  polanned to extend its
> > output DOM tree, in order to get an XML document with information like
> > metadata out of the result query? Don't you thing this could be helpful
> when
> > processing the XML output document through an XSL document in order to
> make
> > some other processing or style transformation?
> 
> If you can come up with some good syntax for configuring this behavior,
> I'll very likely add it to the XSP taglib. If you're interested in coding
> this behavior, so much the better. Sure, most all of the metadata
> information could come in handy at some point or another.
> 
> <<<---------------------------------------------------------------
> 
> Actually I extended the SQLProcessor class with .... a more general
> SQLMetaProcessor class (sorry OO purists !). In the new class (but you can
> insert the code in the base class or wherever you planned to move it) the
> change was:

Change looks handy; if you could send me a context diff as described
above, that'd be ever so much easier to deal with. :)

>     public Properties getQueryProperties(String name) {
>         if (name == null || name.equals("")) return getQueryProperties();
> 		Properties props = (Properties)query_props_table.get(name);
> -		if (props != null) return getQueryProperties();
> +		if (props == null) return getQueryProperties();
> 		return (Properties)props.clone();
>     }
> 
> The last one is not relevant to my new functionalities, but may be a bug!

Oops. Surprised I haven't encountered that one yet.

> Such a structure, will also prevent failures of the previous
> implementation, when the nama of the columns contain blanks (possible
> in MS-Access!!!), so they cannot be tag names but they can be
> attribute values !! At the same time, such a design allows to link
> column values with metadata informations (type, length, ...), usefull
> for subsequent transformations of the DOM output.

Hmm. I'm not sure if I like _requiring_ column names to be attribute
values instead of element names. Admittedly, it overcomes the
spaces-in-Access-identifier-names problem (stupid, stupid). It does make
linking with the metadata slightly easier, I think. Hmm.

> The next step is to include other information in the DOM output, like
> the original query issued, the elapsed time, and so on. But I want to
> be sure of the final shape of the SQL processor before to do that.
> When will it be ready?

I will check in the development taglib tonight.

> Can you provide me with some hints for chaining JSP processing
> (Tomcat) with Cocoon transformations (except XSP) ? I'd like to reuse
> the work I did with JSP and extend it through the Cocoon framework. It
> looks to me that XSP is still not as solid and clean as the code
> written in JSP can be. I use extensively JSP scriptlets, with the most
> of the logic incapsulated in the java classes. I use java code inside
> JSP pages just to obtain come control flow and dynamic values during
> the presentation.

I'm not sure what you mean by chaining in this context; I've never used
JSP extensively, having had such horrid experiences with ASP. I must
disagree with you about XSP, though - it's not necessary to put much java
code in your XML files. You can realize all of the benefits of XSP pages
just by using the standard tag libraries. Boy, some documentation on the
web would be really handy for those! the XSP page on the web site gives a
somewhat lopsided view of XSP. If Ricardo doesn't get back from his
Internet hiatus and no one else volunteers soon, I'll have to get around
to writing some taglib docs.

- donald


Mime
View raw message