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.
CX_props_eventstoallow_text.txt
- How to choose which Events to allow on your calendar (by Type, State, Path, Subject, Creator).
CX_props_eventstorestrict_text.txt
- How to choose which Events to restrict from your calendar (by Type, State, Path, Subject, Creator) according to User, Role, or Group membership.
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.5.3(dev) March 26 2005
(last modified for CalendarX 0.5.3)
by +lupa+ (lupaz on sf.net, lupa at zurven dot com)
Released under the GPL (see LICENSE.txt)
Release Summary: 0.5.3 is a bugfix release. Fixed helpcx.pt so that it works
properly with 0.5 branch. Fixed the +link bug for datestrings in the URL
query that were not properly quoted for use in query strings. Fixed
portlet_calendarxp bug that displayed wrong events in overlapping dates
(such as both March 1 and April 1 in the same view). Fixed calendarPrint
problem where the print version was NOT removing subjectlinks. Added new
property to cx_props_addeventlink to turn on/off the +links, and made mods
to utilize this property.
Attempted but did NOT fix the problem with addNewEvent links not using
portal_factory when Events are selected there: current status is that
portal_factory is bypassed, but with a documented one-line change in
cxCreateEvent.py, you can allow portal_factory to be used even though the
proper date, time, Title and Description parameters will NOT be passed
in to the temporary event.
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. Please
read these for help in figuring out all the configuration. CalendarX has
lots of options, and reading the docs helps a lot. In particular, there are
now many options for configuring who can see what types of events on each
calendar instance on your site.
Read more at these sites:
http://calendarx.sourceforge.net
http://sourceforge.net/projects/calendarx/
http://calendarx.org
http://crashtest.calendarx.org
From the current OVERVIEW.txt:
OVERVIEW.txt
CalendarX 0.5.3(dev) March 26 2005
(last modified for CalendarX 0.5.2)
by +lupa+ (lupaz on sf.net, lupa at zurven dot com)
Released under the GPL (see LICENSE.txt)
Pretty current summary of CalendarX functionality
New Feature list (0.5 branch):
* Now has links (+ sign) in each calendar view cell for members to allow them
to add events on that day, or in that hour (depending on view).
* XHTML valid code throughout.
* Huge speed increase over 0.5.0, and now faster than 0.4 branch too.
* Two portlets to use as mini-calendars for your site. Both of them read
events from a linked, specific CalendarX instance elsewhere in your site,
and link to it from the Month name.
#1 portlet_calendarx: uses the configuration you've already set up in the
referred CX instance, but shows the events as icons in a mini-month view in
a portlet from any page that you want it to show up on (via normal slots
and portlets usage). Thanks to Vanessa for the initial code and idea, this
one offers many possibilities for further customization -- it's much like
a mini-CalendarX instance.
#2 portlet_calendarxp: looks almost just like the original portlet_calendar
that comes with Plone, a nearly plug-and-play replacement, although you
still need to tie it to a CalendarX instance. Thanks to David for pushing
for this one.
See INSTALL.txt for details on installing, using both.
* Portlet-based options allows cleaning up the header. All the choices are
nicely laid out and improved for the portlet. I've made this the default
configuration (with a clean, blank header) for the 0.5 branch.
* Several different configurations of the header options are now available,
allowing different arrangements of the subject, add new event, etc. widgets.
* New user picker option for managers (or anyone, if desired). Choose any one
or several users and the calendar will be restricted to showing only those
users. TALES property controlling access to this is available through the
property sheets! Now you can also just restrict the listing of users to
a simple lines property list of Users. Thanks Alec, this is so cool.
* Big reworking of the code for doing the getEvents queries... saner and more
expandable and better documented. Alec kicked this off with a patch just
before Christmas and I built on it (lots). The result: you can now
restrict your calendar events in MANY more ways than in the 0.4.0
branch. For example you can restrict showing events in your /staff folder
ONLY to those users with a Staff role, or those belonging to a "staff"
group, or to users fsmith, kjones and jrodriguez. And not just paths, you
can restrict by Subject, review_state, Creator and Types too. NOT by any
means a substitute for proper Plone security, but useful all the same.
Basic Feature list (0.4 branch):
* Provides basic calendar functionality with standard Plone content (CMFEvents,
AT Events, custom AT events).
* 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.
* 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.
Planned features for future branches:
* Group calendar support through GRUF 3.0.
* Repeat events (when we get a new catalog index written for them).
* 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.5.3(dev) March 26 2005
(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.5.3(dev) March 26 2005
(last modified for CalendarX 0.5.3)
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.5.3(dev)
New #1. Get portal_factory working properly with the +link addNewEvent
feature. Currently it does NOT send through the proper date and time
to the temporary Event. Bleah. Also there should be better configuration
of options in the CX_props_addeventlink.props sheet once this is fixed.
1-11. same as below. Made some progress on #12, but needs a more thorough
treatment.
13. Get the new prototype repeat events working well enough to use with
CalendarX. Add an "allday" property to the Events and use it in the displays.
ToDo list as seen at launch for CalendarX 0.5.2(dev)
1-6. same as below
7. Clean up code and naming in a number of places. For example, make it
clear from names of things that eventstoallow are really where we are
allowing and not restricting events, and eventstorestrict is where we
are restricting events, not allowing them. Or if it is different than
that then make it sensible sounding.
8. Would really like a nice recoding of the property sheets. Specifically,
I want to be able to nicely create a repurposed type in portal_types, and
give owners (ordinary users) the opportunity to do a limited amount of
configuring the calendar themselves, without needing ZMI access and
manager privileges. Can't do that with regular property sheets... got
some thinking to do on what it should look like.
9. BUG: JumpToDate widget throws an error if the date is illegal, like April 31
of any year. And I don't like the crazy URL it uses... it would be nice to
be a standard CalendarX URL instead. So should use a Controller Python
Script with metadata as a redirct... catch the bad dates in the script, then
use the redirect to get *nice* URLs.
10. Use TALES in a property to control several more of the special features
that should be controlled there, by the Admin, instead of hardwiring
permissions into the code... things like isMember stuff should be TALES
strings properties that get checked out by the checkCondition method.
11. getDictCommon isn't really *common*. Instead there are things in there
that are specific to each view... that's silly, they should be back in
the separate getDictViewname scripts, right? I think there's a reason
that they are not, but there should be a decent workaround to make that
more intuitive.
12. Make sure all URLs are properly formatted and quoted so that they meet
all standards for web URLs. Probably not right now, especially not the
new +links for event creation. Not hard, but needs to be learned and done
correctly throughout the code.
ToDo list as seen at launch for CalendarX 0.5.1(dev)
1. Need more systematic testing of all the 0.5 properties, and work with them
on some real calendars to see what else is needed (a few other properties,
likely).
2. Extend, improve handling of groups for group calendars.
3. Try to make a config page that allows admins to give owners of
CalendarX instances the ability to make some (limited) configuration
changes of their own. Admins decide how much to let them do. Done
right, this will GREATLY simplify configuration, both for Admins and
for owners, and it will make it easy to make a new Calendar type that
is useful for certain groups of users (and be specially configged
just for them).
4. Finish documenting all the new restrict/allow properties. Make up more
silly use cases and helpful hints.
5. Work on new manual for 0.5 branch.
6. Integrate Max's new iCal tool.
From the current CUSTOM.txt:
CUSTOM.txt
CalendarX 0.5.3(dev) March 26 2005
(last modified for CalendarX 0.5.3)
by +lupa+ (lupaz on sf.net, lupa at zurven dot com)
Released under the GPL (see LICENSE.txt)
Notes on customizing CalendarX 0.5 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 nine property sheets (named
CX_props_yadayada). Click on one of the Property Sheets. Then click the
Customize button (to make this into a folder with properties that you can
adjust) and start changing the properties. In brief:
CX_props_calendar: controls most basic calendar functionality, how the
Subject bar is displayed, etc.
CX_props_eventstoallow: what events to allow on the calendar
CX_props_eventstorestrict: what events to restrict from the calendar
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.
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.
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. You should like it too.
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
may 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. 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.
The default installation in the 0.5 branch now sets the right_slots
property to empty, and in the left_slots property it adds a line for the
portlet_cx_choices... this provides all the controls formerly shown in the
top of the calendar, like Public/Private events link, Subject category
selection, etc.
THIS IS AN OPTION. You can go back to the 0.4 branch method by emptying
(or modifying) the slots on your CalendarX instance, and setting the new
calendarOptionsMacro property in the CX_props_calendar property sheet to
a string value of "subjectlinks" (this will display the old-style subject
bar in the head of the calendar views). The default right now is to show
"subjectlinks0", which shows nothing in the subjectlinks area, because all
those controls are now in the portlet. Read the /docs for all the
new properties of the subjectlinks macros available. Make up a new one
and send me the code for it to include in future releases.
2. The calendar uses categories based on the default Event Subjects.
Currently these are Appointment, 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 is only semi-automatic.
If you want CalendarX to choose Subjects based on all the Subjects
available, see the instructions in CX_props_eventstoallow_text.txt
So, find the CX_props_eventstoallow 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, now 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.
Now 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 calendars as you like, even one per member or more.
Overall, if you DO customize property sheets and the like for your calendar,
we recommend putting the customized version INSIDE your CalendarX instance
folder. It's just neater that way, and a very tiny bit faster.
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_eventstoallow and
CX_props_eventstorestrict properties.
5a. Subjects to allow.
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 Types to allow.
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. Paths to allow.
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.
5d. Many more.
Read everything in CX_props_eventstoallow_text.txt and
CX_props_eventstorestrict_text.txt. Many properties to adjust to control
which events are shown to whom.
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. You can select what review_state for events you allow on the calendar. The
default is "published" but you can add "visible" and custom review_states
as well.
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: CalendarX gives you several ways to show a link
that allows users to click on it and go to an appropriate folder where they
can add a new Event... in the Subject Bar, in the control Portlet, or in
each of the calendar cells for every view. 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.
NOTE: Add New Event links also show up as plus signs (+) in the calendar cells,
and send the specified date and time to the newly created Event. However,
as of 0.5.3 this does NOT work properly with portal_factory... the proper
date and time parameters are not picked up by the temporary event. By
default in 0.5.3 the portal_factory is bypassed so that the parameters are
properly passed along. There is an easy one-line change in the script
called cxCreateEvent in the CalendarX skins folder that will allow you to
use portal_factory despite this lack of passed parameters, and it is
documented in the code in that script. This is a priority for fixing in a
future release of CalendarX.
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 has been extensively modified in the 0.5 branch for
speed optimization. The process isn't over now, but the calendar runs
faster than the 0.4 branch by a significant margin, despite doing far more
in the querying department. There's not much more you can do.
Speed Tip: 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.
Other speed tips from previous versions are now obsolete and will have no
effect on speed in CalendarX.
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 might, but don't count on it.
+lupa+
From the current MIGRATE.txt:
MIGRATE.txt
CalendarX 0.5.3(dev) March 26 2005
(last modified for CalendarX 0.5.2)
by +lupa+ (lupaz on sf.net, lupa at zurven dot com)
Released under the GPL (see LICENSE.txt)
MIGRATION from 0.4 branch to 0.5 branch:
Don't migrate so much as create anew. Actually, there are very many code
changes for this branch of CalendarX and it may "break" your old ones.
Actually, I'm fairly certain that simply putting this CalendarX into your
Products folder, restarting or refreshing the product and expecting your
existing CalendarX instances to work is futile. They will not work.
However, you should be able to install this branch and create a new CalendarX
instance and configure it to work like the old one did... some of the property
sheet info has moved around, but the basic procedure is the same.
So if you have a live Production 0.4 branch CalendarX site, don't jump right
into this and expect the seamless upgrade that comes from an alpha release to
a beta or stable branch release. But it still reads all the standard Plone
events just likebefore, so you should be able to get a working CalendarX
instance up withinminutes configured like your old one. So put up a
"Construction" sign on your Production website while you do this. And, of
course, back up your Data.fs first. But you always do that anyway, right?
I knew you did.
OLD (0.4 branch) INSTRUCTIONS
I. Upgrading from 0.4 branch versions of CalendarX.
II. Upgrading from 0.2 branch versions of CalendarX.
III. Upgrading from 0.1 branch versions of CalendarX.
IV. When you've upgraded your Zope. (added 0.4.5)
I. Upgrading to 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.4 or higher).
2. Restart Zope, or in the ZMI you can go to 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."
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.
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.
II. Upgrading from 0.2 branch versions of CalendarX.
Question: I looked through all the docs and I don't see any instructions on
how to migrate from version 0.2.13 to 0.4.3. Since you can't use the
quickinstaller to remove 0.2.13 from Plone, will 0.4.3 simply overwrite
0.2.13 or do you have to manually remove files from the file system?
Answer: Ah, migration.
It really isn't much problem, although it is not perfectly transparent.
1. Leave your current (old) calendar in place for now. The two can run
concurrently if you wish, until the new one is all set up. Or forever (I
have both running as demos at calendarx.org).
2. All the files for the 0.2.13 branch are stored in the instance folder, so
they will not interfere with the new one at all. When you're done with
0.2.13, just delete that folder.
3. Install 0.4.3 as per instructions (untar, unzip in /Products, restart
Zope, use QuickInstaller to add CalendarX to your Plone site. Then (in
Plone), use the dropdown to add a CalendarX instance to your Plone site.
Name it whatever you want. You can change the name later in the usual
Plone way.
4. Customize your CalendarX in approximately the same way that you did before
(with 0.2.13) except that now it's more Plone-ish... you go to
portal_skins/CalendarX and find the property sheet that you want to alter,
hit Customize and then change the Properties in the Properties tab. You can
likewise customize any of the property sheets, the macros, the templates,
the scripts. THERE IS NO MECHANISM FOR DIRECT MIGRATION from the old 0.2.13
property sheets to the new ones. Most of the properties have the same names
though, so it should be fairly easy. 10 minutes tops to migrate if all your
customizing has been in the property sheets.
5. You can leave these property sheets in your /custom folder, or you can use
the ZMI and cut/paste them into your CalendarX instance folder so that they
are out of the way.
6. If you want more than one CalendarX instance, you will definitely want to
use the ZMI and cut/paste your property sheets into the local instance
folders... that way each calendar has its own look, feel, and behavior (what
events it locates, etc.).
Hope that helps.
III. Upgrading from 0.1 branch versions of CalendarX.
Ugh. No idea at this moment. Probably a bit like the ones above. Sorry, but
write me if you are having trouble. Don't upgrade, just replace the olde
one and start fresh.
IV. When you've upgraded your Zope. (added 0.4.5)
I still don't know exactly what the problem is, but when I upgraded my Zope to
2.7.3, I find that my events are being stored with the start/end dates in
Universal time instead of GMT-4 (eastern U.S.A., where my server is located.
This causes some funny time-shifting because older events that have a start
time in the late evening show up on the following day.
I think (uninformed thinking here) that start/end should be stored internally
in Universal time, and reformatted to local time for the calendar IF SO
DESIRED BY THE CALENDAR ADMINISTRATOR. That makes more sense to me... I
think. Or not.
Ten-to-one this is a configuration problem that I didn't set properly. I'll
remove this comment and explain it properly when I learn the real problem,
which I'm fairly certain is in my OS and not my Zope.
From the current CX_props_addeventlink_text.txt:
CX_props_addeventlink_text.txt
CalendarX 0.5.3(dev) March 26 2005
(last modified for CalendarX 0.5.3)
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.
This link now shows up nicely in the new portlet_calendarx, but only for
Authenticated members.
NOTE: Add New Event links also show up as plus signs (+) in the calendar cells,
and send the specified date and time to the newly created Event. However,
as of 0.5.3 this does NOT work properly with portal_factory... the proper
date and time parameters are not picked up by the temporary event. By
default in 0.5.3 the portal_factory is bypassed so that the parameters are
properly passed along. There is an easy one-line change in the script
called cxCreateEvent in the CalendarX skins folder that will allow you to
use portal_factory despite this lack of passed parameters, and it is
documented in the code in that script. This is a priority for fixing in a
future release of CalendarX.
MOD in 0.5.3: changed default for the createObjectOnClickCommand to
"cxCreateEvent" which is the name of the new script used by the +links from
the previous default Plone script, which was "createObject?type_name=Event".
For more info read below.
=== 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.
showAddEventPlusLinks boolean
Check this to include the PLUS (+) links in the views to create new events
from inside the calendar cells. These links use the cxCreateEvent script,
because the standard Plone createObject script does not allow creation of
events with other passed parameters (like start_time).
NOTE: As of version 0.5.3, these +links do NOT work properly with use of
portal_factory. Actually, it works fine but does NOT pass along the proper
start and end date/time parameters. By default, the cxCreateEvent script is
set to ignore portal_factory, but this behavior is easily changed by
customizing the cxCreateEvent script.
NOTE: The +links do NOT use the createObjectOnClickCommand string (next
property)... that's only for the Add New Event link found in the subjectlinks
bar in the header or in the portlet_cx_choices.
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:
cxCreateEvent
which will create a new CMF Event object in the target folder of the link.
If you have a different event type that you would like to create, change the
string to call the "type_name" parameter with your custom type, like this:
cxCreateEvent?type_name=KoolEvent
You can replace the meta_name "KoolEvent" with the appropriate meta_name of
your desired event type.
Alternatively, you can use the command string that uses the default Plone
script for object creation, which is:
createObject?type_name=Event
"cxCreateEvent" which is the name of the new script used by the +links from
the previous default Plone script, which was "createObject?type_name=Event".
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.
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"
This is a nice simple solution for many use cases because it allows neat and
clean storage of all events in a single folder. In order to all this to
work, you must take the steps necessary in the Plone security to allow your
users permission to write events in that folder. For those with only a few
users, you can readily use the Sharing tab on that Plone folder -- simply
scroll down and do a search on User Names (leave the Search Term field blank
and hit Perform Search to list ALL the current User names). Then select the
Users desired, and choose Owner from the Role To Assign list, and then click
the button to assign this "local" role to the selected users.
Another approach is in the ZMI to give access to this folder for ALL of your
Authenticated users. Navigate to the folder where you will store your events,
click on the Security tab and change the security setting of
"Add portal objects" in your ANE folder. In this case, uncheck "Acquire" and
check "Authenticated".
A bit more neat (so that ONLY events end up in this folder) is to customize
the portal workflow so that users create events in their own Members folders,
but then when it moves through workflow and is published, the Event is
automatically moved into the proper event folder. At this writing there
seems to be a HowTo in plone.org/documentation describing this approach. Of
course, if you DO use this approach, you won't need to use this useANEFolder
property, because you'll likely use the useMemberFolder property instead.
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.
Again, you'll need to take the proper steps to make sure the permissions are
set appropriately for your members to add events in those folders...
CalendarX is not going to presume to do this for you.
From the current CX_props_calendar_text.txt:
CX_props_calendar_text.txt
CalendarX 0.5.3(dev) March 26 2005
(last modified for CalendarX 0.5.2)
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.
Significant rearranging of properties has taken place in the
0.5 branch from older 0.4 branch properties.
Use the Properties tab to adjust the attributes of the
property sheets for the calendar as available.
=== List of Attributes ===
title string
Leave this title attribute alone.
defaultView string
Name of the default view to be displayed: month, weekbyday,
weekbyhour, or day.
dayOfWeekToStart int
Value indicates what day of the week the Month and Week
views begin on. Sunday = 0, Monday = 1, etc.
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.
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
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.
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.
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.
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!
useAdvancedQuery boolean
If checked, CalendarX will use Dieter's 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 (ie., not faster).
showSubjectBar boolean
Deprecated in 0.5 branch.
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.
Recommend using calendarOptionsMacro choice below.
calendarOptionsMacro string
New in 0.5 branch.
Default value: subjectlinks0
String to choose which macro is used to display options at the header of
the calendar. There are several to choose from in the CX_props_macro;
here is a brief listing of the pre-built ones:
subjectlinks: the original, plus the new Users picker on the right side.
Looks like the original if Users picker is not activated by the TALES
command in showUserListExpression property.
subjectlinks0 - blank subjectlinks: shows nothing, a clean calendar
Good to use with portlet_cx_choices (the default choice).
subjectlinks1 - only the subjects.
subjectlinks2 - subjects on top row, others + Users in bottom row.
subjectlinks3 - Users in right td, subjects top row, others bottom row.
subjectlinks4 - Users in right td, others top row, subjects bottom row.
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.
useNumericMonthInJumpToDateWidget boolean
New in 0.5 branch.
If checked, the month in the date-picking widget will show up as
a number (1 for January, 2 for February, etc.). If unchecked, the
months are abbreviated months as chosen by Pythons datetime month()
function. Untested, but this may result in the month abbreviations
to be rendered in the local language according to settings on the server.
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.
"USER PICKER" widget
New for 0.5 branch.
This is a new widget that shows a list of users and allows the calendar user
to select from the list of users to show ONLY the events created by those
particular users. There are currently four properties that control
the behavior of the User Picker widget.
There are currently two choices for how the users are selected for inclusion
in this widget: all users that are "Creators" found in the portal_catalog,
or a strict list of manually entered User names.
#Uses a TALES expression which if it evaluates to True will
#show a select widget to determine which USER's events will be shown
#default is (false and isManager). change 0 to 1 for (true and isManager).
showUserListExpression string
New in 0.5 branch.
Default value: python:1 and
portal.portal_membership.checkPermission('Manage users', object)
Determines whether or not the User Picker widget will be shown. This is a
string property that requires a valid TALES statement, that is then
evaluated to determine whether or not to show the User Picker. The default
value is a simple one that ONLY displays the widget for site Managers.
The "1 and" portion is completely useless, except that if you want to disable
this feature for everyone, just substitute "0" for "1" in the TALES
statement... and this lets you keep the rest of the statement there in
case you need to use it sometime. The TALES statement is evaluated via a
method defined in the CalendarXFolder.py code.
useMultiUsers boolean
New in 0.5 branch.
Default value: True
If selected, this enables you to select multiple Users in the User Picker widget for viewing.
If unselected (false), then only one User may be shown in the calendar at a time.
useListOfUsersForUserPicker boolean
New in 0.5 branch.
Default value: True
If selected, the Users that show up in the User Picker will be only those listed in the
listOfUsersForUserPicker property described below. If not selected, ALL Users that are listed
in the portal_catalog as "Creators" will be shown in the User Picker widget.
listOfUsersForUserPicker lines
New in 0.5 branch.
Default value: 3
This is the list of Users that will be shown in the User Picker widget if the
useListOfUsersForUserPicker property is true. The default simply lists three
ficticious user names to give you the idea.
REMOVED:
The following properties have been removed from CalendarX options in the 0.5 branch:
1. includeReviewStateVisible boolean
2. showPendingLink boolean
Both of these options may be handled by options for displaying events now found in the
CX_props_eventstoallow property sheet instead.
MOVED TO OTHER PROPERTY SHEETS:
The following properties have been MOVED from this property sheet to the new
CX_props_eventstoallow property sheet instead.
1. listOfSubjects lines
2. restrictToThisListOfSubjects boolean
3. eventTypes list
4. restrictToThisListOfTypes boolean
5. listOfPaths list
6. restrictToThisListOfPaths boolean
7. restrictToThisFolder boolean
8. listOfSubjectTitles list
9. useSubjectTitles boolean
From the current CX_props_css_text.txt:
CX_props_css_text.txt
CalendarX 0.5.3(dev) March 26 2005
(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)
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.
=== 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 = 35px
Height added to base for "prevnextcurrentlinks" macro (prev, next, date header, footer)
headerMarginBottom default = 15px
Bottom margin pixels for "prevnextcurrentlinks" macro (prev, next, date header, footer)
headerMarginTop default = 5px
Top margin pixels 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
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.
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")
From the current CX_props_custom_text.txt:
CX_props_custom_text.txt
CalendarX 0.5.3(dev) March 26 2005
(last modified for CalendarX 0.4.3)
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.5.3(dev) March 26 2005
(last modified for CalendarX 0.5.2)
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.
Other Properties: 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 by default, you simply tell your
portal_catalog to collect that metadata, then modify the CX_props_macros
page template to read it into your popup text.
There's also a howto on the CalendarX.org website that explains how you
can add other attributes in more detail.
=== 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 a comma-separated list of all the Subjects
that are associated with an event -- because events can have
more than one Subject selected.
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.
showPOPLocation boolean Checked = Show this info.
Whether to show the "Location" field string for this 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.5.3(dev) March 26 2005
(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)
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 all the way to the bottom. We provide a CASE STUDY of the
use of Subcalendars to create a RESOURCE SCHEDULING calendar.
=== 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 ===
Briefly, as a quick draft, here is a simple configuration that will create
a "Resource Scheduling Calendar", suitable for equipment and room reservations,
etc. You can see this calendar in action as a demo on the Crashtest site
of CalendarX.org ( http://crashtest.calendarx.org/resources )
There is a MAIN calendar, and several Subcalendars. We will call the MAIN
calendar "Resources", and create several subcalendars underneath it for the
following resource types: beamers, bicycles, cameras, laptops, and rooms.
(this needs work, but in brief)
1. Create content types for each resource event by copying the CMF Event
type in portal_types, and giving each one a unique name. Here we used "Reserve
a Beamer", "Reserve a Bicycle", etc. These are the names we used, which is
what you see when you go to the main page of the portal_types tool, and is
the "portal_type" and "Type" as listed in the catalog metadata. We created
these because we can then easily restrict the Resource calendar to display
ONLY these types for this calendar application. You can do the same thing
with Archetype-based events. We'll do that soon.
2. Create a MAIN Resources calendar:
2A. Create a new Plone folder with id=resources, and setup the folder
properties exactly as instructed in the INSTALL.txt instructions. It is
important that your properties be set up properly.
2B. Go to portal_skins and click on CX_props_calendar, and then click to
customize it into the /custom folder.
2C. Go to portal_skins and click on CX_props_subcalendar, and then click to
customize it into the /custom folder.
2D. Go to portal_skins and click on CX_props_popup, and then click to
customize it into the /custom folder.
2E. Optionally, do the same for CX_props_css and CX_props_addeventlink.
2F. In portal_skins/custom, select all these property sheets and Cut them,
and then Paste them into your new Resources folder.
3. Create a first Subcalendar for one of your resources:
3A. In your Resource folder, create a new Plone folder with id=beamers, and
setup the folder properties as instructed in the INSTALL.txt instructions.
3B. In your Resource folder, select only the CX_props_calendar and
CX_props_subcalendar sheets, and then click to Copy them, and then
navigate into your Beamers folder and Paste them.
3C. In your Beamers folder, click on the CX_props_subcalendar sheet, then
click on the Properties tab, and set the following properties:
isSubCalendar = Checked, because this is a subcalendar.
nameOfSubCalendar = Beamers
3D. In your Beamers folder, click on the CX_props_calendar sheet, then
click on the Properties tab, and set the following properties:
useMultiSubjects: checked.
listOfSubjects: Beamer1, Beamer2, (one entry per line.)
eventTypes: Reserve a Beamer
restrictToThisListOfTypes: checked.
4. Copy and paste this first Subcalendar to create four more subcalendar
folders, and rename each one (Bicycles, Cameras, Laptops, Rooms) and modify
the property sheets in each one appropriately.
5. Go back and set up the properties in the MAIN Resources folder as well.
Here is a simple guide to how and why of the main property settings for
a Resource Calendar similar to the one we are using.
MAIN calendar:
config: CX_props_calendar:
1. useMultiSubjects: checked. The cool subcalendar menuing options
ONLY will work with this option selected.
2. listOfSubjects: names of the subcalendars I'm using: Beamers,
Bicycles, Cameras, Laptops, Rooms
3. eventTypes: I'm using five new Event types created by simply
repurposing the CMF Event type, with new names and subjects.
4. restrictToThisListOfTypes: checked, because I want this calendar to
ONLY show these special reservation events.
5. useCalendarHelp: checked. I think calendar help will be needed
because subcalendars may present conceptual problems for some users.
config: CX_props_subcalendar:
1. useSubCalendarSubjectMenu: checked, because you need that to
properly navigate to your subcalendars.
2. listOfSubCalendars: fill this with the list of IDs for the
subcalendars. Here this is: beamers, bicycles, cameras, laptops,
and rooms.
3. isSubCalendar - nope, not one.
4. nameOfSubCalendar - nope.
config: CX_props_popup:
1. expanded popup coverage by checking several options, including:
showPOPTitle, Type, Subject, Start, End, Creator, Description.
SUB calendars:
config: CX_props_calendar:
1. useMultiSubjects: checked. The cool subcalendar menuing options
ONLY will work with this option selected.
2. listOfSubjects: names of the subjects desired for this subcalendar.
For example, in the Bicycles subcalendar I'm using: Bicycle1,
Bicycle2, etc. If this was a school calendar, these might be names
of teachers, or sports, or... whatever you want.
3. eventTypes: I list the one type of Event that I want to show in this
subcalendar because I'm restricting my events this way: for my
Bicycle subcalendar, this uses: Reserve a Bicycle.
4. restrictToThisListOfTypes: checked, because I want this calendar to
ONLY show these special reservations for bicycle events.
5. useCalendarHelp: checked. I think calendar help will be needed
because subcalendars may present conceptual problems for some users.
config: CX_props_subcalendar:
1. useSubCalendarSubjectMenu: UNchecked. ONLY for main calendars.
2. listOfSubCalendars: Unused. ONLY for main calendars.
3. isSubCalendar - Yes, because this is a subcalendar.
4. nameOfSubCalendar - A name (Bicycle).
config: CX_props_popup:
1. NONE, don't want one. Drops through and acquires values from
MAIN calendar by acquisition.
That's all. Now go and add lots of events and see how it all works. See
how the navigation works, and allows you to filter according to the types of
resources you may want, or lets you drill down and only look at one resource
at a time in the subcalendars.
Go crazy and dream up new uses for subcalendars. I think it should work
great for school calendars, and I'll probably be setting one up that way
soon.
+lupa+ CalendarX.org
From the current CX_props_eventdisplays_text.txt:
CX_props_eventdisplays_text.txt
CalendarX 0.5.3(dev) March 26 2005
(last modified for CalendarX 0.4.7)
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 CX_props_eventstoallow_text.txt:
CX_props_eventstoallow_text.txt
CalendarX 0.5.3(dev) March 26 2005
(last modified for CalendarX 0.5.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_eventstoallow.
Use the Properties tab to adjust the attributes of the
calendar as available.
This property sheet controls what events will be shown on the calendar. You
can allow events according to their folder path, review state, Subject
categories, Event type, and/or a list of Creators.
=== List of Attributes ===
title string
Leave this title attribute alone.
showCMFCalendarStates boolean
showSpecifiedStates boolean
statesToShow lines
Together, these three attributes allow you to control the choice
of what three review states of events to display on your calendar.
Traditionally, the default in this calendar as well as what makes sense with
the default Plone workflow is to show 'published' events only. This is the
default state that comes with CMFCalendar, so the first of these options
allows you to set CalendarX to read the CMFCalendar setting and go with that.
The second two properties allow you to specify a list of review states that
you want to appear in the calendar. If checked, CalendarX uses the list here
in the statesToShow property as the states that will be included on the
calendar.
NOTE: LIST STATES ONE PER LINE.
The default values included here are the 'published' and 'visible' states.
NOTE: ABOUT PRIVATE EVENTS
A 'private' event is a state that can only be added by the owner of an
Event content object. It also can only be viewed by the owner of the Event
(and also any Managers). If you include 'private' in this list, any
private events will only show up on the calendar for their owners, so it's
safe... but it will be annoying for Managers, and it's unnecessary. If
the use of private events is desired, they will also be displayed on the
calendar if you use the showPublicPrivateLink property found on the
CX_props_calendar property sheet. The showPublicPrivateLink (it says "Show
Only Personal Event" on the new control portlet) shows all events created
by the current user, without regard to review state.
restrictToThisListOfSubjects boolean
listOfSubjects lines
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.
useSubjectTitles boolean
listOfSubjectTitles lines
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.
restrictToCMFCalendarTypes:boolean=
restrictToThisListOfTypes boolean
eventTypes lines
Together, these three allow you to restrict what types of content objects
will be picked up on your calendar. If you want your calendar to show ALL
event types available, simply unselect both of these options and ANY
content type that has a start and an end property will be cataloged and
shown on the calendar.
The default types handled by the CMFCalendar are 'Event' and 'AT Event' (in
Plone 2.0.x). Use the restrictToCMFCalendarTypes property to match your
CalendarX instance to those used by the CMFCalendar.
To choose your own list of types, 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.
restrictToThisListOfPaths boolean
listOfPaths lines
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.
Use Case: This is good for Group folders. Set up a calendar in a group's
communal folder and check this option. Then only events created within
the group's folder will be shown, and Plone's normal security will keep
other groups from seeing this calendar. It will NOT however show any
public events from elsewhere on the same portal... just inside the group
folder.
restrictToThisListOfCreators boolean
listOfCreators lines
Together, these two allow you to restrict whose events will be shown on a
calendar. Enter one username per line in the listOfCreators property and
check the other propery, and you're done.
NOT IMPLEMENTED IN 0.5.0 PRE-RELEASE. WILL BE ADDED SOON.
From the current CX_props_eventstorestrict_text.txt:
CX_props_eventstorestrict_text.txt
CalendarX 0.5.3(dev) March 26 2005
(last modified for CalendarX 0.5.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_eventstorestrict.
Use the Properties tab to adjust the attributes of the
calendar as available.
This property sheet controls what events will be restricted from showing up
on the calendar according to the User's roles, group membership or username.
You can restrict events according to path, review state, Subject categories,
Event type, and/or a list of Creators. In brief, CalendarX applies the
'events to allow' properties first to gather a list of events, and then looks
at the User and these properties to see how that original list should be
further restricted for security.
This is a long property sheet. It is broken down as follows:
#1 Types , restricted or allowable by Roles, Users, Groups
#2 Subjects , restricted or allowable by Roles, Users, Groups
#3 Paths , restricted or allowable by Roles, Users, Groups
#4 Creators , restricted or allowable by Roles, Users, Groups
#5 Review States, restricted or allowable by Roles, Users, Groups
There are six ways of restricting each, and three properties to control each
way, making a total of 90 properties on this sheet. Please take care to set
your calendar up appropriately if relying on these properties for secure
access to any sensitive information. And if you're really concerned about
security, remember that John Ashcroft is looking for a job :)
=== List of Attributes ===
title string
Leave this title attribute alone.
#1a TYPES restricted by ROLES
disallowTypesForRoles boolean
listOfDisallowedTypesForRoles lines
listOfDisallowedRolesForTypes lines
Together, these three properties restrict the TYPE of event according to
the roles of the User.
A typical use of this would be in an organization that runs a public website,
but wants a type of Events ('Member Event') that are only visible to
Members (those who have joined and are logged in to the site). To do this,
simply put 'Member Event' in the listOfDisallowedTypesForRoles list, add
'Anonymous' to the listOfDisallowedRolesForTypes list, and check the
property to enable disallowTypesForRoles. Now the calendar will check the
role of the current User before displaying any 'Member Event'.
NOTE: Double check to make sure that you correctly spell and capitalize
the names of the Types and the Roles that you use here, or else they will
not properly match the values stored in the catalog, and will not properly
restrict these events as intended.
#1b TYPES allowable by ROLES
allowTypesOnlyForRoles boolean
listOfAllowedTypesOnlyForRoles lines
listOfAllowedRolesOnlyForTypes lines
Together, these three properties enable you to allow certain Types of events
ONLY for Users with certain roles.
A typical use of this would be in an organization that runs a public website,
but wants its Staff people to be able to see Staff Events that are only
visible to Staff members (those given a Staff role). To do this, simply
put 'Staff Event' in the listOfDisallowedTypesForRoles list, add 'Staff'
to the listOfDisallowedRolesForTypes list, and check the property for
disallowTypesForRoles.
#1c TYPES restricted by USERS
disallowTypesForUsers boolean
listOfDisallowedTypesForUsers lines
listOfDisallowedUsersForTypes lines
Together, these three properties restrict the TYPE of event according to
the identity of the specific User visiting the calendar.
List the Types you want to restrict in the listOfDisallowedTypesForUsers
property. List the Users (usernames) that should be kept away from these
Types in the listOfDisallowedUsersOnlyForTypes property.
#1d TYPES allowable by USERS
allowTypesOnlyForUsers boolean
listOfAllowedTypesOnlyForUsers lines
listOfAllowedUsersOnlyForTypes lines
Together, these three properties enable you to allow certain Types of events
ONLY for certain Users.
List the Types you want to allow in the listOfAllowedTypesOnlyForUsers
property. List the Users (usernames) who should have access to these Types
in the listOfAllowedUsersOnlyForTypes property.
#1e TYPES restricted by GROUPS
disallowTypesForGroups boolean
listOfDisallowedTypesForGroups lines
listOfDisallowedGroupsForTypes lines
Together, these three properties restrict the TYPE of event according to
the group memberships of the specific User visiting the calendar.
List the Types you want to restrict in the listOfDisallowedTypesForGroups
property. List the Group names who should be kept away from these Types
in the listOfDisallowedUsersOnlyForGroups property.
#1f TYPES allowable by GROUPS
allowTypesOnlyForGroups boolean
listOfAllowedTypesOnlyForGroups lines
listOfAllowedGroupsOnlyForTypes lines
Together, these three properties enable you to allow certain Types of events
ONLY for members of certain groups.
List the Types you want to allow in the listOfAllowedTypesOnlyForGroups
property. List the Group names that should have access to these types in
the listOfAllowedGroupsOnlyForTypes property.
#2a SUBJECTS restricted by ROLES
disallowSubjectsForRoles boolean
listOfDisallowedSubjectsForRoles lines
listOfDisallowedRolesForSubjects lines
Together, these three properties restrict events with certain Subjects
according to the roles of the specific User visiting the calendar.
List the Subjects you want to restrict in the
listOfDisallowedSubjectsForRoles property. List the Roles that should be
kept away from these Subjects in the listOfDisallowedRolesForSubjects
property.
#2b SUBJECTS allowable by ROLES
allowSubjectsOnlyForRoles boolean
listOfAllowedSubjectsOnlyForRoles lines
listOfAllowedRolesOnlyForSubjects lines
Together, these three properties enable you to allow events with certain
Subjects to be shown ONLY for members with certain Roles.
List the Subjects you want to allow in the listOfAllowedSubjectsOnlyForRoles
property. List the Roles that should have access to these Subjects in
the listOfAllowedRolesOnlyForSubjects property.
#2c SUBJECTS restricted by USERS
disallowSubjectsForUsers boolean
listOfDisallowedSubjectsForUsers lines
listOfDisallowedUsersForSubjects lines
Together, these three properties restrict events with certain Subjects
according to the username of the specific User visiting the calendar.
List the Subjects you want to restrict in the
listOfDisallowedSubjectsForUsers property. List the Roles that should be
kept away from these Subjects in the listOfDisallowedUsersForSubjects
property.
Use case: You know that annoying guy from marketing that the VP put on
your product development team? Well with this tool, now he really
won't know about the meetings... just list his username here along with the
Subject 'Product Development Meeting', and he'll never know what hit him.
Just remember to take him back off the list right after each meeting, so
he won't suspect anything. Then complain that he's a slacker who keeps
missing the meetings... he'll be gone in no time.
#2d SUBJECTS allowable by USERS
allowSubjectsOnlyForUsers boolean
listOfAllowedSubjectsOnlyForUsers lines
listOfAllowedUsersOnlyForSubjects lines
Together, these three properties enable you to allow events with certain
Subjects to be shown ONLY for certain Users.
List the Subjects you want to allow in the listOfAllowedSubjectsOnlyForUsers
property. List the Usernames that should have access to these Subjects in
the listOfAllowedUsersOnlyForSubjects property.
#2e SUBJECTS restricted by GROUPS
disallowSubjectsForGroups boolean
listOfDisallowedSubjectsForGroups lines
listOfDisallowedGroupsForSubjects lines
Together, these three properties restrict events with certain Subjects
according to the Group memberships of the specific User.
List the Subjects you want to restrict in the
listOfDisallowedSubjectsForGroups property. List the Groups that should be
kept away from these Subjects in the listOfDisallowedGroupsForSubjects
property.
Note: Groupnames here do NOT need the prefix that Plone puts on groups.
Groups in Plone are a type of user, and as such simply have a prefix at
the beginning of the name. So for a 'staff' group, this usually shows up
in the catalog as 'group_staff', where 'group_' is the prefix. Don't use
the prefix here... just say 'staff' because CalendarX strips off the prefix
internally.
#2f SUBJECTS allowable by GROUPS
allowSubjectsOnlyForGroups boolean
listOfAllowedSubjectsOnlyForGroups lines
listOfAllowedGroupsOnlyForSubjects lines
Together, these three properties enable you to allow events with certain
Subjects to be shown ONLY for certain Users belonging to certain Groups.
List the Subjects you want to allow in the listOfAllowedSubjectsOnlyForGroups
property. List the Groupnames that should have access to these Subjects in
the listOfAllowedGroupsOnlyForSubjects property.
#3a PATHS restricted by ROLES
disallowPathsForRoles boolean
listOfDisallowedPathsForRoles lines
listOfDisallowedRolesForPaths lines
Together, these three properties restrict events located in certain folder
paths according to the roles of the specific User visiting the calendar.
List the folder paths you want to restrict in the
listOfDisallowedPathsForRoles property. List the Roles that should be
kept away from these folder paths in the listOfDisallowedRolesForPaths
property.
Note: To use this feature, you must use a full path exactly as found in your
path index. Two examples:
/clients/companyplonesite/Members/fred
/clients/companyplonesite/staff
These two paths represent folders where Events can be stored that will
be kept away from certain users using these properties. Also folders
deeper than this (subfolders of /staff, for example) will also be
disallowed. 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. In the
future of CalendarX (this branch), we'll change this so that you only need
to use the path from the portal root ('/staff').
#3b PATHS allowable by ROLES
allowPathsOnlyForRoles boolean
listOfAllowedPathsOnlyForRoles lines
listOfAllowedRolesOnlyForPaths lines
Together, these three properties enable you to allow events located in certain
folder paths to be shown ONLY for members with certain Roles.
List the folder paths you want to allow in the listOfAllowedPathsOnlyForRoles
property. List the Roles that should have access to these folder paths in
the listOfAllowedRolesOnlyForPaths property.
Use Case: This is a good supplement to some of Plone's built in security
methods that are not implemented fully. An example is setting up a Plone
Folder with an id of 'staff', and then creating a user group called
'Staff', and in the Security tab of your portal, you create a new Role also
called 'Staff'. In acl_users, you assign the new 'Staff' role to the new
'Staff' group. And finally, in the '/staff' folder, you set up a local
role (using the Sharing tab in Plone) for the 'staff' group as Owner or
Manager.
This *should* be enough. This will work for most other security uses now,
in that anyone NOT belonging to the Staff group can't see the /staff folder,
and can't access the contents. But unfortunately, Events placed in the
/staff folder will still show up on the calendar for everyone to see. Of
course, if a non-staff user clicks on one of those Events in the /staff
folder they will be denied by the Plone security mechanism, but the
unfortunate part of this is that Plone's security is missing a proper check
on folder security for content within the folder. The Plone core developers
know about this problem (see http://plone.org/development/plips/16 for more
information about it... it's a problem with the way the portal_catalog
keeps track of security) and it should be fixed by Plone 2.1 or so.
Meanwhile, to keep CalendarX from showing these staff events to non-staff,
simply put '/myportal/staff' in the listOfAllowedPathsOnlyForRoles list,
and put 'staff' in the listOfAllowedRolesOnlyForPaths list. Now ONLY
staff will have these events show up on their calendar... everyone else
will be spared the agony of staff meetings.
#3c PATHS restricted by USERS
disallowPathsForUsers boolean
listOfDisallowedPathsForUsers lines
listOfDisallowedUsersForPaths lines
Together, these three properties restrict events located in certain folder
paths according to the username of the specific User visiting the calendar.
List the folder paths you want to restrict in the
listOfDisallowedPathsForUsers property. List the usernames that should be
kept away from these folder paths in the listOfDisallowedUsersForPaths
property.
#3d PATHS allowable by USERS
allowPathsOnlyForUsers boolean
listOfAllowedPathsOnlyForUsers lines
listOfAllowedUsersOnlyForPaths lines
Together, these three properties enable you to allow events located in certain
folder paths to be shown ONLY for members with certain usernames.
List the folder paths you want to allow in the listOfAllowedPathsOnlyForUsers
property. List the usernames that should have access to these folder paths
in the listOfAllowedUsersOnlyForPaths property.
#3e PATHS restricted by GROUPS
disallowPathsForGroups boolean
listOfDisallowedPathsForGroups lines
listOfDisallowedGroupsForPaths lines
Together, these three properties restrict events located in certain folder
paths according to the Group memberships of the specific User visiting the
calendar.
List the folder paths you want to restrict in the
listOfDisallowedPathsForGroups property. List the Group names that should
be kept away from these folder paths in the listOfDisallowedGroupsForPaths
property.
#3f PATHS allowable by GROUPS
allowPathsOnlyForGroups boolean
listOfAllowedPathsOnlyForGroups lines
listOfAllowedGroupsOnlyForPaths lines
Together, these three properties enable you to allow events located in certain
folder paths to be shown ONLY for members belonging to certain Groups.
List the folder paths you want to allow in the listOfAllowedPathsOnlyForGroups
property. List the Group names that should have access to these folder
paths in the listOfAllowedGroupsOnlyForPaths property.
#4a CREATORS restricted by ROLES
disallowCreatorsForRoles:boolean
listOfDisallowedCreatorsForRoles:lines
listOfDisallowedRolesForCreators:lines
Together, these three properties restrict events created by certain users
(the Creator of those events) according to the roles of the specific User
visiting the calendar.
List the Creators you want to restrict in the
listOfDisallowedCreatorsForRoles property. List the Roles that should be
kept away from the events originated by these Creators in the
listOfDisallowedRolesForCreators property.
#4b CREATORS allowable by ROLES
allowCreatorsOnlyForRoles:boolean
listOfAllowedCreatorsOnlyForRoles:lines
listOfAllowedRolesOnlyForCreators:lines
Together, these three properties enable you to allow events created by certain
users to be shown ONLY for members with certain Roles.
List the Creators you want to allow in the listOfAllowedCreatorsOnlyForRoles
property. List the Roles that should have access to these Creators' events
in the listOfAllowedRolesOnlyForCreators property.
#4c CREATORS restricted by USERS
disallowCreatorsForUsers:boolean
listOfDisallowedCreatorsForUsers:lines
listOfDisallowedUsersForCreators:lines
Together, these three properties restrict events created by certain users
(the Creator of those events) according to the username of the specific
User visiting the calendar.
List the Creators you want to restrict in the
listOfDisallowedCreatorsForUsers property. List the usernames that should
be kept away from the events originated by these Creators in the
listOfDisallowedUsersForCreators property.
#4d CREATORS allowable by USERS
allowCreatorsOnlyForUsers:boolean
listOfAllowedCreatorsOnlyForUsers:lines
listOfAllowedUsersOnlyForCreators:lines
Together, these three properties enable you to allow events created by certain
users (the Creator of those events) to be shown ONLY for members with
certain usernames.
List the Creators you want to allow in the listOfAllowedCreatorsOnlyForUsers
property. List the usernames that should have access to the events
originated by these Creators in the
listOfAllowedUsersOnlyForCreators property.
#4e CREATORS restricted by GROUPS
disallowCreatorsForGroups:boolean
listOfDisallowedCreatorsForGroups:lines
listOfDisallowedGroupsForCreators:lines
Together, these three properties restrict events created by certain users
(Creator of those events) according to the Group memberships of the
specific User visiting the calendar.
List the Creators you want to restrict in the
listOfDisallowedCreatorsForGroups property. List the Group names that
should be kept away from the events originated by these Creators in the
listOfDisallowedGroupsForCreators property.
#4f CREATORS allowable by GROUPS
allowCreatorsOnlyForGroups:boolean
listOfAllowedCreatorsOnlyForGroups:lines
listOfAllowedGroupsOnlyForCreators:lines
Together, these three properties enable you to allow events created by certain
users to be shown ONLY for members belonging to certain Groups.
List the folder paths you want to allow in the
listOfAllowedCreatorsOnlyForGroups property. List the Group names that
should have access to the events originated by these Creators in the
listOfAllowedGroupsOnlyForCreators property.
#5a STATES restricted by ROLES
disallowStatesForRoles:boolean
listOfDisallowedStatesForRoles:lines
listOfDisallowedRolesForStates:lines
Together, these three properties restrict events with certain review states
according to the roles of the specific User visiting the calendar.
List the review states you want to restrict in the
listOfDisallowedStatesForRoles property. List the Roles that should be
kept away from the events with these review states in the
listOfDisallowedRolesForStates property.
#5b STATES allowable by ROLES
allowStatesOnlyForRoles:boolean
listOfAllowedStatesOnlyForRoles:lines
listOfAllowedRolesOnlyForStates:lines
Together, these three properties enable you to allow events with certain
review states to be shown ONLY for members with certain Roles.
List the review states you want to allow in the
listOfAllowedStatesOnlyForRoles property. List the Roles that should have
access to the events with these review states in the
listOfAllowedRolesOnlyForStates property.
#5c STATES restricted by USERS
disallowStatesForUsers:boolean
listOfDisallowedStatesForUsers:lines
listOfDisallowedUsersForStates:lines
Together, these three properties restrict events with certain review states
according to the username of the specific User visiting the calendar.
List the review states you want to restrict in the
listOfDisallowedStatesForUsers property. List the usernames that should be
kept away from these folder paths in the listOfDisallowedUsersForStates
property.
#5d STATES allowable by USERS
allowStatesOnlyForUsers:boolean
listOfAllowedStatesOnlyForUsers:lines
listOfAllowedUsersOnlyForStates:lines
Together, these three properties enable you to allow events with certain
review states to be shown ONLY for members with certain usernames.
List the review states you want to allow in the
listOfAllowedStatesOnlyForUsers property. List the usernames that should
have access to these folder paths in the listOfAllowedUsersOnlyForStates
property.
#5e STATES restricted by GROUPS
disallowStatesForGroups:boolean
listOfDisallowedStatesForGroups:lines
listOfDisallowedGroupsForStates:lines
Together, these three properties restrict events with certain review states
according to the Group memberships of the specific User visiting the
calendar.
List the review states you want to restrict in the
listOfDisallowedStatesForGroups property. List the Group names that should
be kept away from the objects with these review states in the
listOfDisallowedGroupsForStates property.
#5f STATES allowable by GROUPS
allowStatesOnlyForGroups:boolean
listOfAllowedStatesOnlyForGroups:lines
listOfAllowedGroupsOnlyForStates:lines
Together, these three properties enable you to allow events with certain
review states to be shown ONLY for members belonging to certain Groups.
List the folder paths you want to allow in the
listOfAllowedStatesOnlyForGroups property. List the Group names that
should have access to the objects with these review states in the
listOfAllowedGroupsOnlyForStates property.
From the current HISTORY.txt:
HISTORY.txt
CalendarX 0.5.3(dev) March 26 2005
(last modified for CalendarX 0.5.3)
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 calendar for Plone.
History:
v0.5.3(dev)
Code base: v0.5.2(dev)
Status (development): Works for me, known issue with portal_factory is noted
below.
List of changed code files: helpcx.pt, CX_props_macros.pt, cxCreateEvent.cpy,
weekbyhour.pt, weekbyday.pt, month.pt, portlet_calendarxp.pt,
calendarPrint.css.
Overview of changes: Fixed helpcx.pt so that it works properly with 0.5
branch. Fixed the +link bug for datestrings in the URL query that were not
properly quoted for use in query strings. Fixed portlet_calendarxp bug
that displayed wrong events in overlapping dates (march 1 and april 1 in
the same view). Fixed calendarPrint problem: now removing subjectlinks
properly. Added new property to cx_props_addeventlink to turn on/off
the +links, and made mods to utilize this property.
Attempted but did NOT fix the problem with addNewEvent links not using
portal_factory when Events are selected there: current status is that
portal_factory is bypassed, but with a documented one-line change in
cxCreateEvent.py, you can allow portal_factory to be used even though the
proper date, time, Title and Description parameters will NOT be passed
in to the temporary event.
mod: helpcx.pt: removed xpub and added CXsheetlist code, and moved/fixed
CSS/JS calls up into the HEAD tag for XHTML compatibility, and added a
few other changes for XHTML too. And added a small bit of new text to
describe the +links for adding new events. Anyone using the Help tabs
for their users should consider rewriting the Help to make it more
applicable to their specific portal use.
mod: CX_props_macros.pt: hoursdisplay: added url_quote to the date strings
in the URL query for use in the day template. NOTE: ONLY url_quote the
dates, not the entire query string. Can't do the '?', maybe other parts.
Be careful.
mod: cxCreateEvent.cpy: added url_unquote because we now use url_quote on the
datestrings because they can be very complex ("GMT+1" needs this because
without quoting it, the + signs turn to spaces).
mod: weekbyhour.pt, weekbyday.pt, month.pt: added url_quote in the date
strings for +links.
mod: portlet_calendarxp.pt: fixed the bug in the popups that was bringing
wrong info in for overlapping date numbers (march 1 and april 1 in same
month view).
mod: CX_props_macros.pt: added class="subjectlinksrow" to tag in
all the subjectlinks macros to fix Printing problem (subjectlinks was
showing up when it should have been not). Also took HR tag out of the
copyright macro.
mod: calendarPrint.css: added these lines to visualNoPrint:
TABLE.caltabs TR.subjectlinksrow, /* subjectlinks */
DIV.calxcopyright, /* the copyright macro */
to get rid of them in print mode. Left alone the earlier, but apparently
unproductive line where SPAN.subjectlinks was used.
mod: cxCreateEvent.cpy: many changes inside to try and fix it so that
portal_factory can be used... but it doesn't work. As of this release,
portal_factory use with Events DOES NOT put in the proper date, time as it
does with non-use of portal_factory. Can't seem to get it right, but that
seems to be because you CAN'T change a temporary object because it is just
sitting in the REQUEST object, and portal_factory doesn't seem to have tools
for making these changes BEFORE it goes into the REQUEST. I can envision
some deep voodoo ways of doing this (monkeypatch), but am hoping there is a
simpler means. This is a first priority for the next release, and I would
love to hear from anyone with ideas.
mod: cx_props_addeventlink.props: changed default Command string to use
cxCreateEvent instead of default Plone createObject script. See docs
for detail.
mod: cx_props_addeventlink.props: added showAddEventPlusLinks boolean
property to turn on and off the +links inside the calendar cells. Updated
the docs file to reflect this change.
mod: CX_props_macros.pt, month.pt, weekbyday.pt, weekbyhour.pt: modded to
use the new showAddEventPlusLinks boolean property.
History:
v0.5.2(dev)
Code base: v0.5.1(dev) plus changes in 0.4.13 and 0.4.14(stable)
Status (development): Works for me, no/few known bugs.
Overview of changes: XHTML compatible code for calendar and portlets. Fixed
the Daylight Savings Time bug. Fixed the tuple index bug in subjecttitles.
Added code to show Title, Description and print, email action icons, if
desired. Mod to show Location in JS popup text block. New portlet
(portlet_calendarxp) that is a near duplicate of portlet_calendar Plone
standard, but works with a CalendarX instance. Create New Event links
(plus signs) now show up in every cell on all the views for appropriate
users. Fixed another DST bug in month.pt.
mod: CX_props_macros.pt, day.pt, month.pt, weekbyday.pt, weekbyhour.pt:
added a "headstuff" macro and calls that put it into each view template.
headstuff adds title, description and action icons (email, print, etc.).
mod: CX_props_calendar.props: added a showHeaderTitleAndIcons property that
turns on/off the headstuff macro. Default is ON (show these). Condition
is tested in headerstuff macro in CX_props_macros.
mod: CX_props_macros_portlet.pt, CX_props_macros.pt, portlet_cx_choices.pt,
day.pt, month.pt, weekbyday.pt, weekbyhour.pt: changes to make XHTML valid
code throughout. Seems to be ok. Not tested with all manner of interesting
options for event display added. Test your site for validity and report
any problems to lupa (http://validator.w3.org).
bugfix: CX_props_macros.pt, CX_props_macros_portlet.pt: subjectlinks: changed
TWO lines to fix a bug if there are more Subjects than Subject Titles.
Added a python script (below) to retrieve list of titles safely instead
of directly calling it via getCXAttributes.py.
new: getListOfSubjectTitles.py. Script that safely retrieves the titles from
listOfSubjectTitles property. If there are too many Subjects, the script
appends blank titles to the end of the list to avoid a tuple indexing error.
modded from the version in 0.4 branch to use CXsheetlist.
bugfix: getNumOfDays.py: Display bug in April 2005 was recognized where all
events starting between April 3-30, 2005 and displayed on the April month
view would display their rollover (mouseover) highlighting for the
proper number of days, but shifted one day too early... for single day
events, the day before the event would be highlighted. This was traced to
a problem calculating the number of days from the start of the month when
crossing the boundary for Daylight Savings Time. I think this fix is only
important for servers set to adjust for DST... but you never know, and the
the fix will not cause any problems if DST is ignored on your site.
mod: CX_props_popup.props: added a showPOPLocation property (default=false)
mod: getDictCommon: gather, pass showPOPLocation property in Dict
mod: CX_props_macros.pt: use showPOPLocation property in popuptextbox macro
new: portlet_calendarxp.pt: clone of portlet_calendar (Plone default) that
reads data from a CalendarX instance. Slight differences like this one
includes the dates of preceding, trailing months. Otherwise similar.
mod: getDaysOfTheWeekAbbreviated.py: added a "len" parameter that specifies
the number of characters in the abbreviation [must be integer 1, 2, or 3].
mod: getDictMonth.py: fixed a spurious comment, no code change.
bugfix: mod: getEventDictMonth.py: I didn't follow my own convention. In
CalendarX I've been showing events to end on the previous day if their
end time is midnight: e.g., if an event ends at midnight on Saturday (12am
Saturday), then CalendarX stops the highlighting on Friday (not extending
it to Saturday). THE BUG is that the date displayed was still extending to
the following day. THE FIX is I added a couple lines to tell the
datestring to back up one day if the end time was at midnight on a
multi-day event. Same code change as fixed in branch 0.4.13.
mod: CX_props_macros.pt, day.pt, month.pt, weekbyday.pt, weekbyhour.pt: made
changes to create (+) plus sign links on all the views to allow addition
of a new event on that day or at that hour in the calendar. THANKS SCOTT!!
bugfix: month.pt. After Daylight Savings Time changes, the start DateTime
would be miscalculated. Use a getStartOfDay() wrapped around the startDate
call fixes this. Seems to be no related (too long a day) problem in
October when DST begins.
v0.5.1(dev)
Code base: v0.5.0(dev) plus changes in 0.4.12(stable)
Status (development): Works for me, no/few known bugs, but many new features
and little or no thorough testing yet.
new: here's a list of new scripts, templates, etc.
calendar_portlet.css.dtml: css for portlet_calendarx.pt
calendarPrint.css.dtml: css for Print version of calendarx
CX_props_macros_portlet.pt: macros for the two portlets
getContLaterEventsWBH.py: speeds up weekbyhour view by minimizing queries.
getCXPortletContext.py: sets the context for portlet_calendarx to match
that of the referred CalendarX instance.
getCXSheetlist.py: speeds up attribute gathering by reducing skins usage
month_portlet.css.dtml: css for portlet_calendarx.pt
mod: here's a list of heavily modified scripts, templates, etc.
month.pt: many changes to accommodate CXSheetlist
day.pt: many changes to accommodate CXSheetlist
weekbyday.pt: many changes to accommodate CXSheetlist
weekbymonth.pt: many changes to accommodate CXSheetlist
CX_props_macros.pt: many changes to accommodate CXSheetlist
portlet_calendarx.pt: many changes to make it work better. you still have
to configure it by adding a path to the CalendarX instance that it uses
for determining which events it should show.
mod: A bit of explanation on the speed optimizations that took place for this
release.
#1: SPEED UP THE PROPERTY SHEETS
The getCXAttribute script was slow because it was used very
often, even inside of loops where it would get called repeatedly, and it
was expensive because it utilized the Plone skins methods to find the
appropriate property sheet. To fix this, I did two things: A) took it out
of all loops where it needn't be repeatedly called... just call it once
before the loop starts, and B) introduce a new list object called
CXSheetlist that is generated once at the beginning of each view, and
consists simply of a list of references to the property sheet objects.
Then I modified all the calls to getCXAttribute to include the CXSheetlist
which allows getCXAttribute to bypass the skinning mechanism and go
directly to the property sheets to get the information. Nothing is
sacrificed but simplicity; the skinning mechanism is only hit once instead
of dozens or hundreds of times.
#2 SPEED UP THE QUERIES
A query to the catalog is fairly fast, but the original design required
at least one and sometimes multiple queries FOR EACH CELL displayed. So a
month view would have up to 42 day cells, each getting two queries. I
found that a list comprehension is about 10 times faster than a new query,
so I went through all the code and do a minimum number of queries to the
catalog at the beginning of each view, and then use list comprehensions to
parse the catalog results over and over for each cell. Now the CalendarX
views are much faster than before, and faster than the 0.4 branch queries
even though much more complicated work is being performed in 0.5.
v0.5.0(dev)
Code base: v0.4.10(stable)
Status (development): Works for me, no known bugs, but many new features
and no thorough testing yet.
new: here's a list of new scripts, templates, etc.
CX_props_eventstoallow.props: what events to allow on the calendar
CX_props_eventstorestrict.props: what events to restrict from the calendar
CX_props_macros_portlet.pt: macros for the new cx_choices portlet
getBaseDisallowQuery.py: sets up the query for disallowed events
getBaseQuery.py: sets up the query for allowed events
getCreatorList.py: gets a list of Creators to populate the new user picker
getDaysOfTheWeekAbbreviated.py: abbreviations for new portlet_calendarx
getGroupList.py: gets a list of groups for a new group picker widget (soon)
getMonthName.py: abbreviations for JumpToDate widget
portlet_calendarx.pt: portlet for a month calendar view
portlet_cx_choices.pt: portlet with controls for calendar options
mod: here's a list of heavily modified scripts, templates, etc.
CX_props_calendar.props: a couple new properties, then removed all the
properties related to allowing certain classes of events for all users
and put them in the new CX_props_eventstoallow.props sheet.
getEventsBeforeAQ.py
getEventsBeforeZC.py
getEventsBetweenAQ.py
getEventsBetweenZC.py: many changes to make these queries more sane and
manageable, and better documented internally.
mod: there are a few other changes here and there that I didn't keep proper
track of. It's a significantly new release branch.
[for pre-v0.5.0 History, see HISTORY.txt files with those releases.]
From the current INSTALL.txt:
INSTALL.txt
CalendarX 0.5.3(dev) March 26 2005
(last modified for CalendarX 0.5.2)
by +lupa+ (lupaz on sf.net, lupa at zurven dot com)
Released under the GPL (see LICENSE.txt)
New: portlet_calendarxp requires mods to ploneCustom.css. See section
II-10. below.
Note: CalendarX 0.5 branch is a Plone Product. It installs as a Product
in your Products folder. The instructions below explain this.
I. Software requirements
II. Instructions for Installation for the first time.
III. Documentation available.
IV. Caveats.
Old IV. Instructions for upgrading to new versions of CalendarX
(MOVED these instructions to MIGRATE.txt)
I. Software requirements
Software Requirements for CalendarX (0.5 branch):
1. Plone 2.0+ along with Python/Zope. Tested on Plone 2.0.5, Zope 2.7.3.
As of branch 0.5+, CalendarX no longer works on Plone 1.0.x.
Software Options, Suggestions (NOT REQUIRED):
1. Python 2.2+ (required if AdvancedQuery is used.)
2. Zope 2.6.2+ (may work on earlier Zopes, but untested. Python 2.2+ is not
standard until Zope 2.7+)
3. AdvancedQuery Product for Zope
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 CX_props_calendar property sheet.
II. Instructions for Installation for the first time.
1. Make sure you have the required software and additional Zope Products
in place.
2. Acquire the CalendarX-0.5.x.tar.gz file from sourceforge. This unzips as
a tar file, which untars as a single folder, called CalendarX-0.5.x.
3. Place this folder in your INSTANCE_HOME/Products/ folder and rename it
the folder to /Products/CalendarX instead of /Products/CalendarX-0.5.x.
4. Restart Zope.
5. IN PLONE: 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 NOT 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. NOTE: Using the /custom
folder is fine, but the next note (#9) explains why you might not want to.
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: Find and click on an object in /portal_skins/CalendarX that you want
to customize (start with CX_props_calendar), hit the Customize button to
make a copy of it in your /portal_skins/custom folder, then CUT/PASTE it
out of /custom and into your new CalendarX instance, and then make your
changes to this property sheet, or python script, or page template.
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.
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.
10. PORTLET_CALENDARX.
There are now THREE portlets shipping with CalendarX. One is a controller
portlet that moves the choices (selecting subjects, etc) off the calendar
view and over into a slot on the side. The other two are portlets that
can be used to replace the standard "portlet_calendar" that comes with
Plone: portlet_calendarx, and portlet_calendarxp.
Portlet 1. portlet_calendarx: A miniature CalendarX in a slot. This one is
a little bit big for a regular side portlet, but should be good for custom
work when you need a mini-calendar on your site.
This portlet can be used on any page in your site
the way that you might use portlet_calendar, except this one uses the
configuration in a CalendarX instance to control which events are shown on
your calendar. The event icons are shown, along with the normal popup
descriptions. The month name links to the CalendarX instance that is
controlling the portlet.
To use it, there are two steps in the ZMI:
A. Add the following line to your right_slots property (using the
Properties tab) of your portal root (or any slot, anywhere in
your Plone site):
here/portlet_calendarx/macros/portlet
Looks just like the line for the regular calendar portlet, but adds an x.
B. Put a copy of portlet_calendarx in your /custom folder so that it can
be found by your slots, and then change one line in the code so that it
looks for a CalendarX instance (you MUST have a CalendarX instance installed
somewhere on your site for this portlet to work). The line that says:
PATH2CX string:/cal;
should be changed to lead to the CalendarX instance on your site. So if
you have a CalendarX instance called "calendar" located in a Plone Folder
called "quepasa" that's located in your portal root, then your line
should read:
PATH2CX string:/quepasa/calendar;
That's it. Now the portlet will show the same events that your CalendarX
instance is showing.
Porlet 2. portlet_calendarxp: Near CLONE of the original portlet_calendar.
This portlet works great out of the box. The
Just like portlet_calendarx, this portlet can be used on any page in your
site the way that you might use portlet_calendar, except this one uses the
configuration in a CalendarX instance to control which events are shown on
your calendar. The event icons are shown, along with the normal popup
descriptions. The month name links to the CalendarX instance that is
controlling the portlet. Follow the same install structions for Portlet 1.
IMPORTANT CSS INFO. At first, I had trouble getting this portlet to behave
the same way the original portlet_calendar (Plone default) does. So, I
made some changes in the ploneCustom.css code that helped. Later the
problem seemed to disappear completely.
Just in case you have problems, here are some CSS class mods that you
can try in your ploneCustom.css file in your /custom folder in order to
make this portlet work properly. I think you won't have to use it, but I
include it here for completeness. You may not have to do this, but then
again you might find it works. Try without, see how it looks, then try
with these mods if desired:
**** START OF ploneCustom.css MODS *****
.ploneCalendar a {
text-decoration: none;
color: &dtml-fontColor;;
}
.ploneCalendar a:hover {
text-decoration: none;
color: &dtml-fontColor;;
}
.ploneCalendar th .plain{
background-color: &dtml-globalBackgroundColor;;
font-weight: normal;
font-size: 6px;
text-align: center;
padding: 2px;
}
.ploneCalendar .weekdays td {
background-color: &dtml-globalBackgroundColor;;
border: &dtml-borderWidth; &dtml-borderStyle; &dtml-globalBorderColor;;
border-style: &dtml-borderStyle; none;
font-weight: normal;
text-align: center;
padding: 2px;
}
.ploneCalendar .noevent {
font-weight: normal;
}
**** END OF ploneCustom.css MODS *****
Porlet 3. portlet_cx_choices: Controls subjects, etc for the main
CalendarX instance. Comes pre-installed, but you can disable it by
removing it from the slots and then changing the CX_props_calendar settings
to call one of the alternative "subjectlinks" macros that will put all those
controls back up on the header of the CalendarX instance.
III. Documentation available:
Contents of the CalendarX.0.5.x /docs folder:
CREDITS.txt - some people who deserve our thanks.
CUSTOM.txt - description of how to customize CalendarX with skins.
CX_props_addeventlink_text.txt - how to control the Add New Event link
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_eventdisplays_text.txt - use icons and css to control events
CX_props_eventstoallow_text.txt - which events to allow in your calendar
CX_props_eventstorestrict_text.txt - events/users to restrict from calx
CX_props_popup_text.txt - controls on the rollover popup text block
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.
TODO.txt - some things to finish before this branch becomes (stable).
VERSIONS.txt - explains version numbers used for CalendarX releases.
and these two in the root CalendarX folder:
README.txt - brief message identifying CalendarX.
version.txt - version of CalendarX currently in use.
IV. Caveats.
0. These caveats have been included here since the first releases of CalendarX
and I've never had much 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 disfunction, as it is likely
to function properly, thus causing failure of intended weapon disfunction.
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, because I sure
can't figure it out. Hence bugfix releases. I might start going the route
of Microsquish and just start putting them out once a month instead of all
the time. Sheesh.
+lupa+ Lupa Zurven, CalendarX.org
From the current CREDITS.txt:
CREDITS.txt
CalendarX 0.5.3(dev) March 26 2005
(last modified for CalendarX 0.5.3)
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 the cxCreateEvent code allowing new event
creation at any given time/date from +links within the calendar views.
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
Monetary Contributors:
David Diskin
Milieudefensie Netherlands
Mat Ridley
Logistical Support:
Rimuhosting.com
Smoothstone Systems, Inc.
Zurven.com
Acme Computer Services
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,
Jay of Meangrape, Vanessa Evans, Don Johnson, Ken Wood, Eva Miller, J. Bauer,
George Lee, Danna Dowdy, Luca Fabbri, Steve Hein, Jeremy Cook, Ben Labelle,
Heather Jones, Peter Wallace, Ravi Ramamirtham, Jesper Hoffgaard, Kris Smith,
Madhu Aggarwal, Santosh Malvi, Dirk Niemeyer, Heather Jones...
...and if I missed you send me another email and you'll make the next list.
From the current VERSIONS.txt:
VERSIONS.txt
CalendarX 0.5.3(dev) March 26 2005
(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