Here are the accompanying text files individually, for easy printing or
viewing, if you don't want to scroll down this long page.
README.txt
- brief info about CalendarX.
OVERVIEW.txt
- longer description of CalendarX.
LICENSE.txt
- brief description of GPL licensing for CalendarX.
TODO.txt
- next on the list for changes to CalendarX.
CUSTOM.txt
- how to customize CalendarX.
MIGRATE.txt
- how to migrate/upgrade from earlier versions of CalendarX.
CX_props_addeventlink_text.txt
- Add Event Link properties descriptions and howto tips.
CX_props_calendar_text.txt
- Main Calendar properties descriptions and howto tips.
CX_props_css_text.txt
- Configurable CSS properties descriptions and howto tips.
CX_props_custom_text.txt
- Brief description of using CX_props_custom to add your own properties to CalendarX.
CX_props_popup_text.txt
- Rollover popup text properties descriptions and howto tips.
CX_props_subcalendar_text.txt
- Subcalendar configuration properties descriptions and howto tips.
CX_props_eventdisplays_text.txt
- How to display Event Icons and CSS classes according to Event Subject.
HISTORY.txt
- history of code changes in CalendarX.
INSTALL.txt
- how to install CalendarX in your Plone site.
CREDITS.txt
- people, products and organizations who have helped shape CalendarX.
VERSIONS.txt
- a numbering convention for CalendarX software releases.
From the current README.txt:
README.txt
CalendarX 0.6.6(stable) January 03 2006
(last modified for CalendarX 0.6.6)
by +lupa+ (lupaz on sf.net, lupa at zurven dot com)
Released under the GPL (see LICENSE.txt)
Release Summary: 0.6.6(stable) is a stable release for the i18n branch
of CalendarX. The release candidate has proven quite stable and very
few bugs have been found. Those are now fixed, and the documentation
has been updated, and this should be the last release of the 0.6 branch,
unless new bugs are found. No new translations have been added.
More translations! Make calendarx-XX.po files for us! If you can
translate, please do so and add your translation to the CalendarX project.
It's easy, follow the directions in the INSTALL.txt file in /docs.
CalendarX is a customizable, open source metacalendar application written
for the Plone content management system on top of Zope and Python.
Read the INSTALL.txt document for details, but in essence, put the CalendarX
folder in your /Products folder, restart Zope, use the portal_quickinstaller
to add CalendarX. Then add a CalendarX instance through Plone using the
normal methods.
CUSTOMIZATION: Customize property sheets or other objects found in the
/portal_skins/CalendarX folder. Use ZMI to move these into your CalendarX
instances (from the /custom folder) to restrict the customization to that
one CalendarX instance. This allows creation of multiple CalendarX instances
and also subcalendars (use ZMI to add new subcalendars within a main calendar
instance).
There is fairly extensive new documentation in the /docs folder, including a
new Manual for CalendarX in PDF format. Please read these for help in
figuring out all the configuration. CalendarX has lots of options, and
reading the docs helps a lot.
Read more at these sites:
http://calendarx.sourceforge.net
http://sourceforge.net/projects/calendarx/
http://calendarx.org
From the current OVERVIEW.txt:
OVERVIEW.txt
CalendarX 0.6.6(stable) January 03 2006
(last modified for CalendarX 0.6.5)
by +lupa+ (lupaz on sf.net, lupa at zurven dot com)
Released under the GPL (see LICENSE.txt)
Pretty current summary of CalendarX functionality
Basic Feature list (0.6 branch):
* i18n: English, French, German, Italian, Japanese, Dutch, Danish, Czech,
Spanish, Catalan and Portuguese-Brazilian are the first translations,
others to follow as contributed.
* Calendar views validate as proper XHTML 1.0 Transitional (at w3c.org).
* Provides basic calendar functionality with standard Plone content (CMFEvents,
AT Events, custom AT events when registered in CalendarX property sheets).
* Multimonth, Month, Week by day, Week by hour, Day views available.
* Metacalendar: Categorize your Events using the Subject attribute standard on
all Plone/CMF events. Choose categories in a bar just below the View tabs.
Change subjects in portal_metadata tool. Choose between ONE subject at a
time, or MULTIPLE subjects at one time.
* Many configuration options available through use of property sheets, including
decoration of the calendar, decoration of events by Subject or Type, putting
restrictions on the type, location or subject of events shown, etc.
* Day and WeekByHour views can be easily managed to display fractional days:
from 8am to 6pm, for example. Hours displayed on these can be set to
12 or 24 hour formats. Hours or half-hour periods can be displayed.
* Late events (after midnight) can be shown on the "later events" portion of
the day and weekbyhour views, or shown as early events on those views,
being configured with a simple property to set the hour that separates them.
These are NOT used with the other views, just day and weekbyhour views.
* Multiple calendars can be created within one Plone site. Customized property
sheets for each calendar can (should) be stored within each calendar so that
calendar properties will be unique. Also any python scripts, javascripts,
CSS files can be uniquely customized for any one calendar.
* Subcalendars - nested calendars and modifications to the Subject links
that allow busy calendars to be subdivided beyond just Subject usage. Good
for school calendars, Resource scheduling (equipment reservations), etc.
* Private calendars: All your users automatically have a private calendar, if
they so choose. They can just add Events and set them to "private" status,
and then only they can see them on their calendar.
* "Add New Event" link, with customizable destination folders depending on
user and/or Roles.
* Customize a "calendar help" page for your newbie users. Help appears as a
tab, if you choose to make it available, and is customizable.
* Installs as a normal Plone Product, addable as Plone content, but also may
be added through the ZMI.
* No Dependencies: Only needs Plone standard products. Will use Dieter's
ManagableIndex and AdvancedQuery products if desired. Or not.
* Prints nicely from most browsers (using a special CSS sheet for printing).
Planned features for future branches:
* Group calendar support through GRUF 3.0.
* Repeat events.
* i18n support
* iCal export and import. Does export now, sorta, if you use ATCT Events
(that functionality is built in to ATCT Events).
===
CalendarX builds on a proud tradition of other Zope/Plone products, and
gathers strength through the tremendous efforts of its users
(see CREDITS.txt).
===
From the current LICENSE.txt:
LICENSE.txt
CalendarX 0.6.6(stable) January 03 2006
(last modified for CalendarX 0.4.1)
by +lupa+ (lupaz on sf.net, lupa at zurven dot com)
Released under the GPL (see LICENSE.txt)
CalendarX builds from several programs and products with GPL licenses. It is
designed to run on the Plone CMS (also GPL), which in turn builds on the
Content Management Framework (CMF) and the ZOPE Application Server, which
are both released under the ZPL. Portions of CalendarX that are more
or less completely original are copyright 2004 by Lupa Zurven, and are
largely marked as such in the source code comments.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
From the current TODO.txt:
TODO.txt
CalendarX 0.6.6(stable) January 03 2006
(last modified for CalendarX 0.6.6)
by +lupa+ (lupaz on sf.net, lupa at zurven dot com)
Released under the GPL (see LICENSE.txt)
CalendarX by Lupa Zurven (lupa at zurven dot com)
A metacalendar for Plone.
This ToDo list refers to goals for the current branch, and is not a more
general ToDo wishlist for CalendarX in future branches. Go see the
CalendarX.org website for more complete wishlist ideas for the future
of CalendarX.
ToDo list as seen at launch for CalendarX 0.6.6(stable)
1. Done. Only bugfixes on this branch from this point on. And any more
translations that get submitted. And a Manual revisions too.
ToDo list as seen at launch for CalendarX 0.6.5(stable)
1. Done. Only bugfixes on this branch from this point on. And any more
translations that get submitted. And a Manual revisions too.
ToDo list as seen at launch for CalendarX 0.6.4(rc1)
1. Solicit more translations/localizations (.po files). Please add yours!
2. Done. Only bugfixes on this branch from this point on. And any more
translations that get submitted. And a new Manual too.
ToDo list as seen at launch for CalendarX 0.6.3(beta)
1. Solicit more translations/localizations (.po files). Please add yours!
2. Done. Only bugfixes on this branch from this point on. And any more
translations that get submitted. And a new Manual too.
ToDo list as seen at launch for CalendarX 0.6.2(alpha)
1. Fix the display bug in multimonth view (see HISTORY.txt).
2. Everything down below.
ToDo list as seen at launch for CalendarX 0.6.0(alpha)
1. Solicit more translations/localizations (.po files). Please add yours!
2. Hopefully no more i18n changes to templates, scripts, although I might
have missed some. Please look around for me!
3. Test more, cleanup some code cruft here or there, everywhere.
4. Extend the new Group calendaring aids added in 0.6.0 (anybody using these
yet?), and fixup the documentation for that.
5. More small feature additions as deemed useful and non-intrusive and
unlikely to cause heartbreak and/or instability.
6. That's all. This 0.6 branch is mostly just i18n on top of 0.4 branch
plus a few nice requested features.
7. Move i18n and new view features into the 0.5 branch as well as here.
From the current CUSTOM.txt:
CUSTOM.txt
CalendarX 0.6.6(stable) January 03 2006
(last modified for CalendarX 0.6.5)
by +lupa+ (lupaz on sf.net, lupa at zurven dot com)
Released under the GPL (see LICENSE.txt)
Notes on customizing CalendarX 0.4 branch. (also 0.6 branch)
I. Quick Overview.
II. Tips.
III. Future.
IV. Caveats.
I. Quick Overview of customizing CalendarX.
FIRST: Make sure you have followed ALL the instructions found in INSTALL.txt.
CalendarX puts the "ALL" in "INSTALL".(tm)
A. Go to portal_skins/CalendarX. Find one of the seven property sheets (named
CX_props_yadayada). Click on one of them to view it, and then click the
"Customize" button to move a copy of the property sheet into the /custom
folder. Now you can modify the properties (use the Properties tab!) and
start changing the calendar behavior. In brief:
CX_props_calendar: controls most basic calendar functionality, including
what types of events are shown, how the Subject bar is displayed, etc.
CX_props_css: provides many opportunities for changing the colors and
fonts displayed in the calendar.
CX_props_custom: does nothing. If you add new functionality to your
calendar and need properties, put them in here.
CX_props_popup: checkboxes to select which text is displayed in the
rollover text box associated with each event displayed in the calendar.
CX_props_addeventlink: If you wish to have an "Add New Event" link
displayed in the subject bar, configure the link here.
CX_props_subcalendar: If you have subcalendars beneath your main calendar,
you will need to configure them here.
CX_props_eventdisplays: allows you to use different icons and CSS classes
based on the Subject of each event.
Almost definitely, you will want to customize CX_props_calendar. It has many
basic options for the calendar.
TIP: In some Plone installs, I've run into the situation where the customized
property sheets were being ignored by the skins mechanism. Couldn't find any
good reason for it, even though they were located in the /portal_skins/custom
folder as usual.
SOLUTION: Cut and paste your customized property sheets into your CalendarX
instance folder, using the ZMI to do this. So if your calendar is named
"cal", in the ZMI this will be a folder... put the property sheets inside
there, and the Zope acquisition mechanism will pick them up without using
the skinning mechanism.
B. You can customize anything else in the /CalendarX folder. Page templates,
macros, CSS or Python scripts, or Javascript... anything you find there.
Usually this means clicking the "Customize" button which puts a copy of the
object in the /custom folder for you, where you can change things and
refresh your calendar to see the results. TIP: see tip in #A above.
C. To create more than one instance of CalendarX is easy... just add another
one from the dropdown list. However, all your calendars will use the same
properties from the /portal_skins/custom or /portal_skins/CalendarX folders.
To make each calendar different:
IN ZMI: CUT all the customized objects that you need from the
/portal_skins/custom folder, and PASTE them into your CalendarX folder.
Now your calendar can be customized locally and independently from any
other calendars. I like to use this approach anyway, even if I'm only
using ONE CalendarX instance in my Plone site, because it cleans up the
/custom folder for other uses.
D. If you want to use Subcalendars, move your customized objects out
of the /portal_skins/custom folder and put them directly into your
/calendar folder (using the ZMI). You will need a copy of
CX_props_subcalendar in each of your MAIN and SUBcalendar folders... and you
will very very likely need CX_props_calendar in each of them as well.
There's a detailed section later in the manual that provides an example of
using Subcalendars.
E. READ UP.
Also read everything you find in the /docs folder of the CalendarX product
distribution or in the Manual. And read the source code in the Python
scripts. We've added quite a bit of commentary to most of the Python
scripts to make it all much more understandable, and more readily
customizable.
II. Tips.
1. Slots/Portlets. For most users, we recommend disabling the slots on your
calendar folder, or more specifically, making the slots be empty. If you
want portlets appearing in the slots, click on the Properties tab of your
calendar folder in the ZMI. Add your portlets into left_slots and
right_slots attributes, just like you would in your main Plone site.
2. The calendar uses categories based on the default Event Subjects.
Currently these are Apppointment, Convention, Meeting, Work, Social Event.
You can change these in the portal_metadata/Elements/Subject. If you do
this, CalendarX needs to be told about it... this will be fixed in a
future version to be automatic. Actually, it is now semi-automatic. If
you want CalendarX to choose Subjects based on all the Subjects available,
see the instructions in CX_props_calendar_text.txt
So, find the CX_props_calendar sheet, and list the Subjects line by line
in the "listOfSubjects" attribute, just like you made them in
portal_metadata. And then you're done.
Actually, there's more. If you have used very LONG subject names,
like "French Connection United Kingdom", there is an option to create
shorter "nicknames" for each of your subjects, and show them at the top of
the calendar instead of the LONG names. For example, you could use
the much shorter "FCUK" instead of the long, full name of the Subject
used in the earlier example.
And now there's even more! You can make groupings of subjects, using the
nicknames approach. First, in the 'listOfSubjects' attribute, list your
subject groupings with commas like this:
Mrs Wilson 3rd Grade,Mr Smith 3rd Grade
Mrs Farber 4th Grade,Mrs Jasper 4th Grade
Mr Spinky 5th Grade,Mr Zurven 5th Grade
Field Hockey,Jump Rope,Basketball,Soccer,Chess Club
Then in the 'listOfSubjectTitles' attribute, put the nicknames in that
will be shown in the Subject Bar, like so:
3rd Grade
4th Grade
5th Grade
Sports
Now when a user clicks 'Sports', events from all the sports listed in the
corresponding listOfSubjects line will be returned in a calendar. This is
usually much preferred to listing all 11 Subjects in the Subject Bar of
CalendarX.
Also, this functionality makes subcalendar usage very powerful, as you
will see if you keep reading this drivel.
3. Basic: Access to your calendar for your visitors
First, publish your /calendar folder from within Plone so that it becomes
available on the portlet_navigation. Or not, if you don't want it to
show up there.
Second, another nice hook is to create a portal_tab to go to your new
calendar.
A. In the ZMI, go to portal actions.
B. Add a new action as follows:
Name: Calendar
Id: calendar
Action: string:${portal_url}/calendar
Condition: (empty or whatever)
Permission: View
Category: portal_tabs
Visible? (checked)
This will display your defaultView (whichever view you have selected in
the defaultView property in CX_props_calendar). Default is 'month'.
4. Multiple Calendars.
You can have multiple calendars on your site. Place another CalendarX
instance wherever you want the calendar to appear. Chances are that if you
have multiple calendars, each one will be configured differently. In that
case, simply customizing a property sheet won't be enough, because
portal_skins/custom can't have two different property sheets both
named the same thing. SO... go into the ZMI and cut any CalendarX
property sheets, scripts, icons or templates out of portal_skins/custom,
and paste them directly into your CalendarX folder instance. Now these
customized sheets will ONLY be found by the desired calendar instance, and
you can have as many
5. Restricting events on your calendars.
A common request is to restrict the types of events shown on a calendar.
There are now several ways to do this without customizing the calendar views
or macros, by using attributes in CX_props_calendar properties.
5a. Subject restrictions.
If you want to display ONLY events that contain certain subjects, you can
use the "restrictToThisListOfSubjects" attribute along with the
"listOfSubjects" attribute. Read the directions, and simply
list the Subjects that you wish to show. For example, this might be a way
to have a Music Events calendar on your site, with multiple types of Music
events, as well as an Arts Events calendar, with its own set of Arts
event categories.
5b. Event Type restrictions.
If you want to display ONLY events of a certain "portal_type", use the
"restrictToThisListOfTypes" attribute along with the "listOfTypes"
attribute. A "portal_type" is the type of Plone object that you are using
for your events. For example, you can go to portal_types in the root of
your Plone site, copy and paste the existing Event type, and modify it so
that its type is a "Staff Event". Then you can create a calendar that
will ONLY show Staff Events, just for Staff usage. A good idea is to add
a getNotAddableTypes.py script in your site that will restrict usage of the
"Staff Event" type to just members of your "Staff". See howtos on the
Plone.org website for more instructions on how to use getNotAddableTypes.
5c. Path restrictions.
If you want to display ONLY events that are found within certain folders
of your Plone site, you can use the "restrictToThisListOfPaths" attribute
along with the "listOfPaths" attribute. Read the directions, and simply
list the full paths (as found in the Path index in the portal_catalog)
for the folder objects you wish to use. Then ONLY those events found within
those folders will display on your calendar.
6. Look at all the calendar properties, and read about them in the /docs
folder. There are lots of things you can adjust, and they're all
documented. Try them and see what you like.
7. There's an attribute in calendar properties that lets 'visible' as well
as 'published' events show up on the calendar.
8. Nearly all the most important CSS attributes are now adjustable from
the CSS properties sheet. Font sizes are all expressed in percentages
so that they can vary the way the rest of Plone can, with simple stylesheet
changes.
9. "Add New Event" link: A new addition to 0.4 branch is the ability to put
a link in the Subject Bar that allows users to click on it and go to an
appropriate folder where they can add a new Event. There is a property
sheet that controls this behavior (i.e., where the link goes and who gets
to see the link at all). In brief, the macro controlling this link first
checks to see that the user is Authenticated on the site (few sites allow
un-Authenticated users to add Events, and those who do can easily disable
this in the macro code). The link then can be set to the following
possibilities:
A. Link to the Member's personal folder.
B. Link to a specified folder.
C. Link for certain users to go to different folders (one specified
folder per specified user).
D. Link for users with specific Roles to go to different folders (one
specified folder per specified Role).
E. Link to a specified subfolder within the Member's folder.
If choice C or D is selected, and the current users is not listed among
the possible choices (for listed users or Roles), then the link will roll
back to choice B or A, if either of these has been checked. If the user
is not found in C or D and neither B nor A has been checked, then the
"Add New Event" link will NOT be displayed for this user.
10. New Icons and CSS classes, selected by Event Subject. Now your calendar
can really show its colors by letting you highlight each event on your
calendar in color and with icons depending on the Subject. Simply
check the appropriate box and follow the examples, listing a single line
for each of your Subjects that tells it what icon to use. Add those icons
to your /custom folder, or /calendar instance folder, and your calendar
will take on a whole new look. Read the details in the
CX_props_eventdisplays.txt file in the /docs folder. Or just check the
box and try it with the icons included in the default settings.
You'll also need to add special CSS classes for your subjects. The
default ones are in calendar.css... look at them to see how to do it for
yourself. There are currently two classes for each subject: one class for
the link shown within the calendar proper, and one class for the Subject
bar up at the top of the calendar page.
Also: Icons and CSS by Event Type. Same as above, but works for the
specified Event types listed. Should come in handy for tricky subcalendars.
11. SPEED TIPS. CalendarX is a busy product, doing lots of queries and lookups
in order to display a full-featured calendar. Here are two speed tips to
make sure that CalendarX is running as fast as reasonable. The first one
is imperative, the second is definitely optional. Neither have been
rigorously benchmarked, but informal benchmarks give the first one a
potential speed up of as much as five-fold (in Plone 2.0; this whole
discussion is less critical for Plone 2.1.x). SO DO #1, if it's not
already done for you. It's quite painless.
Speed Tip #1: The skins of Plone create a performance hit to some extent.
This tip speed up the calendar by putting it near the top of the skins
list of layers. Moving it up from the bottom of the skin layers list
can increase speed severalfold. Go to portal_skins in your Plone
site, and click on the Properties tab. Then find CalendarX in the listing
for your plone skin (usually Plone Default or Plone Tableless) and move
CalendarX up to the second spot, right underneath "custom". That's it.
Now your calendar skin will be found very quickly.
Note: CalendarX tries to install up at the top below "custom" at
installation. So this is probably already done for you. But if you
install other products AFTER CalendarX, they may install ahead of
CalendarX in your skins. So you may need to go back and move CalendarX
up in the layers at some future time.
Speed Tip #2: Customize the query methods from /portal_skins/CalendarX
folder and move them locally to the location of the calendar instance
itself... no more skin-inefficiency, because they are found locally. This
should help, but I have no real benchmarks to prove it. In order to
really work, you should move virtually all the scripts and property sheets
to your CalendarX instance. This should definitely be faster than having
your scripts all in the skin layers hierarchy, but probably not much of a
boost over Speed Tip #1 and it is more work, so don't bother.
I'll keep looking for other tips and speed ups. I made some code changes
in 0.6 branch to speed up the page renderings over the 0.4 branch. The
0.5 branch already contains most of these changes. Also, Plone 2.1.x runs
CalendarX faster than Plone 2.0, without bothering with these tweaks...
these may help too, but do upgrade if you haven't already.
III. Future.
1. Tips on creating a custom view.
It is now easier than ever to make a custom view. Much of the convoluted
tal: code has been removed from the view page templates and converted to
python scripts. More to come, but in short: make your view, give it a
decent name, add some code for it among the various python scripts and in
the macros that show the tabs for the views. That's all ;-)
IV. Caveats.
We will release and archive all versions of CalendarX on Sourceforge, so that
the community should always have access to the version of CalendarX that your
skins were built for. Correspondingly, you should keep the version of
CalendarX that comes with your skins intact, or at least the numeric part
(i.e., 0.2.4), for future reference. If we get support for CalendarX
development in the future, we will likely develop scripting methods for
upgrading skins between releases, if that becomes necessary. For now, it
shouldn't take very long at all to upgrade any skins you create to
future releases in the same branch. A few minutes, actually, if you stick
mainly to using the new property sheets and macro sheets. Also, don't count
on any future releases (beyond the 0.2 branch) being compatible with
the earlier Plone 1.0. They probably won't be.
+lupa+
From the current MIGRATE.txt:
MIGRATE.txt
CalendarX 0.6.6(stable) January 03 2006
(last modified for CalendarX 0.6.6)
by +lupa+ (lupaz on sf.net, lupa at zurven dot com)
Released under the GPL (see LICENSE.txt)
Note: Not fully tested for Plone 2.1.1 and above.
I. Upgrading from 0.6 branch versions of CalendarX (updated 0.6.6)
II. Upgrading from 0.4 branch versions of CalendarX (updated 0.6.4)
I. Upgrading to 0.6.6 from 0.6 branch versions of CalendarX.
1. Replace the old version of CalendarX in your INSTANCE_HOME/Products
folder with the new version of CalendarX (0.6 or higher).
2. Restart Zope. DON'T JUST REFRESH IT, I don't think, because there are
probably changes in the i18n folder, and without Restarting Zope, these
changes won't be picked up properly. Or try it: ZMI, Control Panel,
Product Management, CalendarX, and in the Refresh tab, click Refresh. Or
in Plone (2.0+), go to Plone Setup, Add/Remove Products, and under
"Installed Products", look for CalendarX and click the link that says
"This product has been upgraded, click here to reinstall." BUT I THINK
YOU REALLY NEED TO RESTART ZOPE. Or you can try refreshing the ... no,
JUST RESTART ZOPE.
This is important! If you just refresh the CalendarX
product in your quickinstaller, you will NOT get the updated translation
files indexed properly. Alternatively, if you really don't want to
restart Zope, after refreshing the CalendarX product you must go in the
ZMI to Control Panel, Placeless Translation Service, and find the several
translation (po) files for CalendarX... then click on each one of them and
then click the Reindex button for it. See? I told you it was easier to
just restart your Zope!
3. Any parts of CalendarX that you have customized should be compared with
fresh versions (and the HISTORY.txt file) to see if there are changes
that you should be aware of in your customizations. If all you have
changed are the CX_props_XXX property sheets, then there is little chance
of any problems.
TIP: Just do it. Make a new instance of CalendarX, use all new property
sheets from the upgraded distribution. Go through each one to make sure
the values are set how you want them. Read the HISTORY.txt file to see if
there are any changes in this version that you need. Then it will work
as it should... best not to bring old property sheets from an older
CalendarX install, because these frequently change as development occurs.
4a. PARTICULAR FILES THAT HAVE CHANGED RECENTLY (0.6.6):
CX_props_css property sheet: there is a new property that must be present
in order for rollover highlighting to work properly in your calendar.
calendar.js: is now a DTML method, and reads in the values from the
CX_props_css property sheet. IF YOU HAVE changed the values of cell
colors in your old calendar.js file, copy those values to the new
CX_props_css property sheet and use the new calendar.js.
4b. PARTICULAR FILES THAT HAVE CHANGED RECENTLY (0.6.4):
CX_props_macros macros sheet: added a new macro prevnextcurrentlinks_nojump
that is called from the bottom of each view template so that no
JumpToDate widget is shown there, to avoid the IE browser bug that puts
rollover event windows behind that widget.
5. There is not currently, nor immediate plans to create, an automated upgrade
feature that will migrate your configurations to the new versions of the
property sheets, etc. This is because CalendarX is designed to allow easy
TTW access to all the scripts and templates for customization, and any one
CalendarX installation will be expected to have many customization choices
that an automated upgrade mechanism will not properly handle. Document the
changes you make so that you can more easily upgrade to newer versions
of CalendarX.
II. Upgrading to 0.6 from 0.4 branch versions of CalendarX.
1. Replace the old version of CalendarX in your INSTANCE_HOME/Products
folder with the new version of CalendarX (0.6 or higher).
2. Restart Zope. REALLY! Do it! See why above.
3. Get all new property sheets from the new CalendarX skins folder. They will
be similar to the old ones, but just do it anyway. Then go through them
and set the properties the way you want. CalendarX will likely break if
you just try to use your old (0.4) property sheets, so don't do it.
Any parts of CalendarX that you have customized should be compared with
fresh versions (and the HISTORY.txt file) to see if there are changes
that you should be aware of in your customizations. If all you have
changed are the CX_props_XXX property sheets, then there is little chance
of any problems.
4. There is not currently, nor immediate plans to create, an automated upgrade
feature that will migrate your configurations to the new versions of the
property sheets, etc. This is because CalendarX is designed to allow easy
TTW access to all the scripts and templates for customization, and any one
CalendarX installation will be expected to have many customization choices
that an automated upgrade mechanism will not properly handle. Document the
changes you make so that you can more easily upgrade to newer versions
of CalendarX.
From the current CX_props_addeventlink_text.txt:
CX_props_addeventlink_text.txt
CalendarX 0.6.6(stable) January 03 2006
(last modified for CalendarX 0.6.5)
by +lupa+ (lupaz on sf.net, lupa at zurven dot com)
Released under the GPL (see LICENSE.txt)
Instructions for properties in CX_props_addeventlink.
The "Add New Event" link is a means of making it easier for calendar users
to add new events to your calendar. It places a link in the SubjectLinks
bar that takes users to an appropriate place to add events. Because there
are many places/ways that Plone allows you to add events, we've provided
several options for how to control who gets what link. Your suggestions
(and code) for more options are gratefully accepted.
*WARNING* Misconfiguration of these options can cause error messages for your
users... and it's not my fault. Make sure that your calendar users have
the correct permissions to add events in the folders where you point them
using this link. Read all the directions. *YOU HAVE BEEN WARNED.*
=== List of Attributes ===
title string
Leave this title attribute alone.
showAddEventLink boolean
Check this to include an "Add New Event" link in the SubjectLinks bar.
Controls for this link are below. If more than one of the boolean
controls below are checked, the ones below will take priority over the ones
above. For example, if both useANEFolder and useRolesAndFolders are
checked, but the current user does not have one of the specified Roles,
then the link target will fall back to the specified ANEFolderPath. The
order of these priorities is determined by the code in the Python script
"getAddNewEventURL". If no match is found, then a blank string will be
returned to the macro, and a condition there will cause NO "Add New Event"
link to be shown. This way you can restrict display of this link to only
certain users or to users with certain roles. The first two choices
(useMemberFolder and useANEFolder) are shown to all Authenticated users, if
selected.
useCreateObjectOnClick boolean
createObjectOnClickCommand string
Together, these two properties tell the link to instantiate a new Event
object in the target folder. Check this if you want to have the link
automatically initiate editing of a new event for the user. Uncheck this
property if you want the Add New Event link to simply take the user to a
target folder without starting a new Event object automatically.
The createObjectOnClickCommand string is the command that is carried in
the query string of the link's URL target if you are using the
useCreateObjectOnClick property. The default string is:
createObject?type_name=Event
which will create a new Event object in the target folder of the link.
If you have a different event type that you would like to create, replace
the meta_name "Event" with the appropriate meta_name of your desired
event type.
If you use this feature, it is advisable to also set your portal to use the
portal_factory for initiating Events, so that if a user clicks on the link
to start a new event but then decides not to finish it, the event will not
be abandoned half-finished. Portal_factory will simply create a temporary
version and then delete it if left unfinished by the user.
useMemberFolder boolean
Check this so that the link will take users to their default Member folder
where they can add Events.
*WARNING* If your users do not have a default Member folder, or if it is
located somewhere funny (not in "mysite/Members/username") then this option
may cause an error for your users.
useMemberSubfolder boolean
memberSubfolderPath string
Check this property if you want events to be instantiated in a subfolder of
a user's Member folder. For example, if all your users are musicians in
bands (or groupies perhaps) and they post their band gigs on the calendar,
then you might want all the events to be saved in a specific subfolder, such
as "/Members/username/gigs". The proper format for the target folder is
relative to the /Members/username folder and should start with a slash, e.g.:
"/gigs"
NOTE: ONLY use this if you are certain that users WILL have the named
subfolder in their user folder. Otherwise it will return 404, page not
found error, or something closely related.
useANEFolder boolean
ANEFolderPath string
Together, these allow you to specify a single folder that will be the target
of the link. The proper format for the target folder is relative to the
portal_root and should start with a slash, e.g.:
"/somefolderintheroot/thefolderforevents"
useUsersAndFolders boolean
listOfUsersAndFolders lines
Together, these allow you to specify a combination of a username and a
corresponding single folder that will be the target of the link for that
specific user. The proper format for each line is as follows:
"username|folderpath"
where the "pipe" character (a vertical slash) is used as a separator between
the username and folder path. The proper format for the target folder is
relative to the portal_root and should start with a slash, e.g.:
"/somefolderintheroot/thefolderforevents"
An example with two possible role|folder lines:
lupa|/calendar/specialevents
davos|/calendar/drearyevents
If no matching username is found, the priority rules described above will
take over to find a suitable target for the user.
useRolesAndFolders boolean
listOfRolesAndFolders lines
Together, these allow you to specify a combination of a Role and a
corresponding single folder that will be the target of the link for all
users with that Role. The proper format for each line is as follows:
"rolename|folderpath"
where the "pipe" character (a vertical slash) is used as a separator between
the role name and folder path. The proper format for the target folder is
relative to the portal_root and should start with a slash, e.g.:
"/somefolderintheroot/thefolderforevents"
An example with two possible role|folder lines:
Manager|/calendar/specialevents
Member|/calendar/ordinaryevents
The lookup stops when a matching role is found for the user. For example,
if the Manager logs in, the link for the Manager will target the folder
called "specialevents", even though the Manager is also (likely) a Member
of the site. If no matching role is found, the priority rules described
above will take over to find a suitable target for the user.
From the current CX_props_calendar_text.txt:
CX_props_calendar_text.txt
CalendarX 0.6.6(stable) January 03 2006
(last modified for CalendarX 0.6.5)
by +lupa+ (lupaz on sf.net, lupa at zurven dot com)
Released under the GPL (see LICENSE.txt)
Instructions for properties in CX_props_calendar.
New attributes added in 0.6.x branch releases
showPrivateEventsToGroupMembers (0.6.0)
useHalfHours (0.6.2)
numMonthsForMultiMonthView (0.6.2)
earlyDayEventHour (0.6.4)
Use the Properties tab to adjust the attributes of the
calendar as available.
=== List of Attributes ===
title string
Leave this title attribute alone.
dayOfWeekToStart int
Value indicates what day of the week the Month and Week
views begin on. Sunday = 0, Monday = 1, etc.
defaultView string
Name of the default view to be displayed: month, weekbyday,
weekbyhour, or day.
useAdvancedQuery boolean
If checked, CalendarX will use the AdvancedQuery product
for making queries to the catalog to find events. Use
this if you want to override those query methods in your
skin folder. I find AdvancedQuery significantly easier
to use in building complex queries, but it offers no
other advantages for general use in CalendarX.
dayViewStartHour string
Hour of day for CalendarX to BEGIN display for day view and
for weekbyhour view. 8 = 8am = 08:00, 20 = 6pm = 20:00.
For a 24 hour calendar, set this to 0 (zero).
dayViewEndHour string
Hour of day for CalendarX to END display for day view and
for weekbyhour view. 8 = 8am = 08:00, 20 = 6pm = 20:00.
Must be later than dayViewStartHour.
For a 24 hour calendar, set this to 24.
earlyDayEventHour string
Hour of day for CalendarX to use for deciding between events being
classed as "later" or "earlier" in the Day and Weekbyhour views.
Previous behavior was that events up to midnight showed as "later"
events and "earlier" events from midnight to dayViewStartHour showed
up as "continuing". This property is the hour that now serves as the
boundary between these types of events.
Default value is 0, representing 12 midnight, meaning there are no "later"
events.
Setting value to 3, will represent 3am. Seems a reasonable boundary to me,
meaning that events running 1am-2am will show up on the previous day, say
Saturday night instead of Sunday morning.
Use Case: Calendar of events for a city where there are commonly late
night movies or concerts after midnight... consider Las Vegas, for example.
Now you can set the boundary to be 3 or 4am, so that when viewing the Day
view for Friday, the later events as late as 3am on Saturday morning will
show up on the Friday view.
Limitations: ONLY applies to Day and WeekByHour views, not to other views.
Therefore this could create some confusion among viewers who see a late
night event on Saturday night on the Day view, but finding that same event
displayed on Sunday on the month view. A fully consistent fix is
for this situation is difficult, and I'm unwilling to program it at this
time. I tried, and hence the long delay between the 0.6.4 and 0.6.5
releases. Instead I'm leaving it at this for now.
hoursDisplay string
Code to tell the "hoursdisplay" macro how to display the
hours in your calendar views. Currently two possibilities
and they only affect the left column display of hours:
"12ampm" = 12 hour display, with am or pm. Ex. 6 pm
"24.00" = 24 hour display, with period. Ex. 20.00
useHalfHours boolean
If checked, CalendarX will display half-hour increments on the day and
weekbyhour views instead of the default one-hour increments. There
remains NO capability of starting the day on the half-hour... the
dayViewStartHour and dayViewEndHour settings must be integer hour values.
The default value is blank (false), meaning Hourly periods will be used.
There is a modest performance penalty associated with this option, use
at your discretion.
numMonthsForMultiMonthView string
How many months to display in the month view. Default value is 1, but may
be extended up to 12 months. Next buttons move forward by one month, not
by the number of months in the view. Querying time to generate several
months at once may be excessive if many events are to be shown.
A future TODO might be to allow the user a widget to select the number of
months on-the-fly. However, this will necessitate changes in managing the
URL querystring to accommodate this new parameter. At present, this
feature is left as an exercise for the gentle reader.
showHeaderTitleAndIcons boolean
If checked, CalendarX will display the calendar title and description and
email/print/favorites Action icons as it does for other Plone content.
showHighlightFullEvent boolean
If checked, CalendarX will show the full extent of Events on
the calendar, even without rolling over with the mouse.
Default is a blue color, can be changed in CSS property sheet.
NOTE! If you use this, you might also want to disable the
labelEventsOnlyAtStart property. Disabling labelEventsOnlyAtStart means
that the events in the Month view that span several days will show
labels for each of those days, instead of only on the first day of
the event.
showJumpToDateWidget boolean
If checked, a date-picking widget will show up at the top
and bottom of the calendar near the Next/Previous links.
This widget lets users pick a date and jump to it, instead
of using multiple Next, Next, Next click, or manually typing
the date into the URL querystring.
NOTE: this widget has been removed from the bottom of each of the views,
where it has been for many months, in order to avoid a viewing Bug in
IE6. It can be returned by changing the macro call at the bottom of
each of the view templates from "prevnextcurrentlinks_nojump" to the
previous "prevnextcurrentlinks" macro.
useNumericMonthInJumpToDateWidget boolean
If checked, the Jump-To-Date widget will show a numeric month value (ex. "2")
instead of an abbreviation of the month (ex. "Feb"). These abbreviations
are pulled from the python DateTime module, not coded into CalendarX code,
in the getMonthName.py script.
showPublicPrivateLink boolean
If checked, the *Public* vs *My Events* link will be shown in
the Subject Bar. This link allows users to switch between
viewing all the published events, or ONLY their own private
events. If your calendar is mainly for viewing by anonymous
users, you probably don't need this. Default is OFF because
this is a nice feature, but not a commonly chosen one.
useMultiSubjects boolean
If checked, the Subject category picker is a checkbox-style
form, allowing users to select multiple subjects for viewing.
If unchecked, it switches to (an older) single subject chooser
that only allows one Subject category at a time. Default is ON
for this new-style Multi-Subject chooser, because it is ever
so much nicer.
showSubjectBar boolean
If checked, the Subject bar is shown, and if unchecked, it will
disappear from view. Default is ON. Decomplicates the calendar
if you don't want to use Public/Private or Subject categories.
useCalendarHelp boolean
Check this attribute to show a View tab for "Calendar Help". This brings
up a new view page that is intended for you to use for help in case you
have neophyte users who could use some calendar help. I've added some
code that brings up one page of help for "Members" and a different page
of help for "Anonymous" users. This could easily be extended to show
different help screens for other Roles. See the "help" view page
template for more information. The help text is quite minimal, so feel
free to expand it for your users. Feel free to send me a copy of your
nice help files, too!
includeReviewStateVisible boolean
Check this attribute to include events where the review state is
'visible' as well as 'published'. This is useful for calendars where
the only users are trusted users and going through the publishing
workflow only adds unnecessary complication.
In particular, this could work well even on a site with many
untrusted users. In that case, create a calendar for the trusted
users that uses a repurposed Event with a new portal_type name.
Use the 'restrictToThisListOfTypes' attribute to make this new
calendar ONLY read this one type of Event. Then use a
getNotAddableTypes.py script to restrict the use of this type of
Event to your trusted users (as a role, or a group, or whatever).
See the HowTo on plone.org for use of getNotAddableTypes.
showPendingLink boolean
Check this attribute to show a link in the subjectbar that, when clicked,
tells the calendar to display events with "pending" state as well as the
other events (published, and visible if includeReviewStateVisible has been
selected). The link is not a toggle; to get out of the mode where the
pending events are showing, simply click any other link on the calendar.
This link ONLY shows up for Calendar Managers. Who is a Calendar Manager?
User status as a Calendar Manager is determined by the isCalendarManager.py
script. It is easily customized, but as a default is set to allow users
with the "Manager" role. If this role is adequate for you, leave this
script as is. An example is included in the script to show how to look up
group membership to determine Calendar Manager status.
showPrivateEventsToGroupMembers boolean
Check this attribute to allow PRIVATE events to show up to anyone with the
Plone privilege of viewing your PRIVATE events. In short, what this does
is allow you to give one of your Groups or some other user a proxy
ownership role for one of your review_status=Private events. That is
enough to allow them to see it in Plone. But this attribute must be
TRUE (checked) if you want such events to show up on a CalendarX
instance.
For a fuller explanation, what this does is change the standard query
to allow searching for review_state "private" events as well as
"published" and "visible" (if includeReviewStateVisible is checked).
But they will ONLY be shown for those users (or group members) where
they have expressly been given the right to do so, usually via use of
the Sharing tab on the event. So to use this, we recommend the
following:
1. Use a recent version of GRUF (GroupUserFolder) in your Plone (version
3.0 or higher, not the 2.x that comes with Plone 2.0.x).
2. Make a group and enter your event in the group folder (usually something
like /groups/mygroup/myevent.
3. Make the event a "private" event (instead of submitting it for review
for publishing.
4. Use the sharing tab, and give the group proxy ownership of the event.
Now, with the use of this attribute, your group members can have a calendar
that shows group-only events.
showOnlyEventsInMonth boolean
Check this attribute to restrict the Month view to display events ONLY in
the current calendar month, and NOT those events that occur in the days
before or after the month begins and ends (ie., if the month view shows the
30th and 31st of the previous month on the calendar, events will NOT be
displayed for those dates.
labelEventsOnlyAtStart boolean
Check this attribute to put labels on the month view ONLY on the first day
of an event that lasts multiple days. Default is SELECTED. Unselect this
attribute if you'd like the event title and datestring to appear on each
calendar day that the event is on (ie., a four day event will have the label
show up on the calendar four times, on each of the four days of the event).
NOTE! Disabling this (to show events on EVERY day) will only work if the
showHighlightFullEvent property is turned ON (selected). It would make no
sense (to me) to have the event labeled, but not highlighted. So make sure
you use these together. No harm if you don't, but it won't behave the way
you might have expected. It pays to read the documentation.
listOfSubjects lines
restrictToThisListOfSubjects boolean
Together, these two attributes allow you to control the choice
of what categories of events to display on your calendar.
List of the Subjects in your CalendarX, for use in
creating the macro that displays them on your calendar.
1. LEAVE "listOfSubjects" BLANK, if you want to just use the
list of Subjects that is available from already created Events
your Plone site.
2. LIST SUBJECTS ONE PER LINE, exactly as they are present
in your portal_metadata, in the order you want them
displayed. The default values included here are the default
values that come with CMF Event and AT Event types.
If "restrictToThisListOfSubjects" is checked, a query for "ALL"
subjects is restricted to the Subjects in your listOfSubjects
attribute.
If unchecked, "ALL" will return all events found, regardless
of their Subject.
Use of this feature allows you to segregate certain events
pertaining to certain Subjects to unique calendarx instances.
This also means that if checked, the calendar WILL NOT pick up
events that do not have a Subject selected.
ADVANCED FEATURE: Each line in the listOfSubjects can also be a
Comma-Separated-Values list (CSV) where each line becomes a list
of subjects for viewing. This becomes very useful in the case
where you have many Subjects, but would like to combine several of
them at a time and use a Nickname (or abbreviation, or acronym)
to show up in the Subject menu.
For example: In a calendar for a school with five grade levels, and
four classes of children in each grade level, you could try something
like this in your listOfSubjects:
Class1a,Class1b,Class1c,Class1d
Class2a,Class2b,Class2c,Class2d
Class3a,Class3b,Class3c,Class3d
Class4a,Class4b,Class4c,Class4d
Class5a,Class5b,Class5c,Class5d
and then use this in the listOfSubjectTitles below:
Class 1
Class 2
Class 3
Class 4
Class 5
In this way, your subject menu is less cluttered, but it is easy for your
users to check one of these to filter and see only the events for children
of Class 1 age. You may also want to use SubCalendars with this, so that
users can drill all the way down and see ONLY events associated with
Class1c, Class4b, etc.
eventTypes list
restrictToThisListOfTypes boolean
Together, these two allow you to restrict what types of content objects
will be picked up on your calendar. Put one portal_type per line in
the eventTypes attribute, and check "restrictToThisListOfTypes" if
you wish this feature to be activated. If unchecked, no check is done
on the Type index, regardless of the content of the eventTypes attribute.
Usage: For example, this feature means you can create a new
Event type for certain users, and then use getNotAddableTypes.py to
restrict which users can add those special Event types, which gives even
more control over different calendar instances in your Plone site.
This is very useful in subcalendars, where each subcalendar may have a
different event Type.
listOfPaths list
restrictToThisListOfPaths boolean
Together, these two allow you to restrict where (the paths) to event
content objects that will be picked up on your calendar. This means
you can restrict viewing to Events found in certain folders. To use this
feature, use a full path exactly as found in your path index. An example:
/clients/companyplonesite/Members/fred
/clients/companyplonesite/staff
These two paths represent folders where Events can be stored that will
show up on the calendar, if restrictToThisListOfPaths is checked. ONLY
those events in these two paths will be found. Events in fred's personal
folder and events in the staff folder, and any folders deeper than that
will be picked up for display on this calendar. For example, if there is
a meetings folder inside the staff folder, events inside that folder will
also be displayed. If you are having any trouble with this property,
please go to the portal_catalog, click on the Catalog tab, and find one
of the events that *should* show up on the calendar. Look near the bottom
of the page to see what path is being indexed by the "path" index, and use
that as the path to the folder that you will use in listOfPaths.
restrictToThisFolder boolean
This property restricts the calendar so that events are ONLY shown if they
are found within or beneath the parent folder of the CalendarX instance.
Example: add a CalendarX instance as /Members/lupa/cal. If you set this
property to true, then only events found within /Members/lupa and any
subfolders therein will be shown on this calendar instance.
This could also be accomplished manually with the restrictToThisListOfPaths
property, but this property helps in the special case where you want to
allow your users to create a private calendar for their own area. In
that case, you should probably set this property to "1" in the property
sheet on the filesystem, so that all calendars created by your users will
have this property by default.
ADVANCED NOTE: as currently implemented, the restrictToThisFolder option
trumps (overrides) the similar restrictToThisListOfPaths property. In
other words, in the four query scripts, the restrictToThisListOfPaths
property is evaluated first, and if restrictToThisFolder is also selected,
the second one (restrictToThisFolder) takes precedence and overrides the
first property. To change this precedence, simply go into these query
scripts and rearrange the two-line calls for each one so that their order
is reversed.
listOfSubjectTitles list
useSubjectTitles boolean
Together, these two attributes allow you to use sensible (e.g., shorter)
titles on the Subject Bar for your Subject categories. If your Subject
category names are long, three or four subjects can produce an unwieldy
list for your users to select from. Instead, use these attributes to
include a list of shorter titles for each of your Subjects.
*IMPORTANT* Be sure to use this feature in conjunction with the
"listOfSubjects" attribute above. Be certain that both lists have the
exact same number of entries, so that there is a single corresponding
SubjectTitle for each Subject. If these do not match, the calendar may
show an error. Simply test your calendar after any changes to this
attribute to be certain that your calendar is working without error.
From the current CX_props_css_text.txt:
CX_props_css_text.txt
CalendarX 0.6.6(stable) January 03 2006
(last modified for CalendarX 0.6.6)
by +lupa+ (lupaz on sf.net, lupa at zurven dot com)
Released under the GPL (see LICENSE.txt)
Instructions for properties in CX_props_css.
Use the Properties tab to adjust the colors and fonts and
such throughout the calendar.css and other CSS files.
Default values (include below) are set to nearly match those of a
stock Plone 2.0.x install. Or if not match, at least nicely
complement. It isn't perfect, but overall things work OOTB.
The font sizes are all in percentages instead of fixed sizes,
so that the calendar fonts can resize with the rest of the Plone
site if the small Normal LARGE style-sheet widget is used.
These properties have NOT been adjusted at all for Plone 2.1. There has been
one small change in the calendar.css code, to add an explicit definition for
text-decoration to the tag. If you find any problems related to
Plone 2.1 and this CSS, please email Lupa and we'll chat.
Also added a new property (calTableDataEventHighlightBackgroundColor)
in 0.6.6 and hooked several others up to be read by
the calendar.js.dtml file for mouseover highlighting bugfix.
=== List of Attributes ===
title string
Don't mess with this title. Leave it alone. [actually, I don't care.]
**** Section 1: ****
VIEW: These attributes control aspects of the "view" tabs,
(month, week, day, etc. view template names) right at the top
where you choose which view of the calendar is showing.
viewTabsBorderColor default = #8cacbb
View tabs border color.
viewTabsBackgroundColor default = #dee7ec
View tabs background color.
viewFontBaseSize default = 95%
View tabs font size.
viewFontFamily default = "Lucida Grande", Verdana, Lucida, Helvetica, Arial, sans-serif
View tabs font family.
viewTabsFontColor default = #436976
View tabs font color.
**** Section 2: ****
Subject Bar: These attributes control aspects of the subject bar,
where the Private/Public and MetaCalendar Subject choices are
found.
subjectBarBorderColor default = #8cacbb
Color of the border around the subject bar, set in
calendar.css. Also goes around the My:Public choices.
subjectBarBackgroundColor default = #dee7ec
Color of the background for subject bar and My:Public bar.
subjectFontFamily default = "Lucida Grande", Verdana, Lucida, Helvetica, Arial, sans-serif
Font family for the subject bar and My:Public bar.
subjectFontSize default = 97%
Font size for the subject bar and My:Public bar.
subjectBarFontColor default = #436976
Font Color for the for subject bar and My:Public bar.
**** Section 3: ****
Header: These attributes control aspects of the header area,
where the previous and next date arrows, and the calendar date
are displayed, at the bottom and top of the calendar. Code for
this is generated in the "prevnextcurrentlinks" macro.
headerCenterFontSize default = 135%
"July 2004" header font size.
headerSideFontSize default = 93%
"previous" and "next" links font size.
headerFontFamily default = Verdana, Helvetica, Arial, sans-serif
Font Family name for "prevnextcurrentlinks" macro (prev, next, date header, footer)
headerFontColor default = #436976
Color of the font for header.
headerHeight default = 0px (formerly 35px)
Height added to base for "prevnextcurrentlinks" macro (prev, next, date header, footer)
headerMarginBottom default = 0px (formerly 15px)
Bottom margin pixels for "prevnextcurrentlinks" macro (prev, next, date header, footer)
headerMarginTop default = 0px (formerly 5px)
Top margin pixels for "prevnextcurrentlinks" macro (prev, next, date header, footer)
headerPadding default = 3px
Padding size for "prevnextcurrentlinks" macro (prev, next, date header, footer)
**** Section 4: ****
Continuing: These attributes control aspects of the Continuing
Events section, where events that start before or extend across
the entire period of view are shown.
continuingHeaderFontSize default = 90%
Continuing events box, header font size
continuingHeaderFontFamily default = Verdana, Helvetica, Arial, sans-serif
Continuing events box, header font family
continuingOuterBorderColor default = #B3CFD9
Continuing events box, outer border color
continuingOuterBorderWidth default = 1px
Continuing events box, outer border width
continuingHeaderBorderColor default = #436976
Continuing events box, inner border color
continuingHeaderBorderWidth default = 1px
Continuing events box, border width
continuingHeaderBackgroundColor default = #8CACBB
Continuing events box, background color
continuingRowEventBackgroundColor default = #DEE7EC
Continuing events box, color if an event is present
continuingRowNoEventBackgroundColor default = #F7F9FA
Continuing events box, color if no event
continuingRowHeight default = 5px
Continuing events box, row height, added to event bottom
**** Section 5: ****
Cal: These attributes control aspects of the Main Calendar display.
***CONTROL OF THE MAIN CALENDAR
calBorderColor default = #B3CFD9
Main calendar, border color
calBorderWidth default = 1px
Main calendar, border width
***CONTROL OF THE TR TAGS
calTableRowOddBackgroundColor default = #F7F9FA
Main calendar, for certain views where odd/even vary in color,
this controls the ODD row (in TR tags).
calTableRowEvenBackgroundColor default = #DEE7EC
Main calendar, for certain views where odd/even vary in color,
this controls the EVEN row (in TR tags).
***CONTROL OF THE TH TAGS
calTableHeaderBackgroundColor default = #8CACBB
Main calendar, TH tags background color.
calTableHeaderBorderColor default = #436976
Main calendar, TH tags border color.
calTableHeaderBorderWidth default = 1px
Main calendar, TH tags border width.
calTableHeaderFontColor default = #FFFFFF
Main calendar, TH tags font color.
***CONTROL OF THE EVENT FONTS
calEventFontSize default = 85%
Main calendar, TH tags font size.
calEventFontFamily default = Verdana, Helvetica, Arial, sans-serif
Main calendar, font family for the event listings.
calEventPendingTextColor default = #436976
Main calendar, text color for the pending event listings.
calEventPrivateTextColor default = #821513
Main calendar, text color for the private event listings.
calEventPublishedTextColor default = #466A06
Main calendar, text color for the published event listings.
calEventVisibleTextColor default = #436976
Main calendar, text color for the visible event listings.
***CONTROL OF THE TD TAGS (daily cells in the month view, etc)
calTableDataFontColor default = #000000
Main calendar, TD tag text color, but I don't know if it
actually controls anything at this time.
calTableDataBorderColor default = #DEE7EC
Main calendar, TD tag border color.
calTableDataBorderWidth default = 1px
Main calendar, TD tag border width.
calTableDataNoEventBackgroundColor default = #F7F9FA
Main calendar, color when a cell has NO EVENT.
calTableDataEventBackgroundColor default = #DEE7EC
Main calendar, color when a cell has an EVENT. Also used in
calendar.js.dtml for rollover highlighting return value.
calTableDataOutOfMonthBackgroundColor default = #FFFFFF
Main calendar, in the MONTH view when the day shown is NOT
a part of the month, this controls the background color. Also used in
calendar.js.dtml for rollover highlighting return value.
calTableDataOutOfMonthBorderColor default = #F7F9FA
Main calendar, in the MONTH view when the day shown is NOT
a part of the month, this controls the border color.
calTableDataOutOfMonthBorderWidth default = 1px
Main calendar, in the MONTH view when the day shown is NOT
a part of the month, this controls the border width.
calTableDataSpanDayFontColor default = #000000
Main calendar, in the MONTH view, text color of the date
(ie., "3" on June 3 cell).
calTableDataHeightMonthView default = 105px
Main calendar, in the MONTH view, this controls the empty
height of a daily cell.
calTableDataHeightDayView default = 35px
Main calendar, in the DAY view, this controls the empty
height of a daily cell.
calTableDataHeightWeekbydayView default = 105px
Main calendar, in the WEEKBYDAY view, this controls the empty
height of a daily cell.
calTableDataHeightWeekbyhourView default = 30px
Main calendar, in the WEEKBYHOUR view, this controls the empty
height of a daily cell.
calTableDataFontSizeHour default = 130%
Main calendar, in the DAY and WEEKBYHOUR views, this controls
the font size of the HOUR displayed (ie., "8am" or "13:00")
calTableDataEventHighlightBackgroundColor default = #FFE7C4
Main calendar, in the view when an event has a mouseover (rollover) event,
this controls the rollover background color. Read into
calendar.js.dtml for this control.
From the current CX_props_custom_text.txt:
CX_props_custom_text.txt
CalendarX 0.6.6(stable) January 03 2006
(last modified for CalendarX 0.6.1)
by +lupa+ (lupaz on sf.net, lupa at zurven dot com)
Released under the GPL (see LICENSE.txt)
Instructions for properties in CX_props_custom.
Use the Properties tab to add new properties here for use in your CalendarX
instances.
=== List of Attributes ===
title string
Don't mess with this title. Leave it alone. [actually, I don't care.]
[that's all. add new ones below. instructions for how to configure
new properties are in the bottom of the CX_props_custom.props file.]
From the current CX_props_popup_text.txt:
CX_props_popup_text.txt
CalendarX 0.6.6(stable) January 03 2006
(last modified for CalendarX 0.6.1)
by +lupa+ (lupaz on sf.net, lupa at zurven dot com)
Released under the GPL (see LICENSE.txt)
Instructions for properties in CX_props_popup.
Use the Properties tab to adjust the attributes of the
rollover PopUp text that displays when you rollover each
event displayed on the calendar. Just check off the ones
that you want to show up. There's a howto on the CalendarX.org
website that explains how you can add other attributes as well.
Technical Note: These values represent the metadata that are stored in
the portal_catalog for each event. If you want to display other
information about the event that is NOT in the metadata, you can
read the howto on the CalendarX.org website that explains how
you can add other attributes as well.
=== List of Attributes ===
title string
Leave this title attribute alone.
showPOPTitle boolean Checked = Show this info.
Whether to show the "Title" of the event.
showPOPType boolean Checked = Show this info.
Whether to show the "Type" string, telling what type of
event object is showing up in the calendar.
showPOPSubject boolean Checked = Show this info.
Whether to show the "Subject" of the event. Currently
implemented to show only the first Subject, not multiple
events in the case that some of your events have multiple
Subjects chosen. Subjects are separated by a comma and
a space, so that they wrap nicely if you have a long list
of subjects.
showPOPStart boolean Checked = Show this info.
Whether to show the "Start" date and time of the event.
showPOPEnd boolean Checked = Show this info.
Whether to show the "End" date and time of the event.
showPOPCreator boolean Checked = Show this info.
Whether to show the "Creator" (Plone username) for
this event.
showPOPCreated boolean Checked = Show this info.
Whether to show the "Created" date of the event.
showPOPModified boolean Checked = Show this info.
Whether to show the "Modified" date of the event, when
the last time this event was edited.
showPOPState boolean Checked = Show this info.
Whether to show the review "State" of the event, such as
published, visible, etc.
showPOPDescription boolean Checked = Show this info.
Whether to show the "Description" of the event.
From the current CX_props_subcalendar_text.txt:
CX_props_subcalendar_text.txt
CalendarX 0.6.6(stable) January 03 2006
(last modified for CalendarX 0.6.5)
by +lupa+ (lupaz on sf.net, lupa at zurven dot com)
Released under the GPL (see LICENSE.txt)
NOTE: These instructions are greatly supplemented by Part V in this
Manual, a Use Case describing subcalendar use for a Resource Scheduler.
Even if you don't want a resource scheduler, I'd advise you to read it
and/or try it out if you want to use CalendarX subcalendars.
NOTE: Plone 2.1.1 has a bug that affects the use of CalendarX Resource
Scheduler. Read about it (and the patch) in INSTALL.txt.
Instructions for properties in CX_props_subcalendar.
Subcalendars allow for interesting possibilities for special calendars,
especially very busy ones. A subcalendar is a folder inside (nested) in
a Main calendar folder. I have only tried a single level of nesting (one
main calendar with multiple subcalendars), and these controls focus on
menu behavior reflecting that use case.
The properties in this sheet control the basic behavior of subcalendars.
The first two properties are used by the main calendar, and the
second two are used by subcalendars. These properties have been developed
with a Resource Scheduling calendar application in mind, but other
possibilities are certainly possible. Your suggestions (and code) for
more options are gratefully accepted.
ALSO: You will need to carefully consider what properties to use in your
CX_props_calendar property sheets for both the MAIN and SUB calendars.
Examine the Resource Scheduling calendar example provided in order to see
what some of the possibilities are.
FINALLY: Read the "Manual for CalendarX" document. We provide a CASE STUDY
of the use of Subcalendars to create a RESOURCE SCHEDULING calendar. It
will help you more fully grok subcalendars and their usefulness.
=== List of Attributes ===
title string
Leave this title attribute alone.
useSubCalendarSubjectMenu boolean
For MAIN Calendars: Check this property to signal that (1) there are
subcalendars below and (2) hence, use the special Subcalendar Menu for
the Subject Links that allows you to both (either) filter on the
subcalendars as well as click on the Subject (subcalendar name) to drill
down and view that subcalendar alone.
listOfSubCalendars lines
For MAIN Calendars: This is a list (one per line) of the names of the
subcalendars. The menu choices uses this list for display of links to the
subcalendars.
isSubCalendar boolean
For SUB Calendars: Check this property if this calendar folder is a
subcalendar. This controls the style of menu displayed for subcalendars
versus non-subcalendars.
nameOfSubCalendar string
For SUB Calendars: The name of this subcalendar. This is displayed in the
Subject Links area.
=== CASE STUDY: A RESOURCE SCHEDULING CALENDAR ===
[moved to "Manual for CalendarX" document as of v0.6.5)
From the current CX_props_eventdisplays_text.txt:
CX_props_eventdisplays_text.txt
CalendarX 0.6.6(stable) January 03 2006
(last modified for CalendarX 0.6.1)
by +lupa+ (lupaz on sf.net, lupa at zurven dot com)
Released under the GPL (see LICENSE.txt)
Instructions for properties in CX_props_eventdisplays.
Use the Properties tab to adjust the attributes of the Event as displayed
on the calendar views. These properties control the icons available for
display and also the CSS classes. You can choose to control icons and
CSS classes according to the Subject of the Event, or according to the
Type of the Event.
=== List of Attributes ===
title string
Leave this title attribute alone.
useSubjectIcons boolean
listOfSubjectIcons lines
If checked, this will cause the views to choose an icon for each event
based on the Subject names found in the list. The list consists of a lines
attribute where each line consists of a Subject and an icon ID, separated
by a pipe ( | ) character. For example:
Work|event_work_icon.gif where Work is the subject.
Your subject names should (must!) match the actual subjects you use for
your events, or this method will not work well. Actually, it will just
pull the default event_icon.gif from the Plone skin if there is any
problem finding a matching subject name or icon ID.
This property is handy for making your events more visibly recognizable in
your calendar page. The default icon size is 16x16 pixels, with some
white (or clear) pixel space on the right and left sides. I haven't tested
it with larger icons, but keeping to a modest size might be a good idea.
Add your event icons into your /portal_skins/custom folder, or put them
directly into your calendar instance folder for (slightly) better
performance.
useSubjectCSSClasses boolean
listOfSubjectCSSClasses lines
If checked, this will cause the views to choose a CSS class for each event
based on the Subject names found in the list. The list consists of a lines
attribute where each line consists of a Subject and a CSS class name,
separated by a pipe ( | ) character. For example:
US Holiday|event_usholiday where Work is the subject, and
event_usholiday is the CSS class name.
Your subject names should (must!) match the actual subjects you use for
your events, or this method will not work well. Actually, it will just
pull the default event_published CSS class from the Plone skin if there is
any problem finding a matching subject name or icon ID.
This nicely allows you to apply styles like font color to your event
listings according to the Subject of the event. Put your custom styles
into your calendar.css stylesheet, or into a customized version of the
ploneCustom.css stylesheet if you prefer (the sample ones I've created for
default use are found in calendar.css). An example of a CSS class listing
I used to use a blue text color for the "Appointment" event subject:
A.event_appointment {
COLOR: #0000CC;
TEXT-DECORATION: none;
}
A.event_appointment:hover {
COLOR: #0000FF;
TEXT-DECORATION: none;
}
Additionally, if you want the Subjects in the Subject listing at the top of
the calendar to reflect these same CSS classes, you have to add these too.
Example ones (for Appointment, etc.) are in calendar.css for you to
customize. They are in a SPAN tag and look like this:
TABLE.caltabs TD.barright2 SPAN.event_appointment {
COLOR: #0000CC;
TEXT-DECORATION: none;
}
*** ONE MORE NOTE about these. Make sure in your listOfSubjectCSSClasses
and listOfSubjectIcons lines properties that you use the actual SUBJECT
name and not any Subject nicknames you might use for display (as defined
in the listOfSubjectTitles property in CX_props_calendar. Those labels
won't work here, only the actual subject will work.
*** AND ONE MORE NOTE. The following two properties (useEventTypeIcons
and useEventTypeCSSClasses) take precedence over useSubjectTypeIcons
and useSubjectCSSClasses if, for unknown reasons, BOTH have been selected.
There's no real reason to select both... only one can work at a time,
and I chose to make the EventType ones take priority. Go figure.
useEventTypeIcons boolean
listOfEventTypeIcons lines
If checked, this will cause the views to choose an icon for each event
based on the Event Type (portal_type). The list consists of a lines
attribute where each line consists of an Event Type and an icon ID,
separated by a pipe ( | ) character. For example:
Event|event_icon.gif where Event is the portal_type.
useEventTypeCSSClasses boolean
listOfEventTypeCSSClasses lines
If checked, this will cause the views to choose a CSS class for each event
based on the Event Type (portal_type). The list consists of a lines
attribute where each line consists of a Subject and a CSS class name,
separated by a pipe ( | ) character. For example:
AT Event|atevent_class where AT Event is the portal_type, and
atevent_class is the CSS class name.
From the current HISTORY.txt:
HISTORY.txt
CalendarX 0.6.6(stable) January 03 2006
(last modified for CalendarX 0.6.6)
by +lupa+ (lupaz on sf.net, lupa at zurven dot com)
Released under the GPL (see LICENSE.txt)
CalendarX by Lupa Zurven (lupa at zurven dot com)
A metacalendar for Plone.
History:
v0.6.6(stable)
Code base: v0.6.5(stable)
Status: Stable release, no known bugs, tests as valid XHTML
Transitional 1.0 at w3c. Four small bugfixes from 0.6.5: (1) error using
restrictToThisListOfSubjects, (2) repeated event icons shown for some
events with multiple Subjects selected, (3) unnecessary span tags within
certain CSS spans in some views, and (4) CSS for rollover highlighting not
properly set in calendar.js. Bugfix #4 also required addition of one new
property in the CX_props_css and some changes to the calendar.js file so
that it reads properties for highlighting cells properly (see below).
mod: getEventsBetweenZC.py: changed q_xsub initialization to an empty
list ([]) instead of zero (0) to avoid error on restrictToThisListOfSubjects.
mod: getEventsBeforeZC.py: changed q_xsub initialization to an empty
list ([]) instead of zero (0) to avoid error on restrictToThisListOfSubjects.
mod: CX_props_macros.pt: Eventlister and MMEventlister macros: removed the
offensive tal:repeat="subject event/Subject" command that was in place for
useEventTypeIcons option. Bug caused multiple showing of the EventTypeIcon
if an event had multiple Subjects selected... which is only appropriate for
use with the useSubjectIcons property.
mod: CX_props_macros.pt: prevnextcurrentlinks: added tal:omit-tag="" to join
all the i18n components into the control of one class="center" span.
mod: weekbyday.pt: added tal:omit-tag="" to join all the i18n components
into the control of one class="day" span.
mod: weekbyhour.pt: added tal:omit-tag="" to join all the i18n components
into the control of one class="day" span.
mod: CX_props_css.props: added calTableDataEventHighlightBackgroundColor
property to allow changing the highlighted color of the table cell when
user mouseovers an event.
mod: calendar.js has been renamed calendar.065.js
new: calendar.js.dtml: this is the old calendar.js file, but converted to a
Filesystem DTML Method so that it can read in values from the CX_props_css
property sheet. In the skins, it still looks like it is named calendar.js
(and it is), but on the filesystem it is called calendar.js.dtml. This now
reads the following properties in from CX_props_css.props:
calTableDataEventHighlightBackgroundColor for rollover highlighting color
calTableDataNoEventBackgroundColor for empty calendar cells
calTableDataEventBackgroundColor for non-empty calendar cells
calTableDataOutOfMonthBackgroundColor for out of month calendar cells
NOTE: by default, the new calendar.js.dtml will be used instead of the older
calendar.js (renamed to calendar.065.js). To use the old calendar.js, without
reading values from the property sheet, change each of the view templates in
the header information from reading "calendar.js" to reading "calendar.065.js"
and everything should work fine, just as in version 0.6.5 of this software.
History:
v0.6.5(stable)
Code base: v0.6.4(RC1)
Status: Stable release, no known bugs, tests as valid XHTML
Transitional 1.0 at w3c. Very few changes from RC1.
BUGNOTE: Plone 2.1.1, ATContentTypes, event.py has a bug that needs
to be patched in order for the Resource Calendar tutorial to work.
Bug report is here: http://trac.plone.org/plone/ticket/5037 , and
it is described in the updated Manual for CalendarX. I don't know
whether the fix will be applied to Plone 2.1.2, due out soon.
mod: fix several i18n po files that had DOS carriage returns.
mod: minor French translation changes.
mod: fix Japanese translation that accidentally included fallback
instructions that covered English. This had no effect on earlier
versions, but on some installs of Plone 2.1.1 this caused the
Japanese translations to appear on browsers set to English.
mod: refresh.txt: slight change in text wording.
mod: removed DOS carriage returns from several scripts. These caused
errors (!) on systems running Python v2.4, but simply were an
annoyance on earlier Python systems. Affected: getDictMonth.py,
getEventsBetweenZC.py, getMonthName.py, getNameOfPeriods.py.
mod: calendar.css.dtml: added a definition for a generic tag to
force text-decoration: none; This was not needed in Plone 2.0.5
but is needed with the CSS changes that accompany Plone 2.1.x.
docs: mods to CX_props_addeventlink_text.txt to provide proper WARNINGS
about the possibility of misconfiguring these options.
docs: mods to CX_props_calendar_text.txt to provide more info about
limitations of the earlyHour (late night) events processing.
docs: CUSTOM.txt to improve directions and sync with the revised Manual.
docs: revised Manual (CalendarXManual-065-draft06.pdf).
mod: CX_props_macros.pt: minor changes in the prevnextcurrentlinks macro so
that XHTML validation is preserved when the JumpToDate widget is not used.
mod: CX_props_macros.pt: prevnextcurrentlinks_nojump macro added and is called
instead of prevnextcurrentlinks macro at the BOTTOM of each view to avoid the
longstanding IE bug where info windows are obscured by the JumpToDate widget.
Now that widget will no longer be displayed at the bottom of the view. IF
THE PREVIOUS BEHAVIOR IS DESIRED, simply change the views so that they call
the prevnextcurrentlinks macro instead of this _nojump version.
mod: all the views, changed the call to prevnextcurrentlink macro at the bottom
of the page to call the new _nojump macro instead. Read above.
mod: getAddNewEventURL.py: added a check on the getHomeURL() call used. Now if
there is no Home folder (/Members/username, typically) for the user, and the
option is selected to use the Home folder, then CalendarX will set the portal
root as the expected folder. Not great, but not an error. MAKE SURE YOU
configure your AddNewEventURL settings appropriately for your users and check
to make sure that it works.
mod: CX_props_calendar.pt: changed default for the earlyDayEventHour property
to 0 (midnight) to match earlier calendar behavior. Just set this to 3 (for
3am) or some appropriate value to get it working again for the day and
weekbyhour views.
History:
v0.6.4(RC1)
Code base: v0.6.3(beta)
Status (first RC): Works great! No known bugs, tests as valid XHTML
Transitional 1.0 at w3c. Bugfix release with one new property and
one new script. Many small changes/bugfixes in the handling of later
and earlier events on the Day and Weekbyhour views, making it much
better/smarter than the 0.4 branch behavior.
mod: day.pt and weekbyhour.pt: Bug reported that displays events starting in
the second half-hour as starting in the first half hour. This bug was
introduced by supposed fixes in the 0.6.3 release. Now it tests for both
onTheHour and useHalfHours when calculating the "end" DateTime object in the
main calendar view area (for each cell). And it works.
mod: getDictMonth.py: bugfix in startForContinuing events that caused some
events that crossed month boundaries to either not show properly or
misbehave in other ways. startForContinuing was improperly defined.
mod: month.pt: Bugfix in eventsBefore with showHighlightFullEvent for events
not in the month [changes in the main calendar area]. This couples with the
getDictMonth changes. Old bug, never reported, probably exists in 0.4 branch
as well, but affects just a few special events.
mod: getEventDictWeekbyhour.py: changed the calculation of jsStart so that the
exact date of start is the one highlighted, rather than adjusting so that wee
hour events (early morning) showed up on the previous day. that makes sense
sometimes, but is more often confusing.
problem: early morning events (like a 6:30 Meeting) don't show up on the proper
day unless the startHour is set before that time. Should be a property to
set so that you can control when late events for the previous day stop and
early events for the next day begin (earlyDayEventHour: default = 3am).
new: earlyDayEventHour property to fix problem
mod: CX_props_calendar.props: earlyDayEventHour added
mod: getDictDay.py: add startForEarly as a DateTime set to the startdate
adjusted to earlyDayEventHour. changed eveEnd to equal startForEarly of the
next day minus one minute.
mod: day.pt: change continuing events list comprehensions to use new
startForEarly, and added bigQE query to make it work. no change needed for
later events since we modded eveEnd in getDictDay.py.
mod: getContLaterEventsWBH.py: changes to continuing events and later events
to use the startForEarly property so that early events are included in the
continuing events block, and are sorted by new listSortByStart.py
problem: changes to continuing events behavior yields some unsorted lists of
events in continuing
new: listSortByStart.py: sorts a list of events. used in day and weekbyhour
views when gathering the continuing events add the new early events.
mod: getEventDictDay.py: changed the behavior of jsStart so that Early events
highlight the continuingEvents block.
mod: day.pt: changed id of continuingEvents block to dayviewstarthour to
multiply it by periodFactor. made no difference before, but now that we are
highlighting this block, it needs a proper id.
mod: weekbyhour.pt: set id of TH tags for each day so that it can be
highlighted by the early events someday (previously not highlighted for any
events, and not implementing this right now). also changed id of
continuingEvents block to weekviewstarthour to multiply it by periodFactor.
made no difference before, but now that we are highlighting this block, it
needs a proper id.
mod: getEventDictWeekbyhour.py: changed to use earlyHour so that early events
highlight the continuing events block.
mod: getEventDictMMonth.py: Fixed a bug where events that crossed over a month
into the month AFTER the last month still were trying to highlight into that
month, yielding a list out of range error. now tests for that situation to
exclude those events from the crossover highlighting calculations in the
jsCrossoverFlag flag.
mod: multimonth.pt: add nummonths to the parameters sent to
getEventDictMMonth.py for use in the bugfix above.
mod: weekbyhour.pt: change definitions for stForQuery, enForQuery so that the
bigQ query will recover ALL the events of the week from midnight to midnight,
not just from startHour to endHour. changes defined in getDictWeekbyhour.
mod: getDictWeekbyhour.py: added stForQuery and enForQuery so that the query
goes from midnight at the beginning of the week until earlyHour in the wee
hours of the first day of the following week, to catch those pesky trailing
late late events.
History:
v0.6.3(beta)
Code base: v0.6.2(alpha)
Status (first beta): Works great! No known bugs, tests as valid XHTML
Transitional 1.0 at w3c. Several bugfixes (all known ones, and a couple
minor, unreported ones discovered en route). Includes three new translations
and a UI enhancement: Javascript controller added to the Category chooser
checkboxes for sensible handling of the "View All" choice. All views now
work well, this is a very usable release.
new: po files for Czech, Danish and Dutch translations.
mod: ALL po files modified by +lupa+ to enable proper usage of the month of May
in languages where "May" has more than three characters. In the 0.6.2
release, any attempt to use a 3-char abbreviated month name came out as the
full month name because of this.
mod: CX_props_macros.pt: prevnextcurrentlinks: modded the getMonthName function
call in the JumpToDate widget to properly handle use of 3-char month
abbreviations (see po file mods above).
mod: weekbyhour.pt: mod to the Day listings across the top of the calendar view
to properly handle 3-char month names (see po file mods above).
mod: CX_props_macros.pt: subjectlinks: added code to use an onclick JS method
(fixCategories) to add better UI experience when clicking on View All. Now
the behavior is that View All toggles all the other category choices on and
off, and if View All is selected and one of the other Categories is clicked,
the View All choice becomes unchecked immediately. This has been a requested
feature since the Multiple Selection widget was first introduced, but I never
knew enough Javascript to want to learn to do this (and no one else offered
code for it). Now I do know enough, and here we are.
mod: calendar.js: added a new "fixCategories" function that is used by the
subjectlinks macro to control the UI enhancement mentioned above.
mod: all view templates (day, weekbyhour, weekbyday, month, multimonth, help):
added a line: context python:here; which fixes a possible Name Error when
installing CalendarX on older Zope (like 2.6.x ish).
mod: day.pt: squashed a bug on line 161 that caused problems with events not
showing up for the half-hour views.
mod: day.pt: added tal:omit-tag="" to a span around the eventlisting to fix
a minor XHTML validation problem.
mod: CX_props_calendar.pt: useHalfHours default value changed to blank (false)
so that half-hour periods are NOT the default style for Day and WeekByHour
views. Using half-hours is not necessary for most installations and it
slows view rendering down somewhat.
mod: getEventDictWeekbyhour.py: fixed the value of periodsInView by
subtracting 1. Also changed a misspelling of the script name in the
parameter block at the top of the script.
mod: getEventDictDay.py: fixed the value of periodsInView by subtracting 1.
mod: getEventDictMMonth.py: several lines of code added to fix the rollover
highlighting bug where events that span a month boundary failed to highlight
properly into the trailing month. Now it works fine, although the
highlighting extends only into a second month... any events that span portions
of three months will only show highlighting in the first two months.
mod: getNumOfDays.py: changes to fix code comments. No code changes.
mod: getDictCommon.py: removed some cruft and a couple of fairly naked
Try/Except clauses, and some sloppy coding, thanks to an eagle-eyed user
(yes you, Johannes). There is still cruft around, but at least it's a start.
mod: day.pt, weekbyday.pt, weekbyhour.py, getEventDictWeekbyday.py,
getEventDictWeekbyhour.py, getEventDictDay.py: a bugfix for day and week
views: we now pass the currentDate as a parameter from the view templates
into the getEventDictXXX scripts. This fixes the "birthday bug" reported by
Johannes Ammon, where the Jump To Date widget value was not being read by
the script. It shouldn't be; we already have determined that value, and now
we pass it in. The bug only seemed to affect the day view, but it could well
have impacted the week views as well, so it is now moot. Month and multimonth
views are unaffected.
History:
v0.6.2(alpha)
Code base: v0.6.1(alpha)
Status (third alpha): Works well, with one known minor display bug in the
multimonth view documented below. Several bugfixes, plus i18n extended to
include seven language po files with the addition of two (es and ca,
Spanish and Catalan), and a re-translation of parts of the German po file.
Please create more po files and submit your translations to us! I hope to
make another release with this bug fixed soon so that I can make a beta
release of the 0.6 branch as soon as possible. Meanwhile, this is a really
usable i18n version of CalendarX.
new: po files for calendarx-es.po and calendarx-ca.po.
mod: calendarx-de.po re-translated by Johann.
bugfix: getDictCommon.py bug: day.pt isn't showing next day properly.
changed lines 101-103 appropriately (copy-paste helmet malfunction, sorry).
And cleaned out unnecessary comments here and there.
bugfix: getDictDay.py bug: continuing events show ones that start at the
beginning of the day (ex. 8am events show as both continuing and normal
events with default config). this bug also present in 0.4.15 (just noticed
this). fix is use startDate, instead of ADDING one minute. also some
cleaning of remarks, etc.
mod: getNumOfPeriods.py cleaned up some variable names for clarity.
bugfix: getEventDictDay.py bug: continuing events didn't calculate rollover
parameters jsStart and jsEnd correctly. now they seem to. also a change
for later events (multiply by periodsFactor). finally, fixed the regular
events jsStart and jsEnd too.
bugfix: day.pt added bigQL query for later events, mods to make it work. and
fixed the handling of halfhours in the start, end datetimes so that it
actually DOES query on the half hours and not just on the hours. Sheesh!
My lysdexia gets in the way timesomes. Ok, now the day view WORKS.
bugfix: day.pt later events in the day view SHOULD be those that start in
the late evening (after 8pm in the default configuration) and wee hours of
the next day... as long as they end before the start of the next day, so
that they would NOT be considered continuing events of the next day.
But currently that's the not quite the behavior... so I'm changing this in
query for laterevents to only call events that (1) start after end of
this viewable day and (2) start before the next viewable day and (3) end
before the beginning of the next viewable day. NOTE: this means that
wee hour events (like a party on July 8 from 1am to 3am) will show up
on the Later Events section of the day before (July 7) and not on July 8,
unless July 8 has very early start time set in the CX_props_calendar
property sheet.
bugfix: weekbyhour.pt Needed a couple more changes to handle halfhours
properly. Now it seems to.
bugfix: getEventDictWeekbyhour.py Several changes to continuing, regular
and later events to calculate jsStart, jsEnd properly to fix rollover
highlighting.
BUG: multimonth view: Events that extend across month boundaries ONLY show
the rollover highlighting in the month where they start, and NOT in the
following months as they should. This bug will be fixed in a future
release of CalendarX (0.6.3 hopefully).
bugfix: multimonth.pt. Minor changes to help fix rollover highlighting. Now
calls a different eventlisting macro (mMeventlisting).
bugfix: calendar.js Created several new functions to handle passing of
arrays of td ids to highlight and unhighlight. The old versions just used
jsStart and jsEnd to control highlighting, which limits you to one
contiguous block of integers. Now you can send an array of as many start,
end pairs as you like. The multimonth view uses this now, but I only am
sending it one pair (so it could be used in the other views too). But
in the upcoming fix, I will use it to handle multiple highlighting blocks
that are not necessarily contiguous (the BUG described above).
bugfix: CX_props_macros.pt: new macro called mMeventlisting which replaces
the eventlisting macro for the multimonth view only. This version is only
different in that it uses a specially modified mMmouseOverEvent and
mMmouseOutEvent call in calendar.js, and sends jsArray instead of jsStart
and jsEnd.
new: getEventDictMMonth.py 0.6.1 used the month version of this script, but
there was definitely a need for an independent version, hence this addition.
In particular, it sends jsArray to the calendar.js library, rather than
jsStart and jsEnd that the other views use.
bugfix: getDictMultimonth.py Just a little bit of code cleanup, nothing
major.
puzzle: I didn't fix the multimonth rollover completely because it would have
been an ugly hack to do so. Instead I am releasing 0.6.2 with the bug
still in place, but restricted to only events that overlap two or more
months, and it is only a minor display bug... the multimonth view is usable
otherwise. I'm pursuing a new approach toward fixing this bug that may
help ALL the views become faster and have better separation of logic and
content.
History:
v0.6.1(alpha)
Code base: v0.6.0(alpha)
Status (second alpha): i18n extended to include five language po files with
more entries and more comments (de,en,fr,it,jp). Please create more po
files and submit your translations to us! Changed behavior of xsub from
that of the 0.4 branch. New multimonth view to allow multiple months (up
to 12) to be shown on one page. Modded the weekbyhour and day views to
allow use of half-hour increments as well as one-hour increments. Modded
the arrangement of calheader so that JumpToDate widget is out of the way,
and changed some CSS settings to help with that. Couple of small bugfixes
and maybe a few other things here and there that I changed and didn't
document...
new: multimonth.pt: minor tweaks to a month view to now show several months
at one time, in sequence. Next/Prev months still move it forward one month
at a time. Default is 3 months... if you want to change its name in the
tabs from "3 months" to something else, then change the language files,
where it is called "label_multimonth". Then reindex the language files
for CalendarX or else you won't see your label change (or just restart
Zope to reindex ALL your po translation files).
new: multimonth.css.html, getDictMultimonth.py, getEventDictMultimonth.py:
all in support of multimonth.pt view. Validates as proper XHTML format
too (glad I checked, it didn't at first).
new: getNumPeriods.py, getNumWeeksInMonthToShow.py to support halfhours
and multimonths.
new: getContLaterEventsWBH.py: this is a script that is backported from 0.5
branch to help optimize the WeekByHour view queries.
new: calendarx-it.po: mostly complete. needs a few mod translations.
new: calendarx-jp.po: mostly complete. needs a few mod translations.
mod: calendarx-fr.po: mostly complete. needs a few mod translations.
mod: calendarx-de.po: mostly complete. needs a few mod translations.
mod: calendarx-en.po: complete. slightly redone in several places, so
all other translations should be re-examined for completeness and tested.
mod: CX_props_macros.pt for translation changes, and some other changes,
including new macros. See change notes within that file.
mod: getEventsBetweenZC.py, getEventsBeforeZC.py, getEventsBetweenAQ.py,
getEventsBeforeAQ.py: Changed the behavior of xsub so that choosing a
subject in addition to the 'View All' will override the 'View All' choice
and show only the selected subjects. This makes more sense to the user,
and should be a bit less frustrating. Would be nice to have some JScript
logic that shows this (uncheck 'View All' when another selection is made).
mod: day.pt, weekbyhour.pt, getDictCommon.py, getDictDay.py,
getEventDictDay.py, getEventDictWeekbyhour.py, getDictWeekbyhour.py,
to support halfhours.
mod: calendar.css.html, CX_props_calendar.props, CX_props_css.props,
to support changes in the header, looks better now, some comments added,
and one new property: headerPadding.
mod: CX_props_calendar.props: new properties added: useHalfHours,
numMonthsForMultiMonthView, and showHeaderTitleAndIcons.
mod: speedups in all views and corresponding getDictViewname.py scripts. For
each one, I now call the getEventsBefore query only once (because it is
expensive to call in every single cell of the calendar) and instead use a
much faster list comprehension to parse for events. This is a backported
strategy from the 0.5 branch to speed this up a good bit.
bugfix: getEventIcons.py: mod to trap AttributeError for bad icon name, and
cause it to return icon = '', thereby showing NO icon instead of error msg
bugfix: calendar.css.html: mods to the calinfo and inforow divs so that
switching to LARGE TEXT mode doesn't cause text blocks to override each
other... all it really took was changing the box width to "20em" instead
of "250px" because em is relative to the font-size, instead of being fixed.
bugfix: CX_props_macros.pt: popuptextbox macro: changed the Subject so that
it puts a space between each subject. So now it shows "This, That, Other"
instead of "This,That,Other"... this way the subject line will use the
whitespace to wrap appropriately within the popup box.
History:
v0.6.0(alpha)
Code base: v0.4.15b(stable)
Status (first alpha): i18n folder added and basic i18n features added to
macros as a first step toward full i18n of the stable 0.4 branch.
Addition of these changes to the 0.5 branch will follow.
new: i18n folder
new: calendarx.pot: Listing of all the msgids. The msgstrs mostly blank to
allow default values from the page templates to come through. Beginning
to use format strings for the date-time strings because it's a good idea,
formatting of date-time strings is not uniform across boundaries. Also
added a lot of comments to help explain them all.
new: calendarx-fr.po: French translation. Added comments in too.
new: calendarx-de.po: German translation. Added comments in too.
new: calendarx-en.po: (headers, but empty so that English passes through to
the calendarx.pot defaults)
mod: CX_props_macros.pt: many small changes to accomodate i18n, in nearly
every macro.
mod: weekbyhour.pt: some i18n changes for day headings and "Continuing" and
"Later events" labels. Probably not complete.
mod: weekbyday.pt: some i18n changes for day headings and "Continuing" and
"Later events" labels. Probably not complete.
mod: day.pt: some i18n changes for event headings and "Continuing" and
"Later events" labels. Probably not complete.
mod: month.pt: some i18n changes for "Continuing" and "Later events"
labels. Probably not complete.
mod: getEventsBeforeZC.py, and the other three such scripts. Added a three
line mod that shows "private" events for group members who have been
given appropriate privilege to see them. This improves the Group calendar
functionality.
mod: CX_props_calendar.pt: new property "showPrivateEventsToGroupMembers"
(default=False) that when turned on will allow private group events to be
shown. To use, share your private events (with the Sharing tab) with one
of your groups by making them proxy owner of the event. Then the events
they are proxy owners of can show up on the calendar.
mod: getDictCommon.py: i18n change for allEventsChangeString (return a label
instead of the string, then get the string from the po file, even for
English).
todo: a few more i8n mods, especially formats for dates, times.
[for pre v0.6.0 History, see HISTORY.txt files with those releases.]
From the current INSTALL.txt:
INSTALL.txt
CalendarX 0.6.6(stable) January 03 2006
(last modified for CalendarX 0.6.5)
by +lupa+ (lupaz on sf.net, lupa at zurven dot com)
Released under the GPL (see LICENSE.txt)
I. Software requirements (Updated for 0.6.5)
II. Instructions for Installation for the first time. (0.6.5)
III. i18n: Internationalization instructions. WE NEED TRANSLATIONS! (0.6.5)
IV. Documentation available.
V. Caveats.
Old Instructions for upgrading to new versions of CalendarX
(MOVED these instructions to MIGRATE.txt)
Plone BUGFIXES: There are two known Plone bugs that should be fixed in
order for everything to work right in CalendarX... one in Plone 2.0.5
and another in Plone 2.1.1. Details are below.
I. Software requirements
!!! DON'T USE Python 2.4 !!! Well, ok, it does run on Python 2.4 but there
have been some peculiar problems, especially when a file accidentally had
DOS carriage returns in it. Talk about picky! Oh well.
Software Requirements for CalendarX (0.6 branch):
1. Plone 2.0+ (also tested working in 2.1.1).
2. Python 2.2 or 2.3, NOT 2.4.
Software Suggestions (NOT REQUIRED):
1. Zope 2.7.x+ (may work on earlier Zopes, but untested. Python 2.2+ is not
standard until Zope 2.7+)
2. AdvancedQuery [this is available at Dieter's site:
http://www.dieter.handshake.de/pyprojects/zope/ ]
AdvancedQuery is one of two query techniques used. By default, the
traditional ZCatalog query method is used, but using AQ is simply a
switch option in the skins property sheet.
II. Instructions for Installation for the first time.
*NOTE* these instructions were written for Plone 2.0.5. They still work
roughly the same in Plone 2.1.1, but there may be small differences. I've
only just begun working in Plone 2.1.1 myself and haven't a lot of
experience here yet. But it does work, no fear about that.
1. Make sure you have the required software and additional Zope Products
in place. Additionally, there may be bugfixes you need to apply to
your Plone install. Here are the two I'm aware of, one for Plone 2.0
and one for Plone 2.1.
#NOTE: IMPORTANT BUGFIX TO Plone version 2.0.5#
There is a bug in Plone 2.0.5 that will bite you if you change your Events
from 24 hour clock to the 12am,pm style. The bug is documented here on the
Plone.org website:
http://trac.plone.org/plone/ticket/3641 or
http://plone.org/collector/3641 (older link, reroutes to above)
and is also described on the CalendarX website here:
http://calendarx.org/issues/talkback/1104958175
You can patch the bug either on the filesystem, or through the ZMI in your
portal_skins/custom folder.
#NOTE: IMPORTANT BUGFIX TO Plone version 2.1.1#
There is a bug in ATContentTypes, event.py distributed with Plone 2.1.1 that
forces the Event to keep the Event vocabulary, even if you have repurposed
an Event in portal_types and given it a new Type name. The bug is
documented here on the Plone.org website:
http://trac.plone.org/plone/ticket/5307
and also is described on the CalendarX website here:
http://calendarx.org/issues/talkback/1135185404
and must be patched on the filesystem. In brief:
In YourZopeInstance/Products/ATContentType/content/event.py
change the definition of 'getEventTypes' from
metatool = getToolByName(self, "portal_metadata")
events = metatool.listAllowedSubjects(content_type = "Event")
return events
to
metatool = getToolByName(self, "portal_metadata")
my_type = self.getPortalTypeName()
events = metatool.listAllowedSubjects(content_type = my_type)
return events
"Event" was hardcoded into the event.py, so that even repurposing it
failed to get the Vocabulary info from portal_metadata, and there may
be other side effects. FAILURE to fix this one means that the Resources
Calendar exercise in the Manual will NOT work properly.
2. Acquire the CalendarX-0.6.x.tar.gz file from sourceforge. This unzips as
a tar file, which untars as a single folder, called CalendarX-0.6.x.
3. RENAME! In your Zope INSTANCE, place this folder in your
INSTANCE_HOME/Products/ folder and rename the folder to
/Products/CalendarX instead of /Products/CalendarX-0.6.x.
4. Restart Zope.
Note: If you are Reinstalling CalendarX, read MIGRATE.txt in the docs.
There's really nothing to do if you haven't customized it at all,
but nearly everyone does some customizing, at least for the property
sheets.
5. Go to your Plone portal, and log in as a manager. Go to plone_setup
and Add New Products. Find CalendarX in the list and check it, and
click the Install button. This is equivalent to navigating in the ZMI
to your Plone instance, and using the portal_quickinstaller to install
CalendarX.
6. IN PLONE: Navigate to where you want a CalendarX instance, and add a
CalendarX in the normal fashion. Name it "calendar" or whatever you want.
It creates an "empty" folder, but when you now navigate to it in Plone,
it will display the Calendar, set to the default view (Month view).
NOTE: CalendarX is *not* an ordinary Plone folder. The folder_listing and
folder_contents have been disabled. Do attempt to store Plone content
inside your CalendarX instance. Certain advanced features of CalendarX
require you to use this folderish behavior to store CalendarX scripts and
other files within it (such as having multiple calendars on one site, and
the use of subcalendars). See step #9 below for more information.
7. That's it. Navigate in Plone to your calendar folder and the default
(month) view should appear. You may then publish (or not) your calendar
as you wish.
8. To customize your CalendarX, go to portal_skins/CalendarX, and customize
any of the files there (property sheets, scripts, page templates, etc.).
For more information on customizing CalendarX, read the CUSTOM.txt file
in the /docs folder, and each of the separate text documents that
describe the attributes in each property sheet.
9. To create more than one instance of CalendarX is easy... just add another
one from the dropdown list. However, all your calendars will use the same
properties from the /portal_skins/custom or /portal_skins/CalendarX folders.
To make each calendar different:
IN ZMI: CUT all the customized objects that you need from the
/portal_skins/custom folder, and PASTE them into your CalendarX folder.
Now your calendar can be customized locally and independently from any
other calendars. I like to use this approach anyway, even if I'm only
using ONE CalendarX instance in my Plone site, because it cleans up the
/custom folder for other uses. To further customize it, find the object
in /portal_skins/CalendarX that you want, hit the Customize button, then
CUT/PASTE it into your CalendarX instance, and then make your changes.
Only the objects that you want to customize need be CUT/PASTED to your
CalendarX instance. All the other ones needed will be acquired from the
/portal_skins/CalendarX folder in a normal fashion.
III. i18n: Internationalization instructions. WE NEED TRANSLATIONS!
CalendarX-0.6 branch has i18n capability. There are now eleven translations
(as of 0.6.4 release). If you can help, please do! Here's how:
1. Go to the i18n folder. This is where the translations are stored.
2. Choose one of the translated files as a starting point; any of them will do
for getting started.
3. Copy the file and rename it: here are the translations that are standard
in Plone that we don't have yet, and would LOVE to have for CalendarX so
that we're compatible in all these. And we would love to have even more
than these... as many as we have languages for folks using CalendarX! So
copy one of the translations we have, and translate all the terms into your
language of choice.
Thirty-some translations and status:
calendarx-af.po - needed
calendarx-ar.po - needed
calendarx-bg.po - needed
calendarx-ca.po - FINISHED
calendarx-cs.po - FINISHED
calendarx-da.po - FINISHED
calendarx-de.po - FINISHED
calendarx-el.po - needed
calendarx-eo.po - needed
calendarx-es.po - FINISHED
calendarx-es-ar.po - needed
calendarx-es-es.po - needed
calendarx-et.po - needed
calendarx-eu.po - needed
calendarx-fa.po - needed
calendarx-fi.po - needed
calendarx-fr.po - FINISHED
calendarx-he.po - needed
calendarx-hr.po - needed
calendarx-hu.po - needed
calendarx-hy.po - needed
calendarx-it.po - FINISHED
calendarx-ja.po - FINISHED
calendarx-ka.po - needed
calendarx-ko.po - needed
calendarx-lt.po - needed
calendarx-nl.po - FINISHED
calendarx-nn.po - needed
calendarx-no.po - needed
calendarx-pl.po - needed
calendarx-pt.po - needed
calendarx-pt-br.po - FINISHED
calendarx-ro.po - needed
calendarx-ru.po - needed
calendarx-sv.po - needed
calendarx-tr.po - needed
calendarx-uk.po - needed
calendarx-zh.po - needed
calendarx-zh-cn.po - needed
calendarx-zh-hk.po - needed
calendarx-zh-tw.po - needed
Other language .po files gladly accepted! This is the list that is present
in Plone 2.0.5. If more will be available for Plone 2.1, let's get those
all in here too.
4. Translate all the strings and the few date and time formatting strings that
are present. Also, if your translation should serve as a fallback
translation, include those translations that should fallback here... follow
the other calendarx-xx.po files or (really) the examples in CMFPlone/i18n for
a guideline.
5. Test your translation: put it in your /Products/CalendarX/i18n folder, and
restart your Zope. Actually RESTART your Zope, don't just refresh the
CalendarX product -- that's not enough, because the i18n initialization takes
place at Zope startup. After the initial restart, you can test your new
translations or modifications you make by going in your ZMI to the Control
Panel, select PlacelessTranslationService, find the po file you're working
on click it and hit the Refresh Catalog button to update the translation
catalog with your new work. Then email your translated po files to lupa.
6. Check the results in your browser. Set your browser's default language for
your desired translation and see the difference. Also, if desired, you can
download PloneLanguageTool and install it, and use it to make a language
switcher in your site... that makes it easy to test different translations
and see what they look like. I use PLT on the Crashtest site where you can
try out CalendarX-0.6.x translations.
7. Pay particular attention to getting the formatting strings localized... do
you want to say "April 2005" or "2005 Avril"? There are more lots of these
formatting strings... make them the way YOU think your users visiting in your
language translation would be comfortable seeing these strings. Then be sure
to test these all out.
IV. Documentation available:
Contents of the CalendarX.0.6.x /docs folder:
CREDITS.txt - some people who deserve our thanks.
CUSTOM.txt - description of how to customize CalendarX with skins.
CX_props_calendar_text.txt - instructions for the calendar properties
CX_props_css_text.txt - instructions for the CSS properties
CX_props_custom_text.txt - instructions for the Custom property sheet
CX_props_popup_text.txt - instructions for the popup properties
CX_props_addeventlink_text.txt - how to control the Add New Event link
CX_props_subcalendar_text.txt - instructions for subcalendar properties
HISTORY.txt - all the changes in this CalendarX branch so far.
INSTALL.txt - this file, describing the installation.
LICENSE.txt - brief synopsis licensing for CalendarX (GPL).
LICENSE.GPL - a current copy of the General Public License.
MIGRATE.txt - a quick how-to on migrating/upgrading CalendarX.
OVERVIEW.txt - synopsis of what CalendarX is, and does.
README.txt - brief message identifying CalendarX.
TODO.txt - some things to finish before this branch becomes (stable).
VERSIONS.txt - explains version numbers used for CalendarX releases.
CalendarXManual-065-draft06.pdf - a manual with all the
goodies from these documents, and some more besides.
V. Caveats.
0. These caveats have been included here since the first releases of CalendarX
and I've never had excuse to need them. But here they are.
1. For your health, and mine, I've tried to document nearly everything you
need to accomplish significant things with CalendarX. Please read all
the documentation before you ask questions to the list or at CalendarX.org.
There's lots of it, even to the point of explaining each configurable
attribute in the property sheets. It is not, however, capable of explaining
all the possible things you can do with CalendarX. Be creative, and share
your successes and failures with us at CalendarX.org.
2. Part of the code for CalendarX at this point in time comes from the
previous products it builds on -- mainly PloneCalendar (see the README).
I know most of that code now, and have replaced large parts of it with
my own. But I can't vouch for everything it does yet. Do with this
product what you will, but use it responsibly.
3. At this point, I have no idea how CalendarX may interact with or interfere
with any other Zope/Plone products or other software. There are likely to
be name overlaps between objects in this code and those in other apps, and
in a world with Spammish Acquisition, many things are possible. I have
seen no bad such interactions, although one potential user claimed to be
totally unable to import the Fezzik folder (on the 0.2 branch) no matter
how he tried (a month later, this user wrote back and said there are no
problems now with the most recent version). I think this must have been
an interaction with this particular Plone setup, but I have no idea. I've
tried it without any problems on several systems and operating systems,
but I don't know what will happen on your site, because you may have
customizations that do cause problems. Forewarned should be four armed,
but you never know. In the meantime, do with this product what you will,
and remember to use it responsibly.
4. This product has not been thoroughly tested and is likely to have bugs. In
fact, it doesn't even have a unit test suite for it yet. You have been
warned. That said, I and many others use this product routinely in
production Plone sites, and deliver versions of it to clients for use on
their production sites. Do with this product what you will, but use it
responsibly. Practice safe Plone.
5. No animals were harmed in the creation of this Product, and no testing on
live animals was performed. You should not attempt to use this Product in
the manufacture or assembly of weapons of mass dysfunction, as it is likely
to function properly, thus causing failure of intended weapons. Any attempt
to dissassemble or reverse engineer the functionality of this Product is
strictly encouraged, and any successes in such endeavor should be shouted
from the mountaintops. Or at least let me know.
+lupa+
From the current CREDITS.txt:
CREDITS.txt
CalendarX 0.6.6(stable) January 03 2006
(last modified for CalendarX 0.6.6)
by +lupa+ (lupaz on sf.net, lupa at zurven dot com)
Released under the GPL (see LICENSE.txt)
CalendarX is a customizable, open source metacalendar application written
for the Plone content management system on top of Zope and Python.
As open source software, it builds on the work of many other fine
open source products, and on the work of many individual contributors. At
the very top of the list are the creators of Python, Zope and Plone. Without
the fine application development platform these provide, CalendarX would
not exist.
In most cases, I have tried to adapt rather than adopt code from others,
so that CalendarX retains a fairly consistent internal style. However,
there are also places where the code comes straight from the code of
others. I have tried to mention contributors in the comments of the code
wherever this is feasible. I will also try to keep a tally here of the
individuals who have contributed in some way, wittingly or not, to the
success of this project.
Significant Code Contributors:
Oliver Merkel, who wrote the original PloneCalendar and produced a very
thoughtful documentation for its installation.
Alec Mitchell, who wrote the code to make CalendarX into a PloneFolder-based
Product (0.4 branch), and made many other code suggestions, and now helps
manage CalendarX at sourceforge along with even more kool kode kontributions.
Scott Sturgeon, for makeCSV.py and addEvent code
Joris Bauer for XHTML validity fixes throughout the 0.4 branch.
Gaël Pegliasco for i18n kickstart to the 0.6 branch.
Special coding inspiration:
Raphael Ritz for MySite and many listserv postings
Dieter Maurer for AdvancedQuery and many listserv postings
Casey Duncan for Monkey Patch explanation
Jean Jordaan for Internationalization explanation
Monetary Contributors (thanks!):
Several people and organizations have made donations through Sourceforge,
which helps a lot because this is almost purely for hobby now, and an
occasional consulting gig for customization help.
Logistical Support:
Design53
Smoothstone Systems, Inc. (RIP)
Translators:
Gaël Pegliasco, and Gwen (French)
Kai Schlüter and Johannes Ammon (German)
Morino (Japanese)
Massimiliano (Italian)
Miquel Nieto Gallardo (Spanish)
Miquel Nieto Gallardo (Catalan)
Quint Mouthaan (Dutch)
Josef Milota (Czech)
Kim Nielsen (Danish)
Rafahela Bazzanella and Paulo Sérgio Medeiros (Portuguese-Brazilian)
Bugspotters, Featuresuggesters and Questionaskers:
Mat Ridley, Scott Sturgeon, David Diskin, joey (doggonecat), Paul Roeland,
Joe Reilly, Martha Mathiason, Matt Laughter, Karl Ulbrich, Marc Lavallée,
Justin M. Keyes, Michael A Rowley, Cynthia Kiser, Curtis Yanko, Paul Howell,
Dave Campbell, Robert Nagle, Darren Schlamp, Russ Markman, Nate Aune,
Chuck Staley, Jordan Baker, Tobius Helmus, Radim Novotny, Rocky Naidu,
Susan Knight, Francesco Ronzon, Mike Helde, Simone Girlanda, Doug Evenhouse,
Don Johnson, Ken Wood, Eva Miller, Vanessa Evans, George Lee, Danna Dowdy,
Luca Fabbri, Steve Hein, Jeremy Cook, Ben Labelle, Heather Jones, Peter Wallace,
Ravi Ramamirtham, Kai Schlüter, Daniele Grasso, Miquel Nieto Gallardo,
Eric Brown, Kapil Thangavelu, Godefroid Chapelle, Bastien Gauthier, Fadi Asfour,
Andrew Chaney, Tom Vanslembrouck, Ben Labelle, Rik Panganiban, bobb,
Peter Wallace, T. Meyarivan, Jake Isaac, Bruce Dillahunty, Adrian Boeing,
Jeroen van Doorn, Sim Harbert, Richard MacIver, Bryan White, Jesper Hoffgaard,
Santosh, Eric Friesen, Madhu Aggarwal, Dirk Niemeyer, Michael Bernstein,
Kris Smith, Christine, Johannes Ammon, Massimiliano, Lael Powers,
Colin Gillespie, Aurélien Campéas, Ricardo Newbery, Mike Allerhand,
Andrew Chaney, Greg Gehrich, Evan Frisch, Matthew Phillips, Ian J Maude,
Diana Szczesuil, Scott Brown, Kurt Bendl, Bronwyn Carlisle, Souheil Chelfouh,
Francis Lapique, Joshua Levy, Rik Belew, George Lee, BenO, Tess Bond,
Matt Phillips, Jürgen Plasser, John Wright, Nuno Henriques, Peter Anderson,
Mike Revoir, Aaron Bookvich, Ed Gordon, Tracy Reed, Dennis Jen, Colin Donald,
Vaishal Sheth, Sébastien Douche, Jens Nachtigall, Uwe Daub.
From the current VERSIONS.txt:
VERSIONS.txt
CalendarX 0.6.6(stable) January 03 2006
(last modified for CalendarX 0.4.0)
by +lupa+ (lupaz on sf.net, lupa at zurven dot com)
Released under the GPL (see LICENSE.txt)
Starting with CalendarX v0.1.8(stable), we are implementing a new four part
version number system that we think you'll find sensible and easy to
understand. It offers several advantages over other systems for small to
medium scale software projcts. Here's how it works.
CalendarX version numbering scheme with four parts: V.B.F(C)
Version . Branch . Fix (Comment)
Definitions:
Version: significant code base difference from other major Versions
Branch: new features beyond other branches (aka minor version)
Fix: very little new functionality, mostly bug fixes
Comment: added at the end to tell the user something about stability
(exp) - experimental release, definitely needs work, but it obviously
has some functionality or it wouldn't have been released.
(dev) - development release, some bugs, but in a working state.
Expect changes and new functionality to appear under (dev).
(alpha) - seems stable with NO identified critical bugs, requires more
testing and bugfixes. Very minor new functionality, if any.
(beta) - candidate for stable release. Beta is mostly for bugfixes and
minor feature adjustments, with essentially no API changes.
(rcX) - where X is a number (1, 2, etc.) Release candidate for a stable
release. No changes other than bug fixes.
(stable) - well tested, serving in production capacity. additional stable
releases in any branch will only be made for bugfixes.
Critical bug: A bug that absolutely must be fixed before declaring a
branch to be in a stable form.
Minor bug: Bugs that aren't critical. Minor bugs are optional to fix before
declaring a branch to be stable.
For example, the first stable release of CalendarX was that 0.1.8(stable) code
on June 13, 2004. It represents the "0" Version (aka Trunk) of the code, and
the "1" Branch of that code. It went through several Fix stages (actually
more than a dozen under the old version numbering system), and has been
declared Stable as of this release: v0.1.8(stable).
Once a branch reaches stable, it is very unlikely to have any further
development of that branch of the code. Once a branch reaches a stable state,
the only future releases along that branch will be bugfix releases.
Any new features added to the code, other than very minor cosmetic changes,
should cause the opening of a new code branch. Several code branches may be
active at one time, but should always specify in the HISTORY file what stable
code branch it was started from.
The major advantage of this approach is that fantastic new features
need not be held hostage to other, more difficult feature developments.
Example 1: A particularly nasty coding problem is holding up development of
the 1.2.x(dev) branch, but a desirable new feature of that branch has been
completed, then it is entirely possible (and *desirable*) to release a 1.3
branch that builds on the stable 1.1 code base, but releases the desirable
new feature into the community without delay. The 1.2 branch continues, or
it may jump ahead to 1.4 if other new features get added in.
Example 2: Some great new features added into the 0.9.x(dev) branch are very
desirable for 0.8.x(stable) users. If these new features can be readily
backported into the 0.8.x(stable) code base, then a new branch called
0.10.0(dev) should be started to include those features. This branch can
very rapidly be advanced to 0.10.x(stable) status because of the stability of
the 0.8.x branch code base and the small number of changes made. Thus new
functionality can be released in a stable form without undo reliance on
CVS branches or other project managerial magic.
Also, there is no upper limit on any of the numbers, so eventually
one might reach v3.63.7(stable) or something like that. It is unlikely to
reach high numbers in the Fix part of the version number
[i.e., v3.63.119(stable)] unless there were ridiculous difficulties in
squashing bugs in that branch.
I think this numbering system, although truly insignificant (it is just a
convention, after all), will help us produce a more reliable product more
quickly. Perhaps more importantly, it will definitely help us adhere to a
philosophy of "Release Early, Release Often."
+lupa+
CalendarX.org
+lupa+
lupa (at) zurven (dot) com