Reorganization of calendarManager.js

RESOLVED INVALID

Status

Calendar
General
RESOLVED INVALID
14 years ago
12 years ago

People

(Reporter: ago, Assigned: Mostafa Hosseini)

Tracking

Details

(Reporter)

Description

14 years 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:

Updated

14 years ago
Blocks: 269476

Updated

14 years ago
Depends on: 271525
(Reporter)

Comment 1

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

Comment 2

13 years ago
(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'.

calendarManager.js is indeed not used anymore.
No longer blocks: 269476
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → INVALID
The bugspam monkeys have been set free and are feeding on Calendar :: General. Be afraid for your sanity!
QA Contact: gurganbl → general
You need to log in before you can comment on or make changes to this bug.