getting the calendar to work in the first place
Just in case you asre wondering why i have done it the way i have so far….
it would be fair to say that when people add events to a calendar, it is highly improbable that they will do it in a chronological order.
For that reason, i felt the only way to start was by utilising the calendar to generate the event pages.
The problem then occurs that you cannot use a simple numbering system.
Why?
001, 002 —-009,010,011
will be sorted
001,011, 002
So a "base" number plan that will be sorted in the correct manner has to be used.
hence the weird and wonderful system i have used.
month (a-l) week (a-e) day (1-7)
got a better idea?… please, lets hear it :-)
Here's my proposal for a “better idea”
It has the pages:
All of these pages are blank, but the titles of the first 9 pages don't have the preceding zero. They must be created in perfect numeric order, so they can be sorted properly by creation date (this wouldn't be necessary if the ListPages could sort by page-name as well as page-title).
It then has the pages:
And custom CSS must be applied:
So there's a grand total of 33 pages for this “better system”. You can see it in action here.
So there is a different framework for pages of each day in the calendar. Each page is structured year:month-abbreviation:day. So if there was an event on the 10th of August, its page name would be 2009:aug:10.
Using the ListPages module in the inc:month-backend page, you can use the pages from the “days” category to automatically set each page-name for each day of the month.
Combine that with the magic of includes, and you can specify which day the first day of the month is, and how many days in that month.
The inc:month page is where all the real magic happens. I worked out a clever way to hack use the Wikidot engine, where by specifying a variable in an include, you are actually specifying the variable of another variable in the include. Simply said, if you specify that |month=january, the "january" variable will be set to “TRUE”.
Using this technique, I was able to automatically determine the number of days in February depending on whether the |leap-year variable was set to TRUE or not.
The reason that this system is “better” is because you can create a calendar for a month with the use of a single include.
An inconvenience with this system is that you must specify which day of the week is the first day of the month.
How's that Phil?
> So there's a grand total of 33 pages for this “better system”.
Looks amazing, though I only see three pages?
Edit: Actually, I see what you've done…
~ Leiger - Wikidot Community Admin - Volunteer
Wikidot: Official Documentation | Wikidot Discord server | NEW: Wikiroo, backup tool (in development)
my monthy cal i shall call HBBM
your version i shall call BBBN
Thanks Shane, and Phil :D
Not sure what either of those acronyms could possibly stand for though…
There are some things that could be improved upon… if we cater for future Wikidot features. I'm talking about when the ListPages module orders pages by PAGE NAME.
With the current page-name system, year:month-abbreviation:day, if you were to order by page name, it would order by which months come first in the alphabet. This is not what we want.
So should we specify the month part of the page name as a number only? That is, the 10th of August 2009 would be called 2009:08:10
In addition, all pages might be best put in a category — calendar:2009:08:10
The URL is a tad long for my liking, but a live template would enable us to do some cool things. For example, a special javascript extension that would display the day (Monday) of each day, in addition the the day of the month, the month and the year just by parsing the page-name in the URL. This isn't otherwise possible.
To make the ListPages module separate events into years and months, each event wouldn need to be tagged with the year and month… this can be made automated.
Comments?
It's done now.
Pages are part of the category calendar, utilising the syntax of year:month:day in terms of numbers (1-9 are written with a preceding zero, so 01-09).
SEE THIS so that you can understand the jargon I was saying about the javascript extension. This is just an example of what sort of thing you can do. Note that the data about the day/month/year/day-of-week is completely derived from the page-name (2009:08:10) utilising the power of javascript.
HBBM: Hand Built By Moron
BBBN: Brain Built By Neurons
@james
i note you say
we have 2 problems here. "when" can be anytime between now and who knows when.
when you click on a date in the page title only the year id displayed.
at this very moment in time my head isn't working properly because i have sunstoke! (and very RED legs)
but… what i was wondering is…
could we use the sort by url thing?
i will openly admit that i don't understand this, nor can i find any examples of its use that might shead some light on it. Reading the documentation it does give me hope.
without a method of listing events in a chronological order then we are bashing our heads against a brick wall.
Yeah, I'm surprised you were able to walk to the Wikidot playground with those charcoal legs of yours (indeed, I was watching you sunbake from behind those bushes you kept staring at).
Watcha mean?
When I was talking about sorting by page name, I meant the URL UNIX page name. So, for example:
You see, that's sorted alphabetically (or numerically, whatever). Currently we can only sort alphabetically the page Title name… which is completely useful in our case.
and sorting by url i have no idea about.
in the doc.. http://www.wikidot.com/doc:listpages-module
it refers to sorting by @url and i was sorta thinking that might do the trick.
or am i barking up the wrong tree. (or even just "barking")
@URL can be used like this:
http://website.wikidot.com/page-with-listpages/tags/horse/limit/100/perPage/20
Which means, that on the page-with-listpages page you have a ListPages module, that accepts @URL as a parameter for tags, limit and perPage.
All that means is that you can do some cool sorting with links. Add /tags/tag-list or /limit/number to the URL in the same way as you add /edit/true to a URL, and the ListPages module will pick that up and use it to show it's results.
I've used this extensively here.
http://cyclods.wikidot.com/download:skin/noredirect/true/order/ratingDesc/limit/5
Games
http://cyclods.wikidot.com/download:skin/noredirect/true/tags/games/order/titleAsc/perPage/10#skin-list
Movies
http://cyclods.wikidot.com/download:skin/noredirect/true/tags/movies/order/titleAsc/perPage/10#skin-list
The noredirect/true is just there so that it doesn't redirect, and it gives the ListPages module the opportunity to pull it's parameters from the URL and display some results.
~ Leiger - Wikidot Community Admin - Volunteer
Wikidot: Official Documentation | Wikidot Discord server | NEW: Wikiroo, backup tool (in development)