Select to view content in your preferred language

JS API & Dojo 1.8

1810
12
Jump to solution
09-10-2012 11:00 AM
GeorgeSimpson
Regular Contributor
Is there an estimate when the JS API will be fully AMD-compliant and built with Dojo 1.8?
0 Kudos
1 Solution

Accepted Solutions
derekswingley1
Deactivated User
Is there an estimate when the JS API will be fully AMD-compliant and built with Dojo 1.8?


No estimate for both. We will get there, but do currently have an estimated timeline. I can say the next version of the API (3.2, due out shortly) will continue to use Dojo 1.7.

What specific things are you looking to do that you cannot do with Dojo 1.7 and non-AMD style modules?

View solution in original post

0 Kudos
12 Replies
derekswingley1
Deactivated User
Is there an estimate when the JS API will be fully AMD-compliant and built with Dojo 1.8?


No estimate for both. We will get there, but do currently have an estimated timeline. I can say the next version of the API (3.2, due out shortly) will continue to use Dojo 1.7.

What specific things are you looking to do that you cannot do with Dojo 1.7 and non-AMD style modules?
0 Kudos
GeorgeSimpson
Regular Contributor
Right now, I'm adding mobile functionality to my app and am having trouble with a few of the dojo mobile widgets and the map, particularly putting a map inside of a programatically created mobile.view that has a header and footer.  The widgets are different at 1.8 and I think will solve some of my issues.

The AMD compliance isn't too big an issue right now, but I have started porting everything over and would like to keep it all consistent.
0 Kudos
JeffPace
MVP Alum
Sorry, wasn't sure where else to post this.  Is there a beta forum somewhere? I am seeing massive issues with 3.2, particularily with tiled services (both local and ago) and dynamic (WMS seems to work ok). 

The tiles (including dynamic services) are completely scrambled, yet correct within the tile .
Screen shot shows green lines (local tiled service), red lines (local dynamic service) and AGO street map in background.

3.1 api
[ATTACH=CONFIG]17629[/ATTACH]

3.2 api
[ATTACH=CONFIG]17630[/ATTACH]
0 Kudos
derekswingley1
Deactivated User
Sorry, wasn't sure where else to post this.  Is there a beta forum somewhere? I am seeing massive issues with 3.2, particularily with tiled services (both local and ago) and dynamic (WMS seems to work ok). 

The tiles (including dynamic services) are completely scrambled, yet correct within the tile .
Screen shot shows green lines (local tiled service), red lines (local dynamic service) and AGO street map in background.


Jeff�?? where did you get the idea that 3.2 is out? We're close, but not ready to announce it.

One of the big changes we made was to change how CSS is handled in the API. I won't go into detail here (there will be plenty of info when we officially announce 3.2) but add this to your app:
<link rel="stylesheet" href="http://serverapi.arcgisonline.com/jsapi/arcgis/3.2/js/esri/css/esri.css">
0 Kudos
JeffPace
MVP Alum
It was your "due out shortly" comment.  I misinterpreted.

I appreciate the response. I was more hoping that there was a way/process where the development community could be a bit more involded in development/planning/beta via a forum, blog, etc..as opposed to strictly being a comsumer/bug finder type role 🙂
0 Kudos
ReneRubalcava
Esri Frequent Contributor
Getting access to dojo/request would be pretty nice. It looks like a slick module to wrap all the xhr goodies. Notice I said 'nice', not critical.

Personally, I've been making heavy use of DnD lately and it looks like it got some updates in 1.8 for touch capabilities, so that would be 'nice'.

Glad to hear 3.2 is coming up, along with some css improvements.
0 Kudos
derekswingley1
Deactivated User
I see...me and my big mouth ;).

Even though we don't modify releases once we announce them, we release often enough that significant bugs are addressed quickly. 3.2 will be our fifth release of 2012 (and we plan to do one more before the end of the year). We've made the decision that we would rather put out more official releases rather than running a beta program. This approach is more efficient as it allows us to concentrate on improving the API instead of managing additional API versions and an additional beta community. We already see quite a few issues come up again and again here... imagine if we put up yet another forum.

Anyway, did adding that CSS file fix your tiled layer?
0 Kudos
derekswingley1
Deactivated User
Getting access to dojo/request would be pretty nice. It looks like a slick module to wrap all the xhr goodies. Notice I said 'nice', not critical.


That's on our list but there won't be a lot of changes if you're already using esri.request, as we recommend ;). The one change/improvement that comes to mind for dojo/request is access to progress of a request while it's happening.
0 Kudos
JeffPace
MVP Alum
derek. 

First - really appreciate the dialog. 
second - YES css line fixed everything!! thankl you
third - the impetus for the beta request is more selfish.  Basically when the new Api comes out, it kinda feels like Api by ambush.  NEed to drop everything to stay current.  Otherwise it is easy to fall behind, and going from 3.1 to 3.2 is alot easier than going from 2.6 to 3.2 (for example).

I like the rapid release schedule, and the development cycle.  I think what I am looking for is more of a "Will be out in one to two weeks" or "Target date is Oct 1" as opposed to - "Surprise, came out an hour ago".
0 Kudos