Best practice for generating html ids with grails - javascript

I have a template that could be rendered multiple times within the same view.
The template contains a form and I have some jquery event listeners attached to the form elements using the html id.
For now I'm using 'g:set' to create an elementId variable at the top of the template using the current time in milliseconds and appending it to each element on the form. This way each form element will have a unique id within the page no matter how many times the same template is rendered.
My approach works but it seems to me that there must be a better way to achieve what I want to do?
Heres an example of my approach :
<g:set var="elementId" value="${'elementId-' + new Date().getTime()}" />
<form>
<g:textField id="${elementId}name" name="name"/>
<g:textField id="${elementId}address" name="address"/>
</form>
<script>
$("#${elementId}name").on("click", myFunction())
$("#${elementId}address").on("click", myFunction())
</script>

While it may feel a bit 'odd' or 'strange' to do this, your approach will accomplish what you are after. Adding in a random number or UUID that you generate at the GSP level too would help avoid collisions (though that may be overkill).
Grails doesn't offer any assistance in this manner per say. Since this is a concern of how elements are addressed in the browsers DOM and Grails typically addresses server-side concerns.
The alternative is to refactor your code to not rely upon element ids but rather something more generic and based on classification instead. Using class names would be a good approach. Depending on your requirements this may or may not work well.

Related

The best way to target DOM

I'm a front-end developer, and I'm worried about the best way to target my DOM.
Let's imagine a tiny form to create a new zombie :
<h1>Add a new zombie</h1>
<form id="create-zombie">
<input id="zombie" type="text" name="zombie" />
<input id="lvl" type="text" name="lvl" />
<button type="submit">Add</button>
</form>
...and if I want to get the values of zombie and lvl, I will code something like this:
class Zombie_Add extends Controller
# Dom References
el:
'form': '#create-zombie'
'zombie': '#zombie'
'lvl': '#lvl'
run: ->
#on 'submit', #el.form, #validate
validate: (e) =>
e.preventDefault()
zombie = $(#el.zombie).val()
lvl = $(#el.lvl).val()
module.exports = Zombie_Add
That's "ok" and it does the job, but I have some problems with that "structure" :
If somebody touches the DOM and removes an ID, I'm just fucked, it breaks my code (Captain Obvious spotted !)
For more complicated selectors, it's just a mess (I'm thinking about some stuff like that [name^="dummy-"] input:first). I guess it's easy to imagine how shitty the names of el are.
Anyway, what I want to learn today is what's the best way to target the DOM from JS. Is it better to use IDs, class values or, data-* attributes? How we can prettify a selector with plain English, etc...
If somebody touches the DOM and removes an ID, I'm just ****ed, it
breaks my code (Captain Obvious spotted !)
The best way to target a single, unique element in the DOM is with an ID like you are doing with zombie and lvl. It is both fast to execute and simple to code.
It is a given that if someone messes with the id values in your HTML, that will break your Javascript. That's just the way it is. Anyone messing with your HTML has to be smart enough to know that an ID value is there for a reason so if they want to change that or remove it, then it is their responsibility to find someone who can make corresponding changes in the Javascript. That's just the way it is.
For more complicated selectors, it's just a mess (I'm thinking about
some stuff like that [name^="dummy-"] input:first). I guess it's easy
to imagine how ****ty the names of el are.
The same goes for more complicated selectors. Like it or not, a modern web page is a melding of server-side stuff, presentation HTML and Javascript. The three have to work together to deliver the final solution. While you strive to avoid unnecessary dependencies with good design techniques and practices, you cannot avoid all dependencies, nor would even trying to avoid all possible dependencies be an efficient way to develop.
Example
There are coding practices that can make your code less sensitive to edits to the HTML and I consider those to be desirable practices. For example, consider this HTML snippet:
<div class="header">
<div class="headerBorder">
<div class="actions>
Hide
</div>
<div class="contentContainer">
<div class="content">
... content here
</div>
</div>
</div>
</div>
<div class="header">
... more of these repeated
</div>
And you want to have code that, when you click on the Hide link, it will hide the content.
If you code that like this:
$(".header .actions .hide").click(function() {
$(this).parent().next().children().first().hide();
});
Then, you have embedded in your Javascript some extremely detailed knowledge of the HTML structure in the area of your button and content and pretty much any structural change to that HTML (even just adding one more level of div to help with some layout) will break the Javascript. This is bad.
Instead, you could write this:
$(".header .actions .hide").click(function() {
$(this).closest(".header").find(".content").hide();
});
This depends only upon one HTML structural concept - that the .content that corresponds to the .hide button is somewhere in the common .header parent element. The entire structure within that .header parent can be changed and this code will not break. This is robust code that tries to be as independent of the details of the HTML structure as possible.
Anyway, what I want to learn today is what's the best way to target
the DOM from JS. Is it better to use IDs, class values or, data-*
attributes? How we can prettify a selector with plain English, etc...
It's best to use IDs to target elements for which there is only one unique element in the page.
It's best to use class names to target elements for which there can be more than one element in the page and you can combine that with other parts of a selector if you want to target only a specific item with a class name.
data attributes can be used in selectors, but that isn't really their primary purpose. I can't think of any reason why it would be better to use a data attribute instead of a class name. I use data attributes for storing actual data on an object that will be used by scripts. This tends to allow the code to be more generic and let the content describe itself.
When you talk about classes getting removed to change the state of the element, that is a legitimate use of a class, but it would just be a bad design decision to use the same class for selecting an element as for add/removing state. Use different class names for those two purposes. For example, you could have a class name called "selected" that indicates a selection state, but you would only use that in a selector if you wanted just the selected objects. If you wanted all line items in a table, you wouldn't use ".selected", you'd create a more descriptive class name for that object such as "lineitem". Remember, you can have multiple class names on an object so you can use different class names on the same object for different purposes.
You seem to be searching for some magic bullet here that prevents changes in the HTML from affecting Javascript in any way. That simply does not exist. Selecting a DOM element or finding a DOM element relative to something that was clicked will rely on some inherent knowledge of how the HTML is structured or tagged. What is important is that you minimize that dependence to only what is required and that anyone messing with the HTML has an understanding of how to best change things and not break the Javascript or discusses changes with someone who knows the Javascript. If you're using different skills/people on different portions of the project, they have to coordinate their efforts in order to not break things or be aware of what dependencies there are with the other parts of the system. That's just the way it is. There is no magic answer here that removes all dependencies between HTML and Javascript. Smart designs have smaller and more obvious dependencies. Poor designs have large and often hidden depedencies.
Your question about "plain English" isn't particularly clear to me. It seems obvious to use descriptive ID names, class names or attribute names that make it as obvious to the reader what that particular name is being used for. I'm not sure what you were looking for beyond that.

