Czy można stworzyć formularz w jsp korzystający z enum do edycji?

Chciałbym się dowiedzieć, czy można jakoś ładnie zrobić input selecta w JSP, który pobierze dane z ENUM'a?

Zrobiłem coś takiego:

<c:set var="enumValues" value="<%=Accessory.AccessoryType.values()%>"/>

    <form:select path="accessoryType" cssClass="form-control" cssErrorClass="form-control is-invalid" required="true">
        <c:forEach items="${enumValues}" var="item" varStatus="s">
            <option value="${item}">${item}</option>
        </c:forEach>
    </form:select>

Mam problem z tym, jak w przypadku edycji przypisać wartość dotychczasową. Kontroler dobrze podaje, bo testując na zwykłym inpucie jest ok. Jestem w stanie jakąś heretyczną petle for each zrobić, aby to działało, ale nie będzie to ładne rozwiązanie i przede wszystkim szybkie na przyszłość. Zna ktoś fajny sposób jak to zrobić?

Niech zgadnę - na froncie edytujesz jakaś encje? Zrob model pośredni bez enuma, a najlepiej zrezygnuj z JSP :)

Zrezygnuje z JSP w nastepnym projekcie. To jest taki pierwszy konkretniejszy w springu.

Ale jak zrobić model pośredni aby był kompatybilny potem z enumem i dawał mi więcej niż mam teraz?
Jak mam coś takiego :

    public enum AccessoryType{
        komfort,
        stylizacja,
        multimedia
    }

to mam zrobić coś takiego?

class AccesoryTyp{

long id;
sting name;
}

Myślałem po prostu zrezygnować ze wszystkich enumów w projekcie, zrobić normalne tabele w bazie i po problemie, ale logicznie na to patrząc nie ma sensu robić nowych tabel dla paru elementów no i jak to rezygnować :D

Na obecną chwilę to jest totalny dramat :) zacznij od jakiegoś tutoriala albo książki. Możesz też zapoznać się z https://github.com/spring-projects/spring-petclinic żeby złapać jakikolwiek start. Na obecną chwilę strasznie błądzisz, powinieneś nadrobić podstawy.

To prawda, ale to mi nie pomaga. Gdybym znał te podstawy na pewno bym tu o takie bzdety nie pisał :D
Wrzucę może tu swój projekt i ocenisz jeśli będziesz miał parę minut. Nie wydaje mi się, że jest tak źle. Bo wszystko mi się fajnie pisze, mam tylko problem z enumami, bo nie miałem z nimi styczności w MVC.
https://drive.google.com/open?id=1qQCzSzI9RrG6eCsAwa4S16oiLc3DBqO7

Rozwiązałem ten problem, stosując coś takiego:

        <c:forEach items="${enumValues}" var="item">
            <option value="${item}" <c:if test="${accessory.accessoryType == item}">selected</c:if> >${item}</option>
        </c:forEach>

Tylko o to chodziło.

Jak działa, to nie mam nic do dodania. Fajnie, że sobie poradziłeś.

Jak miałbyś chwilkę proszę zerknij ten projekt i oceń czy taka wiedza ma szansę na pierwszą pracę w IT.

https://drive.google.com/open?id=1-CEnu9QMkmabdG61b6VH_nemNGa3-6ly

Nie jestem w stanie ocenić Twojej wiedzy, ani potencjału na podstawie tego kodu. To co rzuca się w oczy, to:

1. Totalny brak testów
2. Brak konwencji nazewniczej i formatowania kodu
3. Dziwne komentarze w kodzie
4. Niepotrzebne interfejsy i klasy *Impl

Ja mam jedną uwagę - wrzucanie kodu na google drive. To bardzo odrzuca od chęci zobaczenia co tam jest.
wrzuć w github czy jakiekolwiek inne publiczne repo.

Charles_Ray napisał(a):

Nie jestem w stanie ocenić Twojej wiedzy, ani potencjału na podstawie tego kodu. To co rzuca się w oczy, to:

1. Totalny brak testów
2. Brak konwencji nazewniczej i formatowania kodu
3. Dziwne komentarze w kodzie
4. Niepotrzebne interfejsy i klasy *Impl

TBo projekt nie jest skończony.
To Serwisów nie robi się na zasadzie INTERFEJS - IMPLEMENTACJA?
Formatowanie / komentarze to raczej kwestia wyrobienia swojego stylu.

Co do gita, spoko, myślałem o tym jak wstawiałem link. Chciałem tylko orientacyjnie zapytać, czy napisanie takiego projektu pozwala mi myśleć o pierwszej pracy, czy muszę zrobić jeszcze jeden lepszy projekt w którym zamienię jsp na coś nowszego?

Najważniejszą radą z tego tematu jest to, żebyś porzucił JSP. Nadal w to brniesz z myślą, że da Ci to pierwszą pracę. Jak zastosujesz się do rad @Charles_Ray to może i znajdziesz, w jakimś legacy projekcie. I każdego dnia będziesz się zastanawiać dlaczego wybrałeś JSP.

