Quote:
Originally Posted by AtomicDryad
Hmm I wasn't aware of discussions not on this board...
|
There have been limited discussions on github, although only between myself and nbriche. I assumed you'd seen them, as you are following the repo.
Quote:
|
...but it didn't seem like a completed skel.
|
It's not - it's the start of a skeleton; I've been waiting for feedback on the design before I sink some serious time into it - I'd rather get it right the first time than have to go back and redo it because people don't like the structure.
Quote:
|
I did notice that the url matching seemed limited...
|
It's more or less a placeholder at this point - like I said, I've been waiting for feedback.
Quote:
|
As far as decision making, I don't want to say the creator of fflag shouldn't be making them. But I also see myself proposing changes to things if it would result in more versatility or effeciency. If that would be more frustrating to you, I'll fork and annotate what's on git, instead of fork/alter/pull request.
|
Please feel more than free to suggest whatever comes to mind. I'm not tied to any particular approach, so if you don't like what's there, or you want to change it, please sing out.
I would like to request that we have a complete (or at least mostly complete) framework first though, before adding lots of special cases.
Quote:
|
Yeah, that. All I need for vbulletin parsing is xpath matching. Not the extra troublesome baggage. Unfortunately, regex is not the best; matching the beginning is no problem, but finding the end where there are nested tags tends to be troublesome.
|
Agreed - regex is largely useless for that.
Quote:
|
Perl's HTML::Treebuilder doesn't frak with encoding for instance.
|
Unfortunately this isn't written in perl
. PHP's handling of various character encodings isn't great in places, I've found that it sometimes pays to do conversions first to avoid munging the data.