პოსტები ტეგით “JavaScript”

JavaScript: String.replace()

რამდენიმე წლის წინ დავწერე პოსტი JavaScript – ით DOM ელემენტის სტილებთან მუშაობის შესახებ. ბრაუზერებს შორის სხვაობიდან გამომდინარე(კერძოდ კი IE – ს განსხვავებული მიდგომის გამო) პრობლემის გვერდის ასავლელად დავწერე ქვემოთ ნაჩვენები კოდი:

1
2
3
4
5
6
7
8
9
10
function getCamelCase(string) {
    var tokens = string.split('-');
    if (tokens.length > 1) {
        for (var i = 1; i < tokens.length; i++) {
            tokens[i] = tokens[i].substring(0, 1).toUpperCase() + tokens[i].substring(1).toLowerCase();
        }
        string = tokens.join('');
    }
    return string;
}

კოდის ერთადერთი დანიშნულებაა ტირეებიანი CSS ატრიბუტების მაგ. border-left-color, background-color გადაყვანა ე.წ. Camel Case ფორმატში ანუ borderLeftColor, backgroundColor და ა.შ.

დღეს კოდის წერისას იგივე პრობლემა მექანიკურად გადავჭერი სხვა უფრო მოხდენილი და რაც მთავარია გაცილებით მცირე ზომის კოდის მეშვეობით:

1
2
3
4
5
6
7
8
var str = "some-test-string";
str.replace(/-([\w])/gi, function(a1, a2) {
    return a2.toUpperCase();
});

//კოდის შესრულების შემდეგ
//სტრიქონი "some-test-string"
//გარდაიქმნება შემდეგნაირად: "someTestString"

დამეთანხმებით რომ თვალსაჩინო სხვაობაა :D როგორ მუშაობს ეს კოდი? პირველ რიგში შეგახსენებთ თავად String ობიექტის replace() მეთოდის სიგნატურას:

str.replace(regexp|substr, newSubStr|function[, Non-standard flags]);

ანუ replace() მეთოდს მეორე პარამეტრად ახალი, ჩასანაცვლებელი სტრიქონის ნაცვლად შეგვიძლია გადავცეთ ქოლბექ ფუნქცია რომელიც დააბრუნებს დამუშავებულ სტრიქონს, ხოლო ეს დაბრუნებული სტრიქონი თავის მხრივ გამოყენებული იქნება რეგულარული გამოსახულების მიერ ნაპოვნი შესატყვისის ჩასანაცვლებლად.

საინტერესოა ასევე თუ რა პარამეტრებს გადასცემს replace() მეთოდი ქოლბექ ფუნქციას. გადასაცემი პარამეტრების რაოდენობა ცვალებადია და დამოკიდებულია მთელ რიგ ფაქტორებზე. მაგალითად ჩემს მიერ ნაჩვენებ მაგალითში ფუნქციას გადაეცემა ოთხი პარამეტრი, კერძოდ კი ფუნქცია გამოიძახება ორჯერ შემდეგი პარამეტრებით:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
//პიველი დამთხვევისათვის ანუ "-t"
function(
  "-t",  //რეგულარული გამოსახულების მიერ ნაპოვნი სტრიქონი სრულად
  "t",    //დამაჯგუფებელ ფრჩხილებში მოთავსებული შედეგი
  4,     //პოზიცია რომელზეც მოხდა პირველი დამთხვევა
  "some-test-string" //სრული სტრიქონი
);

//მეორე დამთხვევისათვის ანუ "-s"
function(
  "-s",  //რეგულარული გამოსახულების მიერ ნაპოვნი სტრიქონი სრულად
  "s",    //დამაჯგუფებელ ფრჩხილებში მოთავსებული შედეგი
  9,     //პოზიცია რომელზეც მოხდა პირველი დამთხვევა
  "some-test-string" //სრული სტრიქონი
);

