Suppose I have the following nested UI-Router route:
/parent/{parentId}/child/{childId}
parent:child in my case is a one:many relation, therefore any valid childId implies a specific parentId. I'd like to maintain the nested state in my application, keeping access to parent resolve dependencies without reloading between sibling children; but instead represent the above with the terser URL:
/child/{childId}
Ideally, I'd like UI-Router to do as much of the lifting as possible, and only write the action to recover just the parent state when it is lost (for example when loading the entire page from a child route URL).
My responsibility could, for instance, be simply handling recovery of the parentId state parameter when it is null.
Is this feasible?
edits day 2: It seems, according to the docs, that UI-Router is designed to allow obscuring parent routes from the URL using Absolute Routes. I can only assume that it is supposed to preserve the parent state normally in this case. So, I tried a quick implementation by including two identical URLs, one an absolute URL that is a child state of the parent, and the other that is an actual root state, which does nothing but resolve the parent parameter, then load a controller to perform a redirect to the actual parent/child route. It had lots of problems. I'm trying to determine if I can do the same thing with an abstract state above the parent route. Anyway, suffice to say I haven't solved this yet.
Related
Not sure this is specific to Laravel but what is the proper RESTFUL way to handle creating a child of a parent with Laravel. For example I have a Car that can have many Drivers (hasMany) and Drivers belong to one Car (belongsTo). If I want to create a Driver whose parent is Car #1 does the CarController.php have the responsibility to create the driver: /car/1/driver/create or do I use /driver/create/car/1 and keep the responsibility within DriverController.php?
Right now I'm doing /driver/create/1 (where #1 represents the Car) which feels wrong but I'm not clear about what the RESTFUL way should be. TIA.
There really isn't a proper way of implementing nested resources in REST as it doesn't really care. There are arguments for and against nested resources, however, there are some generally accepted implementations and the agreement that whatever you decide on, be consistent.
I utilise nested resources, but only a single level of nesting and no more. So for example:
GET /cars/{carId}/drivers/{driverId}
However, I would avoid the following:
GET /cars/{carId}/drivers/{driverId}/incidents
If you have multiple nested resources, consider obtaining the nested resource through the parent resource:
GET /cars/{carId}/drivers/ // Get all drivers for the car
GET /drivers/{driverId}/incidents // Get all incidents for the driver
Arguably nested resource URLs can convey more meaning than a single resource URL at a glance. e.g.
GET /cars/{carId}/drivers/{driverId} // more meaningful
GET /drivers/{driverId} // less meaningful
With the second URL above, I do not know which car the requested driver is associated with until the resource is returned. That being said /drivers/{driverId} can still be applicable and useful to have depending on your use case.
A use case for a /drivers endpoint would be if you can create new drivers that are not yet associated with a car.
In response to your question of how to create a driver, I would consider the following use cases;
Create a driver without an association to a car
POST /drivers
Create a driver with an association to a car
POST /cars/{carId}/drivers
POST /drivers
For the POST /drivers endpoint you would use a DriverController and pass your Driver information to the store method. The validation rules in the store method would allow for an optional car_id parameter as part of the request. This would allow you to either associate a driver with a car at creation, or not.
For the POST /cars/{carId}/drivers endpoint, you would use a CarDriverController (or a DriverController in a Cars subfolder if often seen) and pass your Driver information to the store method. A car_id paramter would not be required in the request as the associated car would be obtained from the {carId} passed in the URL.
For updating your driver resources, you can follow the same principle just amending your HTTP verbs and creating the appropriate routes.
PUT /drivers/{driverId}
DriverController#update
PUT /cars/{carId}/drivers/{driverId}
CarDriverController#update
If you decided to implement both methods for creating drivers and you find duplicate code, consider refactoring it to a service.
Update 1
For #2 POST /cars/{carId}/drivers is the store endpoint does that make GET /cars/{carId}/drivers/create the create endpoint? And similarly for POST /drivers creation endpoint GET /drivers/cars/{carId}?
If you're working with blade views and following the Laravel conventions then your form to create a new driver for a given car would be found at GET /cars/{carId}/drivers/create or GET /drivers/create.
And it sounds like relationships should always get a separate controller.
Ideally yes as most applications are nothing more than CRUD and so everything can be mapped to one of the 7 controller actions. This keeps things clean and simple and responsibilities separate.
Take a look at this video by Adam Wathan which explains how to map what you think are custom actions to one of the 7 basic Laravel actions. Bit lengthy at 40 minutes but well worth a watch.
POST /cars/1/driver.
no interest in specifying the action (create). the method (post) already does it.
i'm doing a app and i have an ajax call that send the data to the server and ask the db,it retrieves me the object data.Until here everything is cool.But i want to do a route with routie to retrieve the results on it'own page. the problem is that the two component are at the same level on the hierarchy, so cant get the props of the state data 😥. I've heard about flux but it's a pretty complex architecture for the project that i'm doing. Do you guys have a good pattern to solve that ?
Very Gratefull ;)
I dont think you need Flux for this. You can not (or at least should not) pass data between Components which are on the same hierarchy level. You should read the following lines: https://facebook.github.io/react/docs/thinking-in-react.html#step-4-identify-where-your-state-should-live
It gives you same hints on how to decide where to put your state by defining some simple rules.
Simply put the necessary logic into a common owner of your two components (so one or more level up in the hierarchy).
I've read this spring-data-rest tutorial https://spring.io/guides/gs/accessing-data-rest/ and I can't see how this can be applied in a real world situation where we don't have just one object, but a graph of objects.
Let's say that we have an Order object which has one-to-many relationship to an Item which is categorized by a Category object. Let's say for the sake of it, that the Category is implemented in a tree-like structure (so it has a parent and some children; i.e. an Electronic category could have 2 children, Computer and TV, the former having another two children, motherboard and keyboards).
And let's say that all these relation are two ways (i.e. an Order can see it's items and an Item can access it's Order)
So when I request an Order object threw my REST service, I'm gone get the Order, all it's Items and each Item will have the whole graph of Category which will be linked to each Item and thus all the orders. So I'm basically returning the whole database.
I do understand that the bidirectional relations is not ideal but even if we suppress the many side of the relationship, when requesting an Order, we would still get
Order-Item-Category-Parent Category-Parent of Parent Category-etc...
So how do you stop a graph of objects being serialized?
Furthermore, you might not want to break the graph at a fix point.
For instance when I request an Order, I might want to see it's items and the category of each item, but definitely not the parent's category.
However, when I want to explicitly display a Category, I would then like to see it's parent. Get it?
Does somebody have some insight for me?
This is where DTOs are a good thing. :)
You build the object structure you need and return it via json. You have full control over this structure, you dont have bidirectional relations and you can just give that back as an object graph from your controller.
Another (good) side effect is that you decouple persistence and view completely. I.e both can evolve independently.
One (negative) side effect can be the increased maintenance. You have, at least, twice the classes to maintain and also the mapping in between. Frameworks like Dozer can help you with the mapping at least.
Another solution can be to implement some addons for Jackson that handle all these cases without the need of DTOs.
I myself created the Antpath filter to dynamically decide which path to filter out in Jackson:
https://github.com/Antibrumm/jackson-antpathfilter
But you will need some more things to consider if you like to work with domain entities directly.
cycle breaker (to avoid bidirectional relations for example)
lazy loading / open session in view pattern as the serialization can go everywhere
hibernate proxies which have method which are not serializable (session)
I have a simple 1:1 relationship:
class MyParentDomain{
String name
MyChildDomain onlyChild
}
class MyChildDomain{
String name
}
Now on a form where I want to make a new parent "Mom", there will be a list with all the existing children. Is there a current good-practice to add children on that same form? I'm imagining a "plus" button next to the drop-down list of "onlyChild" where I could see a form for new "MyChildDomain". I saw a link somewhere where people were talking about cracking this problem (will add the link as soon as I re-discover it). Has this been done? Is anyone doing something like this?
To my knowledge, this hasn't been generally applied to any templates or with a plugin (I might be wrong).
You can, however, use the "list" abilities that Grails has which allow you to submit a list of domain entity data and then build the list of child elements in the controller from the submitted data and persist that. I've never done this myself, however, so you will need to do a bit of digging on it.
As you may have guessed, attempting to create child entities on the fly via Ajax is likely not to work since the parent entity doesn't exist yet, so there's nothing to attach them to.
Is there any way in JSF 2.0/PrimeFaces of re-rendering all components (using the PrimeFaces update="id1 id2..." attribute or the <f:ajax render="..."/> tag) that have got a given ID, regardless of whether they are in the same form that contains the button triggering the AJAX re-render or not?
For example, I want my button to re-render all sections on a page that visualize the user's current shopping basket.
Right now, I always have to specify the absolute path to the components that I want to get updated, e.g.
update=":header:basket :left-sidebar:menu:basket"
which is rather impractical if the structure of the page changes (besides, I have not been able to figure out the correct path for one of these components). I already tried to implement a custom EL function like this, which traverses the component tree:
update="{utilBean.findAllComponentsMatchingId('basket')}"
but at the time that function is evaluated, apparently not the entire component tree has been set up as it doesn't contain the components I am looking for.
How can I deal with this? There certainly must be an easy way of doing AJAX-based updates of sections of the page that are not part of the current <h:form>?
Thanks!
What is the definition of your findAllComponentsMatchingId method? This btw doesn't look like a custom EL function call. Additionally "{}" is not an EL expression at all, but I take it that this is an typo.
Perhaps the problem is in the way your findAllComponentsMatchingId works and not that the components are not yet in the tree? It might be useful to look at the findComponentFor method in this RendererUtils class for some inspiration.
Alternatively you could try binding the components you want to be updated to a request scoped or view scoped Map.
E.g. define in faces-context.xml:
<managed-bean>
<managed-bean-name>updates</managed-bean-name>
<managed-bean-class>java.util.HashMap</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
</managed-bean>
Then bind your components to this:
<x:someComponent binding="#{updates['foo']}"
And then write an EL function that iterates over this updates map and returns a space separated list of all components client IDs (component.getClientId(FacesContext.getCurrentInstance())).
Since (I think) this is determined by the way UIComponent.findComponent(..) works, I'm afraid you are out of luck. The closest naming container is taken as a base for the search.
Anyway, inter-form rerenders should not be that common. And naming container structures should not change that often.