mikebarlow / html-helper Goto Github PK

On whichever class is your main entry point to the library, add a factory function that returns a new instance of that object filled with the default implementations of its collaborators. This will cover 95% of the cases for your users and simplify adoption of the library. Users are, of course, free to instantiate the objects themselves if need be, which allows them to swap in different components as necessary.

It appears that FormData is used to read input. HTTP input isn't necessarily from forms. It could be generated in more ways. The current naming implies some sort of coupling with forms, specifically.

Also, consider that input may not even be coming from a form, but perhaps from a socket, file pointer, etc. I'm not asking you to code against these various other interfaces, but just to design your interface and naming to be general enough that an enterprising person who extends your code could write something against of those these.

There just doesn't appear to be enough in the other project to justify having it as a separate project. That, and the likelihood that it would be used independently of this project is very low. KISS it, please.

You currently have an Interfaces directory/namespace, but have a mixture of interfaces and classes within that folder. The interfaces aren't clearly called out in their names, so it's all very confusing when looking in the folder or in determining what something is.

I propose that you:

• Follow items one through three of the PHP-FIG recommendations
• Split this folder up into more meaningful folders/namespaces. As a general rule of thumb, I've found that if there's a single interface that is supported by multiple classes, those should all go into the same folder. e.g. the snscripts\html-helper\Form namespace would contain FormInterface and some specific implementation of that interface. If you have a hierarchy of interfaces, each of those child interfaces gets its own folder.

Also note that the leading back-slash on a use statement is both unnecessary and undesirable. You can take those off and get slightly better code readability. Consider also not aliasing entities when calling use, unless you have a name conflict. When you use the base name directly, there's less mental processing involved with reading the code. It cuts out a translation step.