any other opinions about breaking the interface? Or shall I just start and
provide a patch?
On Tue, Aug 26, 2008 at 2:59 PM, Roelof Blom <[EMAIL PROTECTED]> wrote:
> I wouldn't worry so much about breaking that interface, if it gives us a
> clean way to make different validation libraries work. I am not sure if I
> like using the attributes for this very much.
>
>
> On Tue, Aug 26, 2008 at 10:50 AM, Gabriel Schenker <[EMAIL PROTECTED]>wrote:
>
>> would it make sense to pass the value of the name attribute via the
>> attributes container (to the validator)?
>> I know, the attributes parameter is thought for the validator to return
>> validation relevant attributes to the form helper but it could be "mis-used"
>> for this purpose since changing the IBrowserValidationGenerator would break
>> backward compatibility (especially important when people have custom
>> validators!!!)
>> What do you think?
>>
>>
>> On Tue, Aug 26, 2008 at 9:18 AM, Roelof Blom <[EMAIL PROTECTED]>wrote:
>>
>>> I guess the patch would need to modify IValidator's
>>> ApplyBrowserValidation and the IBrowserValidationGenerator interface to have
>>> both id and name (instead of current target parameter)
>>>
>>>
>>> On Tue, Aug 26, 2008 at 6:41 AM, Gabriel Schenker <[EMAIL PROTECTED]>wrote:
>>>
>>>> well, I would LOVE to implement a patch but I don't know how I could get
>>>> access to the name attribute (instead id) of the element being validated.
>>>> Do you have an idea how I can access the current element in e.g. the
>>>> validator class?
>>>> The work-around I described in my second post is only a work-around and
>>>> I would prefer to stick with the rule for the jQuery.Validation plugIn.
>>>>
>>>>
>>>> On Tue, Aug 26, 2008 at 6:08 AM, Markus Zywitza <
>>>> [EMAIL PROTECTED]> wrote:
>>>>
>>>>>
>>>>> Now that you know,
>>>>>
>>>>> 1) where the bug is,
>>>>> 2) what the bug is and
>>>>> 3) how to fix it,
>>>>>
>>>>> you are welcome to create an issue at support.castleproject.org and
>>>>> attach a patch to it. If not, you'll have to wait until someone has
>>>>> the time to investigate herself.
>>>>>
>>>>> -Markus
>>>>>
>>>>> On Mon, Aug 25, 2008 at 18:01, gabriel <[EMAIL PROTECTED]> wrote:
>>>>> >
>>>>> > One possibility to bypass the "SetLengthRange" method would be to use
>>>>> > MinLength and MaxLength (as in one of the samples for the
>>>>> > jQuery.Validation plugin). Or is there a pitfall with this approach.
>>>>> >
>>>>> > <input id="field1" name="field1" minlength="2" size="20" .../>
>>>>> >
>>>>> > would require the content of the field1 to be between 2 and 20
>>>>> > characters long...
>>>>> >
>>>>> > On Aug 25, 5:54 pm, gabriel <[EMAIL PROTECTED]> wrote:
>>>>> >> when debugging the 'JQueryValidator' class in Monorail I found that
>>>>> >> the validation method 'SetLengthRange' is not implemented correctly.
>>>>> >> This method defines a rule for the jQuery.Validation plugin.
>>>>> >> Unfortunately the plugin expects the 'name' of the element to
>>>>> >> validated as key where as the implementation takes the 'id' as key.
>>>>> >> But these are (most of the time) different.
>>>>> >> Example: I put an object of type Employee into the property bag
>>>>> >> PropertyBag["employee"]=employee;
>>>>> >>
>>>>> >> then I have e.g. this field in my view (Brail View engine)
>>>>> >> ${Form.TextField("employee.LastName")}
>>>>> >>
>>>>> >> The FormHelper class makes something like this of it:
>>>>> >> <input id="employee_LastName" name="employee.LastName" .../>
>>>>> >>
>>>>> >> note that the id and name are different!
>>>>> >>
>>>>> >> Since the method "SetLengthRange" only receives as a parameter the
>>>>> >> content of the id attribute and NOT the html element it is not
>>>>> easily
>>>>> >> possible to resolve this problem...
>>>>> >>
>>>>> >> Any solutions for this???
>>>>> >>
>>>>> >> Any help is appreciated.
>>>>> > >
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Castle Project Users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/castle-project-users?hl=en
-~----------~----~----~----~------~----~------~--~---
