Some notes. I forget to tell.
It is perfectly working with constans ...
<s:validatorVar name="operationID" value="Testing"/>
,not with beans ...
<s:validatorVar name="operationID"
value="#{mtJobOperation.operationID}"/>
Second line pass to a custom validator method just a null.
Alex.
-----Original Message-----
From: Iakouchev Alexander-EAL027C
Sent: Thursday, July 13, 2006 10:29 AM
To:
user@shale.apache.org
Subject: RE: Is this possible to pass dynamically information from a beans as a shale method parameter?
Hello Craig!
Thank you for feedback.
I want to be more specific. I need validate all rows in "dataTable"
component. JSP page show list of "Foo" objects. For example, the inputText component with id="---" has shale custom validate. I need analyze dependency component id="---" row i from component id="---" row 0...n.
In other words I need pass some current row id to get by id real object.
<s:commonsValidator
type="validateQuoteHoursValue"
arg="quoteHours"
server="true"
client="false"
>
<s:validatorVar name="operationID"
value="#{mtJobOperation.operationID}"/>
</s:commonsValidator>
This valuator does not works. It receive operationID equal null. But outputText shown some not null information.
<t:outputText value="#{mtJobOperation.operationID}"/>
The Shale validator example show some solution with dynamic shale method parameter, but it is with standard validator example not a custom validator.
Alex.
-----Original Message-----
From:
craigmcc@gmail.com [mailto:
craigmcc@gmail.com] On Behalf Of Craig McClanahan
Sent: Wednesday, July 12, 2006 7:45 PM
To:
user@shale.apache.org
Subject: Re: Is this possible to pass dynamically information from a beans as a shale method parameter?
On 7/12/06, Iakouchev Alexander-EAL027C <
EAL027C@motorola.com> wrote:
>
> Is this possible to pass dynamically information from a beans as a
> shale method parameter?
> Alex.
>
>
In JSF 1.1, you cannot do this (it's not a Shale issue, it's the basic functionality of JSF method binding expression). In JSF 1.2, you can ...
but only for calls to static methods.
A better general strategy is to invoke a method that takes no parameters, but ensure that the called method can extract whatever it needs. For example, consider the standard JSF call to your action method (which takes no parameters). There are at least two ways for the called method to access request parameters on the incoming request:
* Via JSF programmatic APIs:
// Retrieve the value of the "foo" parameter
FacesContext context = FacesContext.getCurrentInstance();
String foo = (String)
context.getExternalContext().getRequestParameterMap().get("foo"0;
* By managed beans expression evaluation. This example requires
a bit more setup to configure, but is much easier to use because
the values are injected for you. Consider again that you want to
extract the value of the "foo" parameter and use it in your myAction()
action method. Define your managed bean entry like this:
<managed-bean>
<managed-bean-name>mybean</managed-bean-name>
<managed-bean-class>com.mypackage.MyBean</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
<managed-property>
<property-name>foo</property-name>
<value>#{param.foo}</value>
</managed-property>
</managed-bean>
and set up your bean class like this:
package com.mypackage;
public class MyBean {
...
private String foo = null;
public String getFoo() { return this.foo; }
public void setFoo(String foo) { this.foo = foo; }
...
public String myAction() {
// Get the value of the "foo" request parameter
String foo = getFoo();
...
}
...
}
The formula #{param.foo} is evaluated when the managed bean is created, and extracts the value of the request parameter named "foo" and calls
setFoo() on your bean. By the time the action method is called, the value will be there already.
Craig
SHALE-217. This adds dynamic binding support for the commons validator within a UIData component. This includes client side validation. The validation example in the shale usecases has been extended to show the new features.This fix adds the dynamic binding support in the dataTable component including client side validation. It uses a bit of voodoo so I'm going to leave this one open.
It also includes a patch for client side validation using multiple forms. I updated the shale usecases example to show the new feature. Fix is in the nightly build.