OK, took time to look thru this. Nice clean code. I see what you did with the Range inheritance. I use the Abstract Adapter for shared methods but I have been considering switching to a composition approach.
I put a spreadsheet
out there and added you as an editor if you want to collaborate on definitions, plans, etc.
Couple of points:
1. Another reason I went with one package for validation, filtering and escaping was I wanted to keep things consolidated and clear -- this is where you do field stuff.
Too many times, it seems we have a little bit of filtering here or there and it's not obvious to developers where to do what. I couldn't come up with a good reason why a developer would want this validation package and this package for filtering and this package for escaping.
To me -- it's just Fieldhandling. Any time you deal with data, either by bringing it in to the application or displaying it - it needs to be handled. So, aside from the shared code, etc., above, my thinking, right or wrong, was to keep it all together.
2. In terms of keeping it simple, I like Joomla's Filter API and the Fieldhandler is modeled after the API in terms of what the developer has to do.
Right now, I have well over 50 data type adapters - some are custom for Molajo's application. For example, I have adapters for username, userid, catalog_id, category, tag, etc., some of the unique data elements I want treated a certain way.
But, the developer doesn't have to create those classes. Instead, a proxy class
is injected into the relevant controller already instantiated, humming and ready to go. Then, each validation (or filter or escape) uses that instance.
There is no state to manage because the call thru the proxy creates the class instances needed (multiple in the event of chaining) and returns the results.
I think that's going to be easier to use than the approach you are using where the developer must create each validate class (know it's name then create the instance and then
Maybe your plan is to add a proxy like I described?
3. Looks like you are laying the framework and will need to then add all the data types. Right now, you have 5 or so validations. Essentially, we are using the same approach on the validation, in a couple of cases we validate a data type slightly differently (I marked those on the spreadsheet), but other than that, the test, itself is close.
4. IMO, the PHP community needs to get-it-together on the HTML filtering. All the "experts" say to use HTML Purifier
, but it *still* does not support HTML5. Personally, I'm only comfortable using a whitelist
and I pulled in some very old code called kses
to parse and filter the HTML. I'm thinking about how to "spread the word" and rally a little support either around HTML Purifier's update or some other solution.
As an aside, HTML Purifier had a serious security issue and fairly recent release. That's the first release since 2009. None of the plugins seem to be updated, including the one they use
for their forums. Joomla's isn't even updated for new Joomla releases
. (Plus, it's just used to escape the output -- not filter.)
Anyway, HTML filtering is still pretty antiquated and I'm not happy with my solution there -- but it's likely safe. I'm personally not adding blacklists or going further than that since I think it's not safe.
It'd be good to have the Framework team consider directions in this area. Do you want one package for all data element handling? Do you want to focus on the validation only? I'm happy to help once there is a good idea of where you want to lead. I don't want to get in the way -- we don't have to use my code in this form - if it helps to copy it into another format, fine.
Let me know the next steps if I can be of service.