> I've recently created a similar tool for a project, but have the > server calculate all the positions. The problem is that I have to > rewrite those calculations on the client if I want real-time dragging/ > resizing of events -- which I don't do now. The calculations get non- > trivial when dealing with overlapping events.
Overlapping events will be a real pain in the ass if you're generating your calendar on the serverside, because you have no information whatsoever on the DOM and you need to determine overlap using datetime ranges. Things will be different when you're using clientside code (not easy by any means, but you won't run into the hurdles you will when using serverside code). Although we haven't tackled overlapping events in our project (there wasn't a need for it), it would be a matter of using Prototype's Position methods to determine whether there's an overlap and act accordingly (decrease the width of the underlying event, ) IMHO. Your clientside code doesn't really need to handle date and time for the positioning of the events, it only needs to calculate those values when the actual event is dropped and need to be sent back to the server for creating or updating and even then it's only a matter of determining the start and stop datetime values (the actual data, not the visual representation). What we've found out when creating a javascript calendar/scheduler is that you need to stop considering it as a collection of dates and times for the actual drawing and element interactions of the calendar. Best regards Peter De Berdt --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
