I have a data structure defined as follows:
# Data Structures
## PlayerRank (object)
Represents the minimum amount of data the the client needs to send to give rank information about a particular Player in a particular Played Game.
+ playerId (number, required) - NemeStats unique identifier for the Player.
+ gameRank (number, required) - The corresponding rank of the Player in this Played Game. A rank of 1 means the Player got first place, 2 means second place, and so on.
+ pointsScored (number, optional) - Integer number of points the Player scored in the Played Game.
I'm attempting to use this data structure in another action definition as follows:
## Create a new Played Game [POST]
This service will record a new Played Game.
+ Attributes
+ gameDefinitionId (number, required) - NemeStats unique identifier for the Game Definition (e.g. Race For the Galaxy's unique Id) of the Played Game.
+ datePlayed (string, optional) - The date the game was played in yyyy-MM-dd format (e.g. 2015-04-29).
+ notes (string, optional) - Any notes or comments that the User wants to record about the game for future reference.
+ playerRanks (array[PlayerRank], required) - A collection of PlayerRank objects specifying the game rank and points scored for each Player. See below table for details.
What I want to happen is for the Apiary.io Documentation to show the definition of not only the top level attributes but also those of the PlayerRank object. As a developer trying to understand the UI, I want to see the definition of each object and field so I know how to properly form a request. Right now it only gives the description for the playerRanks object which is : "A collection of PlayerRank objects specifying the game rank and points scored for each Player." but it doesn't expand the definition to show all of the properties of a PlayerRank data structure.
Any idea if the Apiary.io documentation can facilitate this?
now Apiary, API Blueprint supports nested objects which you can define as below for example
+ Attributes (object)
+ name: iPhone 6 / 6s (string, required) - Offer Name
+ price: 10.4 (number) - Offer price
can be a number with 2 decimal places, this is the sale price
+ offer_options (object)
+ option_name: black (string, required) - offer option name
+ max_qty: 0 (number) - Purchase limit to this quantity
AFAIK it's a beta feature and the UI is not finished yet, see this github issue for more information and sneak preview of the birght future.
Related
I am working on a search filter atm where people can specify things like (example) size, color, fabric and so on.
Obviously I have models for each i.e. size, color and fabric. But since this "search" should return every result i.e. size + color + fabric and not just one of the three I would need to make a new struct which contains all the (size, color and fabric) to be able to consume the result that Gorm would return.
Since we have a LOT of filters, this could get very messy. Does anyone know if there is a better way to do it? or what would be a best practice to do this?
type Result struct {
ID int
Name string
Age int
}
var result Result
db.Raw("SELECT id, name, age FROM users WHERE name = ?", 3).Scan(&result)
The above example illustrates how I think it should be done, but as you can expect with the amount of data I need to return this struct would become huge.
The results are quite large in terms of data. I mean what I would want in return in the final version for example (this is about sales):
What products were bought, the amount, color and size. Payment data i.e. price, tax, payment method. Customer information, et cetera.
So in total there is a lot of information to store.
All this information should be returned as a JSON format so we can call it through an API call.
Each call should give back 100 up to 15.000 results, to give you an idea of the side of the data.
Hope someone can explain a bit about a best practice method and -or how I should solve this problem as I am unsure on how to code this effectively.
I have many places in my API where I will need to describe a list of objects. Each object has the same keys / structure but different values. How can I tweak the values of each instance of some data structure while retaining all the original type, description, etc of the original structure?
for example if I had the following data structure Restaurant
# Data Structures
## Restaurant (object)
+ restaurant_name: McDonald's (string, required) - The name of this restaurant
+ years_of_operation: 54 (number, required) - The number of years since established
Then, let's say I want to instantiate several Restaurants in a GET response like so:
### List all restaurants [GET /restaurants]
+ Response 200 (application/json)
+ Attributes
+ data (array)
+ (Restaurant)
+ (Restaurant)
+ restaurant_name: Bob Evans
+ years_of_operation: 23
+ (Restaurant)
+ restaurant_name: Eataly
+ years_of_operation: 16
the JSON body would look like this (note how years_of_operation for Bob Evans and Eatly are now numbers)
and the rendered documentation will only show this (the descriptions for restaurant_name and years_of_operation for Bob Evans and Eatly are now missing)
I thought that MSON would carry over those descriptions and type definitions. Otherwise, I have to update a description (or type, requirement, etc) everywhere that data structure is used... but I was under the impression this is a sort of problem MSON is supposed to solve? Am I doing something silly?
I'm posting here in addition to my github issue since it's been a long time since that repo has had contribution
I am trying to create simple printer support chat bot using rasa-core via nlu interpreter, bot should get the printer model, and printer type and post a issue.
I have used the printermodel and printertype variable in slot and entity, but the slots are not getting populated from the chat string.
Please help me on this.
Not very much information to go off of, but here are several things I would check if my slots weren't being filled correctly:
Is NLU parsing the entities correctly? Slots are usually filled from NLU entities. Send your text direct to the NLU and see if the entities are found.
Entity and Slot names are not consistent? The default method of filling slots without custom programming expects the slot name to match the entity name.
Are the slots defined correctly in the domain information?
If you're still having trouble I encourage you to create an issue or join us on gitter.
For example, we have to design simple conversation
User: I am Shivam
Bot: Hello Shivam
Here, we have to extract name and respond using it.
Step 1: In nlu.md file
## intent:told_name
- i am [shivam](name)
- my name is [shivam](name)
- hi, i am [shivam](name)
Step 2 In domain.yml file
intents:
- told_name
actions:
- utter_greet
entities:
- name
slots:
name:
type: text
templates:
utter_greet:
- text: "Hello {name}"
- text: "Hello {name}, happy to meet you."
Step 3 In stories.md file
# story_01
* told_name{"name": "Mayank"}
- utter_greet
I think, you are missing someting in step 3
We have a querystring parameter called imageDimensions, which specifies the desired dimensions for images of different types.
e.g. ?imageDimensions=poster:600x800,badge:100x100
Is there a way in API Blueprint to specify that imageDimensions should be a comma-separated list of image dimension specs, each of form "(image type):(width)x(height)"?
There is no good dedicated syntax for it at the moment. I would probably go with something like:
## GET /resource{?imageDimensions}
+ Parameters
+ imageDimensions (string, optional) - Comma-separated list of image dimension specs, each of form `(image type):(width)x(height)`
Where the `(image type)` is one of the following:
- badge
- poster
- icon
+ Sample: `badge:100x100`
+ Sample: `poster:600x800`
+ Sample: `poster:600x800,badge:100x100`
+ Response 200
Note, it is planned to move the parameters syntax to full MSON syntax in the near future. See the API Blueprint roadmap.
With it, it should be possible to define types for images as an enum and then reference it in the blueprint.
Currently I'm developing a debate module (much like a scrum/kanban board) for a GPL application (e-cidadania) and I don't have any experience with complex backends. I have developed a basic frontend for it, but now I don't know what approach I should use for the ajax and django backends to save and manipulate the table and notes.
The table can be N rows and N columns, every row and column has a name and position inside the table. Every note has also a position, text and comments (managed with the django comments framework).
I thought to store the parent element of every note (so I can place it later) and store the name of the rows and columns like CSV strings. Is that a good approach?
A screenshot of the current frontend: http: //ur1. ca/4zn4h
Update: I almost forgot, the frontend has been done with jQuery Sortables (so the user can move the note around as he likes) and CSS3.
You just need to model your domain (that is, debates that look like scrum boards) within Django. Think about it in plain English first, like this:
The has debates. These consist of criteria, organised in rows and columns in a specific order. This creates cells, which can have notes inside them.
Then you can set to work translating this into model classes. Don't worry too much about the fields they contain, the most important bit is the relationships (so the ForeignKey bits):
class Debate(models.Model):
title = ...
class Column(models.Model):
title = ...
order = ...
board = models.ForeignKey(ScrumBoard, related_name='columns')
class Row(models.Model):
title = ...
order = ...
board = models.ForeignKey(ScrumBoard, related_name='rows')
class Cell(models.Model):
column = models.ForeignKey(Column)
row = models.ForeignKey(Row)
class Note(models.Model)
text = ...
cell = models.ForeignKey(Cell)
That might be overly complex for what you need, though. I'm not an expert in the problem you're trying to solve? My suggestion, Django is quick – so start hacking, and give it a go, and if it's all wrong then you can go back a few steps, clean out your database and try again.
You might find it useful to play with South, which does database migrations for when you do things like add/remove/edit fields in your models.