[Re-posting, since my original post apparently never got through. Maybe I posted
from the wrong email account.]
Hi all!
As discussed at the MediaWiki Architecture session at Wikimania, I have created
an RFC for the TitleValue class, which could be used to replace the heavy-weight
Title class in many places. The idea is to show case the advantages (and
difficulties) of using true "value objects" as opposed to "active records". The
idea being that hair should not know how to cut itself.
You can find the proposal here:
<https://www.mediawiki.org/wiki/Requests_for_comment/TitleValue>
Any feedback would be greatly appreciated.
-- daniel
PS: I have included the some parts of the proposal below, to give a quick
impression.
------------------------------------------------------------------------------
== Motivation ==
The old Title class is huge and has many dependencies. It relies on global state
for things like namespace resolution and permission checks. It requires a
database connection for caching.
This makes it hard to use Title objects in a different context, such as unit
tests. Which in turn makes it quite difficult to write any clean unit tests (not
using any global state) for MediaWiki since Title objects are required as
parameters by many classes.
In a more fundamental sense, the fact that Title has so many dependencies, and
everything that uses a Title object inherits all of these dependencies, means
that the MediaWiki codebase as a whole has highly "tangled" dependencies, and it
is very hard to use individual classes separately.
Instead of trying to refactor and redefine the Title class, this proposal
suggest to introduce an alternative class that can be used instead of Title
object to represent the title of a wiki page. The implementation of the old
Title class should be changed to rely on the new code where possible, but its
interface and behavior should not change.
== Architecture ==
The proposed architecture consists of three parts, initially:
# The TitleValue class itself. As a value object, this has no knowledge about
namespaces, permissions, etc. It does not support normalization either, since
that would require knowledge about the local configuration.
# A TitleParser service that has configuration knowledge about namespaces and
normalization rules. Any class that needs to turn a string into a TitleValue
should require a TitleParser service as a constructor argument (dependency
injection). Should that not be possible, a TitleParser can be obtained from a
global registry.
# A TitleFormatter service that has configuration knowledge about namespaces and
normalization rules. Any class that needs to turn a TitleValue into a string
should require a TitleFormatter service as a constructor argument (dependency
injection). Should that not be possible, a TitleFormatter can be obtained from a
global registry.
Hello everyone,
During the Google Summer of Code 2013 program that concluded recently I
worked on implementing section handling in the Semantic Forms
extension[1][2] which also involved enabling the Page Schemas extension[3]
to handle sections as well. This means that now, not only templates but
sections too can be defined in forms. The work also included adding unit
tests to the Semantic Forms extension.
In SF a new {{{section}}} tag was introduced to the form definition syntax
to define sections in forms. The Special:CreateForm helper page allows you
to add sections to forms by specifying the section name and also modify its
properties. If you want to add sections manually the basic usage is -
{{{section|<section_name>|level=<header_level>}}}. The "level" parameter
here is optional.
PS now supports a <Section> XML element to be included in the schema to
define sections. The Special:EditSchema page can be used to add sections to
the schema and modify their attributes. As before "Generate pages" will
create the form with the templates and sections in the schema.
These changes can be tried out by pulling the latest code from Git. Section
handling for SF and PS will be available with their next released versions.
Any feedback or bug reports are welcome.
Many thanks to Yaron Koren who mentored this GSoC project and to everybody
who reviewed code and provided suggestions for improvement. It has been a
wonderful learning experience and I hope the newly added section handling
capabilities will be useful in defining a more complete structure for forms!
[1].
http://www.mediawiki.org/wiki/User:Himeshi/GSoC_2013/Project#Project_Descri…
[2].http://www.mediawiki.org/wiki/Extension:Semantic_Forms
[3]. http://www.mediawiki.org/wiki/Extension:Page_Schemas
-Himeshi-