Re: [shale-validator] CommonsValidator doesn't take component converters into account!
jsf-ri1.1 contains converter for javax.faces.DateTime class only... not for java.util.Date class you can download and look at jsf-ri-config.xml... in fact, this is not the main problem... i can overcome my issue by adding a converter for java.util.Date... But this doesn't solve the problem in the origin Because; in JSF, one can add custom converter for each component separately... in such a case, using my by-type java.util.Date converter is meaningless! because, user assigned a custom converter for that field!! JSF will use it instead of by-type converter... so, commons should use it too... now, when assigned custom validator for fields,, JSF RI and CommonsValidator behaving differently!!! this is not an acceptable situation! isn't it? to realize the problem... when returned to my sample in the previous post; suppose that i have a java.util.Date converter... and no custom converter... in this case, CommonsValidator and JSF RI will work same.. both will use our by-type converter... But, if i use a custom converter for my inputtext as below; h:inputtext ... *f:convertDateTime dateStyle=short /* s:commonsvalidator type=required arg=... client=true server=true / /h:inputtext then, JSF RI will use this custom component converter to convert it's value but CommonsValidator will use our by-type java.util.Date converter... different behaviours!!... In conclusion; when we look at JSF RI code, we see that; it first looks for custom component converter then, if can not find, searches for a by-type converter... CommonsValidator must work same i think... i have injected my solution into my CommonsValidator class and it works perfect... above suggestion should be implemented in original CommonsValidator releases as soon as possible i think... i can provide code if required... regards.. hasan.. On 2/21/07, Gary VanMatre [EMAIL PROTECTED] wrote: From: Hasan Turksoy [EMAIL PROTECTED] hi all, Env: jsf1.1, commons-validator1.3.1, shale1.0.4.. i'am trying to put a required validator for my date entering field.. My field has a f:convertDateTime to make conversion between String - java.util.Date. it's like; h:inputtext ... f:convertDateTime dateStyle=short / s:commonsvalidator type=required arg=... client=true server=true / /h:inputtext When i entered a valid value into my date field it throws a ConverterException as below; javax.faces.ConverterException: You have requested a conversion for type java.util.Date, but there is no by-type converter registered for this type. I'm not sure why you are seeing this exception. I belive that the java.util.Data converter should be registered with the JSF runtime. Can you tell where the exception is being raised from the stack trace? The reason for asking is that the shale commons validator uses JSF converters to coerce data types to match the signatures of the server side validation methods. as i understand; it needs a converter for the java.util.Date class.. But in JSF, one can assign custom converter tags as above sample... this means, (my suggestion) commonsvalidator should get the converter for that type from component. if component don't have any converters assigned, it should lookup for a by-type converter then... Otherwise, i will have to define by-type converters for all my component converters! this will be stupid i think... any comments?? or solutions?? What version of the JSF runtime are you using? This sounds like a rutime issue. thanks in advance, hasan.. Gary.
Re: Re: Beginning a dialog (basic dialog manager) with V1.0.3
Hello Paul! Thank you, this solved my problem. Jan K.
Re: [shale-validator] CommonsValidator doesn't take component converters into account!
On 2/22/07, Hasan Turksoy [EMAIL PROTECTED] wrote: jsf-ri1.1 contains converter for javax.faces.DateTime class only... not for java.util.Date class you can download and look at jsf-ri-config.xml... in fact, this is not the main problem... i can overcome my issue by adding a converter for java.util.Date... But this doesn't solve the problem in the origin Because; in JSF, one can add custom converter for each component separately... in such a case, using my by-type java.util.Date converter is meaningless! because, user assigned a custom converter for that field!! JSF will use it instead of by-type converter... so, commons should use it too... now, when assigned custom validator for fields,, JSF RI and CommonsValidator behaving differently!!! this is not an acceptable situation! isn't it? to realize the problem... when returned to my sample in the previous post; suppose that i have a java.util.Date converter... and no custom converter... in this case, CommonsValidator and JSF RI will work same.. both will use our by-type converter... But, if i use a custom converter for my inputtext as below; h:inputtext ... *f:convertDateTime dateStyle=short /* s:commonsvalidator type=required arg=... client=true server=true / /h:inputtext then, JSF RI will use this custom component converter to convert it's value but CommonsValidator will use our by-type java.util.Date converter... different behaviours!!... In conclusion; when we look at JSF RI code, we see that; it first looks for custom component converter then, if can not find, searches for a by-type converter... CommonsValidator must work same i think... i have injected my solution into my CommonsValidator class and it works perfect... above suggestion should be implemented in original CommonsValidator releases as soon as possible i think... i can provide code if required... This definitely sounds like a real issue. Could you file a bug report in our issue tracking system[1] so we can get it addressed? Craig [1] https://issues.apache.org/struts/browse/SHALE regards.. hasan.. On 2/21/07, Gary VanMatre [EMAIL PROTECTED] wrote: From: Hasan Turksoy [EMAIL PROTECTED] hi all, Env: jsf1.1, commons-validator1.3.1, shale1.0.4.. i'am trying to put a required validator for my date entering field.. My field has a f:convertDateTime to make conversion between String - java.util.Date. it's like; h:inputtext ... f:convertDateTime dateStyle=short / s:commonsvalidator type=required arg=... client=true server=true / /h:inputtext When i entered a valid value into my date field it throws a ConverterException as below; javax.faces.ConverterException: You have requested a conversion for type java.util.Date, but there is no by-type converter registered for this type. I'm not sure why you are seeing this exception. I belive that the java.util.Data converter should be registered with the JSF runtime. Can you tell where the exception is being raised from the stack trace? The reason for asking is that the shale commons validator uses JSF converters to coerce data types to match the signatures of the server side validation methods. as i understand; it needs a converter for the java.util.Date class.. But in JSF, one can assign custom converter tags as above sample... this means, (my suggestion) commonsvalidator should get the converter for that type from component. if component don't have any converters assigned, it should lookup for a by-type converter then... Otherwise, i will have to define by-type converters for all my component converters! this will be stupid i think... any comments?? or solutions?? What version of the JSF runtime are you using? This sounds like a rutime issue. thanks in advance, hasan.. Gary.
Re: [shale-validator] CommonsValidator doesn't take component converters into account!
On 2/22/07, Hasan Turksoy [EMAIL PROTECTED] wrote: jsf-ri1.1 contains converter for javax.faces.DateTime class only... not for java.util.Date class you can download and look at jsf-ri-config.xml... in fact, this is not the main problem... i can overcome my issue by adding a converter for java.util.Date... But this doesn't solve the problem in the origin are you talking about this: converter converter-idjavax.faces.DateTime/converter-id converter-classjavax.faces.convert.DateTimeConverter/converter-class /converter that is just the id... I think the -for-class is only there for simple converters like javax.faces.convert.FloatConverter -M Because; in JSF, one can add custom converter for each component separately... in such a case, using my by-type java.util.Date converter is meaningless! because, user assigned a custom converter for that field!! JSF will use it instead of by-type converter... so, commons should use it too... now, when assigned custom validator for fields,, JSF RI and CommonsValidator behaving differently!!! this is not an acceptable situation! isn't it? to realize the problem... when returned to my sample in the previous post; suppose that i have a java.util.Date converter... and no custom converter... in this case, CommonsValidator and JSF RI will work same.. both will use our by-type converter... But, if i use a custom converter for my inputtext as below; h:inputtext ... *f:convertDateTime dateStyle=short /* s:commonsvalidator type=required arg=... client=true server=true / /h:inputtext then, JSF RI will use this custom component converter to convert it's value but CommonsValidator will use our by-type java.util.Date converter... different behaviours!!... In conclusion; when we look at JSF RI code, we see that; it first looks for custom component converter then, if can not find, searches for a by-type converter... CommonsValidator must work same i think... i have injected my solution into my CommonsValidator class and it works perfect... above suggestion should be implemented in original CommonsValidator releases as soon as possible i think... i can provide code if required... regards.. hasan.. On 2/21/07, Gary VanMatre [EMAIL PROTECTED] wrote: From: Hasan Turksoy [EMAIL PROTECTED] hi all, Env: jsf1.1, commons-validator1.3.1, shale1.0.4.. i'am trying to put a required validator for my date entering field.. My field has a f:convertDateTime to make conversion between String - java.util.Date. it's like; h:inputtext ... f:convertDateTime dateStyle=short / s:commonsvalidator type=required arg=... client=true server=true / /h:inputtext When i entered a valid value into my date field it throws a ConverterException as below; javax.faces.ConverterException: You have requested a conversion for type java.util.Date, but there is no by-type converter registered for this type. I'm not sure why you are seeing this exception. I belive that the java.util.Data converter should be registered with the JSF runtime. Can you tell where the exception is being raised from the stack trace? The reason for asking is that the shale commons validator uses JSF converters to coerce data types to match the signatures of the server side validation methods. as i understand; it needs a converter for the java.util.Date class.. But in JSF, one can assign custom converter tags as above sample... this means, (my suggestion) commonsvalidator should get the converter for that type from component. if component don't have any converters assigned, it should lookup for a by-type converter then... Otherwise, i will have to define by-type converters for all my component converters! this will be stupid i think... any comments?? or solutions?? What version of the JSF runtime are you using? This sounds like a rutime issue. thanks in advance, hasan.. Gary. -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: [shale-validator] CommonsValidator doesn't take component converters into account!
From: Matthias Wessendorf [EMAIL PROTECTED] On 2/22/07, Hasan Turksoy wrote: jsf-ri1.1 contains converter for javax.faces.DateTime class only... not for java.util.Date class you can download and look at jsf-ri-config.xml... in fact, this is not the main problem... i can overcome my issue by adding a converter for java.util.Date... But this doesn't solve the problem in the origin are you talking about this: javax.faces.DateTime javax.faces.convert.DateTimeConverter that is just the id... I think the -for-class is only there for simple converters like javax.faces.convert.FloatConverter Yeah, for some reason I was thinking that the RI already has a converter registered by type for the java.util.Date type. converter-for-classjava.util.Date/converter-for-class The shale commons validator uses the ConverterHelper [1] (uses JSF type converters) to convert the submitted value, after the components converter has already converted to a Date object, back to a String to match the commons validator methodParams. validator name=date classname=org.apache.shale.validator.CommonsValidator method=isDate methodParams=java.lang.String,java.lang.String msg=errors.date jsFunctionName=validateDate jsFunction=org.apache.commons.validator.javascript.validateDate depends=/ [1] http://svn.apache.org/viewvc/shale/framework/trunk/shale-core/src/main/java/org/apache/shale/util/ConverterHelper.java?view=markup -M Gary Because; in JSF, one can add custom converter for each component separately... in such a case, using my by-type java.util.Date converter is meaningless! because, user assigned a custom converter for that field!! JSF will use it instead of by-type converter... so, commons should use it too... now, when assigned custom validator for fields,, JSF RI and CommonsValidator behaving differently!!! this is not an acceptable situation! isn't it? to realize the problem... when returned to my sample in the previous post; suppose that i have a java.util.Date converter... and no custom converter... in this case, CommonsValidator and JSF RI will work same.. both will use our by-type converter... But, if i use a custom converter for my inputtext as below; ** / then, JSF RI will use this custom component converter to convert it's value but CommonsValidator will use our by-type java.util.Date converter... different behaviours!!... In conclusion; when we look at JSF RI code, we see that; it first looks for custom component converter then, if can not find, searches for a by-type converter... CommonsValidator must work same i think... i have injected my solution into my CommonsValidator class and it works perfect... above suggestion should be implemented in original CommonsValidator releases as soon as possible i think... i can provide code if required... regards.. hasan.. On 2/21/07, Gary VanMatre wrote: From: Hasan Turksoy hi all, Env: jsf1.1, commons-validator1.3.1, shale1.0.4.. i'am trying to put a required validator for my date entering field.. My field has a f:convertDateTime to make conversion between String - java.util.Date. it's like; server=true / When i entered a valid value into my date field it throws a ConverterException as below; javax.faces.ConverterException: You have requested a conversion for type java.util.Date, but there is no by-type converter registered for this type. I'm not sure why you are seeing this exception. I belive that the java.util.Data converter should be registered with the JSF runtime. Can you tell where the exception is being raised from the stack trace? The reason for asking is that the shale commons validator uses JSF converters to coerce data types to match the signatures of the server side validation methods. as i understand; it needs a converter for the java.util.Date class.. But in JSF, one can assign custom converter tags as above sample... this means, (my suggestion) commonsvalidator should get the converter for that type from component. if component don't have any converters assigned, it should lookup for a by-type converter then... Otherwise, i will have to define by-type converters for all my component converters! this will be stupid i think... any comments?? or solutions?? What version of the JSF runtime are you using? This sounds like a rutime issue. thanks in advance, hasan.. Gary. -- Matthias Wessendorf
Re: [shale-validator] CommonsValidator doesn't take component converters into account!
Craig i have created an issue.. you can reach it from herehttp://www.nabble.com/CommonsValidator-doesn%2527t-take-component-converters-into-account%2521-tf3266040.html ... Matthias you are absolutely right :). converters only defined(by id) in config file but they aren't registered for special types in general.. these converters generally assigned for components externally... may be, i've over consantrated about looking for custom component converters before by-type converters part of conversation ;) Gary in fact, it doesn't matter, whether there is a converter for that type or not... in any case, CommonsValidator should look for component's custom converter first. if can not find, look up for a by-type converter later. this is the main issue... JSF RI works as this way.. there might be a registered converter for my type.. But if i assigned a custom converter for a field, JSF RI will use it not the registered by-type converter.. so CommonsValidator should work like it too hasan.. http://www.jroller.com/page/hasant On 2/22/07, Gary VanMatre [EMAIL PROTECTED] wrote: From: Matthias Wessendorf [EMAIL PROTECTED] On 2/22/07, Hasan Turksoy wrote: jsf-ri1.1 contains converter for javax.faces.DateTime class only... not for java.util.Date class you can download and look at jsf-ri-config.xml... in fact, this is not the main problem... i can overcome my issue by adding a converter for java.util.Date... But this doesn't solve the problem in the origin are you talking about this: javax.faces.DateTime javax.faces.convert.DateTimeConverter that is just the id... I think the -for-class is only there for simple converters like javax.faces.convert.FloatConverter Yeah, for some reason I was thinking that the RI already has a converter registered by type for the java.util.Date type. converter-for-classjava.util.Date/converter-for-class The shale commons validator uses the ConverterHelper [1] (uses JSF type converters) to convert the submitted value, after the components converter has already converted to a Date object, back to a String to match the commons validator methodParams. validator name=date classname=org.apache.shale.validator.CommonsValidator method=isDate methodParams=java.lang.String,java.lang.String msg=errors.date jsFunctionName=validateDate jsFunction= org.apache.commons.validator.javascript.validateDate depends=/ [1] http://svn.apache.org/viewvc/shale/framework/trunk/shale-core/src/main/java/org/apache/shale/util/ConverterHelper.java?view=markup -M Gary Because; in JSF, one can add custom converter for each component separately... in such a case, using my by-type java.util.Dateconverter is meaningless! because, user assigned a custom converter for that field!! JSF will use it instead of by-type converter... so, commons should use it too... now, when assigned custom validator for fields,, JSF RI and CommonsValidator behaving differently!!! this is not an acceptable situation! isn't it? to realize the problem... when returned to my sample in the previous post; suppose that i have a java.util.Date converter... and no custom converter... in this case, CommonsValidator and JSF RI will work same.. both will use our by-type converter... But, if i use a custom converter for my inputtext as below; ** / then, JSF RI will use this custom component converter to convert it's value but CommonsValidator will use our by-type java.util.Date converter... different behaviours!!... In conclusion; when we look at JSF RI code, we see that; it first looks for custom component converter then, if can not find, searches for a by-type converter... CommonsValidator must work same i think... i have injected my solution into my CommonsValidator class and it works perfect... above suggestion should be implemented in original CommonsValidator releases as soon as possible i think... i can provide code if required... regards.. hasan.. On 2/21/07, Gary VanMatre wrote: From: Hasan Turksoy hi all, Env: jsf1.1, commons-validator1.3.1, shale1.0.4.. i'am trying to put a required validator for my date entering field.. My field has a f:convertDateTime to make conversion between String - java.util.Date. it's like; server=true / When i entered a valid value into my date field it throws a ConverterException as below; javax.faces.ConverterException: You have requested a conversion for type java.util.Date, but there is no by-type converter registered for this type. I'm not sure why you are seeing this exception. I belive that the java.util.Data converter should be registered with the JSF runtime. Can you tell where the exception is being
Relative paths Clay
I've run into a very basic problem using Clay that I'm not sure how to solve. Here's the setup: I have a JSP file (we'll call it page.jsp) that contains a single clay tag that points to an HTML template in a subdirectory (we'll call it /templates/blah/foo.html). The HTML template references an image file in a completely different directory (/images/bar.jpg). How do I get the image to display properly both when rendered by Clay and when just loaded as a mockup? When loaded through the JSP using Clay, the image file's relative path is images/bar.jpg. However, when the HTML is loaded directly with a browser either online or offline, the image file's relative path is instead ../../images/bar.jpg. Using the absolute path (/appName/images/bar.jpg) works for both forms of online viewing (via JSP and as mockup), but it doesn't work for offline viewing (since the absolute path then becomes /full/filesystem/path/to/appName/images/bar.jpg), and I'd also rather not hard-code my application's context root into my HTML. I thought of using a base tag with jsfid=void, but that doesn't work, since base only accepts full URL's and not relative paths. Does anyone know of a way around this? Incidentally, the same issue arises with links to stylesheets. Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com
SV: Relative paths Clay
Hi Short answer: You don't. What I do is add a duplicate entry around such stuff using the Clay html remove stuff !-- ### clay:remove ### -- What comes here will be removed by clay, but displayed by a browser !-- ### /clay:remove ### -- Hermod -Opprinnelig melding- Fra: Richard Eggert [mailto:[EMAIL PROTECTED] Sendt: 22. februar 2007 22:30 Til: user@shale.apache.org Emne: Relative paths Clay I've run into a very basic problem using Clay that I'm not sure how to solve. Here's the setup: I have a JSP file (we'll call it page.jsp) that contains a single clay tag that points to an HTML template in a subdirectory (we'll call it /templates/blah/foo.html). The HTML template references an image file in a completely different directory (/images/bar.jpg). How do I get the image to display properly both when rendered by Clay and when just loaded as a mockup? When loaded through the JSP using Clay, the image file's relative path is images/bar.jpg. However, when the HTML is loaded directly with a browser either online or offline, the image file's relative path is instead ../../images/bar.jpg. Using the absolute path (/appName/images/bar.jpg) works for both forms of online viewing (via JSP and as mockup), but it doesn't work for offline viewing (since the absolute path then becomes /full/filesystem/path/to/appName/images/bar.jpg), and I'd also rather not hard-code my application's context root into my HTML. I thought of using a base tag with jsfid=void, but that doesn't work, since base only accepts full URL's and not relative paths. Does anyone know of a way around this? Incidentally, the same issue arises with links to stylesheets. Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com
Re: [shale-validator] CommonsValidator doesn't take component converters into account!
From: Hasan Turksoy [EMAIL PROTECTED]
jsf-ri1.1 contains converter for javax.faces.DateTime class only... not
for java.util.Date class you can download and look at
jsf-ri-config.xml...
in fact, this is not the main problem... i can overcome my issue by adding a
converter for java.util.Date... But this doesn't solve the problem in the
origin
Because; in JSF, one can add custom converter for each component
separately... in such a case, using my by-type java.util.Date converter is
meaningless! because, user assigned a custom converter for that field!! JSF
will use it instead of by-type converter... so, commons should use it too...
now, when assigned custom validator for fields,, JSF RI and CommonsValidator
behaving differently!!! this is not an acceptable situation! isn't it?
I agree it is not acceptable but they are not behaving differently. The
validator assigned to the component will be invoked before the CommonsValidator
is invoked.
to realize the problem... when returned to my sample in the previous post;
suppose that i have a java.util.Date converter... and no custom
converter... in this case, CommonsValidator and JSF RI will work same..
both will use our by-type converter...
But, if i use a custom converter for my inputtext as below;
**
/
then, JSF RI will use this custom component converter to convert it's value
but CommonsValidator will use our by-type java.util.Date converter...
different behaviours!!...
Not exactly, the java.util.Date converter is used by commons validator to
convert a Date object to a String (within the validator's validate method).
The custom converter assigned to the component (the same component that is
using commons validator), is being invoked prior to the call to commons
validator.
I'm not disagreeing that you have uncovered a bug that will be addressed but
what I'm saying is that Shales Commons Validator is using JSF converters as a
utility [1] for converting from one data type to another. It does this
nonsense to provide a generic way (single converter that works for any rule) to
invoke any custom validation rule that you might add.
I'll try to summarize with code:
// Validator's interface
public void validate(FacesContext context, UIComponent component, Object value)
{
..
Date obj = (Date) value;// value is already processed by the components
converter (String -- Date)
ConverterHelper converterHelper = new ConverterHelper();
// uses the a JSF converter Object to String
String objString = converterHelper.asString(context, obj.getClass(), obj);
boolean isValid = isDate(objString, datepattern);
[1]
http://svn.apache.org/viewvc/shale/framework/trunk/shale-core/src/main/java/org/apache/shale/util/ConverterHelper.java?view=markup
In conclusion; when we look at JSF RI code, we see that; it first looks for
custom component converter then, if can not find, searches for a by-type
converter... CommonsValidator must work same i think...
i have injected my solution into my CommonsValidator class and it works
perfect... above suggestion should be implemented in original
CommonsValidator releases as soon as possible i think...
I agree...
i can provide code if required...
regards..
hasan..
Gary
On 2/21/07, Gary VanMatre wrote:
From: Hasan Turksoy
hi all,
Env: jsf1.1, commons-validator1.3.1, shale1.0.4..
i'am trying to put a required validator for my date entering field.. My
field has a f:convertDateTime to make conversion between String -
java.util.Date. it's like;
server=true
/
When i entered a valid value into my date field it throws a
ConverterException as below;
javax.faces.ConverterException: You have requested a conversion for
type
java.util.Date, but there is no by-type converter registered for this
type.
I'm not sure why you are seeing this exception. I belive that the
java.util.Data
converter should be registered with the JSF runtime.
Can you tell where the exception is being raised from the stack trace?
The reason for asking is that the shale commons validator uses JSF
converters to coerce data types to match the signatures of the server
side validation methods.
as i understand; it needs a converter for the java.util.Date class.. But
in
JSF, one can assign custom converter tags as above sample...
this means, (my suggestion) commonsvalidator should get the converter
for
that type from component. if component don't have any converters
assigned,
it should lookup for a by-type converter then... Otherwise, i will have
to
define by-type converters for all my component converters! this will be
stupid i think...
any comments?? or solutions??
What version of the JSF runtime are you using? This sounds like a rutime
issue.
Re: Relative paths Clay
From: Richard Eggert [EMAIL PROTECTED] I've run into a very basic problem using Clay that I'm not sure how to solve. Here's the setup: I have a JSP file (we'll call it page.jsp) that contains a single tag that points to an HTML template in a subdirectory (we'll call it /templates/blah/foo.html). The HTML template references an image file in a completely different directory (/images/bar.jpg). How do I get the image to display properly both when rendered by Clay and when just loaded as a mockup? When loaded through the JSP using Clay, the image file's relative path is images/bar.jpg. However, when the HTML is loaded directly with a browser either online or offline, the image file's relative path is instead ../../images/bar.jpg. Using the absolute path (/appName/images/bar.jpg) works for both forms of online viewing (via JSP and as mockup), but it doesn't work for offline viewing (since the absolute path then becomes /full/filesystem/path/to/appName/images/bar.jpg), and I'd also rather not hard-code my application's context root into my HTML. I thought of using a tag with jsfid=void, but that doesn't work, since only accepts full URL's and not relative paths. Does anyone know of a way around this? You might try something like this: component jsfid=imageBar extends=h:graphicImage attributes set name=url value=/images/bar.jpg/ /attributes /component img jsfid=imageBar src=/appName/images/bar.jpg/ Incidentally, the same issue arises with links to stylesheets. You would be better off looking for a component, but something like this might work too: component jsfid=mycssLink extends=clay:clayOut attributes set name=excapeXml value=false/ set name=value value=lt;link jsfid=quot;mycssLinkquot; type=quot;text/cssquot; rel=quot;stylesheetquot; id=quot;csslinkquot; href=quot;/mycss.cssquot; /gt;/ /attributes /component link jsfid=mycssLink type=text/css rel=stylesheet id=csslink href=/appName/images/mycss.css / Another option would be to use the comment blocks to remove the CSS used for developement. !-- ### clay:remove ### -- link type=text/css rel=stylesheet id=csslink href=/appName/images/mycss.css / !-- ### /clay:remove ### -- link type=text/css rel=stylesheet id=csslink href=/mycss.css / Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com Gary
