Here are some random notes.
Creole 2.0: Links & Transclusions: Application specific extensions
@proposed 20120725
I know people at Creole want to define a standard markup with portability and interoperability in mind; but we evil developers need ways to achieve swiftly what we need to achieve.
For instance, in Diesel-Wiki-Creole, we do support inline HTML attributes and inline CSS style directives inside Creole link markup, although it is not part of the standard; and honestly, I wouldn't go without them. Inline HTML attributes extension is a real bless for links, whether for adding a "_blank" target, a "nofollow" directive or a class attribute for correctly styling menu lists, and both extensions have proven very, very useful when dealing with images.
The bad thing is that it breaks interoperability of the markup; and I honestly doubt it would be a good idea to embed these extensions as part of the standard. I think it would be a better alternative to leave some room inside the standard to allow such extensions.
I hereby propose that application-specific extensions be allowed in both link and transclusion markup, in a way that would be consistent with the standard.
My extension markup proposal goes like this (BNF):
creole_link := '[[' target [ '|' alternate_text ] [ extension ] ']]' extension := '||' extension_specific_data extension_specific_data := (any sequence of characters excepted the ']]' string)
Creole-compliant applications would simply ignore the part after the double-pipe '||' sequence. The part before the double-pipe should render consistently in a Creole-compliant engine.
Same would apply to transclusions.
So, for instance, the following Diesel-Wiki-Creole specific markup would remain valid Creole 2.0 markup:
[[home|My Homepage||target="_top"|font-size:120%;color:blue]]
The application could even hide the double pipes in the editor and restore them upon storage, so the end-user doesn't have to deal with the trouble. An application would only interpret the extension parts it understands. It would be up to the application developer to decide whether it leaves, removes, or hide from the user the parts it doesn't understand, or simply warns the user when such part is found.
Dx4: Modules as Project's namespaces
@proposed 20120725
Ya, so modules will be loaded as namespaces of the project's node:
$myProject = new Diesel_Project();
$myProject->setNode('ns:wiki',new Diesel_Wiki_Module());
At xmeta level, we will implement a default namespace metavariable (which would default to 'xnode'):
$myProject->set('xmeta:default_ns','wiki');
But xmeta:default_ns can also receive an array, so if a node is not found in the first namespace, it will be sought in the next one, for a result similar to what we had with project:dispatch
$myProject->set('xmeta:default_ns',array('auth','wiki','entity'));
When creating a node, user can decide what kind of node it will be by specifying the namespace in the URL, eg:
- http://www.example.com/wiki:people/john.create
- http://www.example.com/entity:people/john.create
As to know which of the latter is viewable when invoking http://www.example.com/people/john if both exists, this is determined by xmeta:default_ns.
Non-wiki content transclusion
Also note that is solves the problem of transcluding non-wiki content, as any node can provide views proper for transclusion. For instance: {{entity:people/john}} would transclude entity people/john with default view. This implies that a project's module namespaces be inherited to the modules themselves (that can be managed at xmeta level).
xmeta 2.0: xmeta namespace nodes are xdatamaps
@proposed 20120725
To avoid instanciating useless nodes, namespaces such as xmeta, that mainly store data, will be instances of xdatamap; hence, the following code won't instanciate a new node:
$node->set('xmeta:my_var','My Value');
Only when necessary, a node will be instanciated on-the-fly:
$metanode = $node->getNode('xmeta:my_var');
--(Geez. creole_code filter has got some greed.)-- ++Fixed! Though Creole yet won't support delete and insert extensions...++
