| # |
Jul 10th 2017, 11:57 |
inoas |
feels sad inside :E |
| # |
Jul 10th 2017, 11:57 |
inoas |
thats should be very clean and concise and I really fear setter-hell for options |
| # |
Jul 10th 2017, 11:57 |
inoas |
much like function overloading even |
| # |
Jul 10th 2017, 11:57 |
inoas |
either to stop the function from executing or - if one pattern is found - to continue - if multiple patterns are found to continue via proxying to protected methods |
| # |
Jul 10th 2017, 11:56 |
inoas |
so I would love to see that we support a simple php-ish way to create schemas that then can be used to pattern match for $options |
| # |
Jul 10th 2017, 11:56 |
inoas |
if yes, I fully agree but the support is not there |
| # |
Jul 10th 2017, 11:56 |
inoas |
like symbols? atoms? |
| # |
Jul 10th 2017, 11:23 |
 lorenzo |
It would be better if php adopted the idea of enums, that Hacklang has |
| # |
Jul 10th 2017, 11:22 |
lorenzo |
I totally see you argument. I wouldn't like to have objects for all options, maybe only for configs |
| # |
Jul 10th 2017, 11:21 |
inoas |
lorenzo can you see my argument/fear? |
| # |
Jul 10th 2017, 10:57 |
birdy247 |
and have updated my index.php accordingly |
| # |
Jul 10th 2017, 10:56 |
birdy247 |
And I have a Application.php like this |
| # |
Jul 10th 2017, 10:56 |
birdy247 |
So my bootstrap looks like this: |
| # |
Jul 10th 2017, 10:55 |
birdy247 |
If I leave a DispatchFilter of ControllerFactory and have turned on Middleware, will this cause problems? |
| # |
Jul 10th 2017, 10:54 |
inoas |
... and the gist above is just an alternate suggestion |
| # |
Jul 10th 2017, 10:50 |
inoas |
hmic and as for business logic, there is parts that are stateless, those can be pre-validated, and parts that are not (say like a specified $id not existing in the database) which still need to be caught by custom business logic |
| # |
Jul 10th 2017, 10:49 |
inoas |
my comment here https://github.com/cakephp/cakephp/issues/10866#issuecomment-313391901 explains it pretty much |
| # |
Jul 10th 2017, 10:49 |
inoas |
https://github.com/cakephp/cakephp/issues/10866 |
| # |
Jul 10th 2017, 10:48 |
lorenzo |
what options? |
| # |
Jul 10th 2017, 10:48 |
inoas |
lorenzo I just wanted to voice my concern about setter interfaces for options (instead of something similar to pattern matching/pattern validation) |
| # |
Jul 10th 2017, 10:48 |
lorenzo |
did you have a question? |
| # |
Jul 10th 2017, 10:48 |
lorenzo |
around now, but I haven’t read back |
| # |
Jul 10th 2017, 10:48 |
hmic |
i've seen the first, and my initial answer was about that. |
| # |
Jul 10th 2017, 10:47 |
inoas |
https://gist.github.com/ionas/94e961bf414c78362442041081dad3ca#file-option-arrays-php-L4 |
| # |
Jul 10th 2017, 10:47 |
inoas |
vs this very concise interface |
| # |
Jul 10th 2017, 10:47 |
inoas |
did you see the setter example here https://github.com/cakephp/cakephp/issues/10866#issuecomment-313391901 |
| # |
Jul 10th 2017, 10:46 |
inoas |
that class can exist I am okay with that |
| # |
Jul 10th 2017, 10:46 |
inoas |
I am not talking about the routing class |
| # |
Jul 10th 2017, 10:45 |
hmic |
me too. but it's up to your (custom!) business logic to implement these. not the routing classes |
| # |
Jul 10th 2017, 10:45 |
inoas |
but I fear the setter/getter-hell will be a very bad pattern here |
| # |
Jul 10th 2017, 10:45 |
inoas |
I totally see the reason to be strict/er on options |
| # |
Jul 10th 2017, 10:45 |
inoas |
it is error prone to miss-type options and it is error prone once interfaces change to forget about removing some etc |
| # |
Jul 10th 2017, 10:44 |
hmic |
why is this? - because the set of options changes. who would need to validate the possible ones? the underlying routing class? - not really. |
| # |
Jul 10th 2017, 10:42 |
inoas |
lorenzo around? |
| # |
Jul 10th 2017, 10:41 |
inoas |
thats what we do already but not standardized but always different each time there are options to consume |
| # |
Jul 10th 2017, 10:41 |
inoas |
building a pattern validator for the options and validating it against that before consuming the options |
| # |
Jul 10th 2017, 10:41 |
inoas |
I can see the reason why to add it but there is a different way... namely doing something like pattern matching one could say |
| # |
Jul 10th 2017, 10:40 |
inoas |
but what is far worse is the interface which is ultra verbose |
| # |
Jul 10th 2017, 10:40 |
inoas |
what I fear is that the code required to do options validation will be very verbose and lack interactions such as nested validation, optionality and default values |
| # |
Jul 10th 2017, 10:40 |
inoas |
I can't follow entirely |
| # |
Jul 10th 2017, 10:39 |
hmic |
inoas, the idea to go with arrays is pretty clear, and i don't think it will change in the nead future, especially for routing/url generation. despite the fact that/if you would want your urlObjects frozen? how do you make your prefix optional? or add another query param? - pass this through like 3 layers of code down to where you need to build the urlObject |