Nieoczekiwane zachowanie przeglądarek – wszystkich

Dzisiaj krótki wpis o zachowaniu wszystkich przeglądarek, które niezwykle mnie zaskoczyło.

W formularzu znajduje się pole tekstowe, które może być albo uzupełnione z palca, albo jego wartość może być wyliczona metodą javascriptową. Po wyliczeniu wartości pole ma zostać zablokowane (przy czym wystarczy blokada interfejsu).
"Co to za sztuka taki kawałek kodu postawić Łup Łup Łup jquery jako tako na kupę i gotowe".


    $('#my-btn').click(function(e) {
        var value = computeValue();
        $('#my-field-id').attr('disabled', 'disabled').val(value);
    });

Wydawałoby się że nic tu się nie da spier…ć, a jednak się da. Przy ustawieniu atrybutu disabled na elemencie input jego wartość nie jest wysyłana na serwer. I jest to zachowanie udokumentowane w w3schools

Rozwiązaniem tego problemu jest użycie atrybutu readonly zamiast disabled. Wadą tego rozwiązania jest brak wyszarzenia kontrolki (trzeba porzeźbić w css), co niekoniecznie musi się podobać biznesowi. Innym rozwiazaniem może być użycie pola ukrytego synchronizowanego z polem tekstowym. Oba rozwiązania mają wg mnie podobną pracochłonność.
Atrybut disabled nie wpływa na działanie metody val z jquery. Nie powinno też być problemów z bindingiem knockoutowym.

5 odpowiedzi do “Nieoczekiwane zachowanie przeglądarek – wszystkich”

  1. Pytanie. A czy jeśli zablokujesz sobie kartę SIM u operatora, to chciałbyś aby nadal można było z niej wysyłać smsy? Myślę, że ta sama zasada panuje tutaj. Jeśli blokujesz pole tekstowe, znaczy, że nie chcesz zawartości tego pola wysłać na serwer. A możesz ustawić pole na readonly i cssem sprawić by było szare tj zablokowane. 🙂

  2. Blokada jest tylko interfejsowa nie sądziłem że wpływa także na transfer danych, dlatego przyczyny błędu szukałem w WebFormsach/logice po stronie serwera, straciłem na to wiele godzin mam nadzieję, że tym postem komuś kilka godzin oszczędzę

Możliwość komentowania jest wyłączona.