Now I just add a 'virtual' resource, which is called 'methods'.
The good thing about this is that it works well standalone, or
in conjunction with actual resources.
Also the system works with it just with minimal changes
Fixes#19
These 'methods' have no resources, and need slightly special handling.
This version at least makes the generator work, even though
it produces duplicates.
However, as it is so ugly, I'd rather consider to change it
substantially ... this feature should just come naturally.
URL expressions allow to substitute values within the URL with
parameters. However, this is not only a simple key-value replacement,
but supports expressions that need a parser.
This one will have to be implemented next.
Now json errors are handled and delegated with the option to retry,
and all other values are just decoded according to plan.
For now, I brutally unwrap json values assuming this will work, because
it really should work.
This doesn't work yet, as I am unable to unwrap the client properly.
It's a refcell that contains a BorrowMut to a hyper::Client, and
lets just, it's complicated.
This caused cargo on a case-sensitive file-system not to find the
cargo file, which made it to look upwards in the directory structure
to find the correctly named Cargo.toml fo the 'cmn' development
project.
Previously, I would just assign all useful traits to all types, no
matter on how they were actually used.
Now it builds all dependnecies and considers them when assigning
traits, which is as precise as we need it.
This is important to us as the `Json` type is just encodable, but
not decodable. Fortunately, we just have to encode it, but in theory
this makes it hard to embed any json in a known structure.
Due to shared global state which was altered, we got wrong results.
This is fixed now, thanks to a deepcopy. Amazing, how altering global
state is always biting you, even though you are convinced it's safe
to do in just this case !
General rule: Just don't do it, no matter what !
Into a complete, global list of schemas, with additional meta-data.
However, it's currently not complete, as $refs are missing.
There is some resemblance to to_rust_type(...), which worries me
slightly
It is a Json object, with a schema as defined elsewhere. It's quite
cool to see this (nearly) working already. However, it will require
us to transitively assign the required markers which is based
on information we don't currently have.
Maybe implementing this could also help to simplify name-clash checks
or make them better at least ?
It was possible for a nested type to be generated with a name that in
fact CLASHED with an existing schema type. What are the odds !
The clash-check added will just verify against clashes with schema
types, which seems to be doing it for now.
At least so it appears.
The implementation doesn't look totally clean to me, as it seems
similar concerns are in different portions of the code, which was
merely tuned to work together.
It could break appart if someone - me - wants to change it sometime
