witam!
wkrótce prawdopodobnie dostane możliwość pracy nad systemem CRM dla pewnej firmy.
Technologia jaką wybiore to prawdopodobnie Java + Hibernate (chociaż biorę pod uwagę jeszcze C).
Moje pytanie dotyczy kwestii GUI. Czy pozostać przy Swingu czy jest to juz raczej przestażełe rozwiązanie i skupić się na obsłudze programu przez przeglądrki?
Wszyscy odchodzą od koncepcji grubego klienta na rzecz klientów webowych ;) Ale pytanie brzmi czy znasz się na technologiach webowych?
Mechanizmach webowych czyli czym?
Przepraszam ale jak ty chcesz pisać jakiś CRM w takim razie? o_O Ty w ogóle wiesz jak się pisze program który byłby "obsługiwany przez przeglądarki"? Bo to nie są rzeczy które można ogarnąć w 2 godziny popijając herbatę...
Nie gorączkuj się tak.
Tylko pytam.
Znam się na pisaniu aplikacji w SWINGu i uzywam do tego hibernate. Wydawalo mi sie, ze nie bedzie wielkim problemem nauczyc sie tegoo tak, zeby dzialalo jako storna internetowa. Jesli cos pomylilem to przepraszam.
Skoro znasz Swinga to polecam naukę frameworków komponentowych, jak np Apache Wicket czy GWT. GWT działa na zasadzie tłumaczenia kodu Javowego do kodu JavaScriptowego, a więc urządzenia nieprzystosowane do JavaScriptu nie będą w ogóle obsługiwać (np wyszukiwarki/ indeksery webowe typu wyszukiwarka Google nie zaindeksują strony). Przy intranecie to raczej nie jest problem (a nawet zaleta), a przy portalach ogólnodostępnych jest to wada.
Apache Wicket, podobnie jak GWT, jest wzorowany na Swingu, ale tutaj nie ma magii z tłumaczeniem do JavaScriptu, pisze się prawie czysty HTML i oprogramowuje to w Javie po stronie serwera, w sposób dość podobny do Swinga, czyli dziedziczenie komponentów, listenery, walidatory, renderery, itp A o ile nie będziesz zbyt intensywnie używał AJAXa (tzn jeśli nawigacja nie będzie wymagać włączonego JavaScriptu) to nie będzie raczej problemów z zaindeksowaniem strony.
@Wibowit:
W aplikacji webowej można zjeść ciastko i mieć ciastko, tyle że będzie to kosztowniejsze i będzie wymagało zatrudnienia lepszych i/lub bardziej wyspecjalizowanych koderów.
Są techniki programowania front-endowego, tj. kodu po stronie klienta, które pozwalają na swobodne użycie Ajaxa, ale bez poświęcania dostępności (np. dla robotów wyszukiwarek). Nie jest to nic nowego; w książce "Kuloodporny Ajax", wydanej na początku 2008 roku, Jeremy Keith opisuje technikę zwaną Hijax. Prosty back-end implementuje tam w PHP, ale język po stronie serwera nie ma znaczenia.
W Hijaxie stronę pisze się tak, żeby działała nawet bez JavaScriptu po stronie klienta. JavaScript, napisany zgodnie z zasadą unobtrusive JavaScript, przygotowany ręcznie i w całości umieszczony w zewnętrznych plikach, skanuje się drzewo dokumentu (DOM) i rozszerza je wedle własnego uznania o dodatkowe dynamiczne elementy i zachowanie. W tym o możliwość wysłania żądań ajaxowych.
Back-end musi być napisany mocno modułowo. Np. konkretna podstrona może się składać z drzewa komponentów. Normalne linki do podstron prowadzą zawsze do korzenia. Gdy wysyłasz GET do korzenia, dostajesz pełny dokument HTML ze wszystkimi podkomponentami. Ale możesz żądać też konkretnego komponentu -- wtedy serwer generuje i zwraca tylko kodem tego komponentu. Takie żądania wysyła właśnie JavaScript.
Opcjonalnie, zawsze można rozpoznawać żądania ajaxowe po tym, że mają parametr ajax=true, który sugeruje, by nie odpowiadać pełnym dokumentem HTML, a jedynie jego fragmentem (lub JSON-em -- możliwych rozwiązań jest wiele).
Przeglądając DOM, JavaScript może pobrać atrybuty href z linków, które bez JavaScriptu są normalnymi, działającymi linkami. JavaScript podpina się pod zdarzenia click, dodaje ew. jakieś rzeczy typu WAI-ARIA (np. role=button) i przerabia zachowanie linków tak, by kliknięcie powodowało czy to wykonanie akcji po stronie samej przeglądarki, czy to wysłanie żądania ajaxowego na serwer.
W takim podejściu jednak JavaScript jest raczej pisany z palca (choć może i są do tego jakieś frameworki -- nie wiem na ile skuteczne). I tutaj, gdy zabiera się do tego Javowiec nie znający JavaScriptu, najprawdopodobniej się osra na różowo i jeszcze wku...rzy, bo JavaScript z Javą ma tyle wspólnego, co kotara z kotem. Choć twórcy JS-a próbowali udawać, że jest inaczej (nie wyszło im). Dlatego przeważnie do takich projektów zatrudnia się również dedykowanych JavaScriptowców.
Jak powiedziałeś: w intranecie można przeważnie olać takie podejście i po prostu wymagać po chamsku obsługi JS-a.
@bswierczynski:
Apache Wicket ma to w zasadzie za darmo: http://wicket.apache.org/apidocs/1.5/org/apache/wicket/ajax/markup/html/AjaxFallbackLink.html
Natomiast w GWT zrobienie takiego triku o którym piszesz jest generalnie niemożliwe (choć nie jestem espertem od GWT, ani nie śledzę mocno tematu, to jednak czuję, że robienie strony indeksowalnej w GWT co najmniej mija się z celem).
humanista zna Swinga, a Swing jest toolkitem komponentowym (tyle że na desktop), więc nie widzę problemu w przystosowaniu się do innych komponentowych frameworków.
Wow, dziękuję bardzo!
Już czytam o Apache Wicket.
To co napisałeś o fallBackLink nie jest poprawne w przypadku indexowania. Znaczy robot google to zaindeksuje ale uwierz - nie chcesz żeby to robił (to tak jakby zaindeksować link wraz sidem).
Cały myk polega na Stateless/Statefull page. Dodawanie Wszystkiego co rozszerza Link nie nadaje się do indeksowania i nie powinno się znajdować na stronie która się indeksuje - taka strona ląduje w PageMap, PageMap rezyduje w sesji - stąd adres do tej strony jest "SessionSpecyfic" - znaczy adres jaki jest generowany dla takich linków odnosi się do bytu w sesji (http://domain.pl/?wicket:interface=:0:kokos::ILinkListener::). Wtedy w góglu pojawi się od cholery linków które po kliknięciu sypią błędem "Session expired".
Kwestia adresów "zwrotnych" - jeżeli coś ma być poprawne dla seo/botów - to tylko BookmarkablePageLink a strona powinna być stateless. To owszem działa po wyłączeniu js(fallbacklink), ale nie jest poprawne do indexowania. Znaczy da sie przeciążyć getUrl ale to wtedy sens używania tej klasy stoi pod znakiem zapytania:D
Ta cała magia Wicketa jest zajebista jak się pisze "aplikację web" gdzie po zalogowaniu robię cuda niewidy, pisanie czegoś a'la strona www z użyciem Wicketa i jego magią z Dereferred Session Creation, StatefullPage, StatelessPage jest dość upierdliwe - owszem da się - ale wtedy główna zalety wicketa się nieco rozmywają.
Jest dodatek o nazwie jolira czy jorila czy jakoś tak, który jakoś tam ułatwia życie w powyższej sytuacji, ale nigdy tego zgłębiałem.
Czegoś tu nie kapuję:
-jeżeli będziesz pisał CRMa dla jakiejś firmy, to ta firma pewnie zadecyduje, czy chce go przez przeglądarkę, czy też desktopowo
-jakie znaczenie mają w tym przypadku roboty google? CRMy zwykle działają w intranecie, a tam nie mają dostępu roboty.