Hey all. Am 30.06.25 um 23:31 schrieb Jaap van Otterdijk:
Thanks again for taking the time to give us an answer. It just underlines my statement that your efforts to get this done are huge.I was thinking again about your answer. And while reading I realized you have a point about the struggle we would have to come with an interface for request validation. It's a hairy topic. Because everyone is doing this in their own way. But that's exactly the point of a standard. It's not just the matter of getting things done. It's about the value it provides. The interface for a captcha seems to me a very small work field. While you could argue that that's a good point. I think interfaces that have a bigger focus are better in place. Not that the interface itself should be large, but the way it can be used should be brought. At least in a standard lib. Or it should focus on a very common problem. The psr standards all focus on very common patterns in a web application. Everyone needs logging, service containers can be found everywhere, and there is literally no php application out there that doesn't do request response. That's why those deserve a psr. That's also why I think validation would be a very good candidate. Because validation is everywhere. . For captcha this is a different story. While there are many captcha providers, not all applications use captcha. It's not a common pattern. It's a solution for a specific problem. So the amount of applications actually using it will be very limited. If the would even exist in the future. I think more and more companies are actually looking for a better way to validate their users are human. I really tried to see the value. But I simply don't get it for this particular psr.
I wholeheartedly agree with Japp here for several reasons:Captchas are - despite their wide usage - an antipattern. The fact that they are used on a lot of platforms does not mean that it is a good idea. A lot of people are using timestamps or convert dates to UTC when there are better options available. Just because people do it does not mean it is the right thing to do.
Providing an interface from the FIG explicitly for Captcha-Usage will make it look like the FIG supports this anti-pattern. I would rather not see that.
On the other side though a Captcha is something that is included in a form. It is one form field. If you don't use forms, you don't need captchas.
And what indeed is missing - and I just stumbled upon this in another project I am working on - is a set of interfaces that allow be to easily build, display and validate a form. SOmething that allows me to add form-fields from different sources to a form "object" and then easily render that and in the next step validate it.
Something like $form->add(new TextField('name', 'value', 'default', ...))
And once there is such a "FormBuilder" interface set that allows adding
different fields from different sources (as they all share the same
interfaces) it should be no issue at all anymore to call then something
like $form->add(new Captcha('name', 'value', 'id-key', 'whatever else'));
Which then allows easily exchangeable Form fields. So then the only thing missing is different implementations of the interface for different Captchas. Switching them out should be a breeze
This way it is easy to use Captchas if you need to (You still should not and you should make your managers understand why not!) but there is no need for a specific captcha-related interface.
My 0.02
Cheers
Andreas
--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:[email protected] N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas |
+---------------------------------------------------------------------+
| GPG-Key: https://hei.gl/keyandreasheiglorg |
+---------------------------------------------------------------------+
--
You received this message because you are subscribed to the Google Groups "PHP
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/php-fig/a170a1bd-c492-4fe7-9616-c83f13103c41%40heigl.org.
OpenPGP_signature.asc
Description: OpenPGP digital signature