Z tym formatowaniem chodziło o to, żebyś trzymał się jednego stylu (najlepiej prawidłowego ;)). W necie jest dużo artykułów o konwencji pisania / formatowania kodu w javie, poczytaj i zastosuj się.

Nie dostaniesz pracy po jednym projekcie (z JSP), a na pewno nie po takim, gdzie kod źródłowy trzymasz poza systemem kontroli wersji (GIT).

zrealowanydawidos napisał(a):

To Serwisów nie robi się na zasadzie INTERFEJS - IMPLEMENTACJA?

A po co Ci ten interfejs? Jaką on wnosi wartość dodaną? A może tylko zaciemnia kod?

Był czas że w Javie do wszystkiego robiło się interfejs, czy to miało sens czy nie miało sensu. Podobno na zachodzie ludzie zwalniali się z firm, bo się przeciwko temu buntowali. Spotkałem nawet szalonego programistę, który starał się mnie przekonać, że DTO też powinny mieć interfejsy. To był zły czas.
Na szczęście przyszło otrzeźwienie i teraz mówi się, że interfejsy powinno się tworzyć tylko do tego co będzie miało kilka implementacji. Najprostszym przykładem takiej klasy może być DAO/Repozytorium. Mamy jedną implementację produkcyjną i do testów integracyjnych a drugą implementację (np na HashMapie) do testów jednostkowych

kixe52 napisał(a):

Najważniejszą radą z tego tematu jest to, żebyś porzucił JSP. Nadal w to brniesz z myślą, że da Ci to pierwszą pracę. Jak zastosujesz się do rad @Charles_Ray to może i znajdziesz, w jakimś legacy projekcie. I każdego dnia będziesz się zastanawiać dlaczego wybrałeś JSP.

Z tym formatowaniem chodziło o to, żebyś trzymał się jednego stylu (najlepiej prawidłowego ;)). W necie jest dużo artykułów o konwencji pisania / formatowania kodu w javie, poczytaj i zastosuj się.

Nie dostaniesz pracy po jednym projekcie (z JSP), a na pewno nie po takim, gdzie kod źródłowy trzymasz poza systemem kontroli wersji (GIT).

JSP użyłem, bo miałem akurat możliwość skorzystania z pomocy właśnie w JSP i wiem, że następny projekt leci w czymś innym, Thymleaf do spring boota?
Do tej pory myślałem, że tak się powinno robić z Servisami (interfejsy i implementacja). Wcale nie jest to coś przyjemnego, bo kod jest klepany w sumie na darmo, traci się czas na te interfejsy, nie problem je usunąć :)

Git to nie problem. Przejrze ten projekt od Charlesa

Nie jestem zwolennikiem thymleaf'a ale lepsze to niż JSP. Najlepiej to żebyś zrobił tak jak się robi obecnie. Na spring boocie stawiasz swoje API RESTowe, a oddzielnie robisz front. Jakiś angular czy coś, z poziomu którego wysyłasz requesty na swoje API RESTowe.

kixe52 napisał(a):

Nie jestem zwolennikiem thymleaf'a ale lepsze to niż JSP. Najlepiej to żebyś zrobił tak jak się robi obecnie. Na spring boocie stawiasz swoje API RESTowe, a oddzielnie robisz front. Jakiś angular czy coś, z poziomu którego wysyłasz requesty na swoje API RESTowe.

Dzieki tak zrobię, trzeba wykonać ten duży krok a później już będzie tak jak trzeba :)

Możesz mi coś polecić, aby to wszystko na początek zrozumieć schematycznie?

Zrób prostego CRUDa. Na froncie zacznij od prostego wyświetlania danych z bazy. Jakieś brzydkie tabelki itp. Potem to krok po kroku ulepszaj. Edycja tych danych, buttony z usuwaniem itp.
A na koniec, żeby się tym gdzieś pochwalić popraw to od strony wizualnej.

Z czasem myśl o jakichś nowych funkcjonalnościach, co można jeszcze dodać itp.

Gdy coś już w swoim kodzie będziesz miał napisane, załóż temat w Oceny i Recenzje.
A no i przede wszystkim, zacznij używać GITa.

No przyznam, ze jestem trochę nieogarnięty z tym gitem, więcej on mi problemów przysparzał niż pomagał jak do tej pory, muszę go ogarnąć na 100% :D

Do tej pory myślałem, że tak się powinno robić z Servisami (interfejsy i implementacja). Wcale nie jest to coś przyjemnego, bo kod jest klepany w sumie na darmo, traci się czas na te interfejsy, nie problem je usunąć :)

Polecam też popracować nad mindsetem. Jeśli przyjąłeś klepanie na darmo za dobrą monetę, to nie wróży to dobrze na przyszłość. Zawsze zastanawiaj się w jakim celu coś robisz i co to daje.