Relative month/year values, multiple navigation-synced instances on same page

[trac-hacks-tickets@…]

Requesting the template month and year values support input relative to the current date. For example, 1 would display next month while -1 would display last month. Perhaps just adding a keyword to set date input to relative relative dates would suffice?

Thank you for your consideration.

[Steffen Hoffmann]

Replying to trac-hacks-tickets@isnoop.net:

Requesting the template month and year values support input relative to the current date. For example, 1 would display next month while -1 would display last month. Perhaps just adding a keyword to set date input to relative relative dates would suffice?

Thank you for your consideration.

Sure, thank you too, for sharing your thought about this plugin.

You may have not noticed by now, that WikiTicketCalendarMacro is going back to it's roots - WikiCalendarMacro. I hope, this will be a new great(er) choice, since you just install one plugin and can play a lot (more) with display style later.

You may find #562 related to this one, if you just consider the aforementioned merge.

Regarding your own proposal I'd like to have a little more information about the expected behavior:

• 1/-1 for month and year argument should work for initial call of the wiki page
• this should work too, if put into the URL like ../mywikipage?month=-1?
• multiple calendar instances, say cal1(-1) cal2() cal3(1) should be possible (similar to #562)?
• navigation sets of multiple instances should change all or just the calendar they belong to?
• if your choice to previous question is 'change all', should multiple calendar instances even share one set of navigation arrows?
• if you care that far, should a calendar navigation never/optionally/always be a separate thing, something like a bodyless 'nav-only' calendar cal(nav-only), so i.e. allow for free placement everywhere on the same wiki page?

Providing answers/comments to these thoughts of mine would help me a lot to better understand and decide on a future design of Wiki(Ticket)Calendar, that could suite your and others needs. Still be prepared, that I'll do not much on the current code before merging with WikiCalendarMacro. The merge is no longer just a plan but already on the way. It gave me the last push for a re-design of the multiple files version towards even more code modularization based on the current 0.12/trunk branch.

All that will have to settle down a bit, before I may consider to start work on another task, i.e. this one. However we're speaking of weeks or months, not years, and I encourage you to not go away, even if you don't see it implemented to your wishes, or even no visible progress within some weeks.

[trac-hacks-tickets@…]

Hello,

Yes, #562 seems to be aiming to achieve a similar end result, though I am interested in putting more than two calendars on a page.

To answer your questions:

• I think passing the argument in on the querystring would add a great degree of flexibility, for sure. It would allow a person to create dynamic wiki links for things like "Next month's release schedule".
• Absolutely multiple calendar instances would be great.
• That's a good question. If the multiple calendar instances took their hard coded month ( cal1(-1) for example) and added the value on the querystring (?month=-1) then I think that would gracefully handle all calendars updating at once.
• I wouldn't make sharing calendar arrows a hangup, especially if one has the ability to create calendars without any arrows in the first place. You could simply put arrows on a single calendar.
• Calendar navigation would ideally be optional, and--in the case where you want multiple calendars and a single navigation pane--being able to have a disembodied nav bar would be handy. I wouldn't call that a critical feature though.

Thanks so much for your hard work. Based on your suggestion, I'm implementing the current WikiCalendarMacro and look forward to future updates!

[Steffen Hoffmann]

#562 has been close as a duplicate of this ticket.

I refocus this request for both macros in the united code base.