search

zendframework / zend-inputfilter

InputFilter component from Zend Framework
BSD 3-Clause "New" or "Revised" License
64 stars 50 forks source link

Feature/unfiltered input data #176

Closed rkeet closed 5 years ago

rkeet commented 5 years ago

Based on old PR (deprecated) discussion here and Issue description here

Link to last comment with action points (copied below)

@froschdesign @svycka @weierophinney

I haven't forgotten this, just didn't have time this weekend. I hope to get to it this week either during work, an evening or maybe during the coming weekend. However, very busy at the moment.

What I'll try to do the coming days:

Setup up a skeleton application demonstrating issue with plain modules, comments, etc. Summarize this thread & #168 into a coherent whole Quick re-read though:

getRawValue(s)() should not be altered from existing functionality to prevent bc-break Agreed with that getRawValue(s)() returns only known input values, UnfilteredDataInterface should provide solution next to these functions UnfilteredDataInterface adds functionality instead of modifying existing ones I'll get into that more by providing the code I mentioned with unit testing - I hope this can wait a few more days (possibly weeks). Like I said, currently very busy, also next to my job. Though holidays soon, so might get something done then...

So I think this might be it

I've done this one TDD (pats own back). I'm however running stretched for time, so I'm hoping to get some feedback for now.

Also, starting a new job next month in Symfony development (my own projects run ZF3/Doctrine), so as I'll have to do some study to get up to speed, ZF3 contributions will regrettably have to go on a back-burner.

svycka commented 5 years ago

And how would I use this? as I understand I could override inputFilter::isValid() and could use this. But still, no way to access unfiltered data in validators and filters would be useful :)

rkeet commented 5 years ago

As what was attempted with the previous setup, it was to make all of the unfiltered data available, not to already implement it in existing functionality. That's why this only adds the property on the InputFilter class and sets it. That makes it available for each to implement/use it at will.

To make it implemented by default, e.g. in the isValid(), I would argue that that would have to be a separate feature. Both the make sure that this one does not break anything and so that a discussion may be held about the (dis-)advantages for a change in current functionality. That's also why I think that would be outside the scope of this PR/feature.

weierophinney commented 5 years ago

Thanks, @rkeet!