Re: Development Goals for Julian

Hb wrote:

> The Julian calendar module has currently some "characteristics" which makes it
> nearly unmaintainable and hinder an effective development.
> 
> Before patching another dozen workarounds into that module we should briefly
> define some common goals. So please comment:
> 
> 
> 1. The code uses several different string date/time formats and
> the UNIX integer timestamp too.
> 
> For simplicity timestamp is better.  Several PHP installations are said to have
> problems with timestamps below 0, i.e. dates before 1970.  In the past string
> based date/time handling was preferred because of lacking PHP capabilities.
> 
> = We should internally use timestamp only in future.

The Unix timestamp is a 32 bit unsigned integer allowing date ranges 
between 00:00:00 1 Jan 1970 and 03:14:07 19 Jan 2038 (UTC).  System 
calls to time or date return an integer in this range before optionally 
converting it to a human readable format.

Since we typically use the int database field type to store dates, in 
theory we could expand our range to sometime on 13 Jan 1901, but 
converting these "negative" timestamps to readable format could be 
difficult.  Windows typically doesn't correctly handle dates before the 
IBM PC was introduced in 1981.

How the dates are handled throughout Julian is convoluted and bloated 
(to put it mildly), with the some date variables being converted through 
several formats, back and forth between GMT and user local time, and the 
like, not to mention being copied several times.  Jason tried to clean 
Julian up, and wrote IEvents instead.  Obviously this is a daunting task.

> 
> 
> 2. The database stores a mix of SQL time format and UNIX
> timestamp.
> 
> = Although not planned to change, we should aim at the SQL format.

Use of the timestamp field type is rare in our repository.

> 
> 
> 3. In some parts of the code the later output and the form fields are
> formated to AM/PM.  The 24 hrs format is neglected.  Xaraya's user depended
> localization features are rarely used.
> 
> = We should use the date/time formats preset in var/locales/xx/locale.xml
> through Xarayas core functions.

Agreed.

> 
> 
> 4. Mixed use of camelCase and under_scored for naming variables. This leads for
> example to an array $event with the keys "eDescription" and "description", both
> carrying the same value (in viewevents.php). The number of blocklayout variables
> nearly doubled since latest release mainly because of duplicate content:
> http://bugs.xaraya.com/attachment.cgi?id=4062&action=view
> 
> = We should serve the templates of the last official release 0.4.5 and delete
> all other variables.

Duplication of data is indeed a problem which needs to be addressed.

> 
> 
> 5. Javascript is used to change the input form after changing the
> recurrence field. Some input fields are hidden while others are
> deactivated.
> 
> = Deactivation is the preferred method.

Agreed, although some older browsers do not support enabled/disabled 
states for inputs.

> 
> 
> 6. Date/time input is currently done on four files (newhook, modifyhook,
> addevent, edit) and several templates in a duplicated manner.
> 
> = For date/time input only one included template should be called by the other
> templates, see bug 5531. This need a unification of variables.

This could be remedied by calling the relevant DD properties rather than 
  creating a dedicated template.

> 
> 
> 7.  Is the included RFC xardocs/calendar.rfc valid?
> 
> = A definiton what we want from Julian is necessary.

No idea, but if it's not numbered and only in a module, it's probably 
not official.

> 
> 
> 
> Hb
>