3 ms·

Won't this completely break down in a DOM simulator? It seems like a bad idea to couple data with presentation. I'm quite honestly dismayed when my team try s

Won't this completely break down in a DOM simulator? It seems like a bad idea to couple data with presentation. I'm quite honestly dismayed when my team try stupid things like this. I can give a recent example, of where we perform stats from data stored in a grid, where performance of the grid is terrible, and it drags the stats performance into the ground, instead of quickly calculating/caching the stats from the data directly. If you suggest adding data caching functionality to a GUI grid, I will start crying!

technoguyrob 18y ago
This is the dirtiest component of going between DOM and the event abstraction (start and end times). When someone resizes the event or moves it, it's going to take some kind of pixel calculations at one point or another, even if they're very generalized, since they used their mouse to do that. This is the point at which I decided to deal with that. Otherwise the events are all handled abstractly. The data isn't necessarily coupled with the presentation, but for example the way they move the event around on the DOM when they're dragging and dropping (presentation) has to be translated into data at one point or another (and so the function is called dom2time--translating presentation to data :).
- watmough 18y ago
  I went back and re-read your explanation above, and my constructive criticism would be the following: 1. Use a table, or horizontal grid of divs to represent the calendar. You can write different server or client side code to render different presentations, e.g. calendar, 5 day view, 7 day view etc. 2. In this grid, tag each div with the appropriate date stamp as appropriate for your application. 3. Build code on the client side to track mouse drags, clicks, or whatever you need to provide the user with a great experience specifying start and end times. None of this sounds that hard or tricky, and I would certainly be happier with an approach that separated out generating time tagged divs from the presentation and selection mechanism.
  - technoguyrob 18y ago
    Yeah, I did all this. :) For part 2, I still need a helper function like this because the timestamp changes (when the user resizes, moves, etc.). Does that make more sense? I have a grid of DIVs, on which I position events on top of. EDIT: I see what you mean. For part 3, for example, I want "12:05", not "12:04:27". Yeah, I was getting to that.

technoguyrob 18y ago

This is the dirtiest component of going between DOM and the event abstraction (start and end times). When someone resizes the event or moves it, it's going to take some kind of pixel calculations at one point or another, even if they're very generalized, since they used their mouse to do that. This is the point at which I decided to deal with that. Otherwise the events are all handled abstractly. The data isn't necessarily coupled with the presentation, but for example the way they move the event around on the DOM when they're dragging and dropping (presentation) has to be translated into data at one point or another (and so the function is called dom2time--translating presentation to data :).

watmough 18y ago
I went back and re-read your explanation above, and my constructive criticism would be the following: 1. Use a table, or horizontal grid of divs to represent the calendar. You can write different server or client side code to render different presentations, e.g. calendar, 5 day view, 7 day view etc. 2. In this grid, tag each div with the appropriate date stamp as appropriate for your application. 3. Build code on the client side to track mouse drags, clicks, or whatever you need to provide the user with a great experience specifying start and end times. None of this sounds that hard or tricky, and I would certainly be happier with an approach that separated out generating time tagged divs from the presentation and selection mechanism.
- technoguyrob 18y ago
  Yeah, I did all this. :) For part 2, I still need a helper function like this because the timestamp changes (when the user resizes, moves, etc.). Does that make more sense? I have a grid of DIVs, on which I position events on top of. EDIT: I see what you mean. For part 3, for example, I want "12:05", not "12:04:27". Yeah, I was getting to that.