Yep,
That helps.
Are you planning on using ajax components (ie, partial-page refresh),
server side submits with each field change, or java-script (preload
the data and the logic to manipulate it at page render)?
That's probably going to determine how you need to perform validation.
I can't help at all with the javascript. I'm guessing you'd need to
do the validation at action processing time rather than trying to do
it for individual components.
I can point to a few components to do it with ajax. I'm not familiar
enough with it in order to say how validation might work.
Up to this point, I've done tasks like this with server-side
processing (cheap enough in the intranet world). In this case, each
component should be able to do validation, and after each component
with dependencies changes, you'd resubmit the component and recompute
other component validation requirements.
I'd probably do this by putting each of my dependency-inducing
components in a separate subForm with a submitOnEvent.
<sandbox:subForm id="countryInputForm">
<h:inputText id="countryInput"
required="#{page.countryRequired}"
value="#{page.country}">
<sandbox:submitOnEvent for="chooseCountryButton"/>
</h:inputText>
<h:commandButton id="chooseCountryButton"
style="display:none"
action="#{page.updateParameterChoices}"
value="go"/>
</sandbox:subForm>
For "text with predefined value", it might be worthwhile to take a
look at the inputSuggestAjax sandbox component.
I doubt that this answer completely handles your situation.
Hopefully it provides a starting point on how you can approach this.
Here's an example of a slightly-different way to approach it (It's far
more simpler than what you want to do, but demonstrates the basic idea
-- two components, the first determines what validation is necessary
for the second). In fact, this may be more appropriate to your
situation, but it'll get more complex as you add more components into
the mix.
<sandbox:subForm id="cisActionManagerExecuteCisActionForm">
<h:selectOneMenu id="cisActionInput"
binding="#{cisActionManager.cisActionInputComponent}"
value="#{cisActionManager.cisAction}">
<f:selectItems
value="#{cisDAOSelectItemsProvider.cisActionItems}"/>
</h:selectOneMenu>
<h:inputText id="argumentInput"
binding="#{cisActionManager.argumentInputComponent}"
required="#{cisActionManager.argumentRequired}"
validator="#{cisActionManager.validateArgument}"
value="#{cisActionManager.argument}">
<sandbox:submitOnEvent for="executeCisActionButton" />
</h:inputText>
<h:commandButton id="executeCisActionButton"
value="Go!"
action="#{cisActionManager.executeCisAction}"/>
</sandbox:subForm>
An option on the pulldown may require an argument, may require no
argument, or the argument might be optional. What constitutes a
valid argument is different for each pulldown option.
The binding of the pulldown component to the backing bean allows the
argument validation code to insure that there's a valid option in the
pulldown and to fetch that value. There's other ways it could be
done -- the second component could contain a reference to the first
component, like the "for" attribute used in so many components.
The binding to the argument input is used to generate FacesMessages.
That could be avoided by using a "real" validator instead of an inline
backing bean method.
On 4/8/07, Marko Asplund <[EMAIL PROTECTED]> wrote:
Mike Kienenberger wrote:
> Don't take this the wrong way, but you're tell me how you want to
> solve the problem instead of telling me what the problem is. Let's
> ignore the dynamic part -- it adds a little more complexity, but I
> don't think it really will impact how the problem will be solved.
>
> It looks like you're doing a report with dynamic search criteria.
>
> So it's something like this in general
>
> Property Operator Value (x N)
Mike,
It's sometimes easy to get caught in the technical details when
explaining your problem, i'll try to do a better job in this email.
Also, some people are more interested in looking at code than taking a
holistic view on the problem.
The system i'm working on acts as an end-user front to a back-end
reporting server. Users select a report type they want to run through
the UI. Then a form including pre-defined report parameters is
presented. The user then fills in report parameter values, submits the
form which results in the front-end executing the report on the report
server and streaming the report to the user.
Administrators define report meta data in the front-end system based
on report server definitions. Report meta data can include 0 to n
report parameters which are available for the user to fill in.
Parameters can be required or optional. Parameters can have a limited
set of allowed values. In this case the system must be able to show
the set of possible values to the user in a select list. There can be
dependencies between parameter values.
An example could be a report containing country and city parameters.
When the user enters 'g*' in the country field he should be able to
make the system present him with a list of countries starting with the
letter g. Multiple values can be selected. After this selection the
user moves on the the city field which depends on country. If the user
enters 'a*' and asks the system to show a list of possible values, the
values entered in the country field should be used to scope the list
of possible cities (that start with the letter a).
Currently, i have 4 types of report parameters
- date: represented as tr:inputDate (uses text field + popup date picker)
- text with predefined value space: text field + popup select list
- simple text: text field
- select one: represented with h:selectOneMenu
Does this better explain the problem?
marko
