AW: RE: Strutscx-user digest, Vol 1 #108 - 1 msg

>Besides, doesn't the "C" in "StrutsCX" stand for Castor ? :)
That's true, but originally the use of Castor focused the backend/data
storage....

>Would love to hear more opinions on this.
... me too!


Berny 



-----Ursprüngliche Nachricht-----
Von: [email protected]
[mailto:[email protected]] Im Auftrag von
Mohammed Dessouky
Gesendet: Dienstag, 20. Januar 2004 14:11
An: [email protected]
Betreff: [Strutscx-user] RE: Strutscx-user digest, Vol 1 #108 - 1 msg

That's interesting that someone else also modified the framework to
marshal with castor, because we did the same thing.

The original reason behind trying to fit castor in the
strutscx-framework was that some types were not converting to XML like
if we ever passed an array or ArrayList of Strings as the
StrutsCXConstants.XML_KEY. We just assumed castor would convert any daya
type since it was a proven and widely used marshalling/unmarshalling
mechanism.

There are also added benefits that castor provides like the mapping file
which gives much more control on the XML presentation as well as
seperates the Java Object from the XML.

Besides, doesn't the "C" in "StrutsCX" stand for Castor ? :)

Would love to hear more opinions on this.

Regards,

Mohammed


-----Original Message-----
From: [email protected]
[mailto:[email protected]] 
Sent: Monday, January 19, 2004 11:03 PM
To: [email protected]
Subject: Strutscx-user digest, Vol 1 #108 - 1 msg

Send Strutscx-user mailing list submissions to
	[email protected]

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/strutscx-user
or, via email, send a message with subject or body 'help' to
	[email protected]

You can reach the person managing the list at
	[email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Strutscx-user digest..."


Today's Topics:

   1. AW: [Strutscx-user] My first contact with StrutsCX (Bernhard
Woehrlin)

--__--__--

Message: 1
Reply-To: <[email protected]>
From: "Bernhard Woehrlin" <[email protected]>
To: <[email protected]>,
	<[email protected]>
Subject: AW: [Strutscx-user] My first contact with StrutsCX
Date: Mon, 19 Jan 2004 14:56:17 +0100
Organization: IT.CappuccinoNet.com

Hi Bertrand,

Thanks for your comments on StrutsCX. Very helpful! Here some quick
annotations:

The checkBeanContent(Object bean) method of the StrutsCXBeanToElement
originally build on an JavaWorld article by Julien Mercay and Gilbert
Bouzeid 'Boost Struts with XSLT and XML'. So actually there was no need
to look for another way to serialize Objects into XML. Of course the use
of Castor XML is one option. - BTW, what advantages do you see in
replacing the actual checkBeanContent with a Castor XML solution? One
disadvantage I see, is the 1.1 MB size of Castor XML JAR.


I followed your suggestion and added the ss.setSystemId(url.toString());
line to the createXSLTemplate() method of the
StrutsCXStandardTransformer.=20

I haven't found time to check out and test your replacement of the
StrutsCXURIResolver. To everybody: Comments on this appreciated...


Greetings,

Berny



-----Urspr=FCngliche Nachricht-----
Von: [email protected]
[mailto:[email protected]] Im Auftrag von
Bertrand Martel
Gesendet: Sonntag, 18. Januar 2004 15:25
An: [email protected]
Betreff: [Strutscx-user] My first contact with StrutsCX

Hello there.

I'm implementing StrutsCX in a prototype/small project in order to
validate
StrutsCX framework.
My first impression is good, StrutsCX framework is small (ie, not a
bunch of
"heavy" jars) and simple to use (excellent & straightforward
installation
guide).

However, if have a few comments about DocumentBuilder & Transformer. I
have
implemented my own classes in order to perform some tasks which were
missing
in the ones delivered. Fortunately, as StrutsCX can be configured to
change/choose our own DocumentBuilder & Transformer classes, this has
been
easy.

I wanted to perform/correct the following :

. DocumentBuilder (aka
com.cappuccinonet.strutscx.xslt.StrutsCXStandardDocumentBuilder)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D=3D
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

In fact my changes did not impact this class but the
com.cappuccinonet.strutscx.xslt.StrutsCXBeanToElement class.
We have been using Castor framework for a while now. I have been quite
surprised to realize that the StrutsCXBeanToElement class did not
serialize/marshall my objets the same way Castor would (letter case,
attributes, etc.). What I did is to overload the "private Element
checkBeanContent(Object bean)" method with :

***********************************************************
private Element checkBeanContent(Object bean)	throws
IntrospectionException, IllegalAccessException,
InvocationTargetException,
MarshalException, ParserConfigurationException, ValidationException
	{
		org.w3c.dom.Document dom =3D
javax.xml.parsers.DocumentBuilderFactory.newInstance().newDocumentBuilde
r().
newDocument();
		org.exolab.castor.xml.Marshaller.marshal(bean, dom);
			=09
		return new
org.jdom.input.DOMBuilder().build(dom).detachRootElement();
	}
***********************************************************

And off course I setted the strutscx-config.xml file properly. This
works
great.

Maybe I missed something, but this behaviour (using Castor's Marshalling
way) should be natively present inside StrutsCX IMHO.


. Transformer (aka
com.cappuccinonet.strutscx.xslt.StrutsCXStandardTransformer)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D=3D
=3D=3D=3D

Two "problems" for this one but both refers to files URI resolving
issue.

a) <!DOCTYPE xsl:stylesheet SYSTEM "entities.dtd"> inside my XSL

