3 ms·

Yes, I skipped over a few of the specifics. The "Saturday/Sunday" at the end of the week versus "Sunday at the beginning" is taken care of, I was just using tha

Yes, I skipped over a few of the specifics. The "Saturday/Sunday" at the end of the week versus "Sunday at the beginning" is taken care of, I was just using that as an example to explain; internationalization works fine. The time property is already attached to the DIV; however, this will be recomputed based on some DOM-change to the event. It makes it simpler, since (for example) when the user resizes the event, I can just deal with the physical resizing of the DOM object, and once they're done, translate it to the timestamp. I'm a presentation/data separation freak to the point of having no Python code include any HTML, and no HTML include any JS (except the <script> tag). However, this is a case where presentation and data are very intimately attached. Maybe I should have explained that I don't use this to get the time of the event. However, when the user resizes the event, at some point that connection between data and presentation has to be made, since their resizing is ultimately caused by pixel-based mouse coordinates. Also, the varying column width is taken care of, as none of this is hardcoded. The vertical and horizontal spacings are computed by looking at offets, and recomputed during window resizing. Does that make my approach any better? I think that addresses every issue. I agree, though, there are better ways to do this, but this isn't a priority project for me so I haven't put as much thought into it as I'd like. Thanks, Neal.

neilk 18y ago
Okay, I think I get it now. You want the user to "stretch" the DOM element representing a schedule item, and then when the user is done stretching, you will translate the movement into a real start and end time. To borrow MVC terminology, your DOM element is then effectively a controller + view in one. Just like we might translate a slider at 50% into 128/256, it's okay to take its properties and then translate those into your model. Presumably you poll the DOM object as it is being dragged, or fire off events when it stops being dragged, which updates the model in near-real-time. Do I understand it? This is actually a good idea then. Although you want to be careful that your controller doesn't rely on magic constants to do its conversion, it should derive those from some initialization from something representing a "layout". But you seem to have done this. To get back to your original question... I did find the code hard to read. I don't have the time to unravel it to make it clearer, but personally, I always like to state the problem as clearly as I can up front, in an expression that approaches pseudocode. Like "return getStartOfWeekTime(el) + getOffsetTime(el)". This hides away the hard bits in smaller routines, and the clueless maintenance programmer (i.e. you in one month) will understand what's going on right away and where the bugs might be. But if this is too slow you may have to bite the bullet and live with something hard to read.
- technoguyrob 18y ago
  Exactly! And yes, all those "magic numbers" are derived. For example... this.hSpacing = Array.prototype.slice.call(this.parent.blocks.filter( function(n){ return n < _this.parent.cols; }) .map(function(n,o){ return o.offsetLeft; }) ); Your function names and decomposition are indeed much easier to read. Thanks again, Neal!

neilk 18y ago

Okay, I think I get it now. You want the user to "stretch" the DOM element representing a schedule item, and then when the user is done stretching, you will translate the movement into a real start and end time. To borrow MVC terminology, your DOM element is then effectively a controller + view in one. Just like we might translate a slider at 50% into 128/256, it's okay to take its properties and then translate those into your model. Presumably you poll the DOM object as it is being dragged, or fire off events when it stops being dragged, which updates the model in near-real-time. Do I understand it? This is actually a good idea then. Although you want to be careful that your controller doesn't rely on magic constants to do its conversion, it should derive those from some initialization from something representing a "layout". But you seem to have done this. To get back to your original question... I did find the code hard to read. I don't have the time to unravel it to make it clearer, but personally, I always like to state the problem as clearly as I can up front, in an expression that approaches pseudocode. Like "return getStartOfWeekTime(el) + getOffsetTime(el)". This hides away the hard bits in smaller routines, and the clueless maintenance programmer (i.e. you in one month) will understand what's going on right away and where the bugs might be. But if this is too slow you may have to bite the bullet and live with something hard to read.

technoguyrob 18y ago
Exactly! And yes, all those "magic numbers" are derived. For example... this.hSpacing = Array.prototype.slice.call(this.parent.blocks.filter( function(n){ return n < _this.parent.cols; }) .map(function(n,o){ return o.offsetLeft; }) ); Your function names and decomposition are indeed much easier to read. Thanks again, Neal!