ნაჩვენები კოდიდან თვალსაჩინოა სავარაუდო პარამეტრების რაოდენობა, თუმცა მნიშვნელოვანია შემდეგი დეტალების გათვალისწინება, ქოლბექ ფუნქციას:

  • პირველ პარამეტრად ყოველთვის გადაეცემა რეგულარული გამოსახულების მიერ ნაპოვნი სრული შესატყვისი;
  • ბოლო პარამეტრად ყოველთვის გადაეცემა სრული სტრიქონი რომლშიც განხორციელდა გარკვეული შესატყვისის ძიება;
  • ბოლოდან მეორე(ბოლოს წინა) პარამეტრად ყოველთვის გადაეცემა ნაპოვნი შესატყვისის პოზიცია.
  • თუ რამდენი პარამეტრის გადაცემა მოხდება პირველსა და ბოლო ორ პარამეტრს შორის დამოკიდებულია რეგულარულ გამოსახულებაში გამოყენებული დამაჯგუფებელი ფრჩხილების რაოდენობაზე(ჩემს მიერ ნაჩვენებ მაგალითში ასეთი პარამეტრი ერთია რადგან მხოლოდ ერთი დამაჯგუფება მაქვს გამოყენებული);
  • replace() მეთოდი გამოიძახებს ერთხელ თუ რეგულარული გამოსახულების ბოლოს არ გვაქვს მითითებული “g” ანუ გლობალური მოდიფიკატორი, ან გამოიძახებს იმდენჯერ რამდენი დამთხვევაც მოხდება კონკრეტული შესატყვისისათვის(ნაჩვენებ მაგალითში გამოძახება მოხდება ორჯერ).

enjoy B-)

ტეგები: ,

Jetpak – დამატებების ახალი სისტემა Mozilla – სგან

jetpack_logo საერთოდ ცნობილია რომ კონკურენცია ძალიან კარგი რამ არის. ამ მტკიცებულების სისწორის კიდევ ერთი ძალიან კარგი მაგალითი გვაქვს სახეზე კერძოდ კი Google Chrome – სა და Mofilla Firefox – ის ე.წ. extension – ების სისტემების სახით.

მოგეხსენებათ რომ Google Chrome ძალიან ახალი ბრაუზერია რომელიც გასული წლის სექტემბრის დასაწყისში მოევლინა სამყაროს. მიუხედავად მისი ინოვაციურობისა მისი კრიტიკის ერთერთ მთავარ მიზეზად იქცა FF – ის მსგავსი დამატებების სისტემის არ ქონის გამო.

ცხადია ასე პირველივე დღიდან ყველაფერის ჩადებას ვერ მოახერხებდა Google თავის ახალ ბრაუზერში, თუმცა, როგორც მალე გაირკვა შეჩერებასაც არ აპირებდა. სულ რამდენიმე თვეში გამოჩნდა პირველი პროპოზალი რომელიც Chrome – ს დამატებების პლატფორმას შეეხებოდა. თუმცა ამ პროპოზალში ერთმა მეტად საგულისხმო დეტალმა გაიჟღერა – განსხვავებით FF – ის ანალოგიური სისტემისგან Chrome – ს დამატებების შესაქმნელად საკმარისია მხოლოდ HTML/CSS და JavaScript. არავითარი XUL, არავითარი რთული XML კონფიგურაციის ფაილები დამატების ინსტალაციისათვის და ა.შ.

Google – ს ეს გდაწყვეტილება ჩემთვის პირადად გაცილებით მისაღები იყო რადგან XUL – ის ვერანაირ აუცილებლობას ვერც FF – ში ვხედავდი მანამდე და სიმართლე ითქვას ვერც დღეს ვერ ვხედავ… თუმცა არც Mozilla – მ დააყოფნა და დღეს უკვე შემოგვთავაზა FF – ის დამატებების შექმნის ახალი მექანიზმი. კერძოდ კი Jetpak!

ციტატა პროექტის საიტიდან:

In short, Jetpack is an API for allowing you to write Firefox add-ons using the web technologies you already know.

