I didn't notice it till now, but SMW is doing the same message
short-circuiting that SF was doing (I fixed that in SF), and it's on the
ToDo.
I've committed a number of wfLoadExtensionMessages into SMW. These
should cover just about every area where messages are needed.
Unfortunately there are
PHP Objects are dynamically extensible. You can add variables into the
ParserOutput just by using $parser->mOutput->varname.
Also you might want to note that ParserOutput also has addHeadItem which
should work for avoiding adding head items to the wrong place.
~Daniel Friesen(Dantman, Nadir-S
Markus, this is probably a question for you: I noticed that RDF export of
Geographical locations has xsd:string type while it makes the most sense to
use geo:Point and geo:lat geo:long.
What's your general approach to attaching external vocabularies to SMW
Types? Do you think it should be configur
On Freitag, 15. August 2008, Daniel Friesen wrote:
> Sub parsers. In what kind of case does this kind of thing happen for you?
Normally, sub-parses happen with (a clone of) the current parser, e.g. when
using a . But I am not aware of any guideline that states that
extensions are not allowed to
Sub parsers. In what kind of case does this kind of thing happen for you?
When one thing is being parsed, there is one parser doing that task. I
don't know of many cases where multiple parsers exist (unless an
extension is doing something screwy).
Have you tried making use of the ParserOutput
Hi Daniel,
it's always refreshing to get some thorough code critique from you in the
morning -- thanks for caring! I have added you to our contributors' list, and
I would much appreciate your ideas on some further hacks that I am well aware
of, see below.
> Anyone want to explain to me why the
