On Sun, Jun 27, 2010 at 7:26 AM, DrunkenMonk <[email protected]> wrote:
> It was the right direction, I had simply missed a few calls to
> BOLTutf2url.
Just shows there are places where the url is needed. There may be
others as well. And even if you have caught them all, there is no
guarantee I will! :)
> Why would you want page names in url, ever? This is a mystery to me.
> An important one, because utf8 problems are far too common.
> Everything is working flawlessly in my version now, with the url
> encoding only showing up as file names on the hard drive, and
> temporarily in BOLTfilter to simplify the filter regexp.
When I get some time, I'll explore this idea, but basically you need
url's at times because that's what the file names actually are.
Important for searching, regex filtering, matching. One big problem is
info vars, which have page names that need to be utf but match urls.
You might be right there are better places to make those switches, but
it's a complex issue and it needs to work right everywhere. I don't
have time to resolve it right now. As far as I know there are no
current utf bugs, so the urgency for change is not so evident. I
suspect it can be done in the future without any disruptions.
> Nothing else needs to bother about it. Ever.
> Oh, well, some things in commands.php do things which should be
> handled in engine.php, and may need to call BOLTutf2url, but thats:
> a) engine code
> b) easilly fixed
There may be more than you think. Without taking time to do a really
thorough assessment, I'm not convinced.
> So much unneccesary code is removed.
> Why do you want the url encoding internally? Thats a horrible idea!
It wasn't intentional nearly so much as it evolved that way. At some
point we will likely move this direction but only cautiously. I
anticipate a good round of bug prone releases till we get everything
ironed out. Want to wait till I have time to kill on that project and
can fix things rapidly.
> Oh, while I'm writing:
> May I suggest a small change for the sake of plugin developers?
>
> EDIT: I think you did something like this while I couldn't post this.
> (I've been having a problem getting to google groups, infitite
> redirects)
>
> Move the {?var} handling code into BOLTvars, to keep all the {} markup
> handling in one place.
> This means that plugins can easilly access these variables and have
> them be filtered in the correct way. It's also quite intuitive, I was
> really supprised when I found that I couldnt call BOLTvars for {?var}
> vars.
I'll make a note to look at it. Why though? Why not just tap into
them directly? Seems a bit of overkill in this case...
> EDIT: I may have mentioned the below a few times since this. It is
> probably not session_write_close.
Huh?
> By the way, something in form markup processing is really slow. A few
> hundred checkboxes are taking more than 3, sometimes 7, seconds to
> parse on my server, where all other pages takes less than 0.5 s.
> I think it might be the constant calls to session_write_close, since
> this will provoke a file-write action, but I'm not sure.
Oh, I see. I think you are right. I have plans to rework this in a
near future release. It should speed up long forms...
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.
