Help me with my new website!

[KevinM1]

[bennyboy]

[FlatAssembler]

I haven't really studied anything beyond the basics of JavaScript. I was sick and tired of reading about polymorphism, template classes and how to build your own iterator class in C++, thinking that such things would help me write programs. They didn't appear to. So, I don't really understand what you're talking about.

Anyway, I've just found out that using object properties instead of the "eval" appears to work:

Code:

for (var j=0; j<odgovor1.length; j++) for (var i=1; i<3; i++) { tablica[i][j]=document.createElement("div"); tablica[i][j].setAttribute("class","rijecUDrugomDijelu"); if (i===1) tablica[i][j].appendChild(document.createTextNode(odgovor1[j])); else if (i===2) tablica[i][j].appendChild(document.createTextNode(odgovor2[j])); tablica[i][j].style.top=228+27*j; tablica[i][j].style.left=-153+110+153*i; tablica[i][j].redak=j; tablica[i][j].onclick= function() { var tmp=tablica[1][this.redak].style.left; $(tablica[1][this.redak]).animate({left:(tablica[2][this.redak].style.left)},500); $(tablica[2][this.redak]).animate({left:(tmp)},500); tmp=odgovor1[this.redak]; odgovor1[this.redak]=odgovor2[this.redak]; odgovor2[this.redak]=tmp; } pozadina.appendChild(tablica[i][j]); }

[bennyboy]

That's definitely a lot more readable and nicer looking.

If you Inspect the page that this puts out (I use Chrome's built-in stuff cuz it's easy), then you'll see that every div has an identical function.  if you have a dozen divs, multiplying that short function won't really matter too much.  If you have a hundred, it might.

