Great to have some technical feedback on this at last Scholle (is that your first name?) I've been pretty much flying alone on this over the last few months. I only started with java/GWT/GAE in September having done virtually no programming for nearly 10 years before that! I only say this because a lot of what you have said below would have been totally meaningless to me 6 months ago. I have built what I have done based on whatever was the easiest and most workable solution I could figure out at the time, so in answer to your question, I have not put any thought into the methods behind what Ive been doing. This product originally started off as one row per hour, and 3 vertical columns as a proof of principle so see if GWT would work for me, and if it worked fast enough! Ive extended as and when I have learned new functionality and methods.
It has always been my intention that as soon as we get some additional funding, then we can employ a "real" programmer or two, to reconstruct the product in a more streamlined way (it does a huge amount more than what you can see in that small demo!) I love your ideas of flowing the views to make it look smooth and "cool". The philosophy behind what I have done has always intended to be a replication of a paper diary as close as possible, such that it is not too "alien" to anyone who has NOT used something like outlook in the past. This is why we have the "month/week/day" forward and backwards buttons, trying to make it a little like turning the page of a paper diary. As such for me it would be nice to make it LOOK like you were actually turning the page (ive seen this in online magazines etc, but they usually use flash to do it). The google approach is surely the best way to go, as we certainly need the ability to create appointments that do not comply with a standard "slot" (incidentally, in the admin section, you can change the number of appointment slots per hour, currently 4 (=15 min)) I currently have a small problem with my version, in that I cannot get rid of the gaps between each table cell. I thought that setting "border-collapse: collapse;" in the CSS would achieve this, and it may well do, but I suspect I have not set it in the correct place, so if you or anyone else reading this can help, please do let me know! Thanks, it was great to hear from you, John On 23 January 2010 15:28, mstu...@googlemail.com <mstu...@googlemail.com>wrote: > 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> > <google-web-toolkit%2bunsubscr...@googlegroups.com<google-web-toolkit%252bunsubscr...@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<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.