JS templating engine that preserves elements

I have the following problem:
A have a web application where I regularly need to update the user interface when data changes. The data consists of a list of items with different attributes. Because the UI representations of these items can be complex, I use JS templating to render them. When they change I just replace them in the DOM with the HTML representing their updated state.
This approach is simple but has several problems:
you need to re-attach all event handlers because you practically replace elements
there is a flickering effect when reloading resources (probably can be solved using document fragments)
it's impossible to work with developer tools (inspector) if the content changes frequently because, again, all the elements are replaced
So I was wondering if there is any JS templating engine of that many that can deal with the situation. I'm thinking of a feature that intelligently matches elements of the new render and an old one and only changes the content when it has really changed.
I'm thinking of something like this:
Old HTML
<div>
<h1>TV</h1>
<span>$250</span>
Add to cart
</div>
New HTML
<div>
<h1>TV</h1>
<span>$260</span>
Add to cart
</div>
The templating engine find the <span> in the original DOM and replaces its changed value but leaves the rest of the elements intact.
Finally I came across Rivets.js which a lightweight, highly extensible JavaScript templating engine with real time data binding. I love it so far, it's exactly what I needed.
you can try the AngularJS
A simple example:http://jsbin.com/opayuf/4/edit
you can check out these examples if they can meet your requirements
http://tutorialzine.com/2013/08/learn-angularjs-5-examples/
HandleBarsJs may be the one you need, you could see the discussion on
Handlebars.js: Use a partial like it was a normal, full template
You can also try Ember js based on HandlerBarsJs, you can check is out
http://emberjs.com/guides/templates/handlebars-basics/
http://emberjs.com/guides/templates/rendering-with-helpers/

