On 10/18/11 17:34 , Mads Enevoldsen wrote:
How would that work in the html client, having a command and a query with the same name? Wouldn't it create identical links for both methods?
No, the query method is just there to provide the GET semantics for the command. So it would show up as a command in the listing, but not as a query.
It would, yeah, probably. The idea was that this is intended behaviour. If you remember from Streamflow there was a common pattern where the client first would call "possibleXyz" which returns list of links, and the user would select one and post it, e.g. "addlabel?entity=123". In this case the client would do a GET on "addlabel" first, which presents the list of possible labels directly.
We *could* define this so that the "query" method really just is a fancier way to produce the GET result for the command of the same name. So in the REST API you would only have a resource that represents "commandwithvalue" that supports GET nicely, rather than one query and one command.
I'm a bit torn on this one.
So because the initial crc.refresh() has discovered the query "commandwithvalue" and command "commandwithvalue", we can do the client.query( "commandwithvalue" ). The name refers to the "rel" attribute of the discovered operations, right? As I understand it there is no modifying urls anywhere.
Correct.
[SNIP] .onQuery( "commandwithvalue", Links.class, new ResultHandler<Links>() { // Select a link from the list and invoke it @Override public void handleResult( Links result, ContextResourceClient client ) { Link link = LinksUtil.withId( "right", result); client.command( link ); }How is the input parameter for the command handled? The commandwithvalue needs a TestCommand as input.
The selected link provides the request parameters needed to construct a TestCommand ValueComposite. Similar to EntityValue, if you remember that one. Just a simple value with an "entity" property.
I'm not sure I understand the analogy that a resource (i.e. ending with "/") is a use case. To me it makes more sense that commands or queries are use cases. Resources are merely containers of use cases - in what resource the use case is located is not relevant for the client.
Resources whose URLs end with "/" are use cases. Commands and queries are also resources, but whose URLs do not end with "/". Commands and queries are interactions, or steps, within a use case. I think you have misunderstood what the word "use case" means. You need a series of steps, i.e. a scenario, to fulfil a use case. The commands and queries provided under each "/" part of a URL does that. And it is indeed very important that they are collected under a particular use case, because the "rel" attribute on the link pointing to it will be used by the client to figure out what set of rules to use for it.
/Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
