Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Weld ignores tagets with multiple occurrences #28

Open
kallewangstedt opened this issue Jun 19, 2011 · 2 comments
Open

Weld ignores tagets with multiple occurrences #28

kallewangstedt opened this issue Jun 19, 2011 · 2 comments
Labels

Comments

@kallewangstedt
Copy link

If Weld is used for inserting strings on a page that have targets for insertion that occur more than once it will ignore all but the first. This is seen especially when using Weld as a dynamic translation engine. Often a page can hold the same strings at different locations in the DOM. As of now Weld demands all those targets to be unique and only occur once on each page.

Example (Weld used as jQuery plugin):

<div id="panels">
  <div id="settings">
    <input type="text" name="name" />
    <a class="lang-CANCEL">&nbsp;</a><a class="lang-SUBMIT">&nbsp;</a>
  </div>

  <div id="configuration">
    <label><input type="checkbox" name="visible" /><span class="lang-SHOWNAME">&nbsp;</span></label>
    <a class="lang-CANCEL">&nbsp;</a><a class="lang-SUBMIT">&nbsp;</a>
  </div>
</div>

jQuery(document).ready(function() {
  $('#panels').weld({
      "lang-CANCEL"   : "Avbryt",
      "lang-SUBMIT"   : "OK",
      "lang-SHOWNAME" : "Visa namnet"
  });
});

The code above would leave the two <a>-tags in the configuration div untouched. Since matching of the keys in the Weld object is done using class names, expected would be that Weld inserted the strings on all elements with corresponding classes.

@tmpvar
Copy link
Owner

tmpvar commented Jun 21, 2011

Interesting, this is not a use case that we have considered until now. The reason for only matching once is efficiency, attempting to match again on a selector introduces a large overhead.

@hij1nx, this goes back to removal of jQuery as a dependency and forcing ops.match to return a single dom node that matched.

@kallewangstedt, I'm sorry, but this is going to take a bit more thought before we can fix it. We are definitely open for suggestions though!

@kallewangstedt
Copy link
Author

I will absolutely try to help. Haven't yet done any deep explorations in the code, but just one spontaneous idea might be to look at the way you now use querySelector() method to get the first match in the DOM of name, id or class corresponding to the selector given. If using querySelectorAll() method you would get a static node list of all matches instead.

To not get a lot of overhead you would have to check the result to see if the list holds more then one match, and only in that case traverse the full list. The method supports length property as well. It work much like getElementByClassName(), but are just as versatile as what you are using right now.

The querySelectorAll() has support from FF 3.1, IE8, Safari 3.1.

I haven't tried this, but it's an idea anyway. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants