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

« წინა პოსტები
ახალი პოსტები »

HTML Form “elements” Property

Apr 05 2009

ამ პოსტის დაწერამდე რამდენიმე წუთით ადრე წავაწყდი 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

ტეგები: , ,

5 კომენტარი »

JavaScript: arrayChunk

Feb 20 2009

დღეს კოდის წერისას დამჭირდა მასივის რამდენიმე თანაბარ ნაწილად დაყოფა, 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) ზომის მასივების მასივს.

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

ტეგები:

კომენტარები »

jCSS – რელიზის კანდიდატი

Feb 18 2009

დაუღალავი და საკმაოდ მძიმე შრომის შემდეგ დღეს ყველა ჩემს ხელთ არსებულ ვებ ბრაუზერში უნიტ ტესტებმა მწვანე აანთო :D რაც ნიშნავს იმას რომ jCSS – მა ყველა მითითებული ტესტი გაიარა წარმატებით(იხ. jCSS Test Suite).

picture-31

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

ტეგები: , ,

6 კომენტარი »

jCSS – CSS Selector Engine

Feb 12 2009

Hi all, ესე იგი მინდა წარმოგიდგინოთ ჩემი ერთერთი პატარა პროექტი სახელად jCSS. იგი წარმოადგენს JavaScript – ზე დაწერილ ე.წ. CSS Selector Engine – ს რომლის მეშვეობითაც მარტივად შეძლებთ HTML დოკუმენტის DOM ელემენტების ძებნას და რეზულტატის მიღებას ტიპიური CSS სელექტორების გამოყენებით.

მინდა აღვნიშნო რომ არავისთვის კონკურენციის გაწევას არ ვაპირებ ანუ jQuery, Mootools, Seezle და ა.შ. :D ეს არის ჩემი პირადი ექსპერიმენტი რომელსაც გარდა პრაქტიკული დანიშნულებისა გააჩნია წმინდა შემეცნებითი დატვირთვა და ამ მინი პროექტზე მუშაობისას ჩემს ძირითად ამოცანას წარმოადგენდა DOM ელემენტებში ნავიგაციისა და ციკლების წარმადობის კვლევა. ნებისმიერ შემთხვევაში სკრიპტი სრულად ფუნქციონალურია და შეგიძლიათ გამოიყენოთ.

წარმადობისა და რეალიზებული CSS სელექტორების ტესტი შეგიძლიათ ნახოთ აქვე. ტესტირებისათვის ვიყენებ Mootools – ის ავტორის მიერ შექმნილ ტესტირების სისტემას სახელად SlickSpeed ასე რომ შედეგებში ტენდენციურობა გამორიცხული :D შედარებისათვის გარდა jCSS – ისა ტესტში გამოვიყენე jQuery – ისა და Mootools – ის ბოლო სტაბილური ვერსიები.

გადაწერეთ jCSS!

გამოყენების მაგალითები:

1
2
3
4
var els = jCSS('#my-element-id div.my-class-name ul a');
for (var i = 0; i < els.length; i++) {
   //do something wit elements
}

სულ ეს არის და ეს, ამ ეტაპზე მეტის დაწერას აზრი არ აქვს. თუ თქვენს მოსაზრებებსაც გამიზიარებთ ძალიან ძალიან გამახარებთ.

enjoy :)

Update:
განვაახლე jCSS აწი უფრო სწრაფია FF, Opera და IE – ში.

SlickSpeed Benchmark: http://www.code.ge/jcss-test/slickspeed/

დავამატე Unit Test Suite ბრაუზერებს შორის და სხვადასხვა ტიპის სელექტორების იმპლემენტაციის სისწორის კონტროლისათვის:
Unit Test Suite: http://www.code.ge/jcss-test/slickspeed/frameworks/test/

Update:

  • დაიფიქსა ყველა ძირითადი ბაგი;
  • დაიხვეწა და განვითარდა Query Parser;
  • დაემატა ყველა ე.წ. ფსევდო კლასების მხარდაჭერა გარდა nth-child და nth-last-child ფსევდო კლასებისა;
  • კომპლექსური ფსევდო კლასების მხარდაჭერა;
  • დავამატე DOM ელემენტების სორტირება ნეითივ სელექტორების მიერ დაბრუნებულ რეზულტატებთან თავსებადობის გამო. თუმცა ამან წარმადობა შედარებით დაწია IE – სა და Opera – ში.
  • დაიხვეწა კონტექსტური პარამეტრების მხარდაჭერა, გარდა DOM ელემენტისა კონტექსტურ პარამეტრად შესაძლებელია გამოვიყენოთ როგორც სელექტორი ასევე DOM ელემენტების მასივი. მაგ:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
      var nodes = jCSS(
       'div > p.paragraph-class-name',
       document.getElementById('my-element-id')
     );

     var nodes = jCSS(
       'div > p.paragraph-class-name',
       '#my-element-id:visible'
     );

     var nodes = jCSS(
      'a em',
      document.getElementsByTagName('h1')
     );
  • განვაახლე SlicckSpeed ანუ დავამატე YUI!, Prototype და Peppy სელექტორ ენჯინები;

    SlickSpeed Benchmark: http://www.code.ge/jcss-test/slickspeed/

  • განვაახლე და გავამდიდრე UnitTest ფრეიმვორკი:

    Unit Test Suite: http://www.code.ge/jcss-test/slickspeed/frameworks/test/

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

1
2
3
4
5
#form option:not(:contains('Nothing'),#option1b,:selected)

#form option:not(:not(:selected))[id^='option3']

:input:not(:image,:input,:submit)

ამ ეტაპზე ნეითივ სელექტორები გათიშული მაქვს Safari, Chrome, IE8 და FF3.1 – სთვის უკუთავსებადობის სრული ტესტირებისათვის. გარდა მაგისა არც ნეიტივ სელექტორები არ არის სრულყოფილად რეალიზებული და ნებისმიერ შემთხვევაში საჭიროა ე.წ. Custom Implmentation(განსაკუთრებით ეს ეხება IE8 – ს).

ტეგები: , , ,

4 კომენტარი »

JavaScript WTF Vol. 5 – magic of onchange event

Jan 31 2009

ხშირად იყენებთ HTML ფორმის ელემენტების ამ ივენთს? :) და რა შემთხვევაში? ალბათ უფრო SELECT ელემენტთან მუშაობისას ხომ? თქვენი არ ვიცი მაგრამ ჩემს პირად პრაქტიკაში განსაკუთრებული გამოყენება ამ ივენთს არ ჰქონია… თუმცა ორიოდე დღის წინ ყველაფერი შეიცვალა და ჩემთვის ერთი ფრიად საინტერესო აღმოჩენა გავაკეთე.

ასეთი რამ გინახავათ?

<div onchange="handleEvent()">
//some other markup
</div>

დამეთანხმებით რომ ერთი შეხედვით ამ ივენთის DIV ელემენტთან გამოყენება ცოტა არ იყოს უცნაურია ხომ? რა ცვლილება უნდა მოხდეს ისეთი DIV ელემენტში რომ მისი დამუშავება მოვახდინოთ ამგვარი გზით? ან დავუშვათ და მოხდა ასეთი ცვლილება მაგრამ რანაირად?

მინდა გაგახაროთ და გითხრათ, რომ, პასუხი მარტივია. DIV ელემენტში არანაირი ასეთი ცვლილება არ მოხდება, მაგრამ, თუ მის შიგნით გვაქვს რადმენიმე SELECT და INPUT ელემენტი რომელთა ცვლილების კონტროლი გვესაჭიროება ეს კოდი მომენტალურად იდეალურ გადაწყვეტად იქცევა!

