国产av日韩一区二区三区精品,成人性爱视频在线观看,国产,欧美,日韩,一区,www.成色av久久成人,2222eeee成人天堂

首先，學(xué) Angular 只有一週就能想到這麼深已經(jīng)是很不容易了，比我當初強太多，我相信你能把 Angular 用的很好。

其次，很遺憾我沒有怎麼接觸過地圖類應(yīng)用，特別是不了解那些 SDK 究竟複雜到什麼程度，所以我很難說換用 Angular 是否能讓事情變得更好。

先說句題外話，我覺得 API 和 SDK 是不同的，特別是對 webapp 來說。 API 通常是用於資料交換的，一般不會涉及到 DOM 物件；而 SDK 才是你說的那種，它們本身就有一套封裝好的邏輯，並且通常都提供了和 DOM 緊密耦合的介面呼叫。

API 對於 Angular 來說可以處理得很好，自備的 Resource 特別適合用於封裝 API 服務(wù)。但 SDK 的話本身的封裝就比較完備了，在 Angular 的世界裡由於強調(diào)不直接操作 DOM 反而使得 SDK 的融入會變得複雜和困難一些。這個現(xiàn)象的確是存在的，解決之道也的確和你想的差不多，利用 directive 抽象 DOM 交互，利用 service 抽象邏輯部分。比如說想Highcharts 這樣的東東——雖然不是地圖SDK，但也是類似的較複雜且封裝完備的第三方庫——它與Angular 的整合就相當不容易，坑也不少，所以才會有很多人單獨做了Angular＋Highcharts 的模組用於重用，你可以搜搜這方面的例子看看其實現(xiàn)大概能估量出是否合適了。

Angular 的封裝是否會讓簡單問題複雜化？有時候是的。這其實取決於問題本身，Angular 也不是萬用藥，它並非適合所有類型的應(yīng)用。你覺得 Backbone 完全能 handle 你現(xiàn)在的工作？那就繼續(xù)用，不用理會「潮流」。反之等你確實發(fā)現(xiàn) Angular 有 Backbone 無法媲美的部分，那就果斷用 Angular 上手，反正沒有一個框架是完美的，該解決的問題只要你碰了就還得解決，不碰就沒有必要操心。

另外我想延伸這個探討。

讓我們把技術(shù)粗略的分為三個部分：過去的技術(shù)（或者說成熟的技術(shù)），眼下的技術(shù)（或者說流行的技術(shù)），以及未來的技術(shù)（或者說代表著趨勢的技術(shù)）。

我們很容易衝動的決定用“眼下的技術(shù)”來替代“過去的技術(shù)”，大體上來說會有代價，但也絕對不會沒有好處，並且處理得當?shù)脑?，好處總是勝於代價的。

問題是「眼下的技術(shù)」總是有很多選擇，我們會比較容易陷入這種選擇中無法決斷，甚至?xí)X得退回到過去的技術(shù)似乎也沒有什麼大不了的，至少很安全。

我沒辦法說怎樣是對的，最近一年回答了很多次這樣的問題，我自己都有些疲倦了，我只能說說自己的判斷。

我傾向於透過學(xué)習(xí)和了解“未來的技術(shù)”來選擇“眼下的技術(shù)”，並堅決取代“過去的技術(shù)”。

「過去的技術(shù)」總是會過去，遲與早不過是一個時間問題，我是那種「逆水行舟，不進則退」的類型，即使代價會大也在所不惜。

「眼下的技術(shù)」是否與「未來的技術(shù)」合拍其實反映了作者／團隊對科技趨勢的理解和判斷，也反映了你個人的理解和判斷，這裡面會帶一點賭博的成分，有沒有這份自信和決斷能力就得看自己了。

我為什麼談到「未來的技術(shù)」呢？就拿你做的地圖類應(yīng)用來說吧，你覺得像現(xiàn)在的這些 SDK 還能用多久？不單單指它們的程式碼本身，而是它們的技術(shù)棧，基於 SDK 以 DOM 為導(dǎo)向的地圖類應(yīng)用開發(fā)模式還能持續(xù)多久？

