271409 - Reorganization of calendarManager.js

Status: RESOLVED INVALID

(Calendar :: General, defect)

Description

[ago]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

There are a few issues which should probably be split into separate bugs, but
since they involve a "broader picture" it is good to have one place to discuss
before coding. 

1) Storage: at the moment storage is handled in at least 3 "palces":
calendar.js, calendarManager.js and libxpical. There should be some thought on
how to unify this. My personal view is that all storage should either be in
calendarManager.js or on libxpical, suboptimal solution is to have "local"
storage in libxpical and use calendarManager.js to add more functionality and as
an abstraction layer. Certainly there should be no direct call in calendar.js to
low level storage functions and there should be no reference to user interface
elements in calendarManager.js. To begin with the deleteItems and saveItem
should be moved to calendarManager.js

2) calendarManager should possibly be considered an "extension" of the calendar
container object, i.e. there should be an array of calendar objects. The
Calendar() constructor in calendarManager.js now is only used to initialise
variables to defaults, Calendars should be used as objects, with properties
cached from the rdf and methods like add/edit/delete item which abstract from
the backend used and the local/remote online/offline settings. Low level library
should be accessed indirectly through Calendar objects.  

3) rdf is used throughout which makes the code somewhat confusing, the
properties should be cached into attributes of Calendar objects.
load/saveProperties methods are needed. 

4) Calendar objects in the calendarManagers.Calendars array should always be
accessed by serverNumber/id not by name or path... The id should be used as the
key in the array of Calendars.

5) Use a single i/o library. Now file.js is used as well as nsILocalFile

6) Unify local/remote calendars. As far as flat-files go, it would help if there
were the following helper functions: startLock, getModifiedTime,
dumpLocally/download, dumpRemotely/publish, reload. Different helper functions
are required for event-level storage. Such helper functions should be invoked by
more abstract methods Calendar.add/edit/delete event which in turn are the ones
called from calendar.js.

7) observers

Reproducible: Always
Steps to Reproduce:

Comment 1

[ago]

The answer to this bug (at least to several of the points above) is
calICalendar, I just found out about it...

Comment 2

[Joey Minta]

(In reply to comment #1)
> The answer to this bug (at least to several of the points above) is
> calICalendar, I just found out about it...

In that case, is there any reason to keep this (and bug 271525) open?  They
cover so many issues that it's difficult to tell under what conditions they can
be marked 'resolve', but with all the changes, I think it might be best to just
scrap these bugs.  If you agree, please mark this bug 'resolved'.

Comment 3

[Michiel van Leeuwen (email: mvl+moz@)]

calendarManager.js is indeed not used anymore.

Comment 4

[Reed Loden [:reed]]

The bugspam monkeys have been set free and are feeding on Calendar :: General. Be afraid for your sanity!