I try to use routing v8 rerouting as in Routing API v8 (8.46.0) -> Get route by handle via POST object reroruting (here map routing v8), but I have no idea how to use it. I think rerouting is helpful then you want to add some waypoints on the calculated route eq.: "by hold polyline points, drop it" and add recalculate route with new via or waypoints. But I can't find some example or something more about this, and unfortunately can't understand what is rerouting[$ref]=#/components/examples/Rerout ?
Could I ask about some examples of how to use it to recalculate route with a new waypoint or via?
This is everything from here map documentation, that I found on this topic:
Related
I am using APEX 20.2.0.00.20. apex.region(region_static_id).widget() method should return a jQuery object according to the documentation. I am trying to figure out how to know what the object's properties and methods are, especially when they are not mentioned in the documentation. I tried running apex.region(calendar_region_static_id).widget() to return the object and inspect what properties and methods it has but I got S.fn.init [div#CAL_calendar.fc.ui-widget.fc-ltr, prevObject: S.fn.init(1)] 0: div#CAL_calendar.fc.ui-widget.fc-ltr length: 1 prevObject: S.fn.init [document] __proto__: Object(0)
I did not get the object. I do not know what s.fn.init or the rest of the returned code is?!
I see code like apex.region("calendar_static_id").widget().fullCalendar("getView"), so I assumed I should have gotten the jQuery object which has the "fullCalendar" method and more when I ran apex.region(calendar_region_static_id).widget(), but I have not.
Is this not the right way to inspect a jQuery object's properties and methods?
APEX integrates the FullCalendar widget, but it doesn't duplicate its documentation. Have a look here for a list of the FullCalendar methods and options.
In general, most (interactive) APEX regions are implemented as jQuery UI widgets. That means you can use them like this:
$('selector').widgetName('methodName'); //invokes said method
$('selector').widgetName('methodName', 'param1'); //invokes said method with a parameter
$('selector').widgetName('option', 'optionName'); //gets a specific option
$('selector').widgetName('option', 'optionName', 'newVal'); //sets a specific option
What's more, you can inspect all available options by running:
$('selector').widgetName('option');
And even have a look at the internal object, see all methods, public and otherwise, via:
$('selector').widgetName('instance');
Moreover, via its region interface, APEX offers an even easier way to reach those methods and options, even without having to know a region's widgetName:
// this
$('widgetSelector', 'staticId').widgetName('methodName');
// is equivalent to
apex.region('staticId').widget().widgetName('methodName');
// is quivalent to
apex.region('staticId').call('methodName');
The last way is the shortest and doesn't require knowing the real widget's id or widget name.
All of this helps when dealing with regular APEX widgets, such as the Interactive Grid.
apex.region('emp').call('instance'); //inspects all methods
apex.region('emp').call('option'); //inspects all options
This however does not work on the FullCalendar region, for reasons that are beyond me. It should help you navigate all other APEX regions, but for the FullCalendar you'll have to resort to their API docs.
Hope this helps a bit.
I am using omnet++ to change a specific route entry for a multicast group address. Usually, a multicast route entry is added by using the best (shortest) route to the source of the message.
However what I need to do is to modify this behavior for a specific multicast address so that it does not take the shortest path to source condition but instead uses "first entry".
What I mean is that, if after flooding the multicast packet (with no multicast route entry before) received on a router via three interfaces with the time of arrival like this: 1.eth0 2.eth1 3.eth2, it automatically sets interface eth0 as the RPF and does not compute whether this is the best path.
The normal behavior was already coded into omnett but when I found the functions to add new routes I do not understand where are the conditions of adding a new route.
internalAddMulticastRoute
AddMulticastRoute
As far as I understand, the methods you posted don't actually check anything with regards to which interface is used: whenever a multicast route is added, it is simply stored and used. You might want to have a look at where addMulicastRoute is called; there might be code there that controls priorities. The code in internalAddMulticastRoute only organizes the routing table (which is kept sorted through upper_bound). If you want to control which interface is used, you'll need to modify the routing table entries. I'd recommend performing a check before calling addMulticastRoute.
I'm trying to wrap my head around the difference between a "collection" and a "store" in REST. From what I've read so far,
a collection is:
"a server-managed directory of resources"
and a store is a:
"client-managed resource repository"
I found this post: How "store" REST archetype isn't creating a new resource and a new URI?
but it didn't really help me clarify the difference. I mean, I understand one is controlled by the server and the other by the client... but can someone give me a concrete example of what a store might be in a real world application?
I *think it's something like this:
GET http://myrestapplication.com/widgets/{widget_id} -- retrieves a widget from db
POST http://myrestapplication.com/widgets/{widget_id} -- creates a new widget from db
PUT http://myrestapplication.com/widgets/{widget_id},[list of updated parms & their vals] -- update widget
PUT http://myrestapplication.com/users/johndoe/mywishlist/{widget_id} -- updates john doe's profile to add a widget that already exists in the database... but links to it as his favorite one or one that he wants to buy
Is this correct?
if so, could the last PUT also be expressed as a POST somehow?
EDIT 1
I found an online link to the book i'm reading... where it makes the distinction between the two:
https://books.google.ca/books?id=4lZcsRwXo6MC&pg=PA16&lpg=PA16&dq=A+store+is+a+client-managed+resource+repository.+A+store+resource+lets+an+API+client:+put+resources+in,+get+them+back+out,+and+decide+when+to+delete+them&source=bl&ots=F4CkbFkweL&sig=H6eKZMPR_jQdeBZkBL1h6hVkK_E&hl=en&sa=X&ei=BB-vVJX6HYWvyQTByYHIAg&ved=0CB0Q6AEwAA#v=onepage&q=A%20store%20is%20a%20client-managed%20resource%20repository.%20A%20store%20resource%20lets%20an%20API%20client%3A%20put%20resources%20in%2C%20get%20them%20back%20out%2C%20and%20decide%20when%20to%20delete%20them&f=false
REST uses http verbs to manipulate resources. Full-Stop. That's it. To build some classes of browser-based application developers sometimes use local storage (a store), but that has absolutely nothing to do with REST (in fact, it's the opposite). Collections are a special consideration in REST-based API design because the REST principles place considerable constraints on how they are represented in the results of your queries -- special consideration also because there are no standards on how these things should be represented and access if you're using anything other than html as a resource type.
Edit:
REST suggests that when we ask for a resource we receive that resource and only that resource and that things referenced by that resource are returned as links, not as data. This mimics the http standard by which we return the requested page and links to other pages rather than embedding linked pages. So, our resources should return links to related resources, not the resources themselves.
So, what about collections?
Let's use as an example a college management system that has Course objects each of which contains a huge lists of Students.
When I GET the course I don't want to have the collection of students returned as an embedded list, because that could be huge and because my user might not be interested. Instead, I want to know that the course has a students collection and I want to be able to query that collection separately (when I need to) and I want to be able to page it on demand. For this to work, the course needs to link to the students collection URL (maybe with an appropriate type so that my code knows how to handle the link). Then, I want to use the given collection's url to request a paged list of resources. In this example, the collection's url could be something like: course/1/students, with the convention that I can add paging info to the search string to constrain the results with something like course/1/students?page=1&count=10. Embedding the students collection into the course resource would be a violation of REST. I would not be returning a course, I'd be returning course-and-students.
I am working on a coldbox application where I would like to create a route that accepts 'n' number of path variables as one variable. Here is what I mean.
http://localhost/api/variable1/variable2/variable3/...
I would like to either be able to grab everything after /api as one path variable where I can split on / and get the values or be able to iterate over all variables after /api.
Is there a way to setup a Route to do this?
with(pattern="/api", handler="api")
.addRoute(pattern="/:variables", action="index")
.endWith();
Any ideas would be most appreciated. Thanks in advance.
As you probably know, the default routing paradigm is to do name value pairs like so:
http://localhost/api/name1/value1/name2/value2/name3/value3
There is no need to create a custom route for that as everything after the matched part of the route is broken up into name/value pairs and placed in the rc automatically.
Now, it sounds like you're wanting to only have values in your route. If you know the maximum number of variables you'll ever have, you could create a route of optional, incrementally-named variables.
addRoute(pattern="/:var1?/:var2?/:var3?/:var4?/:var5?", action="index")
Now, if you truly might have an unlimited number of variables, there is no way to do a route that will match that. What you CAN do is have your route match the /api bit and write an onRequestCapture interceptor that grabs the URL and does your own custom parsing on it. Note, you may need to remove the name/value pairs that ColdBox will try to put in the rc.
I will add a note of caution-- the only way for this to really work is for you to KNOW the order of the incoming variables ahead of time, and if you know that, there is no reason why you can't create a known route for it. Otherwise you're basically rebuilding the SES interceptor over again which is an anti-pattern called "inner platform effect"
http://wiki.coldbox.org/wiki/URLMappings.cfm#URL_Mappings
http://wiki.coldbox.org/wiki/Interceptors.cfm#Core_Interception_Points
http://en.wikipedia.org/wiki/Inner-platform_effect
I'm trying to migrate my app to the new emberjs routing API.
With old router I had some workarounds to provide similar URI for objects saved by ID and for new objects which described by set of params. This were done for ability of exchange links to objects between users without permanently saving it. This is two simplified valid routes from my app:
/objects/12 // fetch object by id (/objects/:object_id)
/objects/<serialized params> // build new object from params (/objects/:params)
Both of this routes are similar to router because they all have dynamic parts and static parts are equal. So I wrote custom RouteMatcher to pickup right route. Lack of query string parsing forced me to do this hack as quick and semilegal solution, also there is ancient ticket about this feature on github.
With the new router matching has been extracted to separate package (route-recognizer) so I cannot do the trick (or it will be full of hacks and injections).
As I can see I have to choose from these options:
Totally rewrite my URIs and separate all intersecting routes
Rewrite URIs but try to implement query string parser for the new Ember.Router
Put all logic into one route and reimplement only serialize/deserialize methods (something dirty)
Second solution seems to be more clean.
What will be the best non complicated decision? Should I try to find another way?
The current router does not support query-string parameters.
We are tracking this bug at https://github.com/emberjs/ember.js/issues/1773. You may want to follow it.
In the meantime, your best bet is probably to use a dynamic segment and manually serialize (with the serialize hook) and deserialize (with the model hook).