My experience with overlapping events was that it was much easier to
calculate if something didn't overlap than if it did.
When you have 2 ranges, you know that they dont overlap if the start of one
is after the end of the other, or the end of one is before the start of the
other.

//psuedocode
if (range1.end < range2.start || range1.start > range2.end)
{
//allow resize
}

vs

if (range1.start > range2.start and range1.start < range2.end) etc
I've drawn numerous diagrams to try and think this one through and I can't
ever get it 100%.


I think the absolutely positioned cells is a good idea, but why create it on
the server at all?
In fact, putting a bit more thought into it, why not have a standard html
table, which is the background to the grid.

You could snap-to-grid using Element.Position on the cells and each
'event/appointment/whatever' could be absolutely positioned on the top.
That way, they could be dragged around the 'grid' by overriding some of the
drag and drop events.
Get the closest cell, im pretty sure there's a method for this.

I will probably end up writing my own but it wont be for some time, clients
work comes first :(

Gareth



On 4/17/07, jharwig <[EMAIL PROTECTED]> wrote:
>
>
> Which is why google doesn't use tables for the event area.  They
> create the rows and columns with absolutely positioned divs, and
> overlay absolutely positioned events on top.
>
> 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.
>
> I couldn't find anything to better to start with, so If you do, let me
> know.
>
> Gareth Evans wrote:
>
> > I've written a Drag&Drop calendar before (without resizing) for another
> > project and the biggest problem was that it was created with table
> cells, so
> > when you had an appointment that was longer than a cell, we had to use
> row
> > span on the destination cell and 'pop off' the cells to the right so
> that
> > the calendar didnt get misaligned.
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to