Aaron Heimlich schrieb: > On 2/12/07, *Jörn Zaefferer* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> > wrote: > > Implementing multiple messages per rule via plugin settings should be > pretty straight forward, but not via the other mechanisms (title > attribute, error labels in markup). > > > Perhaps the Metadata plugin would help here?? I'm thinking of > something along the lines of > > <input type="text" id="email" name="email" > class="{required:true,email:true,messages:{required:'Please enter your > email address',email:'Your email address is not properly formatted. It > should look like [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>'}}"> > > The only problem is that it could get messy with all those error > messages in there (and I don't know if the spaces in the error > messages will cause any problems or not). I wouldn't recommend that, just because it's quite likely that an error message contains a word that is a defined class that is then applied to the element. In case someone needs multiple messages, he has provide them either in the markup as own elements (like the first version of the plugin did) or via plugin settings, like you proposed. > Speaking of metadata, you may want to consider sectioning off the > metadata that your plugin uses from any other metadata an element > might have. For example, my upcoming New Window plugin (unobtrusively > alters selected links so that they open in new windows) can take > advantage of the Metadata plugin (if it's available and the developer > wants to use it), but assumes that anything that it wants is located > in a newWindow object. > > <a href="http://www.jquery.com"; class="newWindow > {happy:'happy',joy:'joy',newWindow:features:{width:500,height:300,resizeable:1}}">jQuery</a> > > > > happy and joy will be ignored (since New Window neither knows nor > cares what they are), and only newWindow will be used by my New Window > plugin. Yours could look something like > > <input type="text" id="email" name="email" > class="{validate:{rules:{required:true,email:true},messages:{required:'Please > enter your email address',email:'Your email address is not properly > formatted. It should look like [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>'}}}"> Good point. I thought about that. I think a mechanism that by default uses my current version and can be modified to look for a certain element would be great. It's not that likely that you would open a new window when clicking an input element, but the conflict is quite likely to appear some day, therefore it is good to provide an easy workaround. But I don't want to force everyone to wrap the validation rules when it is not really necessary. > As far as reducing the reliance on IDs (which I've heard mentioned > here, and would make it a lot easier to use this plugin alongside > server-side validation pacakages), you could start by having the keys > in the "rules" and "messages" options be input names instead of IDs. > You could then use something like this (untested) to get the element's > ID when necessary: While a good form has elements to wire inputs with labels, that isn't always given, therefore I agree that not relying on IDs is preferable. > > function getElementId(element) { > var id = ( /radio|checkbox/i.test(element.type) ) ? element.name > <http://element.name> : element.id <http://element.id>; > > if(!id) { > // Element is not a radio button or checkbox and does not have > an id attribute > id = <generate an ID for this element>; > element.id <http://element.id> = id; > } > > return id; > } The first line of that function is already included in the plugin, but not generating IDs. Sounds like a good idea, I'll investigate that.
Thanks again for your input, helps a lot! -- Jörn Zaefferer http://bassistance.de _______________________________________________ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