Since you are already assigning the class name "rijecUDrugomDijelu" to every div, then I really think it would be better to write an onclick event for that class, separate from this routine, than to have your routine inject a new instance of the onclick even for every single div you make.  Your onclick handler will have to figure out which div called it (which your way doesn't have to do) and then figure out what it's switching with, but overall, it will be a more elegant solution.

Using JQuery (just need to reference a script, it's very easy):

Code:

$(".rijecUDrugomDijelu").click(function (event) {  // put this in your main script body, not in the div-making routine.      var clickedID = event.target.id; // can also use $(this) to refer to the div      alert(clickedID );        // now do stuff with the div });

This will give you the id of the clicked div.  Then you can go ahead and switch it with another div.

[FlatAssembler]

I don't understand how your solution could be faster. JQuery, as far as I am aware, searches the entire DOM tree (which is a linear-time algorithm with respect to the number of elements on your page, since the DOM tree isn't a red-black tree or a heap or anything that would allow a logarithmic-time search) and checks if an element matches the selector (such as ".rijecUDrugomDijelu"), and then it sets its "onclick" method to be the function you passed to it.

[KevinM1]

In the case of something simple, like an ID, tag name, or class name, Sizzle (the jQuery selector engine) simply uses the native JavaScript equivalent (e.g., getElementById(), getElementsByTagName(), getElementsByClassName()).  So, if you grabbed your table elements using one of those functions, you're not going to be incurring any significant penalties by using the jQuery version.

Regardless, speed isn't the most important thing to consider. Modern browsers (let alone computers) are fast. A linear search in place of a logarithmic search isn't going to noticeably negatively affect you. In the real world, in the vast majority of cases, code readability, reusability, and overall elegance is far, far more important than pure speed.

[bennyboy]

I don't understand how your solution could be faster. JQuery, as far as I am aware, searches the entire DOM tree (which is a linear-time algorithm with respect to the number of elements on your page, since the DOM tree isn't a red-black tree or a heap or anything that would allow a logarithmic-time search) and checks if an element matches the selector (such as ".rijecUDrugomDijelu"), and then it sets its "onclick" method to be the function you passed to it.

There's no speed issue either way, though your way will obviously result in more code, especially if you have a lot of rows of data.  Unless you're running the site on a toaster, either way will be fine.

But there's value in beauty, and there are programming advantages in separating information, information processing, and visual presentation. When you're trying to do one thing in one part of your page, a hack job is fine. But when you decide to extend your simple code into a huge page with a lot going on, you'll be glad if you keep everything separate (and well documented, of course, even though everything seems clear right now). But let me give you an insight into web programming that might not be obvious. When you want to debug your page, you will be inspecting your page using developer tools-- and in this case, minimal output will make it MUCH easier to notice and eventually fix problem code.

That being said, I have to confess that I have the same thing sometimes, though I arrive at it differently.  In ASP.NET (Hi, Kevin!), I build user controls which include javascript.  So I might have a user control which includes an image, a couple buttons, and some programming logic, and then populate a page with a hundred of those based on results of a SQL query or something.  So it renders out much like yours will: lots and lots of instances of identical code.

[KevinM1]

Yeah, sometimes a kludge is the best way to go.  But that’s usually because of external pressures (hello deadlines).

But, yes, separation of concerns is one of the pillars of programming.  Most apps - even web apps - are layered.  The most prevalent web app pattern is MVC - Model, View, Controller.  

The Model is, essentially, your data - encapsulated by objects - that interact with each other.  Sometimes Models are simple (forum posts).  Other times, they’re complicated (a graph of objects that act on one another, like one’s financial portfolio).

The View is exactly what it sounds like.  It’s what the end user sees.  It’s how they interact with the Model.

The Controller is the glue that holds it together.  It handles user input, and passes it to the Model.  It returns the proper View based on what the user requests, or based on changes in the Model.

Now, MVC isn’t the only pattern.  Benny, because he’s using ASP.NET Web Forms, is using a different pattern.  But the idea is the same - layered components.

Why is this beneficial?  Because it allows the developer to change/edit/maintain part of the system without worrying about messing up something else.  If I decide to create a new site layout, I don’t need to worry about my database code, or my Controller(s).  I simply make new templates and CSS.

This approach even works in single page apps.  Inline JavaScript and CSS is an example of a code smell.  It’s a sign of doing it wrong.  Most JavaScript comes in the form of externally referenced libraries, with page-specific code placed within script tags either at the top of the HTML document (with some form of code that waits for the entire document to load into the browser’s memory because JavaScript is greedy/fast and will attempt to access the DOM before it’s available) or the bottom.  Similarly, external CSS is loaded in order, so simply start with your sitewide rules, and add page-specific files as necessary.

And, of course, separation of concerns isn’t a web-only paradigm.  It’s how programming is done, period.  Concrete, and layered, components that communicate with each other through clearly defined interfaces.  Which, since you mentioned it in passing before, is leveraged/aided by things like polymorphism.

[FlatAssembler]

Maybe. But what appears to matter far more is the language you use and the frameworks you use to build apps. I've spent years and years studying C++, and the most flashy thing I could make was a tetrahedron that casts a shadow and can be rotated around its axis using the arrows on keyboard using the OpenGL framework. So pathetic. And, after just a few weeks of learning JavaScript and SVG, I was able to make a Pacman game playable on smartphones.

[bennyboy]

Maybe. But what appears to matter far more is the language you use and the frameworks you use to build apps. I've spent years and years studying C++, and the most flashy thing I could make was a tetrahedron that casts a shadow and can be rotated around its axis using the arrows on keyboard using the OpenGL framework. So pathetic. And, after just a few weeks of learning JavaScript and SVG, I was able to make a Pacman game playable on smartphones.

I've made workable games using DirectX in c++ and using .NET wrappers, using the Unreal engine, and using Unity, and even using pure text in an MS-DOS prompt.  If you want a game that can be deployed easily to multiple platforms, then in my opinion Unity is the best way to go.  No disrespect to your Pacman game, but while it's a great programming exercise, there are not people in the world who are going to spend more time playing it than those of us willing to do it to report to you whether it works.  SVG is not even in the top 20 list of platforms worth making games on.

That doesn't mean your time spent is wasted.  SVG is a very useful technology, and definitely has its uses in web sites: my own homepage has an animated SVG logo.  But if you really want to make games, get Unity.  It's free, there are a gazillion tutorials for it, and you can have a working demo game up and running on your phone in a couple of hours.