Re: [shale-validator] CommonsValidator doesn't take component converters into account!
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.
there is NO custom validator Gary, only custom converters there :).. i've
realized that i made a mistake while writing my previous mail.. It should be
custom converter instead of custom validator.. Sorry for this mistake...
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.
what i'm sayin is that too :) i only want to draw attention to custom
converters of components before using those JSF converters.
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 am not talking about using a generic converter or etc - as i say previous
sentence...
Let me summarize the conversation:
in current case; when i assigned a custom converter for a field, JSF RI is
using that custom converter but CommonsValidator is using by-type
converter.. This leads some misbehaviours...
Your comments light my mind,, and asked the same question for whole
yesterday...
if the value passed to the validator already converted, so why
commonsvalidator trying to convert that value again? The answer is; to use a
generic validator to do all validations.. As you say at your previous entry;
The data conversion occurs because the apache commons validator needs a
String data type and not a date data type.
Exactly at this point my issue/suggestion comes:
Main point is: Validator have to use the SAME CONVERTER which used before
sending that value to it...
i mean; if a value converted to java.util.Date type by ConverterX and send
to CommonsValidator to validate, so, CommmonsValidator must use that same
converter(ConverterX) too, to convert that value again toString/toObject...
not java.util.Date type's registered converter...
regards,
hasan
http://www.jroller.com/hasant
On 2/23/07, Gary VanMatre [EMAIL PROTECTED] wrote:
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
Re: Register DialogLifecycleListener
On 2/23/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi ! How or where can I register a DialogLifecycleListener. snip/ It is an application scoped managed bean (long URL, may be fragmented): http://shale.apache.org/1.0.4/shale-dialog/apidocs/org/apache/shale/dialog/Constants.html#LIFECYCLE_ATTR The application scope attribute is (the value of the above constant): org.apache.shale.dialog.LIFECYCLE_LISTENER -Rahul I'd like to attach out transactionmanagement to the DialogContextManager. CU Jan K.
why the arg argument is not early binding?
hi all,
commonsvalidator's arg argument used as the first argument of messages at
validator-rules.xml... in my application, i'm using those arg arguments to
hold some info(in general field's name) about my field which is being
validated
it's like:
h:inputtext ...
s:commonsvalidator type=required *arg=User Name* . /
/h:inputtext ...
above code works as expected and gives appropriate validation message if
that field is not valid (like: User Name is required.)
But, if i bind my arg argument to a key in my bundle, my message is being
as null is required... sample code is as below;
h:inputtext ...
s:commonsvalidator type=required *arg=#{varMyBundle.lblUserName}*. /
/h:inputtext ...
I dive into code and find the problem solution... ValidatorTag class is
setting arg argument's value directly instead of evaluating the expression
and putting the resulting value into it... Some of the arguments (type,
message, client, server) are early binding at the tag class but not
arg argument...
shouldn't the arg argument set by early binding as above attributes? isn't
this an issue?
regards,
hasan..
http://www.jroller.com/page/hasant
Re: [shale-validator] CommonsValidator doesn't take component converters into account!
From: Hasan Turksoy [EMAIL PROTECTED]
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.
there is NO custom validator Gary, only custom converters there :).. i've
realized that i made a mistake while writing my previous mail.. It should be
custom converter instead of custom validator.. Sorry for this mistake...
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.
what i'm sayin is that too :) i only want to draw attention to custom
converters of components before using those JSF converters.
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 am not talking about using a generic converter or etc - as i say previous
sentence...
Let me summarize the conversation:
in current case; when i assigned a custom converter for a field, JSF RI is
using that custom converter but CommonsValidator is using by-type
converter.. This leads some misbehaviours...
Your comments light my mind,, and asked the same question for whole
yesterday...
if the value passed to the validator already converted, so why
commonsvalidator trying to convert that value again? The answer is; to use a
generic validator to do all validations.. As you say at your previous entry;
The data conversion occurs because the apache commons validator needs a
String data type and not a date data type.
Exactly at this point my issue/suggestion comes:
Main point is: Validator have to use the SAME CONVERTER which used before
sending that value to it...
i mean; if a value converted to java.util.Date type by ConverterX and send
to CommonsValidator to validate, so, CommmonsValidator must use that same
converter(ConverterX) too, to convert that value again toString/toObject...
not java.util.Date type's registered converter...
It is a good question and it's not the first time it has been asked. It sounds
like you are familiar it commons validator [1]. Its important to point out
that the shale JSF flavor is an integration layer to an existing solution.
The example we are talking about here is pretty simple. The shale commons
validator is passed a java.util.Date. The method performing the validation
needs two Strings as part of the actual parameter.
Now, lets say that I have a custom validation function that I want to
register. Well use another simple example. Lets say that my custom date
validation function needs a java.sql.Date.
public class MyValidationRule
public static boolean isDateOnWeekend(java.sql.Date value)
To register the custom rule with the shales JSF integration with commons
validator [1], I need to declare a new rule in the validator-rule.xml [2]
configuration file. My custom validation rule doesnt have client side script
support only server-side.
validator name=dateonweekend
classname=org.acme.MyValidationRule
method= isDateOnWeekend
methodParams=java.sql.Date
msg=errors.date
depends=/
..
.
form name=org.apache.shale.validator.dateonweekend
field property=date
arg position=0 name=message key=arg resource=false/
arg position=1 name=message key=submittedValue
resource=false/
arg position=0 name=parameter key=submittedValue
resource=false/
/field
/form
The JSP might look something like this:
h:inputText id=date
value=#{mybean.partytime}
f:convertDateTime pattern=MM/dd//
val:commonsValidator
type=dateonweekend
datePatternStrict=MM/dd/
message={0} is not on the weekend
arg=Party time
server=true
client=false/
/h:inputText
The converter registered with the component, f:convertDateTime, will convert
from String to java.sql.Date. How are we going to invoke this function
without type conversion? The shale commons validator provides a declarative
mechanism to register various validation rules. The same chunk of code handles
invoking all rules, not just the date rule that we have been discussing.
This leads to the bigger questions. Is this the best way to implement
validators in JSF? Well probably not.
Does it provide integration with an existing apache project that focuses on
declarative form based validation (client and server side). Yes.
[1] http://jakarta.apache.org/commons/validator/
[2]
http://svn.apache.org/viewvc/shale/framework/trunk/shale-validator/src/main/resources/org/apache/shale/validator/validator-rules.xml?view=markup
regards,
hasan
Re: why the arg argument is not early binding?
From: Hasan Turksoy [EMAIL PROTECTED]
is this code working with shale.1.0.4 version? can you verify it?
because, my code exactly same as above.. it's working with 1.0.2 version but
not with 1.0.4 version... there is no problem with my bundles.. because i
can see its value in a ... like:
I'll try to take a look at it tonight. Can you verify that the validator
example in the shale-usecases [1] is not working [2] ?
--- snippet ---
h:inputText id=creditCard
size=11
value=#{validate$test.creditCard}
val:commonsValidator
type=required
arg=#{messages['prompt.creditCardNumber']}
server=true
client=false/
val:commonsValidator
type=creditCard
arg=#{messages['prompt.creditCardNumber']}
server=true
client=false/
val:commonsValidator type=mask
mask=[4-6].*
message=#{messages['validate.test.unknown.credit.card.type']}
server=false
client=true/
/h:inputText
--- snippet ---
[1] http://people.apache.org/builds/shale/nightly/examples/
[2]
http://svn.apache.org/viewvc/shale/framework/trunk/shale-apps/shale-usecases/src/main/webapp/validator/test.jsp?view=markup
hasan...
Gary
On 2/23/07, Gary VanMatre wrote:
From: Hasan Turksoy
this is not a dynamically changing value.. it is simply
internationalization!... instead of hard coding the field's name, i am
binding it to my bundle.. so that i can internationalize my app by using
bundles for my all messages, labels, field names, etc...
I see, then there should not be a problem. The following should work as
expected as long as there is a properties file supporting the locale.
hasan...
Gary
On 2/23/07, Gary VanMatre wrote:
From: Hasan Turksoy
hi all,
commonsvalidator's arg argument used as the first argument of
messages
at
validator-rules.xml... in my application, i'm using those arg
arguments to
hold some info(in general field's name) about my field which is
being
validated
it's like:
above code works as expected and gives appropriate validation
message if
that field is not valid (like: User Name is required.)
But, if i bind my arg argument to a key in my bundle, my message
is
being
as null is required... sample code is as below;
/
I dive into code and find the problem solution...
ValidatorTag class is
setting arg argument's value directly instead of evaluating the
expression
and putting the resulting value into it... Some of the arguments
(type,
message, client, server) are early binding at the tag class
but
not
arg argument...
shouldn't the arg argument set by early binding as above
attributes?
isn't
this an issue?
I'm curious as to why the value from the resouce bundle doesn't exist
at
the point the JSP tag is processed?
The reason for the late binding of the attributes is to handle the
case
where the component is in a dataTable and the validation arguments
need to
be changed for each row in the table.
I guess I just never thought there would be a usecase were someone
wanted
to dynamically change the name of an input field on a form. Is that
the
scenario you are talking about? Why do you need late binding on the
arg
property?
regards,
hasan..
http://www.jroller.com/page/hasant
Gary
SV: Relative paths Clay
Hi By the way, there is a Tomahawk sandbox component for the link (tx:link?). Hermod -Opprinnelig melding- Fra: Richard Eggert [mailto:[EMAIL PROTECTED] Sendt: 23. februar 2007 16:19 Til: user@shale.apache.org Emne: RE: Relative paths Clay Thanks. Those ideas worked great. Here's what I ended up doing to make them reusable: component jsfid=sym:graphicImage extends=h:graphicImage attributes set name=url value=@imageUrl / /attributes symbols set name=imageUrl value=@src / set name=src / /symbols /component component jsfid=sym:headerLink extends=clayOut attributes set name=escapeXml value=false / set name=value value=lt;link type=quot;@typequot; rel=quot;@relquot; href=quot;@linkUrlquot; /gt; / /attributes symbols set name=type / set name=rel / set name=linkUrl value=@href / set name=href / /symbols /component link jsfid=sym:headerLink rel=stylesheet type=text/css linkUrl=./path/to/style.css href=style.css / img jsfid=sym:graphicImage src=../../images/bar.jpg imageUrl=images/bar.jpg / Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com -Original Message- From: Gary VanMatre [mailto:[EMAIL PROTECTED] Sent: Thu 2/22/2007 5:48 PM To: user@shale.apache.org Subject: 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
WebXmlParser warning about dispatcher - shale-framework-1.1.0-SNAPSHOT for Feb 23, 2007
Hi all: I just downloaded the shale-framework-1.1.0-SNAPSHOT (dated today) and after a bit of hastle got my server to at least start up (it was a challenge since I use tiles too..(:(. My web.xml has this filter-mapping: filter-mapping filter-nameshale/filter-name url-pattern/*/url-pattern dispatcherREQUEST/dispatcher dispatcherFORWARD/dispatcher /filter-mapping However, when tomcat starts up I get the following warnings: [WARN] FacesConfigurator - More than one managed bean w/ the name of 'org.apache.shale.dialog.MANAGER' - only keeping the last [WARN] WebXmlParser - Ignored element 'dispatcher' as child of 'filter-mapping'. [WARN] WebXmlParser - Ignored element 'dispatcher' as child of 'filter-mapping'. [WARN] SCXMLLifecycleListener - No dialog configuration information present. No default configuration found at: /WEB-INF/dialog-config.xml. No embedded configuration found at: META-INF/dialog-config.xml [WARN] BasicLifecycleListener - No dialog configuration information present. No default configuration found at: /WEB-INF/dialog-config.xml. No embedded configuration found at: META-INF/dialog-config.xml Since I am (as of now) not using dialogs I ignored the dialog warnings. However, I think the WebXmlParser is in fact important because when I try to access my app, I get a 403 error (Access to the specfied resource () has been forbidden). My initial page does a forward and that is why i think getting the WebXmlParser warning is important. Btw, my chain-config.xml has this: catalog name=shale !-- Disallow direct access to JSP and JSFP resources -- chain name=preprocess command className=org.apache.shale.application.ContextRelativePathFilter includes=\S*\.xml,\S*\.faces,\S*\.css,\S*\.html,\S*\.gif,\S*\.png,\S*\.js,\S*\.jpg,/index0\.jsp,/index1\.jsp,/index\.jsp,/test\.html,/assessmentDone,/createProcess,/dbPing\.do,\S*\.resources excludes=\S*\.jsp,\S*\.jspf/ /chain /catalog Can anybody give me a clue what's going on? .. Or at least why I get the WebXmlParser warning? Btw, my web.xml has this header: web-app version=2.4 xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; Many thanks in advance for all help..:) Geeta