რითია საინტერესო Jetpak? პირველ რიგში ისევე როგორც Crhome – ს შემთხვევაში, Jetpak – ის შემთხვევაშიც დამატების შესაქმნელად საკმარისია მხოლოდ HTML/CSS და JavaScript. ამ შემთხვევაშიც არავითარი XUL და რთული XML კონფიგურაციის ფაილები. ასევე არავიტარი ბრაუზერის გადატვირთვა დამატების ინსტალაციის შემდგომ და რაც ყველაზე ყველაზე ყველაზე მნიშვნელოვანია დეველოპმენტის პროცესში შეგვიძლია გამოვიყენოთ ნებისმიერი არსებული ინსტრუმენტული საშუალებები და Firebug დებაგირებისათვის რაც არსებულ მოდელში პრაქტიკულად შეუძლებელია. ასევე jQuery – ს მოყვარულთათვის ძალიან მნიშვნელოვანი ფაქტია რომ ეს ბიბლიოთეკა ნაგულისხმევად არის ჩადებული Jetpak – ში, რაც კიდევ უფრო გაამარტივებს დამატებების პროგრამირებას.

მართალია დასრულებამდე და საყოველთაო გავრცელებამდე კიდევ დიდი გზა აქვს გასავლელი Jetpak – ს, თუმცა მისი გამოყენება უკვე შესაძლებელია. ასე რომ თუ არ გეზარებათ შეგიძლიათ დააინსტალიროთ და დამატებების წერასაც შეუდგეთ :)

ტეგები: , , , ,

Handling “onchange” event revisited

რამდენიმე თვის წინ დავწერე პოსტი, HTML ფორმის ელემენტის onchange ივენთისა და მისი დელეგირების შესახებ.

ნახსენებ პოსტში ნაჩვენებია onchange ივენთის დელეგირების მაგალითი სადაც ფორმის ყველა ელემენტის აღნიშნული ივენთის ცენტრალიზებული კონტროლი ხორციელდება მშობელი ელემენტის onchange ივენთის მეშვეობით.

მსგავსი შედეგის მიღწევა შესაძლებელი ე.წ. Event Bubbling – ის წყალობით რაც ივენთის, საწყისი ელემენტიდან მშობელი ელემენტისკენ გავრცელებას ეწოდება. მეტი თვალსაჩინოებისთვის იხ. სურათი(სურათისათვის განსაკუთრებული მადლობა ირაკლის):

picture-17

ივენთის გავცელების(შვილიდან მშობლის მიმართულებით) ასეთი მეთოდი ყველა ბრაუზერში ერთნაირად მუშაობს. და წესით ეს უნდა ეხებოდეს ყველა ტიპის ივენთს. თუმცა როგორც მოსალოდნელი იყო IE – ში მისი მერვე ვერსიის ჩათვლით სწორედ ამ ივენთზე აღმოჩნდა შეზღუდვა და იგი საწყისი ელემენტს(ელემენტი რომელზეც უშუალოდ წარმოიშვა ეს ივენთი) იქეთ არ ვრცელდება.

ერთი შეხედვით, ამ ჩიხიდან რამდენიმე გამოსავალი შეიძლება მოიძებნოს:

  1. ფორმის ყველა ელემენტის ჩამოვლა და მათთვის onchange ივენთ ჰენდლერის მინიჭება. თუმცა აქ მთელ რიგ პრობლემებს წავაწყდებით:

    • ელემენტებზე ასეთი გზით ივენთ ჰენდლერების მინიჭება IE – ში იწვევს მეხსიერებასთან დაკავშირებულ პრობლემებს, ე.წ. memory leaks. ეს გარემოება განსაკუთრებით მნიშვნელოვანია თუ ფორმაში ბევრი ელემენტები გვაქვს.
    • თუ ფორმის ელემენტები იტვირთება დინამიურად Ajax – ის მეშვეობით, ყოველი ასეთი ჩატვირთვის შემდეგ საჭიროა: ა) ყველა ფორმის ელემენტისა და მათი ივენთ ჰენდლერების განადგურება რათა თავიდან ავირიდოთ მეხსიერებასთან დაკავშირებული პრობლემები; ბ) ახლად ჩატვირთული ელემენტების იტერაცია და მათთვის შესაბამისი ივენთ ჰენდლერების განსაზღვრა.

    დამეთანხმებით რომ აღწერილი ორი მეთოდი დიდი მოქნილებით არ გამოირჩევა.

  2. ნაცვლად onchange ივენთისა გამოვიყენოთ onfocus და onblur ივენთები. თუმცა აღმოჩნდა რომ არც ამ ივენთების გავრცელება არ ხდება ტრადიციული(შვილიდან მშობლის მიმართულებით) მეთოდით.

