[pmwiki-users] About {$:var} text-variables

[J. Meijer]

On 9/6/06, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> On Wed, Sep 06, 2006 at 09:20:48AM +0200, Roman wrote:
> > On 9/6/06, Kathryn Andersen wrote:
> > > I *really* like the idea that the {$:var} stuff uses
> > >
> > >        Name: Patrick
> > >        Version: 39
> > >        State: Texas
> > 
> > I like this simple syntax as well but some more explicit syntax would
> > be also desirable. I think we can expect quite common request to use
> > text variables definitions together with tables because of vertical
> > alignment of values or because of better styling. I doubt that this
> > simple syntax would work with tables, e.g.
> > 
> > ||class=sometableclass
> > ||Name:      ||Patrick ||
> > ||Version:   ||39      ||
> > ||State:     ||Texas   ||
> 
> Oooh, I like it.  But even if it's not a PmWiki default it will
> be a customizable option.  Actually, individual sites will be
> able to choose whatever syntax(es) they wish.
> 
> > One of J.Meiers's suggestions tries to solve this request. But there
> > could be other ways, e.g. separate variable definition from its
> > appearance. In this case, text variable definition should not appear
> > in the HTML output:
> > 
> > (:some variable definition beginning:)
> > Name: Patrick
> > Version: 39
> > State: Texas
> > (:some variable definition end:)
> 
> We already have the capability to define values that aren't displayed... :-)
> 
>     (:if false:)
>     Name: Patrick
>     Version: 39
>     State: Texas
>     (:ifend:)
> 
> Pm
> 


I think Patrick's missing many points here. 


I also think I can improve my point without reiterating motives: just use the {#tag} syntax for accessing tagged text fragments. 

This syntax would give access like {$:tag}, but also to any clips (=sections) defined in the page. Clips and text-variables would share the same namespace, with clips having priority for being explicit. Note that there is litle or no performance penalty in this.  

Now tags inside clips can be accessed using the same syntax. So:

  {#clip#tag}    # extract some tagged data in the clip. 

This states: look for a tag named 'clip', then look into that for a tag named 'tag'. 
  
  
Where you Patrick really fail to miss the point is suggesting that 

  (:if false:)
  BenevolentDictator: Patrick
  (:if:)

would somehow be comparable to:

  (:cut data:)
  GuidingStar: Maristela
  (:end data:)


In the second case you'd be defining an interface where external pages can look into. Which is essential when you start looking at pages as being data containers /also/. Furthermore the clipboard syntax is capable of morphing this data as a whole, and rendering it in place to any formatting and style required (from a template for that matter). 

Pages with the clipboard markup enhance their value in a way that makes them future proof. At the same time first time users will have no trouble reading what is intended. 

Your counterpoint replying Roman, with the (:if false:) syntax, sucks because it doesn't address the argument made and because it sucks users into the wiki Matrix. That's because the (:if false:) syntax, despite it's mathematical logic, is syntax of the type that makes users afraid. Afraid they are being sucked into a logic that isn't theirs anymore. They don't see this syntax as a statement, and indeed it is not. 

Yep, the (:if false:) syntax doesn't cut it ;)


<sidenote>

As a perl guy, Patrick may overlook the shortcomings of the matrix. Yes, the matrix has logic to it, and it helps because you can derive cues from it. But the fact that logic exists doesn't impede the fact that other logic may be superior. It's a matter of dominance. 
I for one don't use much of the wiki matrix's !!!, '' and ''' (and for that matter all the other inline markup syntaxes). More importantly I don't use the [[link]] syntax. And I also don't use (:include:), 'Attach:' or wikistyle syntaxes. My eyes hurt scanning some page sources from the documentation. But note I'm not directly affected by whatever Patrick chooses to implement. 

</sidenote>


Discussions to follow or precede this one:

1. Let's hide the distinction between page- and text-variables? Non-prefixed identifiers should access page-variables first, then scan for tagged sections? Only when we want to force a specific type of access, only then, a prefix should be used, like '$', ':' or '#'. 
2. We need some kind of {$ simple-expression} or (:expr simple-expression:) syntax and decide what symbols represent identifiers (f.e. 'varortag', '$var', ':tag' or '#tag'). This is I suppose the underlying motive for Patricks 'the more I think about it', with him deciding on var and :var as identifiers. 
3. A dereference syntax to access properties of variable values that involve pagenames, f.e {$parent->tax} or {$parent::taxrefund}. 

Anyway, probably the first operator we need is the delinking operator to convert a link to the bare pagename. 

I like D. Faure's solution, but instead of appending operators using the colon, we may perhaps use a more 'conventional' cast-syntax like:

   {(space)$Name}
   
 Which would be the same as both

   {$NameSpaced}     # pmwiki standard variable
   {$Name:spaced)    # D. Faure syntax
   
 
PmWiki should of course choose to support some format soon. Any solution is much better than the current crippled name=name+function format. 

'nuf said.

jm




_________________________________________________________________
Express yourself with gadgets on Windows Live Spaces
http://discoverspaces.live.com?source=hmtag1&loc=us