如果你覺得這個問題很難回答，那麼第一可以回顧一下業(yè)界領(lǐng)頭羊們的發(fā)展歷史，比如 Google Maps；再一個去了解一下同行中領(lǐng)先者的技術(shù)架構(gòu)。

我們差不多都知道並且可以預(yù)期WebComponents 將會是webapp 的下一個big thing，那麼，當WebComponents 變成“眼下的技術(shù)”的時候（說不定用不了多久），現(xiàn)在的這套基於SDK 以DOM 為導(dǎo)向的地圖類應(yīng)用開發(fā)模式還有多少進步空間與生存空間？

我不知道答案，也不想灌輸給你什麼“價值觀”，我只是描述一下我會如何思考並如何決斷。透過你對問題的描述我感覺你並非只是一個程式設(shè)計師，說不定你在你的團隊裡也扮演者「架構(gòu)師」一類的角色，所以我才多說這些，總的意思就是四個字：高瞻遠矚。

感覺map部分不一定要跟angular扯上什麼關(guān)係，可以把地圖放在angular之外或是讓angular不去編譯map部分。但不影響你去使用正常的map（畢竟已經(jīng)被他們封裝好了），在需要angular做處理的時候，再交由angular去處理。

雖然你用了angular，但是不一定頁面上所有元素都要和angular相關(guān)，把它用在它擅長的地方的就可以了。不要為了用angular而去把所有東西都和angular掛鉤。

本人之前做過一段時間的Openlayers開發(fā),對Angularjs也有一些初步的認識

這屬於兩個不同領(lǐng)域的框架
地圖API專注於G的展現(xiàn),AngularJS專注於IS的展現(xiàn),兩者並不衝突.舉例
當我們做查詢時,服務(wù)端返回一系列的要素資訊,現(xiàn)在一般的做法都是便利要素,獲取資訊,然後透過模板拼湊出HTML,顯示結(jié)果列表,同時,將這些要素資訊加入圖層,繪製到地圖上.

地圖API幫我們完成了地理要素的繪製,但是資訊資料是需要我們自己來控制的.

讓我們來模擬一段滑鼠和要素互動的例子

function highlight(feature){
    map.control.select(feature)
}

//偽代碼(原始),或其他前端模板

var i=0,l=arrs.length,str=[],$case,map;
for(;i<l;i++){
    str.push("<li>"+arrs[i].name+"</li>")
}
$case.on("mouseenter","li",function(){
    var index=$(this).index();
    var feature=arrs[index];
    highlight(feature);
})

//AngularJS

<li ng-repeat="item in arrs" ng-mouseenter="highlight(item)">{{item.name}}</li>

當然,原始採用其他的js模板也可進行MVC,但是使用AngularJS的好處在於單頁應(yīng)用,中間實現(xiàn)過程都只是條條大道通羅馬而已.

但是,需求改變了,我們在高亮要素的同時,能夠高亮當前的li元素,或者其他的新需求,這時候就會發(fā)現(xiàn),我們改動代碼的點不在一個位置

原始方法需要在事件綁定的過程中增加樣式的切換

//AngularJS

<li ng-repeat="item in arrs" 
    ng-mouseenter="highlight(item);item.active=true"
    ng-mouseleave="item.active=false"
    ng-class="{'highlight':item.active}"
    >{{item.name}}</li>

簡單來講,維護變的更快速,原有業(yè)務(wù)不受影響.

的確，地圖SDK已經(jīng)幫你完成了DOM的管理，這部分的工作和ng的重複了，所以再強加ng上去就會感覺怪怪的。如果地圖SDK的提供本身就是ng方式的那可能就會帶來不一樣的開發(fā)體驗了。

剛開始覺得有點麻煩，不過逐漸理解angular就覺得比較順手了。
要知道不管什麼JS框架，物件都是傳遞的參考。
然後對於SDK，其實把SDK的物件綁到一個service上，注意在回調(diào)裡$apply一下就好了