გარკვეული კვლევა ძიების შემდეგ მივაგენი ისეთ ივენთებს(დიდი მადლობა PPK – ს) რომელთა ბაბლინგი IE – ში ისე მუშაობს როგორც საჭიროა. ეს ივენთებია onfocusin და onfocusout.

როგორ შეიძლება აღნიშნული ივენთების გამოყენება პრობლემის გადასაჭრელად? სანამ უშუალოდ კოდის წერას დავიწყებთ საჭიროა კარგად გავერკვეთ თუ როგორ მუშაობს onchange ივენთი HTML ფორმის ცალკეული ელემენტებისათვის და ასევე თუ რა გვერდის ავლის მექანიზმების გამოყენებაა შესაძლებელი IE – ში.

SELECT ელემენტი

ამ ელემენტის შემთხვევაში onchange ივენთი წარმოიშვება მხოლოდ იმ ჩამოსაშლელი სიიდან კონკრეტული ელემენტის ამორჩევის დროს. IE – ში იგივე ხდომილების ემულაციისათვის შესაძლებელია onclick ივენთის გამოყენება, თუმცა, ასეთ შემთხვევაში ივენთი ორჯერ წარმოიშვება ერთხელ ელემენტის გააქტიურებისას ხოლო მეორედ ჩამოსაშლელი სიიდან მნიშვნელობის არჩევისას. თუმცა ამ პრობლემის არიდება მარტივად არის შესაძლებელი სწორედ onfocusin და onfocusout ივენთების მეშვეობით რადგან ეს ორივე ივენთი წარმოიშვება onclick ივენთამდე, გამომდინარე აქედან შესაძლებელია წინა ივენთის ტიპის დამახსოვრება და შემდგომ უკვე დადგენა ეს იყო პირველი კლიკი თუ ჩამოსაშლელი მენიუდან ელემენტის არჩევა მოხდა?

INPUT text და TEXTAREA ელემენტები
ამ ელემენტების შემთხვევაში onchange ივენთი წარმოიშვება როდესაც ელემენტი კარგავს ფოკუსს. IE – ში იგივეს მიღწევა შესაძლებელია onfocusout ივენთის მეშვეობით.

INPUT checkbox და radio ელმენტები
ამ ელემენტების შემთხვევაში onchange ივენთი წარმოიშვება მათი მნიშვნელობის ცვლილების თანავე. IE – ში იგივე შედეგის მისაღებად მარტივად არის შესაძლებელი onclick ივენთის გამოყენება.

მაშ ასე წინა სამი პარაგრაფში გამოიკვეთა სამი ისეთი ივენთი რომელთა გამოყენებაც შესაძლებელია onchange ბაბლინგის ემულაციისათვის. ეს ივენთებია: onclick, onfocusin, onfocusout.

ამ ინფორმაციაზე დაყრდნობით მარტივად არის შესაძლებელი სულ რამდენიმე სტრიქონი კოდით გადავწყვიტოთ პრობლემა:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
(function() {
   
   var div = document.getElementById('testonchange');
   
   //ყველა ბრაუზერი IE - ს გარდა
   if (document.addEventListener) {

      div.onchange = function(e) {
         //აქ შეგვიძლია გამოვიძახოთ ივენთის უშუალო ჰენდლერი
      };

   } else { //IE - ს სპეციფიური რეალიზაცია
     
      var previousEvent = null;
     
      div.onfocusin = div.onfocusout = div.onclick = function() {

         var e            = window.event,
            target       = e.srcElement,
            isSelect     = target.nodeName  == 'SELECT',
            notTextInput = target.nodeName  == 'INPUT' && /^radio|checkbox$/i.test(target.type),
            isTextInput  = (target.nodeName == 'INPUT' && target.type == 'text') || target.nodeName == 'TEXTAREA',
            validElement = notTextInput || isSelect;

         if (isSelect && !target.size && /^focus(in|out)$/.test(previousEvent)) {
            validElement = null;
         }

         previousEvent = e.type;

         if ((e.type == 'click' && validElement) || (e.type == 'focusout' && isTextInput)) {
            //აქ შეგვიძლია გამოვიძახოთ ივენთის უშუალო ჰენდლერი
         }

      };

   }
   
   div = null;
   
})();

