[Shadow] add CliRequest class
Review Request #88 — Created April 25, 2013 and submitted
Information | |
---|---|
olivier | |
Lunr | |
https://github.com/owizen/lunr/tree/CliRequest | |
7315 | |
Reviewers | |
lunr | |
this adds the Cli request class made for being compatible in signature with the request class.
Unit tests prepared but waiting for GetoptCliParser
-
-
-
src/Lunr/Shadow/CliRequest.php (Diff revision 2) I'm expecting 10 entries here, but there are only 2
-
-
src/Lunr/Shadow/CliRequest.php (Diff revision 2) Implementation doesn't match documentation. At all.
-
src/Lunr/Shadow/CliRequest.php (Diff revision 2) this is void. Why does it return NULL? Why is it not implemented properly?
Change Summary:
change made according to review unit tests added, more to come concerning them.
Diff: |
Revision 3 (+528) |
---|
Change Summary:
Update made to class according to review. Introduce store_url and store_get methods. Unit tests updated, return statement added to LunrBaseTest::get_reflection_property_value
Diff: |
Revision 6 (+577 -2) |
---|
-
-
-
-
src/Lunr/Shadow/CliRequest.php (Diff revision 6) you are aware that what you are doing here is like asking santa clause if his first name is santa, right?
-
-
-
Change Summary:
Change made according to review, split the test case in 3 files. for store_url, dont know what is the best action.
Diff: |
Revision 7 (+654 -1) |
---|
-
-
src/Lunr/Shadow/CliRequest.php (Diff revision 9) Conceptually this is fine. And if it were the only thing left, I wouldn't mind it staying that way. But if you have to go over it one more time, you might just as well combine it.
-
src/Lunr/Shadow/CliRequest.php (Diff revision 9) Semantics: -We have a certain format for methods that return data from an environment source. All of have a name matching "get_..._data", except for this one. - On the cli we have parameters/arguments and options. Looks like I was using them wrongly too (was looking it up just now). If we look at the command "cli.php -a test", then "-a" is an option and "test" is an argument/parameter to that option. I don't mind whether you use parameter or argument for it, but be consistent and correct, ie. don't say argument when you mean option. - $index is no longer necessary
-
src/Lunr/Shadow/CliRequest.php (Diff revision 9) I still don't know why you treat an empty array as a special value. If you look at the function from a semantic view, "get_arg" returning "FALSE" is an error case. But an option with no argument is not necessarily an error
-
src/Lunr/Shadow/CliRequest.php (Diff revision 9) This kind of hangs in the air, compared to the other methods. There is no equivalent for post/get/cookie and the function name doesn't match the documentation. If you can think of (please do, because I might be overlooking something) a good use case for having this it can stay (with proper function name). Otherwise I'm inclined to just see it gone.
-
src/Lunr/Shadow/CliRequest.php (Diff revision 9) I still don't understand why it hurts to implement this
-
src/Lunr/Shadow/Tests/CliRequestBaseTest.php (Diff revision 9) Please use meaningful test names. phpunit has an option that translates the method name into a test description. This one would say: test Store url........OK/FAILED which doesn't really tell me anything about the test (except that I'm storing the URL. For a CLI request)
-
src/Lunr/Shadow/Tests/CliRequestBaseTest.php (Diff revision 9) If you look at this you see that what you are doing here is actually performing five tests in one. That's something you want to avoid generally and what we use data providers for.
-
src/Lunr/Shadow/Tests/CliRequestGetSetTest.php (Diff revision 9) That is correct, but non-constructive. You write unit tests only for the purpose of code coverage. But if you look at the implementation in the standard request class you'll see that there is an actual useful test you can implement that tests the same thing, but doesn't need to be rewritten when we have the time to properly implement this. (also valid for the other NULL methods)
Change Summary:
Change made according to review, implement json_enums support.
Diff: |
Revision 10 (+768 -1) |
---|