OK, after that mail worked properly, here is my first update on the implementation status in current SVN. If you develop with SMW, it is suggested to go over this to see whether changes in your code are needed.
Overview:
* Files have changed for easier reading and maintenance.
* Factbox display works differently with slightly different results.
* smwfRequireHeadItem has been replaced by a new method: everyone using this
function, but also everyone that writes a special page, parser hook, or
parser function invoking SMW outputs must adopt his or her code! Read on.
Also, there were first set of changes to Type:Date, enabling internationalised
date parsing and year-only dates (e.g. "1970" failed before). This is rather
a user-issue than a matter of concern for developers, so I do not detail this
here. There will be updates on the list as this project progresses.
<snip>
== Code reorganisation ==
> > Some of the core files of SMW are messy: Hooks, GlobalFunctions, Factbox
> > all contain a rather colourful mix of things. We will try to re-organise
> > the code, possibly using some more/different files and classes. This
> > should affect you only if you call any of those functions directly.
Much of this was done, though few developers should be affected by these
things (unless you patch/overwrite parts of those files). An exception are
some global functions that changed name to become static class functions (see
below).
SMW_Hooks.php, SMW_Data.php, and SMW_TemplateDeclare.php are no more. Instead
there are three new files:
* SMW_ParseData.php: Static methods for storing data during parsing (this was
in SMW_Factbox.php so far). This change was already explained in the previous
mail ("Data storage during parsing").
* SMW_ParserExtensions.php: All parsing and parser function implementations
(mostly hooks). Content collected from various places (GlobalFunctions and
the three deleted files).
* SMW_Ouptuts.php: Static methods for safely adding header items (so far these
were global functions in SMW_GlobalFunctions.php). See below.
Moreover, SMW_Factbox now only contains stuff related to Factbox *display*.
See below.
== Data storage during parsing ==
> > SMW currently keeps data in the SMWFactbox class, using static variables.
> > The data is accessed directly for writing (SMWFactbox::$semdata) by many
> > functions. This changes as follows:
> >
<snip>
No changes compared to last mail. However, there is another change:
== Factbox display ==
The Factbox is no longer created during parsing, but only later on output.
This should fix all kinds of problems with <gallery>, <poem>, <cite>, etc.
since no interaction with those extensions can happen any more.
The Factbox now is *below* the Categories, at least in MW >= 1.14a. This is
intentional and is based on MediaWiki's internals. But it appears to be
useful especially during Preview. Older versions of MW show the Factbox still
right below the text, as it was until SMW 1.3.
== smwfRequireHeadItem ==
> >
> > This function was meant to be a flexible way of adding scripts and CSS to
> > the HTML output, disregarding whether or not we are on a special page. It
> > seems that this approach has failed: especially on Special pages, it
> > happens that background jobs confuse the set of scripts/CSS so that the
> > special page is not correct. I expect that this can only be changed by
> > providing more details to the smwfRequireHeadItem function, so that
> > callers will after all have to distinguish whether or not they are part
> > of some parsing or of some plain HTML generation. This will entail
> > changes in the API since many callers currently are not tracking the
> > parser at all. I will analyse where the function is currently used and
> > try to find a convenient new API.
This was done now and has lead to some fundamental changes that could not be
avoided. Background information is given in SMW_Outputs.php (and the
according online documentation). Three things you need to know:
* If you even call smwfRequireHeadItem() you need to change that to
SMWOutputs::requireHeadItem(), same parameters.
* If you have written a Special page that uses any SMW output (datavalues,
tooltips, queries, whatever), then you need to call
SMWOutputs::commitToOutputPage() before your printout function is finished.
See any of the SMW Special pages for examples.
* If you have code that binds to any parser hook or function and inserts text
that uses SMW output, then you need to call SMWOutputs::commitToParser()
before your parsing hook/function finishes.
These changes were not avoidable but appear to be minimal for what they
achieve: a secure and reliable way for adding CSS and JavaScript that no
longer interferes unexpectedly with extensions and jobs.
The further topics of my earlier mail were not addressed yet.
Cheers,
Markus
> >
> >
> > == Handling of properties ==
> >
> > I mentioned earlier that we want to get rid of the distinction of
> > properties into Title objects (normal properties) and numbers (special
> > properties). Instead, there will be a new property class that can deal
> > with both. I have to design the details yet, but this will of course
> > change how special properties are accessed.
> >
> >
> > == SMWSemanticData, SMWQueryResult, SMWPrintoutRequest ==
> >
> > We would like to use SMWSemanticData for passing around query results,
> > thus rendering the current query result objects obsolete. The intention
> > is to preserve many interfaces in the process, but some changes cannot be
> > avoided due to the fundamentally different data structures. Query
> > printers are the most prominent piece of code that will need some change,
> > but again this was discussed before anyway (for having more flexible
> > query outputs). We will provide more details when this progresses.
> >
> >
> > Cheers,
> >
> > Markus
--
Markus Krötzsch
Semantic MediaWiki http://semantic-mediawiki.org
http://korrekt.org [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------- 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