ეს არის და ეს :) კოდის დეტალური გარჩევით თავს აღარ შეგაწყენთ, ხოლო რეალური დემონსტრაცია შეგიძლიათ იხილოთ აქ.

ტეგები: , ,

JavaScript: Regex and Multi-line Mode

დღეს აღმოვაჩინე რომ JavaScript – ის Regex იმპლემენტაციას გარდა სხვა ნაკლოვანებებისა ასევე არ გააჩნია ე.წ. “multi-line match mode”. ამ შემთხვევაში ლაპარაკი არ მაქვს რეგულარული გამოსახულების “m” მოდიფიკატორის მხარდაჭერაზე, ლაპარაკი მაქვს “s” მოდიფიკატორზე რომელიც “.“(წერტილი) სიმბოლოს აიძულებს გარდა სხვა სიმბოლოებისა(ნაგულისხმევად “.” ნიშნავს “ნებისმიერი სიმბოლო გარდა ახალი სტრიქონის სიმბოლოსი”) ასევე მოძებნოს ახალი სტრიქონის სიმბოლო.

ჩემი მარტივი ამოცანის გადასაჭრელად საჭირო იყო მოცემულ ტექსტში მეპოვა შემდეგი ტიპის მონაკვეთი:

1
2
3
function myFunction($param1, $param2) {
      return array($param1, $param2);
}

ხოლო ნაპოვნი მონაკვეთიდან ამომეღო {code}{/code} ტაგებს შორის მოქცეული ტექსტი. თუმცა ეს გასაგები მიზეზების გამო არ გამომივიდა.

ნებისმიერ PCRE – სთან თავსებად იმპლემენტაციას გააჩნია “s” მოდიფიკატორი რომლის მეშვეობითაც მსგავსი ამოცანა წყდება ძალიან მარტივად. მაგალითად PHP – ში რეგულარულ გამოსახულებას ჩავწერდით შემდეგნაირად:

1
2
3
//ყურადღება მიაქციეთ გამოსახულების ბოლოში
//მიწერილ "s" სიმბოლოს
$regex = '/{code lang="(\w+)"}(.*?){\/code}/s'

სამწუხაროდ ასეთ გამოსახულებას JavaScript – ში ვერ დავწერთ. თუმცა, ცოტაოდენი კვლევაძიებისა და ექსპერიმენტების შემდგომ მივაგენი გამოსავალს რაც გამოიხატება სპეციფიური ე.წ. character class – ის გამოყენებაში. ამისათვის საჭიროა “\s” და “\S” მეტა სიმბოლოების დაჯგუფება character class – ში. შედეგად მივიღებთ შემდეგ გამოსახულებას:

1
[\s\S]

სადაც “\s” შეესაბამება ნებისმიერ უხილავ სიმბოლოს, ხოლო “\S” შეესაბამება ნებისმიერ არა უხილავ სიმბოლოს.

შედეგად მივიღე ასეთი JavaScript – ის რეგულარული გამოსახულება:

1
/{code\s+lang="(\w+)"}([\s\S]*){\/code}/

ეს გამოსახულება მუშაობს ანალოგიურად PCRE – სთან თავსებადი გამოსახულებისა რომელიც იყენებს “s” მოდიფიკატორს.

ტეგები: ,

HTML Form “elements” Property

ამ პოსტის დაწერამდე რამდენიმე წუთით ადრე წავაწყდი HTML form ელემენტის elements თვისებასთან დაკავშირებულ ერთ პრობლემას(შეცდომას) რომლის შესახებაც აქამდე არაფერი მსმენია და ცოტა არ იყოს უაზროდ დამახარჯინა დრო.

