I owe John: 1 proselytizing message on OOP.
Buffistas Building a Better Board
Do you have problems, concerns or recommendations about the technical side of the Phoenix? Air them here. Compliments also welcome.
Did you just give him an OOP FYI I.O.U.?
OK have a look at this page: [link]
Which tags is this supposed to check? Because it's not closing a t table tags.
it's not closing a table tags.
It is now.
You tell me what tags, I'll add them -- does it actually make sense to tell it to close TABLE, TR and TDs?
You tell me what tags, I'll add them
Since I'm 3000 miles from home, I can't check the code and give you the list, but didn't I post a list upthread somewhere?
Ahh! I found it:
<a> <b> <i> <u> <ul> <ol> <li> <p> <br> <strike> <table> <tr> <td> <th> <font> <pre> <code>
does it actually make sense to tell it to close TABLE, TR and TDs?
Yes, but tables are tricky. As I pointed out a while back, the mere existence of a t td t /td pair within a post, without a t table t /table pair around them, causes havoc with the tables on this page. So even if you close an open t td tag, we'll still have problems.
I still think we should disallow table tags altogether (sorry, ita).
didn't I post a list upthread somewhere?
The list I'm using is exactly that, with the table tags taken out.
The only way to reliably check table code would be with a proper parser, that checked syntax, not a brute-force method like mine.
Thinking about my function, why would it need to return an error.
There are only two kinds of strings in the world. Those with unclosed HTML tags and those without. The string "" is a member of the second group.
So the array returned by it should just be ([true|false], content), right? The empty post thing would be handled elsewhere already.
I still think we should disallow table tags altogether (sorry, ita).
I think we should ignore the problem until we see it happening once a week. When it starts happening that frequently, we should make the board either fix or reject such posts.
Thinking about my function, why would it need to return an error.
Right now, maybe not, but perhaps it will need to in the future. How about we change the boolean to an integer, where zero is success without change, 1 means success and the message was changes, and anything negative is an error?
I admit I've been skimming the gory code details, because I've been so excited that I could.
What's the overhead involved in opening unmatched closes as well as closing unmatched opens? It's symmetrical, it's the full problem, and it means that the table thing's not a problem.
Very easy for me to say, what with someone else writing the code.
Did t strike just get knocked out? I had a "strike" tag in my last message in Sunnydale Press and when I went back to check on it, the strike doesn't work -- though when I went into Edit mode, the formatted tags were still there.