I need to create a one-to-one relationship between a Game and a Site - each game happens in one site. In my database, site is an attribute of the Game object which points to a Site object.
I couldn't find much on the internet about this, these are my ideas:
GET /game/<game_id>/site
Gets a game's site, hiding the site id.
POST /game/<game_id>/site
Creates a game's site, this is only used once when creating the game.
PUT /game/<game_id>/site
Updates a game's site
DELETE /game/<game_id>/site
Deletes a game's site.
But what if someone wants to get a list of all the sites? Should I add a /sites URI and have the get method for the Site object detect whether a game_id has been passed in? Should I also let people access a site by /sites/<site_id> Or should I let the client populate their own list of sites by iterating over all games? Finally, I usually have an 'href' attribute for each object which is a link back to itself. If I went with the above design (incl. the /sites/ URI), do I link to /game/<game_id>/site or /sites/<site_id>? Should there be two places to access the same info?
Am I on the right track? Or is there a better way to model one-to-one relationships in REST?
If it matters, I'm using Flask-RESTful to make my APIs.
Your ideas make a lot of sense.
The big distinction is whether or not a site can exist independently of a game. It sounds like it can. For example, two games may point to the same site.
As far as I understand with RESTful API design, there isn't a problem with exposing the same site resource through both /game/<game_id>/site and through /sites/<side_id>. But REST encourages you to link data through hypermedia.
Exposing the site in two different places could complicate things, since you'd then expect to be able to interact with site objects through both of those URLs.
My recommendation to keep your structure explicit and simple would be:
Have a collection of site resources at /sites
Expose site resources at /site/<site_id>
Use a link object from a game to a site. See Thoughts on RESTful API design by Geert Jansen.
Following the link object design, your game resource representation would include something like this:
{
"game_id": 10,
...,
"link": {
rel: resource/site
href: /api/sites/14
}
}
Without more design work, this would mean you'll make a second call to get the site's information. Every design has its compromises :)
Related
Our Application has components which consume components with consume components of varying complexity. So i just want the input on the page, to validate when an object is set that the text is correct. The issue is that it is one of these subcomponents.
My colleague told me that there is 2 ways to do this, The first is to use Page Objects, and Chaining annotation to find it on my page, and then find the next id etc until my input is found. It requires me to look through another teams' Component Markup to narrow it down to the input i want to leverage. I dont believe I should have to go into another component definition, or a definition of a definition to get the appropriate chain to get this arbitrary input. It starts to create issues where if a lateral team creates changes unbeknownst to me, my PO will be broken.
The other option my friend asked was to use fixture.query to find the component. This would be as simple as:
fixture.query((el)=> el.attribute["id"] == "description",
(comp){
expect(comp.value, value);
});`
Using Query looks at the markup but then will automatically componentize it as the appropriate SubComponent. In this case, comp.value is the value stored in the HTML. So, if i did something like:
fixture.update((MainComponent comp) {
comp.myinput.value = new Foo();
});
Then I am setting and getting this programmatically, so i am a bit unsure if it properly would reflect what is on the screen.
Whats the best course of action? It seems PO would be better, but im not sure if there is a way around having to deep query for input boxes outside of the component i am testing.
Thanks
I don't think I have a definitive answer for you but I can tell you how we do it at Google. For pretty much any component we provide the page object alongside the component. This is twofold it is for testing that widget, and also so we can have this as a shareable resource for other tests.
For leaf widgets the page objects are a little less fleshed out and are really just there for the local test. For components that are shared heavily the page object is a bit more flushed out for reusability. Without this much of the API for the widget (html, css, etc) we would need to consider public and changes to them would be very hard (person responsible for making the public breaking change needs to fix all associated code.) With it we can have a contract to only support the page object API and html structure changes are not considered breaking changes. At times we have even gone so far as to have two page objects for a widget. One for the local test, and one to share. Sometimes the API you want to expose for a local test is much more than you want people to use themselves.
We can then compose these page objects into higher level page objects that represent the widget. Good page objects support a higher level of abstraction for that widget. For example a calendar widget would let you go to the next/previous month, get the current selected date, etc. rather than directly exposing the buttons/inputs that accomplish those actions.
We plan to expose these page objects for angular_components eventually, but we are currently working on how to expose these. Our internal package structure is different than what we have externally. We have many packages per individual widget (page_objects, examples, widget itself) and we need to reconcile this externally before we expose them.
Here is an example:
import 'package:pageloader/objects.dart';
import 'material_button_po.dart';
/// Webdriver page object for `material-yes-no-buttons` component.
#EnsureTag('material-yes-no-buttons')
class MaterialYesNoButtonsPO {
#ByClass('btn-yes')
#optional
MaterialButtonPO yesButton;
#ByClass('btn-no')
#optional
MaterialButtonPO noButton;
}
I have a question regarding some action accessing, i'm not talking here about authorization etc, but more about the direct access to actions.
Basically i have 2 question, 1 general and 1 more contextual:
Situation imaging i have an action : MyArticles/DeleteArticle/id
1) How can i prevent that if someone will just put this url with a proper id remove article? How can i say that it can only be used with a button on my website? And should this action be a get or post?
At this moment i use $.ajax and GET method ....
2) Now imagine i have many people, and if all th ppl are registered, they can delete each others article, what if i want to avoid that and let users only delete their own articles, because at this moment for example if they can guess the id they can directly access the action with id and delete it.
Can anyone provide explanation and some tips about that?
i'm not talking here about authorization etc
Yes, you are. The authorization to delete the article should take place within the action itself, it's not the responsibility of the calling code or of any UI which displays a link to the action.
How can i say that it can only be used with a button on my website?
I imagine any approach to that is going to complicate the issue tremendously. Understand how HTTP requests work... Your application isn't making the request to the action, the user is. They're doing so (in the general case) by clicking a link on an interface provided by your application, but the request itself is coming from the user. (Well, from the user's web browser, which is in their control and not yours.)
The most straightforward approach to this is to encapsulate authorization in the action itself (or, better still, in the model functionality being invoked by the action... but logically that's still part of the "request" being performed).
When you expose a piece of functionality which not everybody should be able to invoke, put the authorization on the functionality itself instead of on the UI which invokes it. That way no matter how it's invoked it always maintains the authorization, instead of just assuming that some other component maintained it.
You have a lot of control in MVC with respect to the USER. To allow a user to delete only his own work, you must remember in the database who wrote what. If this is the case - and you know it, a simple if statement in the beginning of the action will do the trick.
Apologies if this has been discussed before, have searched and searched but didn't find anything useful :)
But here goes.
We're currently in the process of rewriting a portion of our webapp. Our app is rather old and therefore suffers from some rather cowboy'ish approaches to programming, conventions and urls.
What we're looking for is a simple clean way to design our views and urls so that we can maintain both easier in the future.
The problem is; as of now our urls.py file for the main site is one big mess. a lot of urls that point to a unique view that only does one thin.
Ex. list_books/, edit_book/ etc.
when it comes to specific formats etc. we have something like list_books_json/
(these aren't the actual urls though, but just used to prove a point since the real urls are much worse)
What we want to do now is clean it up a bit. And we we're wondering what the best way to get around it would be??
What we have thought of so far(after reading a lot of things on the subject):
We've thought of designing our urls after the following pattern:
domain/object/action/
so the urls for the apps "staff" site for changing books in the app would be:
staff/books - to view all books (GET)
staff/books/ID - to view one books (GET)
staff/books/new - to create a new book (POST)
staff/books/ID/edit - to edit specific books (POST)
staff/books/ID/delete - to delete specific books (POST)
The thought was then to have only 1 view, views.staff_books() to handle all these actions when dealing with books through the "staff" part of the site.
so that staff_books() checks for ID or a certain "action" (edit, new, delete etc.)
The result would be fewer, but a lot larger views that have to handle all aspects of staff/books. Right now we have a ton of small views that handle only one thing.
Does this makes sense, can you see potential problems? How do you guys go about it??
One place where I think we're lost is in regards to formats.
Where would you put ex. the request for returning the response in json?
we're wondering "staff/books.json" or "staff/books/ID.json" etc. and then keeping all the json logic in the same "staff_books()" view.
So thats it basically. I'm sorry the question is a little "fluffy"... We basically need some examples or good design advice as to how to structure urls and views.
Kind Regards
pete
As an extension (and solution) to your problem I would suggest to use the strategy pattern. Since you already have a structure and the only thing that differs is "how" it is supposed to be carried out, this pattern fits your problem perfectly. What I mean by that is the following:
Create a view which is your entry point to your application with functions named as your url-based functionality (edit, new, delete etc.). I.e where your url.py determines where to go from there.
Create classes which do your stuff based on your domains etc. Lets call them Book, Calendar etc for now.
Implement functionality of those classes, like edit, new, delete etc.
in your view then, determine what class to instantiate and call the corresponding function, e.g in View.edit() call domain.edit()
I think that should do it ^^
Hope it helps :D
While working on my Django-based projects I'm always trying to follow Django's approach to reusable apps - I'm trying to decouple my applications from each other and especially trying to avoid cross references but sometimes it does not seem to be possible.
Let's consider a simple example with 2 applications: articles and users. Articles application defines article model, articles list view and single article view, users application defines user model and user profile view. Article is referencing user from the author field, so articles application is obviously dependent on users application which is fine.
But when it comes to user profile, I want to display latest articles authored by the user (and may be latest articles viewed by the user) on that page but that makes users application aware of articles application which is what I'm trying to avoid.
I can obviously try to push all such references to the template level but it still does not solve the issue completely and at the same time may be very inefficient in terms of database queries sometimes.
What do you guys do in such cases?
If you are really set on not having any conversation between the 'user' app and the 'article' app, then you need a third app to act as interface. That would know about users and articles and define all the coupling between them. Your article view would be in there, since it has to get the user data, and your user profile view would be in there, because it needs to say "Fred wrote 5 articles".
Whether this level of decoupling is worth it, I don't know. Sometimes programming for re-usability gets in the way of making the thing usable in the first place.
The standard (or preferred) way of keeping coupled apps decoupled is to add a conditional coupling - like in some apps that try to import django-notification and only if they find it, they report events to it.
Still, if you have two apps that talks to each other by design, then I don't see any point in decoupling them - there are plenty of examples in Django world of apps that just require other apps. Note that I'm talking here about writing real-world software, not about some academic delibrations :-)
It seems that in this case, the dependency of users on articles is in a method, not a field. (Whether it's a model method, a model class method, or a manager method is immaterial). If that's so, you can do a lazy import of articles inside the method. By the time this import is performed, users.models will be fully loaded, so even if this is a circular import, it will not cause problems. The "import users" statement in articles will not have to re-load users and will have the full users namespace available.
I have created an article site, where articles are published in several languages. I am using transmeta (http://code.google.com/p/django-transmeta/) to support multiple languages in one model.
Also I am using generic comments framework, to make articles commentable. I wonder what will happen if the same article will be commented in one language and then in another. Looks like all comments will be displayed on both variants....
The question actually is:
Is there a possibility to display only comments submitted with current language of the article?
I tried the approach of transmeta for translation of dynamic texts and I had the following experience:
You want another language, you need to change the database model which is generally undesirable
You need every item in both languages, which is not flexible
You have problems linking with other objects (as you point out in your question)
If you take the way of transmeta you will need two solutions:
The transmeta solution for translating fields in a model
For objects connected to a model using transmeta you will need an additional field to determine the language, say CharField with "en", "de", "ru" etc.
These were major drawbacks that made me rethink the approach and switch to another solution: django.contrib.sites. Every model that needs internationalization inherits from a SiteModel:
class SiteModel(models.Model):
site = models.ForeignKey(Site)
Every object that would need transmeta translation is connected to a site. Every connected object can determine its language from the parent object's site attribute.
I basically ran the wikipedia approach and had a Site object for every language on a subdomain (en., de., ru.). For every site I started a server instance that had a custom settings file which would set the SITE_ID and the language of the site. I used django.contrib.sites.managers.CurrentSiteManagerto display only the items in the language of the current site. I also had a manager that would give you objects of every language. I constructed a model that connects objects of the same model from different languages denoting that they are semantically the same (think languages left column on wikipedia). The sites all use the same database and share the same untranslated User model, so users can switch between languages without any problem.
Advantages:
Your database schema doesn't need to change for additional languages
You are flexible: add languages easily, have objects in one language only etc.
Works with (generic) foreign keys, they connect to an object and know what language it is. You can display the comments of an object and they will be in one language. This solves your problem.
Disadvantages:
It's a greater deal to setup: you need a django server instance for every site and some more glue code
If you need e.g an article in different languages, you need another model to connect them
You may not need the django Site model and could implement something that does the same without the need of multiple django server instances.
I don't know what you are trying to build and what I described might not fit to your case, but it worked out perfectly for my project (internationalized community platform built upon pinax: http://www.bpmn-community.org/ ). So if you disclose some more about your project, I might be able to advise an approach.
To finally answer your question: No, the generic comments will not work out of the box with transmeta. As you realised you will have to display comments in both languages for the article that is displayed in one language. Or you will have to hack into the comments and change the model and do other dirty stuff (not recommended). The approach I described works with comments and any other pluggable app.
To answer your questions:
Two Django instances can share one database, no problem there.
If you don't want two Django instances, but one, you will have to do the following: A middleware checks the incoming request, extracts desired language from URL (en.example.com or example.com/en/ etc.) and saves the language preference in the request object. The view will have to take the request object with the language and take care of the filtering of objects accordingly. Since there is no dedicated server for the language (like in the sites approach where the language is stored in the settings.py file), you can only get the language from the request and you will have to pass attributes from the request object to Model managers to filter objects.
You could try to fake a global language state in the django application with an approach like threadlocals middleware, however I don't know if this plays out nicely with django I18N engine (which is also does some thread magic).
If you want to go big with your site in multiple languages, I recommend going for the sites-approach.