Letractively / jxlib

Automatically exported from code.google.com/p/jxlib
0 stars 0 forks source link

Duplicate Id's #194

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
new Jx.Field.Text ({ id: 'test', name:'test }).addTo(fieldset);

Would generate code:
<span class="jxInputContainer jxInputContainerText jxFieldRequired"
id="test">

<label class="jxInputLabel" for="test">Text One:</
label><input type="text" name="test" class="jxInputText" id="test">

</span>

same id's for span and input.

then when I use css
#test
{
width:250px
}

this applied to both.

Thanks

Regards

Hugues.

Original issue reported on code.google.com by hugues.gauthier@gmail.com on 19 Aug 2010 at 12:23

GoogleCodeExporter commented 9 years ago
You are perfectly correct!  The problem is that Jx.Field derives from 
Jx.Widget.  Jx.Widget automatically applies the options.id to the id of the 
container of the field while Jx.Field assigns a computed id value to the actual 
input.  Jx.Field computes a unique id if there is no options.id supplied.

I'm not sure what the correct solution is here.  Should Jx.Field just assign a 
computed id to the input and ignore options.id, allowing that to be put on the 
container by Jx.Widget?  This seems the simplest and just requires some 
documentation clarification.  I can't really think of a downside to this ... it 
would always be possible to use the id on the container to style any of its 
contents and to access them as well.

Original comment by pagameba on 20 Aug 2010 at 10:53

GoogleCodeExporter commented 9 years ago
Seems like a reasonable, and simple, change to me.

Original comment by jbomgard@gmail.com on 20 Aug 2010 at 11:53

GoogleCodeExporter commented 9 years ago
Hughes, I've committed this change to Jx.Field in r969.  Now your id will be 
assigned to the container only, not to the input element inside it.  You can 
use your id as a scope for modifying the style of the input:

#test .jxInputText { width: 250px }

or just the container:

#test { width: 250px }

Original comment by pagameba on 20 Aug 2010 at 12:17

GoogleCodeExporter commented 9 years ago
Hi,

Since the last revision #969

I got and error when validating form.

Error: this.field is undefined
Source File: http://eventmanager/js/jxlib/jxlib.uncompressed.js
Line: 35899

    validateField: function () {
        //loop through the validators
        this.valid = true;
        this.errors = [];
        this.options.validators.each(function (v) {
            var val = (Jx.type(v) === 'string') ? Form.Validator.getValidator(v) : this.validators.get(v.validator.name);
            if (val) {
--> here       if (!val.test(this.field.field)) {
                    this.valid = false;
                    this.errors.push(val.getError(this.field.field));
                }
            }
        }, this);
        if (!this.valid) {
            this.field.domObj.removeClass('jxFieldSuccess').addClass('jxFieldError');
            this.fireEvent('fieldValidationFailed', [this.field, this]);
        } else {
            this.field.domObj.removeClass('jxFieldError').addClass('jxFieldSuccess');
            this.fireEvent('fieldValidationPassed', [this.field, this]);
        }
        return this.valid;
    },

Original comment by hugues.gauthier@gmail.com on 22 Aug 2010 at 8:10

GoogleCodeExporter commented 9 years ago
This should be fixed in r970.  The issue is that the normal way of specifying 
which fields to validate identifies the fields by name.  Previously, the name 
was also the ID of each field.  The form validator was retrieving references to 
the fields assuming they had an ID the same as the name.  With the previous 
change implemented, the form validator now needs to retrieve the fields by name 
instead since the fields have auto-generated IDs.

Original comment by pagameba on 23 Aug 2010 at 12:23

GoogleCodeExporter commented 9 years ago
fixed. thanks

Original comment by hugues.gauthier@gmail.com on 24 Aug 2010 at 12:55