Podpowiedź
W rozwiązaniu opartym o SAX pomocne mogą być ćwiczenia 14. W przykładzie Transformer3 mamy połączone ze sobą: parser SAX, filtr SAX, Transformer – tak samo może wyglądać struktura rozwiązania. Trzeba tylko dodać walidację w parserze (jak w SAXValidateSchema), napisać własny filtr zmieniający cennik, no i oczywiście na początku wczytywać listę rabatów.
Należy walidować dokumenty wejściowe, ale do tego potrzebne są pliki ze schematami. Czy te pliki mają być na stałe umieszczone w programie?
Proszę zdefiniować stałe ze ścieżkami do schematów, ja sobie je zmienię podczas testowania.
Jak ktoś woli, może ścieżki i inne stałe podać w pliku properties.
Czy w rozwiązaniu zadania można wczytać do pamięci całą zawartość pliku z rabatami? Chciałbym umieścić wszystkie rabaty w tablicy haszującej, a potem przechodzić SAXem cennik i wstawiać/modyfikować odpowiednie wartości.
Tak, to bardzo dobre rozwiązanie.
Procent może być w zakresie [0, 100] (domkniętym obustronnie). Czy nie byłoby wskazane ustawić ten zakres na [0, 100) lub nawet (0, 100)? Przy rabacie 100 % cena musiałaby wynosić 0, a to jest niezgodne z XSD. Dodatkowo, jeśli stary rabat wynosiłby 100, nie można by policzyć nowej ceny.
Zgadzam się z tą uwagą. Dlatego zmieniam schemat: w pliku cennik_wspolne.xsd, linii 19
maxExclusive zamiast maxInclusive.
Ograniczenie dokumentów wejściowych nie powinno wpłynąć na poprawność już napisanych programów, a w dokumentach wyjściowych rabat 100% nie powinien się pojawiać „znikąd”.
Rabat zerowy zostawiam, nie jest to aż taki problem.
Czy wpis <rabat>0<rabat> jest wskazany, skoro uznaliśmy, że brak wpisu = rabat 0 %? To już nie jest tak problematyczne, ale chyba pozostawia pewną dowolność.
Akceptowane będą oba rozwiązania (z wpisywanym rabatem 0 i bez). Także z niektórymi wpisywanymi a niektórymi nie :)
W zadaniu jest uwaga o tym, że element opis może zawierać w sobie inne elementy opis. Po próbie zwalidowania takiego dokumentu pod Javą otrzymałem błąd:
ERROR: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'opis'.
Nie za bardzo wiedziałem, co z tym zrobić.
Pewnie brakuje prefiksu przestrzeni nazw, ale mamy też znowu błąd w schemacie :( Schemat powinien dopuszczać dowolną zawartość elementu <opis> i nie kontrolować już tej zawartości.
Dlatego wprowadzam kolejną poprawkę: w wierszu 43 dodaję processContents="skip".
Uzupełniłem też przykład cennika o ilustrację złożonej zawartości w opisie.
Czy efektywność rozwiązania ma znaczenie? Czy można dla każdego towaru liniowo przeglądać listę (bądź drzewo DOM) rabatów?
Efektywność może mieć wpływ na ocenę, powiedzmy że do 2 punktów. Ile odejmę konkretnie za takie rozwiązanie to się okaże jak zobaczę więcej rozwiązań, ale sądzę że 1,0 - 1,5 punktu.
Wyszukiwanie rabatu w drzewie DOM albo na liście wczytanych rabatów jest mniej efektywne niż skorzystanie ze słownika (HashMap albo TreeMap).
Myślę, że znajdowanie rabatu w słowniku jest nawet programistycznie prostsze niż szukanie w drzewie DOM czy przeglądanie listy.