Hi developers, as announced in my previous mail, SMW is changing a bit. This will make processing more stable and the code more readable and easier to maintain. To help all developers to adjust their code when needed, SMW 1.4 will have a release candidate in around five weeks that can be used to establish extension compatibility. And of course there will be updates on this list.
The main internal API changes that we expect are as follows: == 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. == 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: * The data will be stored as part of MW's parseroutput. * Direct access for adding data to the current parser output will vanish. Instead, a new class SMWParseData will provide static access methods (some of which are found in the current SMWFactbox) to write data to the parser. * All access to the parser data will require callers to provide a parser object. This ensures that the data goes to the right place. All SMW parts are stateless -- the data is managed more reliably by the parser. * Factbox initialisation is no longer needed. == 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. == 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
