You make a good point, but I think the real complexity is we are
trying to get code.snippets to do too much. For example, you can put
simple skin settings in there, entire forms, even javascript. We also
have to contend with where the snippets markup is in the markup table.
We have thee options of what to return, maybe more: raw markup,
processed html, escaped processed html. In a skin you want processed
html--there's no need to escape it because no markup is rendered in
the skin, just the zones.
In the zones we were returning processed html, until we got bug
reports caused by double processing. IE, the html output itself
generated markup BoltWire recognized, which got double processed later
in the markup table, after it was inject into the page. So I decided
to escape the output in zones--but this caused problems where you want
the exact value, not the escaped value, like functions, and now
conditionals.
Your suggestion is that we return the snippet as raw markup and let
the engine take care of it naturally. This would solve many problems
(and maybe it is a better solution). But this means anything processed
before snippets in the markup table would never get processed.
Including:
`escape, /=no markup =/, <rules>, <html>, <markup>, <code>, <box>, /*
comments */, <embed script>, and $$snippets (nested!).
Which also means you couldn't insert direct html or javascript using
[[#mysnippet]]
/=
some javascript here
=/
[[#end]]
However, it does suggest a solution though... What if when injected a
snippet into a zone, we simply processed these prior rules only, then
injected it as raw markup from that point on--as you suggest. This way
we would not lose any functionality, solve all these sorts of
escape/unescape problems, and not require any special code in
functions/conditions. It also saves processing time--as we only do the
processing we need when we want to.
Sounds like an excellent solution... I've done some preliminary
testing of it and it seems to work. Thank you for helping me think
this through! No promises it won't break something, but at least I
think we got the right idea. Here's the code if you care to
experiment. Rewrite the entire BOLTMsnippets function (in
markups.php, line 595) to this
function BOLTMsnippets($var, $page='', $skin=false) {
## TAKES SNIPPETS AND PREPARES FOR DISPLAY IN PAGE OR SKIN
// $out = BOLTescape(BOLTdomarkup(BOLTsnippets($var, $page)), false);
// if (strpos($out, "\n") === false) {
// if ('<p>' . substr($out, 3, -4) . '</p>' == $out) $out =
substr($out, 3, -4);
// }
// if ($skin) return $out;
// return BOLTescape($out);
$out = BOLTsnippets($var, $page);
if ($skin) {
$out = BOLTdomarkup($out);
if ('<p>' . substr($out, 3, -4) . '</p>' == $out) $out =
substr($out, 3, -4);
return $out;
}
return BOLTdomarkup($out, '', '', 'pre');
}
We'll give this a try in the next release, and revert the special code
in the conditions and functions that handles the unescaping.
Cheers,
Dan
On Sun, Oct 4, 2009 at 6:33 PM, Hans <[email protected]> wrote:
>
> Thanks for the explanations! I did not understand all, but some (I hope).
> The whole thing sounds quite confusing.
> Why would you want to undo any BOLTescapes?
> It seems more logical only to 'escape' anything rendered to HTML.
> And only to render to HTML anything which had all variables resolved.
> With exception of 'code'.
>
> The fact that you need to undo 'escapes' for some processing, then reapply it,
> suggests the process is going astray earlier.
> Something going wrong in the markup sequence,
> or 'escapes' applied unnecessarily.
> Or so I guess.
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
