წყალქვეშა ქვებს რაც შეეხება:
1) ბრაუზერებს შორის თავსებადობა, 99% შემთხვევაში კოდი თავსებადია ყველა არსებული ბრაუზერისთვის გარდა IE - სი, ეს ეხება როგორც IE6 - ს ასევე ახალ IE7 - ს დანარჩენი ყველა ბრაუზერისთვის უმეტეს შემთხვევაში უპრობლემოდ ხდება ყველაფერი.
2) მემორი მენეჯმენტი აქაც IE ჟონავს, ანუ java_script - ისა და DOM - ის მემორი და გარბიჯ კოლექტორები ცალკე აქვს აქვს, და თუ დავუშვათ ჩვეულებრივი JS ობიექტს აქვს მითითება DOM ობიექტზე ხოლო შემდეგ ხდება ამ ჩვეულებრივი ჯავასკრიპტის ობიექტის განადგურება მეხსიერებაში რჩება DOM - ის ობიექტი, რამაც შეიძლება მეხსიერების გადავსება და არა მარტო ბრაუზერის არამედ მთლიანი სისტემის დაკიდება გამოიწვიოს.
3) თვითონ Ajax - თან არანაირი პრობლემა არ არის არსად ერთადერი უცნაურობა რაც IE - ს ახასიათებს არის XHR ობიექტის ინიციალიზაციის და მისი მეთოდების გამოძახების მიმდევრობაში სხვაობა... რაც იწვევს იმას რომ ე.წ. multiple instance - ბის გამოყენება ხდება შეუძლებელი... გვერდის ავლა ადვილია...
4) კოდირებებთან პრობლემები არ არსებობს გარდა იმისა რომ თუ ვიყენებ განსხვავებულ კოდირებას (არა UTF-8, XHR ყველაფერს UTF-8 კოდირებით გზავნის სერვერზე) მაშინ სერვერის მხარეს რიქვესტის პარამეტრების მნიშვნელობების შესაბამის ენკოდინგში გადაყვანაა საჭირო რაც მიიღწევა mb_string - ით ან iconv - თი. თუმცა ისევ IE6 - ში რომელიღაც კოდირებაში გარღვევაა...
5) პრობლემები რესპონსთან გხვდება IE - ში ანუ innerHTML - ს გამოყენება გარკვეულ მომენტებში სახიფათოა მითუმეტეს თუ tabale ან form ელემენტებთან ვმუშაობთ... თუმცა გამოსავალი არსებობს...
6) DOM თითქმის ყველგან ერთნაირია და განსხვავებების მართვა ადვილია... (თუმცა IE და ზოგ შემთხვევაში Opera უბრავენ)
7) დეველოპმენტისთვის FireFox და FireBug არის must!!!
8) ზოგადად Ajax არ არის მარტო XHR და ძალიან მაღალ კვალიფიკაციას მოითხოვს და საკმაოდ საფუძვლიან ცოდნას Ajax აპლიკაციების წერა
9) გარდა XHR - ისა პრობლემები გვხვდება CSS - თან რა თქმა უნდა IE - ში, სხვაგან ყველგან მეტნაკლები სიზუსტეა (Opera შედარებით პრობლემატურია)
10) დინამიურ stylesheet - ებთან მუშაობისას განსხვავებები მარტო IE - ში გვხვდება, Safari - ში readonly იყო და ბოლო ვერსიაში დაფიქსეს...
11) პრობლემებია XML რესპონსთან ოღონდ ძალიან მცირე
* * *
ბიბლიოთეკების ოვერვიუ
1) prototype და scriptaculo (ეს განვითარებაა prototype - სი) პიონერები და ერთერთი წვერებიანი ბიბლიოთეკებია კარგი და წარმატებული რამეებია... თუმცა არ მომწონს დიდად...
2) ზემოთნახსენები ბიბლიოთეკების მსგავსია კიდევ mootools ძალიან ძალიან კარგია..
3) YUI ანუ Yahoo User Interface ესეც კარგია თუმცა შედარებით ზონზროხაა...
4) GWT ანუ Google Web Toolkit - ასეთი მძ%&$ი მე ჯერ არ მინახავს სრული პასუხისმგებლობით ვაცხადებ რომ მაგარი ტუტუცობაა...
5) PHP - სთვის არსებოს XAjax შედარებით კარგი და სტაბილური ძრავია და მარტივი რაც მთავარია... იდეოლოგია მე ძალიან მომწონს და ზოგადად მომხრე ვარ მაგ იდეოლოგიის...
დანარჩენ დეტალებს საჭიროების მიხედვით დავწერ
* * *
6) jQuery - ესეც შესანიშნავი რამ არის უბრალოდ შედარებით ძალიან ოდნავ ნელია mootools - ზე...
ასევე მოსაზრებები ბიბლიოთეკების გამოყენებასთან დაკავშირებით:
1) აუცილებლად უნდა გამოვიყენოთ თუ თვითონ წერა გვეზარება...
2) აუცილებლად უნდა გამოვიყენოთ იმ შემთხვევაში თუ წერა არ გვეზარება მაგრამ ყველა ბრაზერის განსხვავებების დევნის დრო არ არის...
3) უნდა გამოვიყენოთ თუ საერთოდ არ გვაინტერესებს კლიენტის მხარეს რა ხდება სინამდვილეში და ტყუილად რომ არ ვაბრალოთ წარმოშობილი პრობლემები ბრაუზერების ვენდორებს (ნერვებსაც დავზოგავთ და დროსაც)
* * *
4) უნდა გამოვიყენოთ იმ შემთხვევაშიც თუ ზოგადად framework - ების წერის გამოცდილება არ გვაქვს, აქ ლაპარაკი არ არის ზოგადად java_script - ზე აქ მნიშვნელოვანია როგორც კლიენტის მხარეს ასევე სერვერის მხარეს აპლიკაციების არქიტექტურის აგების და ჩამოყალიბების ცოდნა და გამოცდილება... ისე 100დან 100 შემთხვევაში შედეგი იქნება დიდი თუჯის ქვაბი...
ასევე ერთი რამ არის მხედველობაში მისაღები, ბიბლიოთეკების გამოყენება არ ნიშნავს რომ არ უნდა ვიცოდეთ ან არ უნდა ვისწავლოთ არაფერი... უკიდურეს შემთხვევაში თავად გამოყენებული ბიბლიოთეკის შესწავლა მაინც გვიწევს საფუძვლიანად... წინააღმდეგ შემთხვევაში შედეგია დიდი 0...
კიდევ ერთი, ის რომ Ajax მოიცავს რამდენიმე ტექნოლოგიას ასევე ის მოიცავს დეველოპმენტს სტანდარტების დაცვით (ამ საკითხს არ სჭირდება გაჯაზება, ეს თავისუფლად შესაძლებელია), აქედან დასკვნა არის ის რომ Ajax != XHR, ეს არის კომპლექსური და საკმაოდ ნიუანსური იდეოლოგია...
* * *
ჰო ჰო მოდის აზრები
ესე იგი Ajax - ის გამოყენება ბრმად არ შეიძლება... Ajax - ის გამოყენებ ფრონტენდზე როდესაც ვლაპარაკობთ რაიმე პაბლიკ რესურსზე უნდა მოხდეს ფრთხილად და ზომიერად... რაც შეეხება კონტროლ პანელების წერას აქ სრული თავისუფლება გვაქვს...
საიტის შემთხვევაში Ajax - ის გამოყენება სასურველია და დასაშვებია მაგალითად რაიმე ფორმის შევსებისა და გაგზავნისათვის... რეიტინგებში/ვოუტინგებში... და ასევე ისეთ შემთხვევებში სადაც კონტენტი არ თამაშობს გადამწვეტ როლს..
არავითარ შემთხვევაში არ უნდა გამოვიყენოთ Ajax საიტის ნავიგაციის მენიუებში! არ უნდა გამოვიყენოთ Ajax მნიშვნელოვანი კონტენტის გამოსატანად...
ასევე საიტზე Ajax - ის გამოყენება ხშირად რატომღაც ლამაზი ეფექტების გამოყენებაში ერევათ... ათასგვარი ლამაზი მენიუები და ეფექტები არ ნიშნავს რომ საიტი არის Ajaxed...
კიდევ ერთი დეტალი უნდა ავირჩიოთ და გამოვიყენოთ ისეთი ბიბლიოთეკა რომელიც იქნება ძალიან მცირე ზომაში, სასურველი იქნება თუ მისი ზომ არ იქნება 50KB - ზე დიდი... ამისათვის არსებობს სპეციალური კომპრესიის საშუალებები...
* * *
Ajax აბრევიატურის ავტორის ესე ამ მიმართულების შესახებ
http://www.adaptivepath.com/publications/e...ives/000385.php * * *
რაც შეეხება სერვერის მხარეს
PHP იქნება ეს თუ სხვა ენა აუცილებელია ორი რამ... უნდა მოხდეს Rrequest - ის და Response - ეს უნიფიცირება... უნდა გვახსოვდეს რომ Ajax - ს გამოვიყენებთ თუ არა Request არის Request და Response არის Response... თუმცა როდესაც ვმუშაობთ XHR - ით საჭიროა ვიცოდეთ რომ სერვერის მხარეს უბრალოდ პასუხის გამზადება და შემდეგ echo - თი გამოფურთხება არ არის საკმარისი...
პასუხი შესაძლოა იყოს სამი ტიპის, ესენია:
1) ჩვეულებრივი ტექსტი
2) JSON
3) XML
არჩევანი უნდა გაკეთდეს JSON - სა და XML - ს შორის, რადგან ორივე გვაძლევს პასუხის სტრუქტურირების საშუალებას... თუმცა მე პირადად XML მირჩევნია... რადგან თუ საჭირო გახდა შესაძლებელია CDATA სექციის გამოყენება ტეგებში და მასში სასურველი ტექსტის ან პირდაპირ JSON - ის ჩადება...
თვითონ პასუხის დამუშავება უნდა იყოს გარკვეულწილად უნივერსალური ანუ უნდა ჩამოვაყალიბოთ response - ს გარკვეული ფორმატი რაც შემდგომ უკვე კლიენტის მხარეს დამუშავდება, თუმცა მისი აწყობა გარკვეული მექანიზმებით უნდა მოხდეს სერვერზე...
ასევე უნდა იყოს იმის საშუალება რომ პასუხში ჩავდოთ ისეთი XML ტეგები რომლებიც არ არის გათვალისწინებული სპეციფიკაციის მიხედვით თუმცა კლიენტის მხარეს უნდა იყოს იმის საშუალება რომ შეგვეძლოს response handler - ების რეგისტრაცია მსგავსი არაგანსაზღვრული ელემენტებისათვის...
სასურველია რომ ნებისმიერი XHR რიქვესტს ღებულობდეს ერთი უნივერსალური კონტროლერით ხოლო შემდგომი განაწილება უკვე იყოს გარკვეულწილად ფრეიმვორკის საქმე...