On Sun, Oct 11, 2009 at 3:52 AM, Hans <[email protected]> wrote:
>
> Dan, please forgive me if i am not following you with regards to
> patching code, doing a str_replace here and there. I get easily
> confused with all the replacing, and cannot easily see why a
> particular 'replace patch' exists (forgive the term).
No problem. You have made some great suggestions, we've been able to
get some good simplifications, and I'm happy to do more if we can.
Just we can't strip out patches that will leave some functionality
broken until we find a better solution.
> I am more concerned to perhaps find a generally simpler solution,
> requiring less, or no 'replacement patches'.
Coming up with a patch is fast and easy. Finding the real cause is
often much harder. We can consider these temporary until we get to the
root of things. Though I do have limits on the time available to me
to spend on some of these hunts.
> Re: & and XHTML
> Please can you explain what the problem is with the '&' character and
> XHTML compliance? Anything I can read up on this?
I was just going by what Kevin said. Kevin, do you have the specs
handy somewhere? Is it just forms we are talking about or page
content? It doesn't make sense to me in terms of the latter, because
there is an & in all escaped values and in some javascript. I think
perhaps it is just the form inputs we need to be worried about. If
anyone can verify this, I'll make the appropriate fixes.
> Re: $ and possible problems with variables and snippets:
>
> Literal $ characters are no problem if the markup using $ characters
> is precise. It may be a problem if the regex is too loose, or the
> markup defined too general.
>
> At present a string like '$abc' in a page will be treated as markup
> for a var, and $$abc as a snippet var. The latter is defined that way
> and should not be a problem. But $abc should not be trated as a var
Agreed, though to be honest I have no idea why this is happening. I've
discovered if you comment out line 70 of markups.php it eliminates the
problem with $pageLink. I tried echoing out the $1 capture as the very
first line of the BOLTMlines function and it seems to already be
converted to the php equivalent. Yet if you leave that markup rule
out, it is not. Very strange. I've tried rewriting the regex various
ways with no luck--this seems the clearest:
if (BOLTconfig('BOLThonorlines') !== 'false') MarkUp('end', 'lines',
'/(.+)(\n+)/e', 'BOLTMlines("$2", "$1")'); // line spacing breaks
So until I can get an answer to what is happening here I think we need
to keep the $ escaped out in domarkups...
> Re: [messages] in code* pages.
>
> I am not sure what the problem is. Surely a markup [messages] in a
> code page should not do anything, but just shown literally. But if a
> snippet contains [messages] and is used somewhere in a normal page,
> then it should be used as a marker for message display.
[messages] are not processed like other markups. Rather they are a
separate rule processed after all the zones are processed--because I
don't know where the form and/or the message markers are. The problem
is, at this point in the html rendering I can no longer tell whether
it is in a text box, was originally escaped, or anything. So my
solutions--which I am happy about is--is to temporarily disable it
when I want it escaped and then restore it after messages are
processed.
This really gives nice advantages as you can now put anywhere--any
function, markup, core code for debugging, whatever.
BOLTmsg($id, $msg);
And you get messages in the page. This was not possible before. Could
only send messages back with forms, which are processed before
anything else.
> Generally most markup in code* pages should not be rendered when
> viewing the code page. I am not sure how you handle this, but I
> imagine that when viewing a code page a different set of markup
> rendering is enforced.
It essentially wraps <code></code> around the entire page, and
processes it like any other page. The BOLTMcode function has a few
replacements that are similar to the source function. So we may want
to create a sourceEscapes function or something to make sure both are
handled exactly the same, and so bug repairs can be fixed more easily.
I have not studied carefully to see the differences between these two
sections of the code.
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
-~----------~----~----~----~------~----~------~--~---
