Timeline for Jquery field add code - Improvements in readability, compactness or efficiency
Current License: CC BY-SA 3.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 27, 2013 at 15:30 | answer | added | rusln | timeline score: 1 | |
| Jun 26, 2013 at 19:02 | comment | added | Flambino | For the record, Benjamin and I kept arguing in the chat for a bit (we agreed to disagree), and ended up with these two fiddles: His, using KnockoutJS and mine, which is not too different from yours. I used CoffeeScript for mine, but here it is as JS | |
| Jun 26, 2013 at 17:22 | comment | added | Benjamin Gruenbaum | let us continue this discussion in chat | |
| Jun 26, 2013 at 17:15 | comment | added | Flambino |
@BenjaminGruenbaum And I still disagree. If HTML was only about presentation, we'd still be using <font> tags, or <i> when we mean <em>. If anything HTML is less about presentation nowadays, although you can treat it as merely that. Yes, you can do everything in JS, keep state there, and make sure the DOM reflects that state. Or you can consider the JS itself (in this simple case) practically stateless and wholly event-driven. The goal is DOM manipulation (adding/removing elements) so why complicate it?
|
|
| Jun 26, 2013 at 16:36 | comment | added | Benjamin Gruenbaum | @Flambino Right, and you can use XML for data all you want (although it's a data-exchange format for documents). However, HTML is not just XML (or at all) and it's a specific mark up language for the presentation of web pages. Just because you can use something to store data doesn't mean that you should. You can store data in custom attributes but it's a horrible idea - just like you can create one giant string and slice it at specific places instead of using variables at all - doesn't mean it makes sense, it's simply not where it belongs. The DOM is about data, presentation data. | |
| Jun 26, 2013 at 16:31 | comment | added | Flambino | @BenjaminGruenbaum And I still hold that the DOM is about data, not necessarily presentation. Markup of any kind provides structure and semantics for data, and the DOM is the API: It is - among other things - a database you can query. (If we were talking about a simple XML file, I think you'd agree that it's just structured data, since XML by itself has no GUI.) It's a beast because it's not the nicest/fastest API for manipulating structured data, but it is an API nontheless. It also has a GUI component, but that doesn't invalidate its data modelling abilities. | |
| Jun 26, 2013 at 15:42 | comment | added | Benjamin Gruenbaum | @Flambino The DOM is not a beast. I think that the DOM is quite a nice abstraction to do presentation and it works which is why you see similar concepts for GUI like XAML in WPF or QML in QT. That's what it is though, presentation. Using data representing things - like JavaScript objects to represent well... data is not another abstraction - it's common sense. Storing application state in the presentation layer with all the markup is a bad technique that completely ignores how GUI is coded - it originates in an age where web pages were static. You don't need a framework to do it right! | |
| Jun 26, 2013 at 15:27 | comment | added | Flambino | @BenjaminGruenbaum If we're talking about a full-on everything-is-ajax-and-js application, then sure, throw Angular or KnockoutJS or anything else at it. Would I want to keep all state data in the DOM for such a project? No, of course not. But for this I'd do it. The DOM is beast, yes, but it's still a data model (and jQuery tames it). Libs like Knockout & Angular are neat, but they're also more code and more abstractions, and overkill in this case. All we're talking about is a neater HTML form. | |
| Jun 26, 2013 at 1:33 | comment | added | Benjamin Gruenbaum | @JamesWillson A lot of libraries like AngularJS and KnockoutJS provide bi-directional data-binding, for example (which is very similar to what you're doing) see learn.knockoutjs.com | |
| Jun 25, 2013 at 22:39 | comment | added | J.Zil | I'm a little confused. Are we talking about submitting the array via ajax so that the results don't have to be stored in actual DOM field elements? The advantage of using fields is that I can easily edit the contents of each field after they have been added, otherwise I would probably just have text in printed above with no way to edit | |
| Jun 25, 2013 at 21:05 | comment | added | Benjamin Gruenbaum | @Flambino I consider that a blunt mistake. You're developing a web application not a document. The state should be stored in JavaScript, in models like in any sensible GUI that does separation of concerns. This is exactly what the transition from static web pages to web applications is all about. Do you honestly think querying your presentation is reasonable whenever you want to know your application's state? Storing HTML in JavaScript strings and having no separation of concerns? Storing application state in the DOM is dangerous and harmful. Separate the right concerns. | |
| Jun 25, 2013 at 21:00 | comment | added | Flambino |
@BenjaminGruenbaum I disagree. I'd say state should be stored in the DOM. That, I'd argue, is exactly how to separate concerns: JS controls behavior, the DOM contains the data, and CSS governs presentation. If the user is supposed to see what's going on, the data must necessarily be added to the DOM at some point, so I'd say keep it there to begin with. To get a "clean" JS array rather than a list of DOM elements, a simple jQuery .map() will suffice.
|
|
| Jun 25, 2013 at 15:44 | comment | added | J.Zil | Posted the code. I am adding in fields (I'm guessing thats what dom elements are applying to in this case) because it seemed a lot easier to submit in a form that way | |
| Jun 25, 2013 at 15:26 | history | edited | J.Zil | CC BY-SA 3.0 |
added 1329 characters in body
|
| Jun 25, 2013 at 15:22 | comment | added | Benjamin Gruenbaum | You are storing your application state in the HTML instead of keeping a JavaScript object and separating concerns ("requirements" for example is conceptually an array, not a list of DOM elements). This approach will make it very hard for your code to scale in terms of maintenance (Even atm, it's not very readable). Also, please post the code here as well. | |
| Jun 25, 2013 at 15:20 | history | edited | J.Zil | CC BY-SA 3.0 |
edited title
|
| Jun 25, 2013 at 15:08 | history | asked | J.Zil | CC BY-SA 3.0 |