Hi John, first, I just visited your calendar app and it looks like a nice piece of code... I like the feature of being able to select the number of days and also the separation of different concepts such as Employee, Owner... Regarding the first, I have this feature on my list as well. I was also thinking about giving the user the possibility to choose the granularity of the hours axis, so let's say you have field like 1-2, 3-4, .... This option might be useful if you have events lasting several hours. I was also thinking about implementing a more advanced switch between any time range. Let's say you have a week view and press the button to show the next week. Currently, all calendar implementations "just" replace certain parts of the calendar view, .e.g. clear old and render new events etc. Wouldm't it be nice to fade week 1 out and week 2 in at the same time? Basically, it requires you to build up week 2 in an invisible area and then stitch it directly to the right side of week 1. This done, you smoothly move the container containing week 1 and 2 to the left. I have implemented a proof-of-concept in pure JavaScript and it looks pretty cool. What do you think about this?
Another thing I am still undecided with is regarding the question of how to build the calendar grid itself. I looked at your DOM representation. You decided to use a pure Table-based approach. This means you have one cell per time unit (e.g. 15 min). In contrast, the Google calendar is based on a mix, using a table as the overall container. It then uses one div per time unit (they use 1 hour = 24 divs) on the horizontal axis. Wisely, they use just one div for the whole time range, 7 days in this case. On top of this, they create another set of divs on per day basis on the vertical axis. Thus, they need 7 divs to construct one week. The latter div also serves as a container for events, making it possible to size events on a per pixel basis which is very flexible. Another approach would be to use a one div per time unit per day. For 7 days and a time unit of one hour, you would need to create 24*7 divs, whereas the Google calendar approach only requires 24+7. Due to simplicity reasons, I have used the 24*7 div approach in the proof-of-concept implementation mentioned above which worked fine. However, the Google approach obviously outperforms the 24*7 approach. John, have you thought about these issues or even have another lightweight solution in your sleeve? Thanks! Scholle On Jan 23, 2:45 pm, John Denley <j...@deba.org.uk> wrote: > It all depends on what your "several reasons" for doing it yourself are... I > have had to do it all myself, I'm not 100% pleased with the results, but at > least the functionality is working how I want it to work, and I have 100% > control over what it does and how it works. > > I was lead to believe there were some things in the pipeline for the google > calendar API that might help me do what i needed to do, but it seems that > the API for the google calendar itself wont do what i need it to do in quite > the right way and certainly not in the timeframe i need, so im sticking with > my self built solution. > > The hardest part I have found so far is dealing with mouse interraction and > resizing of columns and rows, not least to take account of scroll bars, > which are different sizes on different browsers, and I have yet to find a > consistent automatic way to take care of this. > > Ive also had a huge amount of problems with figuring out dynamic CSS > priorities, which obviously effects the look and feel of the calendar area. > firebug has helped a great deal on this, but i still find myself saying "why > has that border size not filtered through correctly?" > > HTH, > John > PS if you want to look at what Ive done so far you can see it > athttp://demo.ideba.net(doesnt seem to work in IE7, havn't figured out why > yet!) > > On 22 January 2010 15:39, mstu...@googlemail.com > <mstu...@googlemail.com>wrote: > > > Useful hint, one can certainly use the calendar of this lib as a > > reference implementation... > > > Thanks! > > > On 21 Jan., 19:02, Paul Robinson <ukcue...@gmail.com> wrote: > > > Seehttp://code.google.com/p/ftr-gwt-library/ > > > > Paul > > > > mstu...@googlemail.com wrote: > > > > Hi All, > > > > > I am quite new to GWT and currently evaluating this technology. For a > > > > project I need to build an application containing a calendar such as > > > > Google Calendar where the user can create and move events around. The > > > > SmartGWT lib contains a Calendar Widget but I want to build my own due > > > > to several reasons. However, when using the SmartGwt Calendar widget, > > > > it seems very slow. Of course, it doesn't necessarily mean that > > > > building such kind of widgets with GWT will be slow. However, the > > > > alternative to using GWT would be implenenting it in pure JavaScript > > > > and using some of the libs such as Prototype, Dojo, etc. I am pretty > > > > familiar with. > > > > > Has anyone build a Calendar in GWT or something similar and is willing > > > > to share some experience? > > > > > Thanks very much! > > > > > Scholle > > > -- > > You received this message because you are subscribed to the Google Groups > > "Google Web Toolkit" group. > > To post to this group, send email to google-web-tool...@googlegroups.com. > > To unsubscribe from this group, send email to > > google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2bunsubscr...@googlegroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/google-web-toolkit?hl=en. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
