cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Interesse Michelangelo <M.Intere...@netsiel.it>
Subject R:R:MS-Access and ColumnFormatter issues ... & solutions
Date Fri, 04 Feb 2000 22:12:06 GMT
>  <<SQLProcessor.diff>>  <<ConnectionDefs.diff>> ----------
> Da:	Donald Ball[SMTP:balld@webslingerZ.com]
> Risposta a: 	cocoon-dev@xml.apache.org
> Inviato:	giovedì 3 febbraio 2000 20.31
> A:	'cocoon-dev@xml.apache.org'
> Oggetto:	Re: R:MS-Access and ColumnFormatter issues ... & solutions
> 
> 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.
> 
Sorry, I don't have cvs installed on my c. , but I provide you with the
enclosed diffs, that look equivalent to me (let me know, otherwise!).


> > 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. :)
> 
Finally, I have inserted the code in the SQLProcessor class itself (the
patch is enclosed). That because the behaviour of the class remains the
same, unless you don't use the extended attributes in the XML input. So
please, consider how helpfull could be to apply the patch !

> >     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). 
Yes ! Yesss!

> It does make
> linking with the metadata slightly easier, I think. Hmm.
> 
Consider the XSL example I attached in my previous e-mail ... and its
extensions ...

> > 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.
> 
May be I'm not so expert (at all) in using XSP, and I'm confident with JSP,
.... but please, don't loose flexibility in design, i.e. : make XSP and JSP
(and not ASP !!!) co-exist and complement each other. Thanks.


> - donald
>  
> Michelangelo Interesse
> ----------------------------
>       Process Support Systems
>                Netsiel S.p.A.
>       * ++39-080-5092.220
> ----------------------------
> 
> 
> 

Mime
View raw message