Currently I override messageModel() (an approach I don't like very
much either, but until we have a better one). That is part one. Part
2: I modified AbstractValidator.error() to load a string resource with
validator.getClass() being the key (solving the default problem) and
finally I added a StringResourceLoader to application settings which
read string resources from Application.properties which contain the
ultimate default values if none of the other files contain the
properties.
Juergen
I add an additional StringResourceLoader to the settings which
On 10/12/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > The default message problem can be solved and it is working
> > on my laptop already. But IMO your request has two parts:
> > ${label} AND default messages.
> > And the ${label} part IMO is the one which needs some more
> > discussions. Any idea on how to solve the problem that a
> > context is kind of anonymous where you prefer setLabel().
> > What about a FormComponentContext which is derived from
> > HashMap and which implements setLabel()?
>
> Imho this is not a two-part problem. How are you feeding the label to the
> validators right now?
>
> -Igor
>
>
> >
> > Juergen
> >
> > On 10/12/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > > > Lets continue the discussion on the list
> > > >
> > > > Currently I do not have the perfect solution. Your
> > approach is more
> > > > concise but I don't like that it
> > > > - is limited to label and tomorrow someone else will ask for yet
> > > > another variable to add validators
> > >
> > > This discussion started out to find a solution to provide default
> > > error messages. Label is a required variable for that. I
> > cant really
> > > think of any other variables that users may ask for, can
> > anyone give suggestions?
> > >
> > > > - the same will happen to formComponent. Add yet something else
> > > > - though label and form components do have a relationship, I'd
> > > > prefer not to add that "dependency" (see the previous comments).
> > > > Label is not realy a part of a formComponent and inventing a
> > > > FormComponentLabel doesn't make it better, IMO.
> > >
> > > There is no dependency, you don't need to use
> > FormComponentLabel it is
> > > simply a convinience.
> > >
> > > > Just an idea: What about a "context" (HashMap) which we'll add to
> > > > FormComponent instead of Label. Thus users are more
> > flexible and we
> > > > must not fear to add additional varaibles next month. The
> > "context"
> > > > would automatically be added to the validators pre-existing model.
> > > > Instead of
> > >
> > > I like the context but I really don't like magic strings.
> > Externally I
> > > would still like to have set/getLabelModel(). Seems to me if people
> > > will want to use default error messages or provide their
> > own generic
> > > messages there will always need to be a label in the context so we
> > > might as well make it easy/foolproof to set it.
> > >
> > > -Igor
> > >
> > >
> > > >
> > > > TextField tf=new TextField("hi");
> > > > tf.setLabelModel(new Model("Hi TextField"));
> > > >
> > > > you would do
> > > > TextField tf=new TextField("hi");
> > > > tf.getValidatorContext().put("label", labelModel);
> > > >
> > > > The name implies it is related to validators (no magic)
> > and it is a
> > > > general solution.
> > > > What do you think? Are there any other idea how to solve
> > the problem
> > > > flexible and elegant?
> > > >
> > > > Juergen
> > > >
> > > >
> > --------------------------------------------------------------------
> > > > --
> > > >
> > > > Initial Comment:
> > > > we need to be able to generate validator messages with pattern
> > > > "${label} is a required field.". Somehow we need to link a label
> > > > with a form component.
> > > >
> > > >
> > > >
> > > >
> > --------------------------------------------------------------------
> > > > --
> > > >
> > > > >Comment By: Igor Vaynberg (ivaynberg)
> > > > Date: 2005-10-12 17:00
> > > >
> > > > Message:
> > > > Logged In: YES
> > > > user_id=1293035
> > > >
> > > > so what you are proposing, if i understand it correctly,
> > would work
> > > > like this:
> > > >
> > > > final IModel labelModel=new Model("Hi TextField");
> > TextField tf=new
> > > > TextField("hi");
> > > >
> > > > tf.add(new RequiredValidator() { messageModel() { return
> > > > super.messageModel().put("label", labelModel);});
> > > >
> > > > tf.add(new EmailAddressTypeValidator() { messageModel() { return
> > > > super.messageModel().put("label", labelModel);});
> > > >
> > > > as opposed to:
> > > >
> > > >
> > > > TextField tf=new TextField("hi");
> > > > tf.setLabelModel(new Model("Hi TextField"));
> > > > tf.add(RequiredValidator.getInstance());
> > > > tf.add(EmailAddressTypeValidator.getInstance());
> > > >
> > > > is that correct?
> > > >
> > > >
> > > >
> > > >
> > --------------------------------------------------------------------
> > > > --
> > > >
> > > > Comment By: Juergen Donnerstag (jdonnerstag)
> > > > Date: 2005-10-12 16:35
> > > >
> > > > Message:
> > > > Logged In: YES
> > > > user_id=544015
> > > >
> > > > your are wrong. Validators already use a local model (see
> > > > AbstractValidator.messageModel) which are created while executing
> > > > error() (that is, it is not a object variable).
> > > > Overriding messageModel does not at all prevent validator
> > singletons
> > > > etc. I suggest you take a look at AbstractValidator and
> > some of the
> > > > other Validators which already extend messameModel.
> > > >
> > > > Yes, most (not every) FormComponent have labels and and they have
> > > > forms and they have pages and they have ... Does it mean
> > we should
> > > > add this information as well. No. I still think overriding
> > > > messageModel is the better solution
> > > >
> > > >
> > --------------------------------------------------------------------
> > > > --
> > > >
> > > > Comment By: Igor Vaynberg (ivaynberg)
> > > > Date: 2005-10-12 15:31
> > > >
> > > > Message:
> > > > Logged In: YES
> > > > user_id=1293035
> > > >
> > > > I dont see what value is added by adding the model into the
> > > > validators instead of the component. If we do it that way the
> > > > validators can no longer be singletons, also the same
> > model has to
> > > > be added to all validators for any form component which wastes
> > > > space. FormComponent seems like the perfect place to do it.
> > > >
> > > > Most form components have label components "associated" with them
> > > > which have a model - we can create a formcomponentlabel that will
> > > > use the formcomponent's label model as its own so we will not be
> > > > adding anything extra by having another IModel ref in the
> > > > formcomponent.
> > > >
> > > >
> > > >
> > --------------------------------------------------------------------
> > > > --
> > > >
> > > > Comment By: Juergen Donnerstag (jdonnerstag)
> > > > Date: 2005-10-12 06:10
> > > >
> > > > Message:
> > > > Logged In: YES
> > > > user_id=544015
> > > >
> > > > I'm -1 on adding a label model to FormComponent and automatically
> > > > use it for validators, because you actually can extend the model
> > > > used by the Validator by overriding
> > > > messageModel() already with any value you want, not only a label
> > > > (only IntegerValidator's messageModel is final which must be
> > > > removed).
> > > >
> > > > The 2nd part of your request, Wicket to provide default
> > properties
> > > > files with properties like RequiredValidator=xx instead of
> > > > formname.input2.RequiredValidator to define default
> > values for all
> > > > RequiredValidators I agree upon with one addition. Users must be
> > > > able to disable/enable it through apps.Settings.
> > > >
> > > > Juergen
> > > >
> > > >
> > --------------------------------------------------------------------
> > > > --
> > > >
> > > > Comment By: Igor Vaynberg (ivaynberg)
> > > > Date: 2005-10-09 18:49
> > > > - Show quoted text -
> > > >
> > > > Message:
> > > > Logged In: YES
> > > > user_id=1293035
> > > >
> > > > no, this is not supported currently.
> > > > right now if i want to use a required validator i need to do the
> > > > following:
> > > > page.properties:
> > > > formname.input1.RequiredValidator=Input 1 is required
> > > > formname.input2.RequiredValidator=Input 2 is required
> > > >
> > > > what i would like is to be able to do the following:
> > > > application.properties:
> > > > RequiredValidator=${label} is required and have the formcomponent
> > > > feed the proper ${label} value
> > > >
> > > > what this allows us is to provideis a list of default validator
> > > > messages ie in webapplication.properties:
> > > > RequiredValidator=${label} is required EmailTypeValidator=field
> > > > ${label} contans an invalid email address
> > > >
> > > > so the users dont have to provide
> > component*validator-count property
> > > > messages that are all mostly the same.
> > > >
> > > > i think the easiest way to accomplish this is to add an
> > IModel label
> > > > field to the FormComponent and have the abstract
> > validator set the
> > > > value of that model as the ${label} variable in the context.
> > > >
> > > > This would also allow as to have a nice
> > FormComponentLabel component
> > > > that uses the FormComponent's label model as its own model.
> > > >
> > > >
> > > >
> > --------------------------------------------------------------------
> > > > --
> > > >
> > > > Comment By: Juergen Donnerstag (jdonnerstag)
> > > > Date: 2005-10-09 12:40
> > > >
> > > > Message:
> > > > Logged In: YES
> > > > user_id=544015
> > > >
> > > > I think this is already supported. Please see wicket src/test
> > > > wicket.util.tester.apps_1.CreateBook
> > > > (java/properties) and wicket-examples src/java
> > > > wicket.examples.forminput.FormInput (java/properties)
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This SF.Net email is sponsored by:
> > > > Power Architecture Resource Center: Free content, downloads,
> > > > discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl
> > > > _______________________________________________
> > > > Wicket-user mailing list
> > > > [email protected]
> > > > https://lists.sourceforge.net/lists/listinfo/wicket-user
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by:
> > > Power Architecture Resource Center: Free content, downloads,
> > > discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl
> > > _______________________________________________
> > > Wicket-user mailing list
> > > [email protected]
> > > https://lists.sourceforge.net/lists/listinfo/wicket-user
> > >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by:
> > Power Architecture Resource Center: Free content, downloads,
> > discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl
> > _______________________________________________
> > Wicket-user mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/wicket-user
> >
> >
> >
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Wicket-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
