Rails spinoffs - Apr 2007 - Drag and Drop Calendar

Drag and Drop Calendar

Has anyone seen something like this around using prototype and
scriptalicous?

It would need to do the majors- resizing, moving, creating.
I can use google calendar or somesuch but a custom solution may be more
suited to the requirements.
It''s for my companies internal job manager site- to help with
resourcing, so
we will need all sorts of custom type things, such as assigning multiple
people to an appointment.

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.

I''m looking for either a base or some techniques that could be used.
Any information is helpful.

Gareth

--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

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
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

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 <jason.harwig-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi,

I am also trying to create this type of application. I created the
grid with divs
and the scheduled events (div layer) can be placed on top of that.
But, in the loading time itself, I need to specify which are the
droppables.
 Then only I will get the target (droppableelement). In my grid, there
are
48 divs coming in one row. Around 25 rows will come. So I need to
specify
all these divs as droppable items. That is taking time. And while
dragging
time, the overall performance also decreasing.
Any other soution to get the target (where the scheduled event is
placed)  ?

Binoy


--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

The way I was picturing it, there were no "droppables", just dragables
that
stopped wherever you dragged them too... Thus, the only objects that need to
be created are the events that are dragged around.
The dragables would snap to the grid (by means of an ondrop or onmove type
handler) which was defined in the background and not actually used for
anything but display and object snapping.

Someone correct me if this approach won''t work.

Gareth


On 4/17/07, binoyav-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
<binoyav-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
>
> Hi,
>
> I am also trying to create this type of application. I created the
> grid with divs
> and the scheduled events (div layer) can be placed on top of that.
> But, in the loading time itself, I need to specify which are the
> droppables.
> Then only I will get the target (droppableelement). In my grid, there
> are
> 48 divs coming in one row. Around 25 rows will come. So I need to
> specify
> all these divs as droppable items. That is taking time. And while
> dragging
> time, the overall performance also decreasing.
> Any other soution to get the target (where the scheduled event is
> placed)  ?
>
> Binoy
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

On 16 Apr 2007, at 23:25, Gareth Evans wrote:
> Has anyone seen something like this around using prototype and  
> scriptalicous?
>
> It would need to do the majors- resizing, moving, creating.
> I can use google calendar or somesuch but a custom solution may be  
> more suited to the requirements.
> It''s for my companies internal job manager site- to help with  
> resourcing, so we will need all sorts of custom type things, such  
> as assigning multiple people to an appointment.
>
> 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.
>
> I''m looking for either a base or some techniques that could be
used.
> Any information is helpful.
You can see a working calendar at http://demo.placid.be/agendas/1;manage

I can tell you our developer has tried out quite a lot of techniques  
to finally get to the point of getting the calendar as performant as  
it is right now. Our first route was using a table and  Droppables on  
every table cell, but it became slow as hell (even causing browser  
crashes on older computers). Now, the trick to making it performant  
is using a single element with a repeating background image to  
contain the calendar events, then use the coordinates to determine  
what''s being done.

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
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

> 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
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Wow Peter, that''s some nice work there :)

On 4/17/07, Peter De Berdt
<peter.de.berdt-LPO8gxj9N8aZIoH1IeqzKA@public.gmane.org>
wrote:
>
> 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
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

The ondrop event can be assigned only to droppable element. So I can
not remove
all droppable elements from the page load. Because of this , I have
added one more
div and that will include all droppables and draggables. And I removed
the initialization
of all droppables except the parent one. And ondrop of an event, I
tried to get the target
element. But it is not showing the exact div id where it is placed. It
is showing the
parent div id. If I specify the all div as droppables, then only I am
getting the correct
target id.

Peter,
How can I get the target id , if I apply image as background ?

Please help me...


--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

On 17 Apr 2007, at 17:02, binoyav-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
> The ondrop event can be assigned only to droppable element. So I can
> not remove
> all droppable elements from the page load. Because of this , I have
> added one more
> div and that will include all droppables and draggables. And I removed
> the initialization
> of all droppables except the parent one. And ondrop of an event, I
> tried to get the target
> element. But it is not showing the exact div id where it is placed. It
> is showing the
> parent div id. If I specify the all div as droppables, then only I am
> getting the correct
> target id.
>
> Peter,
> How can I get the target id , if I apply image as background ?
You use Prototype''s Position and a bit of math to determine the drop  
zone, there is no target id as such. I''m simplifying things here, but  
that''s the gist of it. If you don''t feel very very comfortable
with
Javascript, don''t even try it, sorry to be so blunt.
You need to either build up some experience with both Javascript and  
Prototype/Scriptaculous or outsource it (and it''s not going to be  
cheap, no matter who you put on it).


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
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Thanks for the reply.
I am new to Prototype/Scriptaculous. I think you mean to say something
like this -
There will not be any target ids and if the event is in x position I
need to get
the target id equals (or nearer) to that x position. I think it is
depends upon the
browser. Am I correct ?


On Apr 17, 8:16 pm, Peter De Berdt
<peter.de.be...-LPO8gxj9N8aZIoH1IeqzKA@public.gmane.org>
wrote:
> On 17 Apr 2007, at 17:02, bino...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
wrote:
>
>
>
> > The ondrop event can be assigned only to droppable element. So I can
> > not remove
> > all droppable elements from the page load. Because of this , I have
> > added one more
> > div and that will include all droppables and draggables. And I removed
> > the initialization
> > of all droppables except the parent one. And ondrop of an event, I
> > tried to get the target
> > element. But it is not showing the exact div id where it is placed. It
> > is showing the
> > parent div id. If I specify the all div as droppables, then only I am
> > getting the correct
> > target id.
>
> > Peter,
> > How can I get the target id , if I apply image as background ?
>
> You use Prototype''s Position and a bit of math to determine the
drop
> zone, there is no target id as such. I''m simplifying things here,
but
> that''s the gist of it. If you don''t feel very very
comfortable with
> Javascript, don''t even try it, sorry to be so blunt.
> You need to either build up some experience with both Javascript and
> Prototype/Scriptaculous or outsource it (and it''s not going to be
> cheap, no matter who you put on it).
>
> 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
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

On 19 Apr 2007, at 06:59, binoyav-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
> Thanks for the reply.
> I am new to Prototype/Scriptaculous. I think you mean to say something
> like this -
> There will not be any target ids and if the event is in x position I
> need to get
> the target id equals (or nearer) to that x position. I think it is
> depends upon the
> browser. Am I correct ?
Yes, exactly. Prototype has pointerX and pointerY properties in the  
Event class.

You first need to obtain the position of the container, run through  
the DOM tree upwards and add the offsetLeft and offsetTop values of  
each element. Then you can use this value in a method to calculate  
the position of the mouse over the grid in the container.


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
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Thanks for the reply.. Let me try this...

Thanks a lot..
>
> Yes, exactly. Prototype has pointerX and pointerY properties in the
> Event class.
>
> You first need to obtain the position of the container, run through
> the DOM tree upwards and add the offsetLeft and offsetTop values of
> each element. Then you can use this value in a method to calculate
> the position of the mouse over the grid in the container.
>
> 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
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---