> On Oct. 25, 2013, 6:10 a.m., Prasanna Santhanam wrote: > > I actually don't quite see how marvin uses the typeInfo. Will it only act > > as a carrier for this information? > > > > How would a test case author use this? It would've been nice if we could > > use the type info to deserialize the response returned by the server so > > each field gets its appropriate type. But in most tests we don't use the > > type information afaik. > > Ryan Dietrich wrote: > Yes, a carrier. The main goal was to get the type into commands.xml, so > other "things" could take advantage of this extra meta-data.
I'm okay with it going to the 'commands.xml'. But may be we could wait on including it in cloudstackAPI stubs since you're not using this information directly from marvin? - Prasanna ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14889/#review27513 ----------------------------------------------------------- On Oct. 23, 2013, 9:38 p.m., Ryan Dietrich wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/14889/ > ----------------------------------------------------------- > > (Updated Oct. 23, 2013, 9:38 p.m.) > > > Review request for cloudstack, Marcus Sorensen and Prasanna Santhanam. > > > Repository: cloudstack-git > > > Description > ------- > > I have a requirement for some work I am doing to "fail early". The existing > marvin cloudstackAPI classes give me both the "legal" and "required" elements > for each API call as well as the response attributes. However, they do not > tell me the types of each value. I've gone ahead and exposed that type > information to python and to commands.xml as well. I decided to try and > expose things so we're being as descriptive as possible. It's a little > deflating how the Request/Response annotations aren't equal (Requests can > expose "strings" as "uuid's", allowing me to auto generate regex's for > validation). Responses however, simply fall back to the specific java type, > (Integer, Long, String, Boolean). > > I believe cloudmonkey could take advantage of this, by stopping invalid > parameters from being sent to Cloudstack in the first place (client side > validation is good, right?) > I also think the UI could use this as part of their validation routines, if > they're using commands.xml as part of their build process. > > > Diffs > ----- > > server/src/com/cloud/api/doc/ApiXmlDocWriter.java c3c0cab > server/src/com/cloud/api/doc/Argument.java 29c361e > tools/marvin/marvin/codegenerator.py 96729f6 > > Diff: https://reviews.apache.org/r/14889/diff/ > > > Testing > ------- > > mvn clean > mvn > cd tools/apidoc > mvn > inspect target/commands.xml > cd ../tools/marvin > mvn > inspect python classes > > > Thanks, > > Ryan Dietrich > >