How HTML, JS and CSS work together

I would like to understand how HTML, JS and CSS work together and reference one another.
I have found that HTML can reference CSS via an id reference.
Example: <div id="left-show"></div>
However, it would be much appreciated if someone could clarify the following:
How would you tell your HTML code to reference a specific JS function.
Within a JS function, is it a good practice to reference a CSS id?
If a JS function and CSS id share the same name, would that create a conflict?
How would you tell your HTML code to reference a specific JS function.
Generally, you don't.
You include a script (with a <script> element) that accesses whatever parts of the DOM you want it to interact with (via the document object that the browser will make available to the script).
You can use the addEventListener method to bind a function so that it will run in response to an event (such as a button being clicked).
Within a JS function, is it a good practice to reference a CSS id?
There is no such thing as a CSS id. HTML has IDs which have a multitude of purposes including being matched by CSS ID selectors, being linked to with a fragment identifier on the end of a URL and allowing a <label> to reference its associated form control with the for attribute.
If you want to access a specific element, then an HTML ID is a good way to identify it (via the getElementById method).
If a JS function and CSS id share the same name, would that create a conflict?
There can be some issues if JavaScript variables of any kind (including functions) match the ID of an HTML element. This is best avoided by staying away from the global scope as much as possible (as per this answer).
Your questions are a bit far-reaching for a full explanation on a concise Q&A site like SA. You would really need to read a lot of material for a full understanding.
However, some brief simplified answers to get you started
1) HTML links to JavaScript via events that trigger JavaScript functions. This is an example of a very simple event on an HTML element that will look for a function in your JavaScript declared as function aJavaScriptFunction(){ } when you click on the button. There are different ways to do this and different types of event, but this is a good place to start.
<input id="thebutton" type="button" value="A Button" onclick="aJavaScriptFunction();" />
2) It very much depends what you are trying to do, but in general selecting HTML DOM elements via their ID is an efficient method of selecting them to do something with them. So this might be the JavaScript function that we're using in the previous example.
function aJavaScriptFunction()
{
var aButtonElement = document.getElementById("thebutton"); // <-- It's not a "CSS id" as such, CSS can use the HTML id
// .... some more javascript that uses aButtonElement like
aButtonElement.style.borderColor = "red";
}
3) No. JavaScript and CSS don't really directly overlap as such in the way you might be thinking, when you're beginning, think of them both as altering the HTML. It is possible to do some of the same things with JavaScript as CSS, but in general they happen at different times. This CSS doesn't conflict with the previous JavaScript, though they both do similar things.
#thebutton { border-color: blue; }
Here are all my examples put together into a jsFiddle where you can play with them.
You'd be best off visiting somewhere like W3 Schools or Code Academy.

Best practice to avoid element name conflicts in views - BoilerplateJS

Imagine you have several components in your application, each having its own view.
While the components are independent, their views may use the same identifiers for DOM elements, e.g. there is a chance that 2 or more components would have views with similar input control like:
<label for="Bid">Bid</label>
<input type="text" id="Bid" name="Bid" value="0"/>
After components are activated, their views are attached to the DOM by Boiler.ViewTemplate, and now there's a name conflict for Bid element, causing side effects, e.g. clicking on the label works only in 1 view, and is disabled in the others.
What is the best practice to avoid such collisions? Should i use "unique" suffix/prefix for all elements in my views, like id="ComponentName_Bid"? Or there is more elegant solution?
This is indeed a very good question. I too struggled with it many times. Sometime back I did an implementation of giving an auto generated unique id for every ViewTemplate instance.
This UID could be used from JS logic (viewmodel.js etc) by passing it from the ViewTemplate instance.
This could be used by view.html as well as by the component specific .css file as a tag {comp.uid} which will be replaced by a special ViewTemplate logic, just as used for 'nls' replacement (see line 105 at view-template.js).
That ofcourse worked, but the complexity was too much for the developers to understand. So in a later version of BoilerplateJS I removed this functionality and let developers to manage the elementIDs manually as you have suggested above.
I still do not know what the best approach for this.. but for the moment I believe managing it manually results in a much cleaner code.
Another option is to simply put input inside label like this:
<label>
Last Name
<input type="text" name="lastname" />
</label>

Is there a way to create your own HTML element?

Is there a way to create your own HTML element? I want to make a specially designed check box.
I imagine such a thing would be done in JavaScript. Something akin to document.createHTMLElement but the ability to design your own element (and tag).
No, there isn't.
The HTML elements are limited to what the browser will handle. That is to say, if you created a custom firefox plugin, and then had it handle your special tag, then you "could" do it, for varying interpretations of "doing it". A list of all elements for a particular version of HTML may be found here: http://www.w3.org/TR/html4/index/elements.html
Probably, however, you don't actually want to. If you want to "combine" several existing elements in such a way as they operate together, then you can do that very JavaScript. For example, if you'd like a checkbox to, when clicked, show a dropdown list somewhere, populated with various things, you may do that.
Perhaps you may like to elaborate on what you actually want to achieve, and we can help further.
Yes, you can create your own tags. You have to create a Schema and import it on your page, and write a JavaScript layer to convert your new tags into existing HTML tags.
An example is fbml (Facebook Markup Language), which includes a schema and a JavaScript layer that Facebook wrote. See this: Open Graph protocol.
Using it you can make a like button really easily:
<fb:like href="http://developers.facebook.com/" width="450" height="80"/>
The easiest way would be probably to write a plugin say in Jquery (or Dojo, MooTools, pick one).
In case of jQuery you can find some plugins here http://plugins.jquery.com/ and use them as a sample.
You need to write own doctype or/and use own namespace to do this.
http://msdn.microsoft.com/en-us/magazine/cc301515.aspx
No, there is not. Moreover it is not allowed in HTML5.
Take a look at Ample SDK JavaScript GUI library that enables any custom elements or event namespaces client-side (this way XUL for example was implemented there) without interferring with the rules of HTML5.
Take a look into for example how XUL scale element implemented: http://github.com/clientside/amplesdk/blob/master/ample/languages/xul/elements/scale.js and its default stylesheet: http://github.com/clientside/amplesdk/blob/master/ample/languages/xul/themes/default/input.css
It's a valid question, but I think the name of the game from the UI side is progressive markup. Build out valid w3 compliant tags and then style them appropriately with javascript (in my case Jquery or Dojo) and CSS. A well-written block of CSS can be reused over and over (my favorite case is Jquery UI with themeroller) and style nearly any element on the page with just a one or two-word addition to the class declaration.
Here's some good Jquery/Javascript/CSS solutions that are relatively simple:
http://www.filamentgroup.com/examples/customInput/
http://aaronweyenberg.com/90/pretty-checkboxes-with-jquery
http://www.protofunc.com/scripts/jquery/checkbox-radiobutton/
Here's the spec for the upcoming (and promising) JqueryUI update for form elements:http://wiki.jqueryui.com/Checkbox
If you needed to validate input, this is an easy way to get inline validation with a single class or id tag: http://www.position-absolute.com/articles/jquery-form-validator-because-form-validation-is-a-mess/
Ok, so my solution isn't a 10 character, one line solution. However, Jquery Code aside, each individual tag wouldn't be much more than:
<input type="checkbox" id="theid">
So, while there would be a medium chunk of Jquery code, the individual elements would be very small, which is important if you're repeating it 250 times (programmatically) as my last project required. It's easy to code, degrades well, validates well, and because progressive markup would be on the user's end, have virtually no cost on the server end.
My current project is in Symfony--not my choice--which uses complex, bulky server-side tags to render form elements, validate, do javascript onclick, style, etc. This seems like what you were asking for at first....and let me tell you, it's CLUNKY. One tag to call a link can be 10 lines of code long! After being forced to do it, I'm not a fan.
Hm. The first thought is that you could create your own element and do a transformation with XSLT to the valid HTML then.
With the emergence of the emerging W3 Web Components standard, specifically the Custom Elements spec, you can now create your own custom HTML elements and register them with the parser with the document.register() DOM method.
X-Tag is a helpful sugar library, developed by Mozilla, that makes it even easier to work with Web Components, have a look: X-Tags.org

Categories