[Shadow] add CliRequest class

Review Request #88 — Created April 25, 2013 and submitted

olivier
Lunr
https://github.com/owizen/lunr/tree/CliRequest
7315
lunr
this adds the Cli request class made for being compatible in signature with the request class.
Unit tests prepared but waiting for GetoptCliParser
  • 0
  • 0
  • 23
  • 0
  • 23
Description From Last Updated
olivier
pprkut
  1. 
      
  2. src/Lunr/Shadow/CliRequest.php (Diff revision 2)
     
     
     
     
     
     
    What's this used for?
    1. for early exit if the parser detects invalid command line
    2. and you do that where exactly?
    3. In the front controller, for example
    4. What's the use case for it? When would an application developer want to know that the command line was invalid? What would he do with that information?
  3. src/Lunr/Shadow/CliRequest.php (Diff revision 2)
     
     
     
    I'm expecting 10 entries here, but there are only 2
    1. I can then init the entries with all the default entries from the configuratio
    2. why would you do that?
    3. for class signature compatibility.
    4. Check the Request class. When are the values initialized with the default values and what's the impact of that on the CliRequest class?
  4. src/Lunr/Shadow/CliRequest.php (Diff revision 2)
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
    What's a stored value and why would it be empty?
    1. following this command: -a param -b
      
       get_arg('a') returns "param"
       get_arg('b') returns false cause the key contains an empty array -> 0 in an invalid index
      
      
    2. Note I am not sure that false is the best value for empty keys.
    3. Consider a developer who wants to do something with the arguments. He finds a function that says "Retrieve a stored value for..." and his first reaction is "wtf is a stored value..."
    4. I got it, the diff was updated this way.
  5. src/Lunr/Shadow/CliRequest.php (Diff revision 2)
     
     
     
     
     
     
     
     
     
     
     
     
     
    Implementation doesn't match documentation. At all.
    1. Oops crappy copy paste
      
  6. src/Lunr/Shadow/CliRequest.php (Diff revision 2)
     
     
     
     
     
     
     
     
     
     
     
     
    this is void. Why does it return NULL? Why is it not implemented properly?
  7. 
      
olivier
olivier
olivier
olivier
pprkut
  1. 
      
  2. src/Lunr/Halo/LunrBaseTest.php (Diff revision 6)
     
     
     
     
    unrelated change
    1. I know, should dispappear once this is merged
      http://reviews.lunr.nl/r/91/
    2. No. Properly base your diff against the branch this is based on and document your dependencies. I will reject double reviews. No exception.
  3. src/Lunr/Shadow/CliRequest.php (Diff revision 6)
     
     
     
     
     
     
     
     
     
     
     
     
     
     
    This does not do what it advertises
  4. 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?
    1. I know but other wise I dont have any point in making the method and removing the affectations from the constructor...
    2. And I would add that the request class checks the sapi to act, I update the review and we will discuss about it later
      
    3. Dude, cause and effect. Simple physics. Cause = Disussion, Effect = Change. No change without discussion. What do you change? You haven't understood anything...
    4. No and no clear point of view for me concerning this...
    5. Ok, in simple terms then. You have a class abstracting a CLI request. And you have a function that does things differently depending on whether the request was made from the cli or elsewhere. What use case do you see where the CLI request class is used in a non-cli context?
    6. So I get it
  5. src/Lunr/Shadow/Tests/CliRequestTest.php (Diff revision 6)
     
     
     
     
     
     
     
     
     
     
     
    this tries to do too much. Split it up
    1. Ok will be done so
      Let's say I add base and get set files
      
  6. why the extra parameters?
    1. Sigh. I'm ASKING a QUESTION, god dammit. 
    2. Cause I did't use the mock builder, this is changed by now. Otherwise invoking the parse method failed
      and the mock didn't build without contructor params.
  7. mock the configuration class
  8. 
      
olivier
olivier
olivier
pprkut
  1. 
      
  2. 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.
    1. I will group them in store default as it is the only thing we do here in fact.
  3. 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
    1. go for get_option_data as it is the most consistent name we can give here.
      
  4. 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
    1. I think the best option would be to return an empty array then.
  5. 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.
    1. then renaming it to get_all_options seems a correct name.
      
  6. src/Lunr/Shadow/CliRequest.php (Diff revision 9)
     
     
     
     
     
     
     
     
     
     
     
    I still don't understand why it hurts to implement this
    1. True this can be usefull and doesn't really cost time
  7. 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)
  8. 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.
  9. 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)
  10. 
      
olivier
olivier
dinos
  1. 
      
  2. src/Lunr/Shadow/CliRequest.php (Diff revision 11)
     
     
    will it stay like this?
    1. That method is here for signature compatibility with the core Request class.
      Both CliRequest and Request classes must be exchangeable. In the future
      this might return something, if there is a relevant usecase.
  3. src/Lunr/Shadow/CliRequest.php (Diff revision 11)
     
     
    here too
  4. src/Lunr/Shadow/CliRequest.php (Diff revision 11)
     
     
    here too
  5. src/Lunr/Shadow/CliRequest.php (Diff revision 11)
     
     
    here too
  6. src/Lunr/Shadow/CliRequest.php (Diff revision 11)
     
     
    here too
  7. 
      
dinos
  1. Ship It!
  2. 
      
olivier
Review request changed

Status: Closed (submitted)

Change Summary:

Merged into master
Loading...