Well there's room for differences of opinion. But my thinking is this:
1) The basic process by which content is typed into a text box and
saved should give back exactly what you entered when you ask for the
source of that page. Such as when you edit a page. Same with data
vars. In other words, the saving process should be seamless--and not
produce quirky behavior. If you want something you typed in to display
something different, you need a markup rule to transform it. That's
what wiki markups does. Saving should be transparent.
2) There are reasons to escape certain characters for various reasons.
I've identified those to the best of my ability, and noted the
reasons, but we can discuss specific replacements if you wish.
Personally, I think we have kept the number down to the minimum
necessary to maintain security, comply with standards, and accomplish
transparent saving.
3) It is faster to escape whatever needs escaping when the content is
saved to a page, than to escape it repeatedly every time it is
retrieved into a page. In other words we are not double encoding, we
are pre-encoding. So we only have to do it once, not multiple times.
4) It also gives added security to keep certain characters escaped,
particularly < and $. I wish we did not need to worry about security,
but it is a real issue. And I believe making a .htaccess file the ONLY
thing protecting your site from attack is unwise. Security is very
hard. And because I'm not an expert, I try to err on the side of
caution.
I appreciate your suggestions, and am willing to discuss specific
changes to the code. In particular, it may be possible we could change
the "&" functionality, though I'm not sure I see how. If you escape it
near the end of the output, you risk escaping some && in a javascript
function or something. If you escape it when it's loaded into a page,
you won't get your , you'll get &nbsp;. It's possible you
could escape it only when you load it into a page source or form
input, etc. But we'd have to figure out exactly where to do that.
If you care to tinker, you could do this. Comment out line 1802 in
engine.php to disable the current escaping of &.
// BOLTreplace('&', '&');
Then try to figure out a better place to escape it... Perhaps it only
needs to be added to ~580 in functions.php. But we'll also have to fix
< so it doesn't get double encoded. We also need to figure out how
to escape it when someone types "Nuts & Bolts" into a title data
field, or into some comment box. Or we lose our xhtml compliance. And
we have to make sure code pages are handled properly since they are a
bit different.
These are not insurmountable, but it feels less solid--more hackish. I
like the experience now that what I type into a text box shows up in
my page. And back in my edit box. Unchanged. That the saving just
works. There is a certain efficiency of course to leaving these things
unescaped in the source, as a kind of hidden (automatic) markup. But
then again, hidden markups strike me as a bit illogical--esp if you
buy the argument that a wiki uses markup to transform source code.
As for \n, not sure what you mean. The \r and \r\n conversions are
essential for Windows and Mac users. Trust me. If you are talking
about the shortcut that converts '\n' to "\n" in editing functions
that is configurable. Otherwise I don't believe \n is converted to
anything in the source. If you don't like the markup rules which
convert it to intuitive line spacing, those rules can be redefined
easily enough. Missed the point here.
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
-~----------~----~----~----~------~----~------~--~---
