On Tue, Feb 10, 2009 at 4:56 AM, Hans <[email protected]> wrote:
>
> 2009/2/10 The Editor <[email protected]>:
>>
>> Ok, I've been looking into this and the problem is this: the title
>> action has a line like this:
>>
>> [text title "{:title}"]
>>
>> Page variables are substituted before form inputs so after the data
>> var is substituted you have:
>>
>> [text title "[about] linly"]
>>
>> Now BoltWire sees the first ] and thinks it is the close of the text
>> box... It is probable we could develop a better markup rule that would
>> exclude the ] when it is between ' ' or " ", but it would not be easy
>> for me. If anyone cares to take a stab, I'd gladly incorporate it.
>> When I feel up to the challenge I may tackle it myself. Who knows,
>> might not be that bad...
>
> To me this points to a bigger underlying problem: namely the use of
> [...] and {...} as markup. Basically Boltwire makes it very difficult
> to use these two types of brackets in ordinary content. You get some
> nice short markup like [c] and {var} at the big expense of excluding
> these brackets for normal use, leaving an author with just one type,
> (...), of brackets. This is a pretty severe restriction, and not at
> all intuitive for an author.
>
> A less aggressive approach for choosing markup for variables and form
> elements would be better, IMHO.
This is an insightful observation, Hans. At the very outset of
BoltWire, I wrestled with this exact balance and decided to focus on
the easier markups after seeing PmWiki's markup become more and more
complex. As pointed out there are pro's and con's to this choice, but
it was entered into consciously. BoltWire is purposefully geared
towards non-programmers as editors.
In my view, the goal is making smarter markup rules, not requiring
smarter editors. I think you will find in most cases, < { & [ work
fine in normal text, because the patterns are smart enough to
recognize when they are being used as markup and when they are not.
There are exceptions, of course, but I have never had a problem
personally. And there is always the simple escape markup which allows
`{now}.
You are right though, that in this specific case my solution is not
really adequate. (It wasn't really intended to be, just another easy
to implement feature). The real solution is again, to improve our
forms markup rule so it skips over a closing bracket when enclosed
within quotes (single or double), using an approach similar to that
used when parsing an args string. Doing this enables us to keep [text
field "valuewith]init"] rather than requiring of the author something
like [:text "field valuewith]init" :] or something similar.
Pm and I had many discussions on this, but with all my admiration for
him, I was never quite persuaded to his view.
> Above the markup table it says that one can change any of the definitions.
> I tried to change markup for variables from {var} to {$var}, which
> totally broke the wiki. So it is not possible to make custom markup
> changes for any markup in the table. I guess this is because in php
> functions strpos and strstr etc are used to extract bits from a
> variable, so a change like mine which introduces a new character will
> break the string extraction.
I'd like to see your markup rule, to know what you did. But I tried
this rule and it works fine. Perhaps there was a glitch in your
pattern... Just put this line in config.php in field/config/ (create
file if it doesn't exist).
MarkUp('vars', 'var', '/\{\&\#36\;([-_.*:a-zA-Z0-9]+)\}/e',
'BOLTvars("$1", "$zone")');
One thing to note is that BoltWire escapes the $ when it saves the
page text along with < and a couple other things. There is also a
$$var markup to watch out for. What we call skinvars, but will soon be
renamed to snippets.
Another thing to note is that there are lots of system pages with the
old markup that will break (obviously) if you use this new markup. To
really switch over, you would need to run a replace function on all
the system files--but then you are diverging from the core and would
have problems with upgrades. There is, I think, a replace plugin,
which can scan and replace patterns on pages and upgrade to new markup
automatically. You could run this on the system pages easily enough...
Anyway, thank you for your challenging comment. It is always good to
review one's core choices and priorities and make sure they still
appear valid.
Cheers,
Dan
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"BoltWire" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/boltwire?hl=en
-~----------~----~----~----~------~----~------~--~---
