[pmwiki-users] About {$:var} text-variables - wikipaths - lists - external data sources

[Martin Fick]

After thinking about things a little more, I 
think that I am leaning towards taking a step 
backwards.  While the grand unification idea
has been fun, it has some drawbacks and I am
not sure that the benefits are that good.

Let me outline/name/split up some of the ideas 
that have been floating around of things/features 
that people seem to feel are things they would 
like in PmWiki.


- Natural ways of inserting data into wiki pages
- Getting data from other sources (mysql)
- Looking up data in wiki pages ( : and wikipaths)
- Settable (extended) pagevariables
- Conditionally friendly pagevariables
- Nestable Function calls
- List looping constructs
- Adding some HttpVariables


Some thoughts about the ideas/features mentioned
above:

A - Extended pageVariables and page lookups are
two distinctly different beasts and both are 
important and desirable.  

1) One driving question becomes, if we can look 
things up in a page, then why do we need to be 
able to set pagevariables?

It has to do with the fact that setting a value
makes it much easier to reuse it somewhere else
in the page without having to redefine (a 
potentially long) lookup pattern and without
having to run any manipulations (function) calls
on the data.

So:  (:set headline={$:firstname} {$:lastname}'s
Resume:)

can easily be reused in a page with something 
like: {$headline}


2) Another major difference is that it probably
makes sense to someday make extendedpagevariables
work well with conditionals, but this is not
really necessary for lookups.  A lookup can be
described and understood to not be a variable, 
but simply a document lookup.  A data value 
is either there or not, it probably doesn't make 
sense to get conditionals involved.

3) And lastly, as mentioned many times by Patrick,
a lookup lends itself to being much more free 
about how data is defined in a wikipage whereas 
an extended pagevariable tends to want a well 
defined syntax.



B - Function calls merit their own syntax
Maybe something like ((function args))

1) If we think that both pagevariables
and pagelookups are valuable, we should be able
to apply functions call to either.

2) I should be able to apply function calls
to straight text without understanding lookups
or pagevariables.

3) The ability to nest function calls and to use
them in yet unforeseen ways is probably easier 
if they are defined on their own.


C - Lists, like function calls might be a 
concept worth developing on their own.

This means that many things should be
able to create lists and list constructs
could be built to operate on those.  I 
mainly am referring to looping here.  If
we have several ways of supplying lists:
pagelists, lookups (wikipaths), extended
pagevariables, external data sources
(mysql),... there is no reason that these
list creators need to be related to the
list looping operator.


D - Wikipaths should stick to wiki page data
lookups.

1) Since they are leaning towards the complex,
keep them as focused as possible.

2) Easier to understand when told that they 
are lookups and not variables.

3) Keeping them separate from other things
gives us more symbols to work with which
is sorely needed for a rich wikipath 
vocabulary!

4) Extending them to other Farm fields would
still make sense as another recipe.


E - Let the external data sources recipe
creator come up with a way of defining
data and list lookups.





Putting it all together:

By keeping things separate, I can combine
them easier.

(:set MyName=((toupper {{$:name}})) {$?LastName}:)

(:foreach Martin Patrick Dominique {{$:author}}:)
|| {=} || {{$:phone{=}}} ||
(:endforeach:)


I know, it's been a little long, sorry,

-Martin



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com