Hi, that's good to hear. Yes, Semantic Calendar still has the problem that
it needs caching to be disabled on a page it's on for the user to be able to
go to other months, although I don't think using the Special:Ask page is the
answer - calendars should really be embeddable within normal pages, instead
of having to be linked to.
Also, SC has its own date handling, using code borrowed from Temlakos'
"Historical Date" class, so I think it should be fine for now regardless of
how SMW handles dates.
-Yaron
On Thu, Oct 16, 2008 at 1:52 AM, Markus Krötzsch <
[EMAIL PROTECTED]> wrote:
> On Wednesday, 15. October 2008, Yaron Koren wrote:
> > Hi,
> >
> > I'm thinking of changing Semantic Calendar to simply define an #ask query
> > format, which would be called 'calendar', instead of using its own parser
> > function (#semantic_calendar); and at the same time moving all the code
> > into the Semantic Result Formats extension instead of having it be a
> > standalone extension. Would that be alright?
>
> Sure, that would be perfect.
>
> > If so, I have a few questions:
> >
> > - should this move wait until SMW 1.4 is released, or could it be done
> > earlier?
>
> You can do it earlier; if changes in the result printers are required, we
> will
> make the necessary adjustments on all SRF printers right away. There will
> be
> some changes in the capabilities and features of SMWTimeValue, but unless
> you
> rely on getXSDValue(), there is probably no need to react there.
>
> Be aware, however, that some dates might be historic, so that you cannot
> rely
> on PHP time functions without first checking if the date is in the proper
> range (there will be a method to check this, the SVN version is not there
> yet). In the long run, it may or may not be possible to directly access the
> built-in calendar awareness of SMWTimeValue to cover historic dates too.
>
> > - how should the language definitions of Semantic Calendar be handled? I
> > don't believe any formats currently in SRF have a language file. Should
> > each format use its own language file, or should there be one for all of
> > SRF?
>
> SRF should get its own language file, and it seems that one file for all
> would
> be most convenient (and not much overhead). This would also be needed to
> move
> the timeline messages to SRF. Feel free to ask Siebrand to register this at
> translatewiki.net, or ask Denny to take care of this (he maintains SRF).
>
> > - are there any other issues I should consider about this move?
>
> None I can think of now. Does the calendar still require the special
> setting
> for enabling calendar page flipping in-page? It might be possible to solve
> this by moving page-flipping to Special:Ask, and merely have previous/next
> month link being customised versions of "further results" (see e.g. the RSS
> printer code on how to add arbitrary params to further result links).
>
>
> Right now, SRF registers all printers by default, i.e. if nothing else was
> specified after including. I guess this will change to include only formats
> by
> default that (1) do not need further MediaWiki extensions to be installed
> first, and (2) do not call to external web services. In this case, the
> calendar would be among the defaults.
>
> Markus
>
> >
> > -Yaron
>
>
> --
> Markus Krötzsch
> Semantic MediaWiki http://semantic-mediawiki.org
> http://korrekt.org [EMAIL PROTECTED]
>
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
