We are looking into ways of visualizing Issues and Rfi’s (minimally) as geopositioned items in our GIS (Geographic Information System). We achieved some interesting results, though looking at automating the process, ideally, I would like to have data pushed to me as opposed to have to manually pull it. The obvious solution is to use Webhooks Events. A list of exposed webhooks is available here but there is nothing related to Issues and Rfi’s. I was wondering what is the roadmap for Forge Webhooks.
Is there another way to achieve the same “Push” effect?
Is there a plan to expose Issues and Rfi’s events to Webhooks? (Creation, status, modifications…)
Notification is something we often hear. We have a wish as a future enhancement. But I don't think it's in our radar for near future. (RFI, for example, access API itself is still to come.) We will be announcing new APIs through our newsletter or on our documentation. But feel free to check back say in 3-6 months to see where we are.
For now, we will need to check back periodically.
Related
I am currently in the process of implementing pagination, sort and search functionalities in the project files/plans/sheets views of BIM 360 Docs integration.
Since I couldn't find any best practices regarding to these features, I thought I would reach out so that I don't keep stuck reinventing the wheel.
Background:
Most of the implementation uses https://github.com/Autodesk-Forge/forge-api-dotnet-client/ SDK.
Based on what I saw it looks like there is no built-in results sorting in the Forge/BIM 360 APIs. BIM 360 Docs looks as if it sorted results on the client.
One has to cache all the results as structured data on the client in order to provide the sorting functionality. That also does not play well with any pagination approach.
Question:
Is there a way to sort results using the API, so that they come back in a predefined order, also while paginating?
According to our engineering team, the "sort" feature isn't currently supported by Forge Data Management API. Apologizing for the inconvenience caused.
I have logged a request FDM-1813[Support sorting in APIs of BIM360 integration] in our internal system to our engineering team to allocate time to evaluate the possibility. As it required some time to complete this task, please remember this request id for the future reference. You're welcome to track updates or provide additional information by quoting this request id via forge.help#autodesk.com.
However, a workaround is to fetch all data from the API, then sorting on the client side via Javascript.
Cheers,
When changes are imminent to the API version, are admins/devs notified in advance via email or some other system?
Some companies I have found use twitter, hitch, or nothing at all to notify users of changes that may be deprecated. My goal is for us to stay on top of API changes so we never experience breakage.
I don't think this is the case. When Google makes changes to the Drive API (and to others), most of the time it is written on the Relase Notes.
There is also the Migration Page Guide where Google lists what's new and what's deprecated. Google also writes in red letters the outdated functionalities in their guides. Another way is they update devs is to announce it during conferences like Google I/O.
And lastly, the support page tells us devs to post questions here on Stackoverflow.
I'm a relative beginner using Google Apps Script and JavaScript, but I've been playing around with bot for days now and I've created a few simple programs and I'd really like to try and get started on my dream project, even if it takes me forever. I'd like some advice on what I should use in terms of making the UI and what database I should use to hold the information (and if this app is even possible).
The App
I'd like to create an online novel management app that utilizes Google Drive as it's source for files. The UI would have a tree that showcases all the google drive files in the novel. When a scene is clicked, the scene opens up for editting.
Questions
Is this app a possibility?
If so, in terms of a UI, what do you think I should use? The google
provided UIbuilder? The HTML service - for example, can I have a
frame on the right that the google doc that needs to be editted
can open up in on the right?
Lastly, what database should I use? The database would have to store
chapter names and positions, as well as scene names, positions,
and the google doc ID that the scene corresponds to. I've got a
handle on ScriptDB and Spreadsheets... And if either of these two
aren't the best option, would some other database work better? And
why?
This app will, hopefully, be able to give an overview of a novel in tree form, allow you to open a particular scene and edit it, create new scenes, and also change the order in which the scenes are displayed. And then when the person finishes their novel, the app will compile all the scenes into one novel (also in google Drive).
Any insight or suggestions would be greatly appreciated!
Having a look at the questions you recently posted I think I have a pretty good idea of what you are trying to do and it looks like an exciting project... I can only encourage you to start it as soon as you can even if you're not comfortable with all the tools you will need to use, the best learning method is probably to work on something important to you.
Now your 3 questions : 1 - This is perfectly doable in the GAS environment and shouldn't be too hard to go through.
2 - the GUI builder is an easy way to start with UI but it lacks a number of features and tools that you will be needing (tree for example ) and is not so easy to expand if you ever need to. Depending on your knowledge in html, the choice is mainly between UiApp and html service... I would choose UiApp because I'm not good at all in html (but that's not relevant here ;-) but both are capable of building what you want, are easily expandable and not too hard to debug. The advantage could go to html service if you are going to look for 'nice looking features' because it opens the door to 3rd party tools... but again, this is a matter of personal choice.
3 - A recent post from Mogsdad showed that spreadsheet are faster than scriptDb for data storage and manipulation. I find it also easier since I can have a global view on data in the spreadsheet when debugging. Of course Spreadsheet must be considered as a container and data manipulated at array level to benefit from maximum performance. I use that in a lot of database application with full satisfaction.
Sorry for these "general considerations" that don't comply to sto standards ;-)
Yes, it seems that all of the things you are requesting are not too ridiculous. I recommend sticking to Google services because they are all easily integrated. To start off, you may want to use the UI builder/UI services. There may be a point in this project where you may want some functionality that the UiApp doesn't provide. At that point, you might want to switch over to HtmlService.
My answer is the same for the databases question. You might want to use a spreadsheet for your database so that you will be able to easily edit it by hand if you need to. You may not have the performance that another database would give you, but it will be fairly easy to test and mess around with your spreadsheet "database."
You could start out with getting the basics down. There's a serious amount of data out there. I would suggest you research on an "as-needed" basis. Design some work-/dataflow patterns for your app, for which you could try to use the Fluid UI extension for Chrome. Have a look at this from Mozilla on the designing of apps.
When you've gone through this you might want to have a look at Phonegap and the basics of web development and how you could combine the two.
There's also several ways of using/storing data. You could try WebSQL though it they no longer develop it. You could look at IndexedDB. You could try to use cookies.
Seriously, have a look around. You might also like the books of Wrox. They're very informative and have great work with reading demo's. Though the books are huge ;)
Is there any way to add a business with complete information (with address, geospatial location, categories, trading hours etc) to Google Places in a programmatic fashion?
We want to add new franchises to a listing of stores. Manual changes are too brittle, the bulk upload takes a long time to be confirmed and the standard Places API has only a very limited method on it. Am I missing something or is there no support for managing your own store listings via an API?
I don't think you're missing anything at this time. Support for that sort of thing is currently limited to what's documented at the link you provide, I believe.
The Places stuff is in the odd grey area where Google is kind of pushing it and promoting it, but also saying that it's just in Labs, it's just experimental, etc., so it may not have all the features you need.
There might be other ways to get your businesses into Google Maps, if your concern is Google Maps generally and not the Google Places stuff specifically. If they exist, they may have more fully featured API capabilities for updates. Or this might be a big dead end.
If this issue is closer to a big annoyance instead of a total dealbreaker, then the approach I'd recommend, if you can wait long enough, would be to implement what you can in the existing API, and keep an eye on the API docs to see if they add more capabilities in the coming months. Open a feature request for Places API in the issue tracker and maybe keep an eye on other features requests there, especially issue 2431.
Just started testing Zoho Crm as a CRM solution for our company. Someone asked for a Google map on the page showing our upcoming engagements.I know Zoho provides an API that allows accessing its data from the outside, but I actually need to integrate the map on the data-entry form.If anyone could provide a pointer to any mashup with Zoho CRM (be it Google MAps, Bing Maps, or any similar web service), I would be extremely grateful.
I know this is an ancient question, but since there's no answers and this is pretty much all that came up on google when searching for Zoho CRM integration with Google Maps I'll take a stab at this anyway. I recently got a similiar request, but in this case they wanted to display the leads on a page outside of Zoho.
I created a Java servlet and JSP that runs on Google App Engine. The servlet will connect to Zoho CRM to retrieve all leads and geocode the addresses they are registered with. The client-side Javascript is then taking care of creating the markers on the map for all the addresses.
It's a bit too much code to paste here (although not that much), but you can check it out at http://code.google.com/p/zohomap/.
I put the demo up at http://zohomap.appspot.com/.
I know this is an old question, but it came up on Google Search. About three years ago, I start a similar Google Maps integration project for SugarCRM. The JJWDesign Google Maps project is up on GitHub.com. The idea came about during a marketing meeting and quickly grew out of control.
Download at:
https://github.com/jjwdesign/JJWDesign-Google-Maps
Here are some of the pitfalls that I've experienced:
Exceeding Limits of Geocoding: The Google Maps API v3 has in place a limit of 2,500 Geocoding requests per day. It is also throttled to 10 per second. So, you'll most likely need to develop something to queue these requests. I used a CRON/Scheduled Task to handle the processing trigger.
PHP Memory Limits: The design of SugarCRM creates rather large objects for each one of it's records. Using 10,000 of these objects will usually exceed the memory allowed for PHP to execute. So, special consideration may be needed in examining the best way to pull data into the map.
Always develop/test with a large data set; 10,000+ records. This way you'll be able to more easily see inefficiencies in your code; especially JavaScript. The IE Browser has been know to cause issues with MarkerClustering.
Get ready for an explosion of interest in advanced search / filtering functionality. Also, expect to develop a large section of Admin configuration. Everyone wants something slightly different.
Cheers,
Jeff