In order to use &nbsp; and other entites in my XSL I include a dtd
reference
which declare those entities.
The XSLT engine (at least Xalan) do not use the URIResolver to find out
the
dtd file.
Actually I had the following error : "could not find the file
c:/document &
settings/Toto/Temporary/entities.dtd".
The path is resolved against the user.dir directory. In order to get rid
of
this issue I implemented my own Transformer
(which extends StrutsCXStandardTransformer) which sets SystemId to the
XSL
Source.

In method "protected Templates createXSLTemplate" :
[...]
logger.info("XSL File has changed: reparsing...!");
StreamSource ss =3D new StreamSource(urlConn.getInputStream());

ss.setSystemId(url.toString()); // <=3D=3D=3D=3D=3D=3D this is the =
"magic" line to
add

xslTemplate =3D tFactory.newTemplates(ss);
[...]

b) <xsl:include href=3D"toto.xsl" /> & <xsl:import href=3D"toto.xsl" />

I could not successfully import/include xsl tree inside my XSL with such
statements. The URI could not be resolved and I had an error stating
that the file could not be found.

NOTE 1 : the @href is relative (e.g. : "toto.xsl")
NOTE 2 : my XSL files are inside /WEB-INF/xsl

So I created my own URIResolver (source code is appended at the end for
readibility sake). Works with JDK1.4+ (I use the java.net.URI class).



I wanted to contribute to the community this way.
Keep the good job.

Sincerely.

Bertrand.


************************************************************************
****
****************************
package fr.bmartel.strutscx.xslt;

import java.io.IOException;
import java.net.MalformedURLException;
import java.net.URI;
import java.net.URISyntaxException;
import java.net.URL;
import java.net.URLConnection;

import javax.xml.transform.Source;
import javax.xml.transform.TransformerException;
import javax.xml.transform.URIResolver;
import javax.xml.transform.stream.StreamSource;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

public class StrutsCXURIResolver implements URIResolver
{
  /**
   * The Logger we use to log JDK 1.4 conform.
   */
  protected Log logger =3D LogFactory.getLog(this.getClass());
=09
  /**
   * The document root we will sent to the Constructor
   */
  public URI documentRoot;

  /**
   * Creates a new URIResolverImpl.
   *
   * @param documentRoot the path to the Server root which is used to
'resolve' the URI
   * @param servlet the ServletConfig we do need to create the
URLConnection
on the Server
   */
  public StrutsCXURIResolver(URI documentRoot)
  {
    this.documentRoot =3D documentRoot;
  }

  /**
   * This is called automatically from the Transformer.=20
   *
   * @param href expects a URL relative to the webapplication root
starting
with "/"
   * @param base
   */
  public Source resolve(String href, String base) throws
TransformerException
  {
		URL url =3D null;
    try
    {
			URI hrefURI =3D new URI(href);
			url =3D
this.documentRoot.resolve(hrefURI).toURL();

      if (url =3D=3D null)
      {
				throw new TransformerException("Could
not
resolve resource " + href);
      }
      else
      {
        URLConnection urlConn =3D url.openConnection();
        urlConn.connect();
        return new StreamSource(urlConn.getInputStream());
      }
    }
    catch (MalformedURLException e)
    {
      logger.error("MalformedURLException with href string " +
url.toString() + ": " + e);
      throw new TransformerException(e);
    }
    catch (IOException e)
    {
      logger.error("Could not connect to " + url.toString() + ": " + e);
      throw new TransformerException(e);
    }
		catch (URISyntaxException e)
		{
			logger.error("Could not connect to " +
url.toString() + ": " + e);
			throw new TransformerException(e);
		}
  }
}
************************************************************************
****
****************************



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Strutscx-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/strutscx-user




--__--__--

_______________________________________________
Strutscx-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/strutscx-user


End of Strutscx-user Digest


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Strutscx-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/strutscx-user



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn