First time here? Check out the FAQ!
Ask Your Question
4

The Future of post.js?

During my adventures through the old and new templates I eventually developed a lot of hate for a file by the innocent name of post.js. As I understand, it was mainly just carried over from CNPROG. Well, I'm sure these guys had their reasons, but two things bother me:

  • AskBot uses JQuery, post.js however could be written much more efficiently exploiting all of jQuery's features.
  • More importantly: requirements on the site's structure are hard coded into post.js, for example it wants me to use a span with class delete-icon for the delete comment element, but an a tag with edit class for the edit comment action. Where's the consistency in that? It is for example currently impossible to place the comment-button outside the area where the actual comments are displayed, as the javascript will examine the context of the button to find out where to display the widget.

What's your opinion on post.js?

Edit: Separated possible solution into an answer to facilitate discussion.

maebert's avatar
133
maebert
asked 2011-12-07 19:02:02 -0600, updated 2011-12-09 12:17:24 -0600
edit flag offensive 0 remove flag close merge delete

Comments

add a comment see more comments

1 Answer

1

I would propose slowly rewrite post.js to be independent of the site's structure by using the HTML5 data- attribute. That way we can define the behaviour in the template without touching javascript, ie. by

<li class="list-button" data-action="upvote" data-source="{{ post.id }}">Like</li>
...
<span data-role="vote-counter" data-source="{{ post.id }}">...</span>

The script will then dynamically link methods to the elements containing the respective data-action and outputs to the elements defined by data-role. Downside is that this takes a bit longer, but employing jQuery's full power should make up for that.

maebert's avatar
133
maebert
answered 2011-12-09 12:17:35 -0600
edit flag offensive 0 remove flag delete link
more

Comments

Gradual improvement is a good idea. We want to add test cases for the UI, then we can do refactoring while still being confident about the quality. Re using HTML5 doctype - that would be nice, we need to make sure that pages validate after the switch. Data attributes look much cleaner than encoding the values into class or id names.

Evgeny's avatar Evgeny (2011-12-09 12:46:56 -0600) edit
more
  • delete

I have seen people using data attributes to enrich the DOM with information used for scripts a few times, but I think there is currently no real consensus on how they should and should not be used - other than it should validate. At any rate I think it's the best compromise between flexibility for templates and performance for the script.

maebert's avatar maebert (2011-12-12 03:22:42 -0600) edit
more
  • delete

It is definitely something to think about I am curious if google scrapes that data and tries to make sense of it..

Evgeny's avatar Evgeny (2011-12-12 10:33:55 -0600) edit
more
  • delete
add a comment see more comments