most specifications are made of a text content, which is parsed
a specification - can be a text, a wiki or anything else we can parse to extract some piece of configuration
can retrieve specs, by wpath and ver
a specification of a template - templates are sections inside specs name = name parmStr = list of tags, really
basic user concept - you have to provide your own implementation
basic user concept - you have to provide your own implementation
configurations are normally user-aware, especially when drafting
the wiki adds WikiUser and WikiUsers
final runtime adds User and Users
user factory and utils
position of an element - reference where the item was defined, so we can scroll back to it
basic implmentation
uniquely identifies a piece of specification
uniquely identifies a piece of specification
for identifying sections inside a larger document, the wpath will include like a section pointer (...#section)
important concept - query/select a list of topics, based on inclusion/exclusion of tags
important concept - query/select a list of topics, based on inclusion/exclusion of tags
LOGICAL: a/b|c/d is a and (b or c) and d ACTUAL: a/b,c/d is a and (b or c) and d - in url , is not escaped, so easier to use than |
todo perf if tq contains a cat like below, optimize to search just those - it's done in DomGuardian
tag query tricks: if a tag uses an upper case like "Story" then it referes to the category and it optimizes things a lot in big reactors
ltags - all AND expressions atags - the AND expressions without OR otags qt - array of array - first is AND second is OR
NOTE the one way to do the search today is WikiSearch.getList
the simplest spec - from a named string property
a specification - can be a text, a wiki or anything else we can parse to extract some piece of configuration
Specifications are meant to be parsed and DOM/diesel elements collected. Also, they are addressable (specPath)
We do not concern with the way these are found - that's the inventory, but usually they are passed into an engine etc