How to implement Constraint Match Total in VehicleRouting example - optaplanner

I'm trying to explain the score of the VehicleRouting example with GUI, but i don't understand this: "Do not attempt to parse this string or use it in your UI or exposed services. Instead use the ConstraintMatch API below and do it properly." What is the ConstraintMatch API, and how can I implement it with the GUI example?
I only try to print solver.explainBestScore(), but it says to "Do not attempt to parse this string or use it in your UI or exposed services".

Take a look at the rest of that javadoc:
* Do not parse this string.
* Instead, to provide this information in a UI or a service, use {#link #getScoreDirectorFactory()}
* to retrieve {#link ScoreDirector#getConstraintMatchTotals()} and {#link ScoreDirector#getIndictmentMap()}
* and convert those into a domain specific API.
In the documentation, do ctrl-f "getConstraintMatchTotals()" and you'll end up at the section "Explaining the score" which documents how to do that.

Related

{Object} and Object in Node.js API documentation

In the Node.js API doc, some items in the list below some headings are like:
{Object} and some like Object (without curly brackets).
What's the difference?
It's just a documentation quirk as there's no difference: in both cases it's identifying the type of the item.

What's the most common expected behavior for a PUT on a JSON based REST API? A document replacement or a partial update)?

I know there's a whole RFC for HTTP methods but I was wondering what would be the expected behaviour from a PUT to a REST API that responds with Content-type: application/json and accepts JSON encoded bodies.
Is it expected to replace the document entirely with the new JSON object passed in the body?
Is it expected to modify only the attributes passed in the JSON body? (as its the recommended behaviour for the PATCH method RFC 5789).
What if the documents that the API exposes do not conform to an schema and the JSON object in the body has new properties not present in the current document?. Should it add them?
Any comment or resource for me to read will be welcome.
In practice, either of those approaches is all right as long you stick to it throughout the whole application so you keep consistency. I personally like to use PUT if I want to update all the attributes of a record according to the ID. This way I can save the PATCH method for endpoints where I need to specify and update only some attributes like the a typical change password request where I only need to update a specific attribute.
I really recommend this book: http://www.amazon.com/REST-API-Design-Handbook-ebook/dp/B00890OBFI/ref=sr_1_2?s=books&ie=UTF8&qid=1425669926&sr=1-2&keywords=rest+api
1) and 2) PUT means replace. Using it for partial replacement is incorrect. That's what PATCH is for.
3) That's up to your application logic.

Error message with “import-world”

I used "export-world" to export the state of my model. But when I import my world from "import-world", I obtain this error message (I use the time Extension):
Thanks very much for your help.
Looks like the extension you're using doesn't support import-world for the custom data type(s) it defines.
It's something you'd need to take up with the extension's author, or try to hack the extension yourself.
And/or, you could you try to work around it as follows:
If the extension doesn't provide them, define your own procedures for converting the custom data type to a string and back.
Before doing export-world, convert all of the custom objects to their equivalent strings, replacing them in place.
After doing import-world, reverse the process, converting the strings back to the custom data type.

Best way to represent object views (summary, detail, full etc) in Spring based REST service

I am working on a REST service which uses Spring 4.x. As per a requirement I have to produce several different views out of same object. Sample URIs:
To get full details of a location service: /services/locations/{id}/?q=view:full
To get summary of a location service: /services/locations/{id}/?q=view:summary
I have thought of two solutions for such problem:
1. Create different objects for different views.
2. Create same object, but filter out the fields based on some configuration (shown below)
location_summary_fields = field1, field2
location_detail_fields = field1, field2, field3
Could someone help me to understand what could be an ideal solution? I am not aware of any standard practice followed for this kind of problems.
Thanks,
NN
See this article on how google gson uses annotations to convert a Java Object representation to a json format : http://www.javacreed.com/gson-annotations-example/
Since you want two different representations for the same object you could roll your own
toJson method as follows :
a) Annotate each field of you model with either #Summary, #Detail or #All
b) Implement a toJson() method that returns a json representation by examining the annotations for the fields and appropriately using them
If you need an XML representation same thing, except you would have a toXML().
In my opinion the best option is to use separate POJOs for different views. It's a lot easier to document it (for example when you use some automated tools like Swagger). Also you've to remember that your application will change after some time, and then having one common POJO could make troubles - then you'll need to add one field to one service and don't expose it through another.

In JetBrains WebStorm 6, NodeJS/Javascript how can you define, in the comments a JSON example?

I have a function with a json parameter that comes with the same structure each time.
/**
* #param box {object}
*/
function testBox( box )
I am looking for a way to instruct the autocomplete of a structure I insert in that input parameter aside for the fact that it is an {object}. I am looking to avoid typos in coding the function.
I have noticed if I add a structured json to a var, later in the function the IDE hints of the structure, but in the case of a function parameter, I don't do such a thing.
How might one do this?
please, see the following thread: https://groups.google.com/forum/?fromgroups#!topic/jsdoc-users/vR5REZ1I8Jc - the recommended way of documenting this is using #typedef
WebStorm does support JSDoc #typedef annotation. In case oif any problems with resolving/typehinting, please, feel free to file a bug to http://youtrack.jetbrains.com/issues/WEB

Resources