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()?
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