ცნობილია, რომ form ელემენტის აღნიშნული თვისება არის HTMLCollection ტიპის კოლექცია და იგი შეიცავს კონკრეტული HTML ფორმის შიგნით გამოყენებულ ყველა(input, select, button) ელემენტს. სწორედ ეს კოლექცია წარმოადგენს საჭირო ფორმის ელემენტებთან წვდომის ყველაზე უსაფრთხო(თურმე პირობითად) გზას.

როგორც აღმოჩნდა თუ ფორმის ელემენტებს მოვათავსებთ fieldset ტეგში(და წესით ეს ასეც უნდა გავაკეთოთ) elements კოლექცია მოულოდნელ რეზულტატს დაგვიბრუნებს. კერძოდ კი fieldset ელემენტიც(ან ელემენტები) ამ კოლექციაში აღმოჩნდება.

ჩემი ამოცანა მდგომარეობდა შემდეგში, რომ ფორმის ყველა ელემენტებისაგან მიმეღო მათი სახელებისა და მნიშნვნელობების ე.წ. key/value ობიექტი:

1
2
3
4
5
var map = {}, els = target.form.elements;
for (var i = 0, el; (el = els[i++]);) {
   map[el.name] = el.value;
}
console.log(map);

თუმცა ძალიან უცნაური შედეგი მივიღე რადგან fieldset ელემენტს არც name და არც value თვისებები არ გააჩნია.

პრობლემის იდენტიფიცირების შემდგომ ინტერნეტში მოვიძიე მცირეოდენი ინფორმაცია:

The HTML 4 standard adds new <fieldset> and <label> tags to the set of elements that can appear within a form. In IE 5 and later, placing a <fieldset> in a form causes a corresponding object to be added to the form’s elements[] array. Fieldset elements are not scriptable in interesting ways like other form elements are, and their objects do not have a type property like other form elements do. Therefore, the presence of Fieldset objects in the elements[] array seems like a mistaken design decision. This is particularly true since <label> tags do not cause corresponding objects to be added to the elements[] array. The Mozilla and Netscape 6 browsers have chosen to follow Microsoft’s lead on this in order to be compatible with IE.

What this means is that if you define a form that contains fieldsets, the contents of the elements[] array differ in recent, HTML 4-capable browsers and in older, pre-HTML 4 browsers. In this situation, using position-based numeric indexes in the elements[] array is not portable, and you should define name attributes for all your form elements and refer to them by name.

მოკლედ კვლავ IE :D ნუ რას ვიზამთ რეალობა ასეთია :P

ტეგები: , ,

JavaScript: arrayChunk

დღეს კოდის წერისას დამჭირდა მასივის რამდენიმე თანაბარ ნაწილად დაყოფა, PHP – ს ამ ამოცანის გადასაჭრელად გააჩნია შესაბამისი array_chunk() ფუნქცია, მაგრამ, JavaScript – ს მსგავსი არაფერი გააჩნია.

ეს არის ე.წ. quick solution ამ ამოცანის გადასაჭრელად:

1
2
3
4
5
6
7
function arrayChunk(array, size) {
    var start = 0, result = [], chunk = [];
    while((chunk = array.slice(start, start += size)).length) {
        result.push(chunk);
    }
    return result;
}

ფუნქცია ღებულობს ორ პარამეტრს 1) მასივი რომელიც გვინდა დავყოთ; 2) თითოეული დანაყოფის ზომა;

თუ ამ ფუნქციას შეასრულებთ FireBug – ის კონსოლში:

var a = [1, 2, 3, 4, 5, 6, 7, 8, 9];
console.log(arrayChunk(a, 2));

მიიღებთ შემდეგ შედეგს:

 [[1, 2], [3, 4], [5, 6], [7, 8], [9]]

შედეგიდან გამომდინარე ფუნქციის საბოლოო რეზულტატი თვალსაჩინოა, იგი აბრუნებს სასურველი(ამ შემთხვევაში 2) ზომის მასივების მასივს.

დამატებითი დეტალების ახსნისგან თავს შევიკავებ რადგან ფუნქცია უმარტივესია, თუმცა ძალიან სასარგებლო :)

ტეგები: