I am wondering whether we can use our own identifier when passing a document towards box-view and then on the basis of this identifier request a view session. This would prevent us from the need to implement an identifier mapping between the box-view id and our own local id's.
Specifying your own id is not currently possible with the View API. You can suggest features by sending an email with a description of your desired feature to view-api-features#box.com. It helps if you also give some background and use cases for the feature (in this case it's pretty obvious, though). I'll go ahead and suggest this one on your behalf.
Related
iCalendar has a UID field which is a universal identifier. It's intended to be unique value so the same event can be recognized when syncing or trying to add the same event twice. They're usually randomly generated, eg. a37c3632-3c26-4543-b91d-355a1b668a3a.
I'm tempted to use a URL describing the event as my UID. Is there any reason this isn't a good idea?
While strictly speaking this may not be forbidden, if you do care about interoperability, you are always taking a risk by not following common practices. There will be some client or server out there which will choke on your events. For example, some CalDAV servers tend to use the UID value as the last segment in CalDAV resource URLs. With your type of UID, they will need to URI encode that last segment, which some of them may fail to do.
Of course you can always put the blame on those bad implementations but, at the end of the day, it will be your users who will be unable to see your events.
There are new recommendations for the UID property which were published as part of RFC 7986 (see https://www.rfc-editor.org/rfc/rfc7986#section-5.3 ). Although the main purpose of this section is to allow use of UID in VCALENDAR, the recommended format make sense in all cases.
I would use a URL or X- property to convey your URL if you do care about it.
I'll make it quick. I'm building an application that will relay heavily on Firebase, and especially the Real Time Database. It functions purely off of user input, which can obviously change and mutate. Essentially they will be sending what I'm calling Bundles to the database. They contain vital information about location, information, etc. So, the question, how can I structure the add script from my application so I can make sure that no duplicate data bundle names are generated, as it wouldn't be ideal at all. Using a users UID also wouldn't be ideal as that could lead to an immediate duplicate data if they send two Bundles. Thanks everybody!
You'll have to use childByAutoId when creating the "bundle" node, This will create a node with a unique identifier.
Source: https://firebase.google.com/docs/database/ios/save-data
I accomplished this by using the push function in the firebase documentation. This allows me to not only add the data bundle right into a list of other data bundles, but it also includes the server providing it with a unique key, thus removing all chances of duplicate bundle names occurring. You can check out the same docs by clicking here
I'm developing a dropbox app (accessing a Dropbox for Business account). I need to pass along a custom header, X-Dropbox-Perform-As-Member, which has it's value set to a member ID (or member_id).
For the life of me I can't seem to figure out where to find or retrieve this specific value. Hell, I don't even know what it looks like ...
Anyone care to point me in the right direction? Thanks in advance.
There are a few places the member ID might come from... it depends a lot on the kind of app you're building. One likely source is a call to /members/list. Another likely source is /members/get_info (if you're looking up by email address).
For an auditing app that's watching activity within a Dropbox for Business account, you'll find the member_id as a member of lots of events in the audit log (i.e. via /log/get_events).
Event stores are supposed to be Add only, you never delete or edit data.
In my case, we didn't disallow some mid-stream changes that were made by a user, and the data is "bad" / inconsistent... in that they changed a domain name for google docs that we were provisioning mid-stream...
I can reprovision from the event store, but that data is broken.
Should I create a mutator of some kind that as it pulls the data from the event store, fix it up?
I need some ideas here!
If I understand you correctly, the "bad" data were correct back then?
I suggest you fix this by not touching the events, but update the provisioning service to handle the broken domain names. That could be a component which knows how to fix a domain name or a url: You send a resource in and get a corrected version in return. Unknown resources could be returned as is.
I have a site that has different features and functionality based on the location that the user has selected. Each location has events that are unique to that location. These events are the primary reason that a user comes to the site for.
There are key areas of the site that are not navigable unless a location is selected for the user. Therefore, the location has to be presumed until the selected location is known -- I plan on using some basic GeoIP lookups for this.
So the requirements basically boil down to:
Location must be set before any page on the site is loaded
User can change the location setting
The location setting must persist from request to request
This setting should be accessible to the layout and view and will be a prerequisite for most controllers
I can think of a few ways off the top of my head to tackle this (Zend_Registry, custom Zend_Session_Namespace, etc) but I'm curious if there isn't a more widely identified strategy for this type of problem.
I see this as similar to setting language for a site with i18n and so i would implement in a similar fashion. Id probably store the location in a session value, or if the user is registered they could obviously save it to their settings/profile in whatever backend storage mechanism is being used. You could also add this location to the route params as is often done with i18n but that could get messy given its a geo location and not just a locale.
I don't think Zend_Registry might fit your needs, since it will only make location settings available throughout the application during a single request but will not persist.
If you need these settings to be persistent between requests, your best (and very likely - only) choice is Zend_Session.
As to #1, I suggest using a controller plugin for that.