Formularz wprowadzania uczniów miał formę tabelki: 4 kolumny i 36 wierszy, każdy dla pojedynczego ucznia. W pierwszej kolumnie imiona, potem nazwiska itd. Aby było łatwiej przepuścić to przez opfValidator, wszystkie imiona zgrupowałem w tablicę, skorzystałem ze zbiornika opfArrayContainer i zrobiłem to samo z następnymi kolumnami. Pojawił się jednak problem. OPF zamiast przekazać sterowanie do DAO, odświeżył formularz i zgłosił problem Pole nie jest tablicą. Co więcej, od 27 ucznia lista była pusta, choć wpisałem 35 nazwisk, a system powinien odświeżyć wszystkie dane. Dalszy rzut oka wykluczył udział kosmitów oraz samego OPF w tym niecnym procederze; wszystkie poszlaki wskazywały na PHP jako głównego winowajcę. W $_POST na samym początku skryptu dane były ucięte, tymczasem $HTTP_RAW_POST_DATA zgłaszał obecność wszystkich pól. Ostatecznie zawinił twórca paczki dla Arch Linuksa, bowiem aktualizacja usunęła ten tajemniczy limit, jednak to nie wszystko.

Okazało się, że OPF wciąż wymaga dopracowania, jeśli chodzi o bardziej skomplikowane ustawienia:

1. Normalnie w OPF przyjęta jest zasada, że definicja jednego pola w opfValidator odpowiada jednemu komponentowi, zaś zbiornik opfArrayContainer służy do jeżdżenia po np. liście checkboksów, gdzie naraz możemy wybrać kilka wartości. Tutaj Do jednej reguły przypisałem aż 36 komponentów, co spowodowało, że domyślnie biblioteka wymagała podania danych dokładnie 36 uczniów, zaś mechanizm zgłaszania błędów przestał działać. Na razie ominąłem to prowizorycznie, dokładając flagę ignorowania błędów w Array Containerze.
2. Brak możliwości stworzenia połączenia w rodzaju: jeśli podane zostało 30 imion, dokładnie tyle samo pól musi być wypełnionych w kolumnie nazwisk.

Niedociągnięcia mogą wynikać z próby wykorzystania elementów OPF niezgodnie z założeniami, organizując dane w formie kolumn, a nie wierszy. Jednak drugie wyjście również nie ma na razie zbyt dobrego wsparcia; po pierwsze, trzeba nadefiniować okropnie dużo reguł, a po drugie tak głębokie zagnieżdżanie nie jest wspierane.

Wniosek jest jeden: przy bardziej ekstrawaganckich wymaganiach OPF może napsuć nieco krwi i trzeba to wyeliminować. Ponadto uporządkowania wymaga kod komponentów, który wyszedł dość śmietnikowo, przynajmniej w porównaniu z całą resztą. Na odwieczne pytanie: "kiedy", odpowiedź jest jedna; jeśli Destroyer się nie zgłosi szybko do poprawiania eksperymentalnego kodu JS, to usunę tę część z biblioteki i będzie spokój, bo w zasadzie tylko ona hamuje cały cykl wydawniczy. Bez niej zapewne byłyby już release candidate'y lub nawet jakaś finalna.

Powrót

Na Zyxist.com panuje swoboda wyrażania opinii oraz krytyki pod dowolnym adresem. Jedyny warunek: musi być ona kulturalna i rzeczowa. Na chamstwo, prostactwo lub jawne obrażanie kogokolwiek nie ma tu miejsca i takie komentarze są bardzo szybko usuwane. Jeśli zamierzasz polemizować z treścią wpisu, wpierw uważnie ją przeczytaj.