კლასიკურად უფრო სწორად ძველი სკოლის მიდგომით ასეთი ამოცანის გადაჭრის დროს ყველა, SELECT და INPUT ელემენტის onchange ივენთს მივანიჭებდით ჰენდლერს. თუმცა თუ გავიხსენებთ ფაქტს რომ DOM დოკუმენტში ხდომილება ვრცელდება საწყისი ელემენტისგან(ელემენტი რომელზეც უშუალოდ მოხდა ესა თუ ის მოვლენა) ანუ ელემენტების იერარქიაში ქვევიდან ზევით, ჩემს მიერ ნაჩვენები კოდიც მომენტალურად პრაქტიკულ დანიშნულებას შეიძენს. ამ ინფორმაციაზე დაყრდნობით შესაძლებელია ასეთი კოდის დაწერა:

1
2
3
4
5
6
7
8
9
10
<div id="container">
   <input type="text" name="f1" />
   <br />
   <input type="text" name="f2" />
   <br />
   <select name="s1">
       <option value="v1">Value 1</option>
       <option value="v2">Value 2</option>
   </select>
</div>

ნაჩვენები კოდის შესაბამისი ამოცანა მდგომარეობს ყველა INPUT და SELECT ელემენტის onchange ივენთის დაჭერასა და შესაბამის დამუშავებაში. ნაცვლად იმისა რომ გამოვიყენოთ სათითაოდ ყველა ელემენტს onchange ივენთი, მარტივად შეგვიძლია გავაკეთოთ შემდეგი რამ:

1
2
3
4
5
6
7
8
9
10
11
12
13
document.getElementById('container').onchage = function(e) {
   
   //მოვიპოვოთ Event ობიექტი
   e = e || window.event;
   
   //მოვიპოვოთ საწყისი ელემენტი რომელზეც უშუალოდ დაფიქსირდა ივენთი
   var targetElement = e.target || e.srcElement;

   //თუ ელემენტი არის SELECT ან INPUT ტიპის შევასრულოთ დანარჩენი სამუშაო
   if (/^input|select$/i.test(target.nodeName)) {
       //do something here
   }
}

დამეთანხმებით რომ ძალიან მარტივია ყველა ელემენტის ცვლილების ამდაგვარი ცენტრალიზებული კონტროლი. ეს არის ზუსტად ე.წ. Event Delegation მოდელი რომელიც ძალიან პოპულარულია დღესდღეობით. რატომ არ ვიცი მაგრამ ჩემთვის onchange ივენთი იმდენად ცალსახად იყო ასოცირებული ფორმის SELECT ელემენტთან რომ მისი ამდაგვარი გზით გამოყენების შესახებ არასოდეს მიფიქრია, თუმცა საბოლოო შედეგმა ყოველგვარ მოლოდინს გადააჭარბა.

იმედია ეს პირადად ჩემთვის ჭკუის სასწავლებელი შემთხვევა თქვენთვისაც სასარგებლო იქნება.

enjoy :)

ტეგები: , ,

11 კომენტარი »

Ant, Rhino, YUICompressor & JS Packer

Dec 21 2008

დაახლოვებით ერთი წლის წინ ზედაპირულად შევეხე JavaScript ფაილების კომპრესიას. ძველი პოსტის მიხედვით თუ ვიმსჯელებთ არცთუ ისე ცუდი შედეგია. თუმცა რამდენიმე დეტალი მაინც საჭიროებს გადახედვას, კერძოდ კი:

  • JavaScript ფაილების კომპრესიის პროცესი არ არის ავტომატიზებული;
  • ფაილების კომპრესია მთლიანად ეყრდნობა დენ ედვარდსის ე.წ Packer – ს რომელიც გარკვეულ მიზეზთა გამო საკმაოდ მოუხერხებელია;

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

მიზანი

  • JavaScript ფაილების გაერთიანება და ერთი საბოლოო ფაილის მიღება;
  • გაერთიანების შედეგად მიღებული ფაილის მინიფიკაცია და ობფუსკაცია;
  • მინიფიცირებული ფაილის ზომაში კიდევ უფრო მეტად შემცირება base62 კოდირებით;
  • საბოლოო ფაილის gzip კომპრესია;

სრულად »

ტეგები: , ,

1 კომენტარი »

« წინა პოსტები
ახალი პოსტები »