As part of a calendar software we need a floating edit box comparable to the one in iCal able to manipulate event data passed (details given) via a number of input fields that will also have to be written by the coder. It should be written as a Mootools class.
We plan on using this event box to replace an existing implementation and want it to be both neatly coded and looking good. That said if a bidder mentions that they prefer not to undertake the task of styling, we'll take that into account.
The bid is on creating an edit box we plan to attach to calendrical event. The box will be opened by a function as described below. It should contain a number of fields for the below data as well as a 'Done' button that closes the box.
The box should also close when the user clicks outside it (our implementation has a linkable mouse listener elsewhere so we only require a *close* method).
Only one instance of the box should be open at any time.
**Event Data & Fields**
The edit box will be opened with reference to the originating DOM Object and another Object holding the event data, formatted as below. A mootools Event named 'update' should be despatched to the latter class when the 'Done' button is pressed.
name: string (single line),
It should be possible to add one or more recurrence rules to the class. These should be in a list below each other. It should be possible to chose if a rule is inclusive (does occur on match) or exclusive. The options should be equivalent to those permitted in the iCal custom repeat options. The interface layout will have to be discussed, as will the formatting of the recurrence data, which is mostly up to the programmer.
We are currently in the progress of upgrading our system's recurrence rule capabilities. They currently only allow a single recurrence with the below options. It should be possible to switch between those two kinds of forms through use of a hardcoded constant.
Every [n] [days|weeks|months|years] (inclusive).
The class or classes should work in Mootools 1.2.0, all other dependencies will have to be discussed.
CSS and graphics can either be inline or external.
The class should be well written in terms of legibility and code style. Other programmers will probably have to make adjustments as time goes by. The coding for each data 'field' should therefore be kept relatively modular as well - via additional classes if necessary.
These things given no documentation will be required.
See the attachment for a very rough visual draft.
We are happy to send code and documentation to our existing solution if you consider it helpful.