Java Fórum 2.0

eppen 404 :-( de figyelek ezerrel

Néha csinálok undeploy - deploy műveletet, éppen kifogtad talán... :)

A doc.javakocsma.hu direkt nem letezik?

Igen, ez még nincs meg, mint domain, illetve JavaDoc sincs még... :)

Majd érkezik szépen.

Nincs még felhasználókezelés, de vannak már portletek, amelyek működnek is... :)

Nos, örömmel jelentem be, hogy elkészült a Java Forum 2.0 JSR-168 kompatibilis portál rendszer váza. Sokminden nincs még implementálva, de a portletek a specifikációnak megfelelően működnek (kicsit eltértem a portlet szabványtól, de erről majd a cikkek között bővebben).

A lényeg, hogy hamarosan elkezdem megtervezni az egyes portletek működését és viselkedését (hírek, fórum, *tár, stb). Ehhez szeretnék némi segítséget kérni, a (Java Forum 2.0 prototípus) http://www.javakocsma.hu oldalon a legalsó portlet erre szolgál, de ebbe a témakörbe is nyugodtan lehet írni a kívánsághalmazt.

Tehát: mit kíván a nép? :)

Ez nagyon oromteli:) igy szerintem akinek idelye kedve van egy-egy alltala igenyelt/hianyolt funkciot konnyeben meg tud irni es az gond nelkul hasznalhato lesz remelhetoleg...

Arra vigyázzatok, hogy nem "thread safe", vagyis az utolsó mentés a győztes... :)

Pár megvitatandó kérdés... :)

AJAX

Gondolkodom azon, hogy legyen-e a portál oldalon AJAX a portletek kezelésénél. Alapvetően JS nélküli működést is szeretnék, de ha van JS, akkor a portletek állapotát (normal, maximized, minimized, view, edit, help, admin) lehetne JS hívással lekezelni teljes oldalletöltés nélkül, pusztán a portlet belső (fragment) újratöltésével.

A portletek belső működésénél nem akarok túl sok JavaScript működést, de a validálásnál jó szolgálatot tesz, illetve a normál oldal-újratöltés mellett szeretnék AJAX tartalommentést és tartalomújratöltést, (automatikus) tartalomfrissítést.

Azonosítás

Alapvetően valami szabványosnak kinéző dolgot szeretnék, mint például az OpenSSO és/vagy OpenID; megtartva a portálon való regisztáció lehetőségét is, hiszen mindenképpen kell bejegyzés az adatbázisba és a jogkezeléshez is szükséges.

Testreszabás

Megoldható - elvileg, hogy minden felhasználó kap egy privát szegmenst, ahova rá tudja húzni a portál publikus oldaláról a portleteket, illetve tud saját portleteket is definiálni. Van-e erre egyátalán igény? :)

Egyéb ötletek

Most van lehetőség a rendszer alapvető működésével kapcsolatos hozzászólásokra:

• Esemény naptár (ezt (K) bevállalta)
• Hozzászólások utólagos szerkesztése (fórum, stb)
• FCKeditor helyett TinyMCEditor
• Fórum témákhoz-témakörökhöz önkéntes "Guruk" rendelése, aki (email) értesítést kap az új üzenetekről
• CKFinder plugin FCKeditor-hoz
• Kereshető CV gyűjtemény
• Java projekt inkubátor (SVN repó, projekt-manager felület)
• Keresés (nem google! :)
• Java fejlesztői Instant Messanger (portletként beépülve)
  
• Email integráció (IMAP4 és POP3 monitor) portlet
• Szavazás (most már tényleg! :)
• Webáruház (java fórum póló, börge)

Nos, az AJAX első része elkészült, a portlet fragmentek újra tudnak töltődni a háttérben. Amit tud a portál:

• A view, edit, help, normal és minimize módokat implementálja teljes portál újratöltés nélkül
• JavaScript nélkül is működik ugyan az a link, csak oldalújratöltéssel

Amit még implementálni kell a kényelmes működéshez:

• A portlet ablak maximized módját (de ez nehézkes lesz oldalújratöltés nélkül, bár lehet tenni a layout temaplate-be egy alapból rejtett maximized részt)
• AJAX letöltés esetén a portál oldal összes renderelt linkjét át kell írni (bár azok is JS-el mennek, minek?)
• AJAX letöltés esetén a böngész címsorát átírni (lehetséges ez?)
• Form küldése is AJAX kommunikációval menjen, majd siker esetén töltse csak be a view módot, sikertelen esetben maradjon az edit mód
• Minden link és tartalom működjön JavaScript nélkül (keresőbarát oldal!)
• Validáló scriptek, amelyek jelzik a beviteli mezők szerepét és hibás tartalmát
• Időzített tartalom-újratöltés
• Saját JavaScript lib készítése a fentiekre, mivel nem nagyon akarunk több JS funkciót a portálon

Egyéb ötlet?

Jah, a http://www.javakocsma.hu portálon megtekinthető az eddigi munka. Mivel szeretnélek Titeket - mint közösséget és elsődleges felhasználókat - bevonni a tesztelésbe és munkába, örömmel töltene el, ha véleményt mondanátok, hogy jó irányba viszem-e a portál felépítését... :)

Javaslat:
- Ha mod van ra, csokkenteni kene a html mennyiseget, amit a motor kibocsajt. Ugyancsak ki kene dobalni a tablazatokat a htmlbol.
- A fix javascripteket rakd ki kulon fileba, nem kell, h feleslegesen szennyezzek a htmlt. Egyebkent milyen megfontolasbol irtad meg magad a XHR letrehozo fuggvenyt? Annyi kesz tortenet van mar.
- Ha lehetne egy alternativ beviteli mod a forum postoknal jo lenne. Opera userkent eleg macera kezzel irogatni a html kodot, raadasul nem is biztonsagos. Raadasul, ha elirom a html tageket, akkor szetzuhanhat az oldal. Esetleg alternativakent egy minimalista wiki parser?

A HTML mennyiség az design függő, de majd alakítunk rajta, ha lehet. (izll?)

A JavaScriptek külön lesznek, persze, de ez még egy igen kezdetleges dolog... :)

Sajnos az FCKeditor nem megy Opera-val, de majd gyúrunk még rajta, hátha menni fog.

Sajnos az FCKeditor nem megy Opera-val, de majd gyúrunk még rajta, hátha menni fog.
Mi lenne, ha a felhasznalo megadhatna, hogy milyen inputot akar hasznalni? Ugyis csak regisztralt felhasznalo postolhat, konnyen el lehetne donteni, hogy a felhasznalotol html, vagy wiki, vagy bbcode, vagy valami egyeb tartalom jon, es azt megfeleloen lehet kezelni.

Idéznék tvik-nek írt levelemből, mivel ő még régebben magánban érdeklődött a javakocsma projekt iránt:
Nos, alapvetően a javakocsma.hu egy lazább szerkezetű, de Java kötődésű portál lesz, ahova egyfajta iwiw szerű funkciókat is szeretnék tenni, illetve (akár kliens programmal) egy ICQ szerű dolgot is (ahol a portálon jelölt ismerősökkel lehet információkat cserélni). Nem tudom, mennyire fog beválni, a terveim ezek... :)
A javakocsma.hu lesz a Java Forum 2.0 első projektje, de záros határidőn belül szeretném átvinni alá a javaforum.hu portált is. Ez egyben példaprojekt is lesz, illetve egy teljesen elejétől a végégig cikkekkel dokumentált és verziókövetett JavaEE 5 példaprojekt, amiből - remélem - sokat lehet tanulni. :) A záros határidőt kb. 2 hónapra becsülöm, november elejére már szeretnék egy olyan portált,
amely működik, és november végére át szeretném tenni rá a javaforum.hu portált is a jelenlegi - fizetős - rendszerről. Az admin felület lesz a nehezebb, erre több időt és tervezést kell szánnom, de ezt majd később ütemezem... :)
Elvileg minden meglévő linket kezelni fog az új rendszer, minden tartalmat átvezetek, erre egy filter fog szolgálni, amely Location az új URL felé irányítja a böngészőt.
A licenc kérdése még lebeg, elvileg CC-GPLv2 alatt szeretném kiadni.

Kezd eléggé nagyon körvonalazódni a Java Forum 2.0 portál, mint portál rendszer, de még messze nincs minden funkció kitalálva a javaforum.hu portálon, mint tartalom, és tartalomkezelés. Mivel ez egy nyílt forrású rendszer lenne, akinek kedve, ideje vagy lelkesedése van: adok SVN hozzáférést és direktben írhat a forrásba. :)

http://mail.javakocsma.hu/mailman/listinfo/javaforum-dev-hu

No, fenn van az SNV repóban (http://svn.javakocsma.hu/javaforum2.0/) az aktuális állapot

Elnézést, ha nem jó helyre írnék. A fősulin Java-t tanulunk, amit szeretnék otthon gyakorolni.

De a szokásos, 'Hello World' programon kívül nem futtat a böngésző mást (Explorer/Mozilla sem).

Applet név notinited jelenik meg a státuszsorban. A .class-t létrehozza, exit code 0. Scite-ben írom a

programot, ott is fordítom le. Mi lehet a gond? Próbáltam letölteni hozzá cuccokat, de nem jártam sikerrel.

Mi kellene letöltenem hozzá?   

Jó helyen, csak nem ebbe a témakörbe kellene... :)

A kedv és a lelkesedés adott, idő meg majd lesz valamikor.

Még arról kéne valami infó, hogy ezt az codebase-t milyen környezetben kell/érdemes buildelni és futtatni. Gondolom hogy Netbeans, de hányas verzió, milyen edition, vagy milyen kiegészítések kellenek hozzá. Aztán mit kell nyomogatni hogy legyártson egy működő verziót és hogyan kell elindítani. Kell hozzá külön DB-t installálni lokális teszteléshez? Szóval ilyen build infók kellenének.

A kedv és a lelkesedés adott, idő meg majd lesz valamikor.

:)

Még arról kéne valami infó, hogy ezt az codebase-t milyen környezetben kell/érdemes buildelni és futtatni.

NetBeans 6.0 Beta1 alatt készült, szerintem megeszi a NetBeans 5.5 és 5.5.1 is. Eclipse is talán tudja importálni.

Aztán mit kell nyomogatni hogy legyártson egy működő verziót és hogyan kell elindítani. Kell hozzá külön DB-t installálni lokális teszteléshez? Szóval ilyen build infók kellenének.

Az adatbázist legyártja maga alá, viszont az adatbázishoz kell némi adat, hogy menjen is rendesen... ezeket majd elkészítem... :)

Milyen részébe gondoltál beszállni?

Milyen részébe gondoltál beszállni?

Nagyjából mindegy, amibe be tudok / be lehet szállni.Gondolom nem úgy lesz hogy boldog boldogtalan mindenfélét bekommitolhat, bár az is biztos egy érdekes projekt lenne. :) Egyelőre buildelni akarom és nézegetni a belsejét, tesztelgetni, de erre csak jövő héten lesz alkalmam legközelebb, legjobb esetben.

Egyelőre nem célom elsietni a projektet... tehát idő van még... :)

Elfelejtettem írni, hogy gondolkodni is kellene segítségképpen... :)

A kérdéseim még mindig élnek, amiket feltettem ebben a témakörben.

Körülnéztem kollaborációs szoftverügyileg, és úgy döntöttem, hogy az egész projektet, ahogy van, átviszem a dev.java.net alá, mivel ott minden megvan ingyen, ami szükséges:

• subversion
• fórum
• levelezőlista
• issue-tracker
• wiki
• dokumentumtár
• hírek
• stb

https://javaforum20.dev.java.net/

Szeretném kicsit felpörgetni az eseményeket, ehhez elsősorban ötletek és javaslatok kellenek... benne vagytok? :)

Benne Gábor! :)

Picit haladtam előre a projektben, került bele XML, ami lehetőséget ad arra, hogy a portlet processAction metódusa és a kliensoldali JS képes legyen együttműködni.

Alapvetően az lenne a cél, hogy legyen valamiféle validálási lehetőség először a kliens oldalon, majd a szerver oldalon is, amely  utóbbi esetben lehetőleg ne töltse újra az egész portlet tartalmát (FCKeditor-t újratölteni lassú lehet), hanem XML-ben adja vissza a hiba helyét és okát.

Milyen "bevált" módszerek vannak erre?

Elso nekifutasban azt javasolnam, hogy xml helyett json-t hasznalj js-java kommunikaciora. Nem kell igy js-el xml-t feldolgozni, hanem direktbe kiertekelheted, es megkapod az adathiearchiat, amit tudsz mar hasznalni. Masik megfontolando, hogy erdemes tiszta html kodot lekuldeni, mert egy innerHTML-es megoldas gyorsabb, mint xmlbol (jsonbol) letrehozni a domfat.

JSON szerintem is jobb mint az xml csak ha sok az adat akkor a kiértékelés esetleg kicsit lassabb lehet mint az xml-el..

Jelenleg a következőképp gondolom a JavaScript hátteret (hangsúlyozva, hogy közel azonos funkcionalitással JavaScript nélküli működést is szeretnék):

• kliens oldali validálás (szerver oldalon generált JavaScript adatok alapján), vagyis a szerveren a portletek processAction részénél - ahol egyébként is validálok - előállítok egy olyan JS programkódot, ami renderelődni fog a portlet tartalmában. Szerver oldali validálás is lesz, vagyis amikor a kliens JavaScript kód engedte a form küldését, akkor a kapott adatokon további validálás is fog történni, amelyről a kliens oldalnak nem lehet információja (illetve megtörténik a kliens validálásával egyező validálás is). Ezek nem JavaScript formában fognak érkezni, hanem a portlet teljes tartalma jön le újra, benne azok a hibaüzenetek, amelyeket a portlet programja hoz létre.
• A kapott XML vagy JSON valahogy így fog kinézni:
  

  <?xml version="1.0" encoding="utf-8" ?>
      <ajax>
      <status>ok</status>
      <content><![CDATA[
      <div style="text-align:left;">
        A belépéshez szükséges az email cím és a jelszó.
        Teszteléshez használható az <b>admin@javakocsma.hu</b> email
        cím és az <b>admin</b> jelszó.
      </div>
      ]]></content>
      </ajax>

  Amint látszik, egy státusz és egy tartalom érkezik mindössze, nem tudom, hogy érdemes-e erre JSON, mert XML-ben teljesen tömör. A működés során megnézem, hogy mi a státusz, és egyszerűen megkapja az innerHTML a tartalmat.
• A küldést úgy csinálom, hogy egy JavaScript végigmegy a portlet form beviteli mezőin, és elküldi azt a szerver felé, amire majd jön egy fenti válasz. Ha nincs JavaScript, akkor simán oldalújratöltéssel jön le a portál tartalma és az aktuális portlet is.
  
• A portletek vezérlése (view, edit, help, normal, min és max) szintén JS kód lesz, ha nincs JS, akkor oldalújratöltéssel működnek.

Egyelőre ennyi, ennek egy része már működik szépen és jól, némelyik része még implementálandó dolog... :)

Biztos hogy kell az a status mezo? Elvegre van a http response-nak kodja.

Nem igazán célom http kódokkal kódolni azt, amit szeretnék... tehát nem csak egy "ok" vagy egy "error" lenne a státusz, hanem ott érkezne, hogy váltson view nézetre az eredménnyel, vagy ilyesmi.

Apropo, a https://javaforum20.dev.java.net/ cimen van valami oka, hogy nem lehet se anonimkent, se regisztralt felhasznalokent megtekinteni az oldalt?

https://javaforum20.dev.java.net/ cimen van valami oka, hogy nem lehet se anonimkent, se regisztralt felhasznalokent megtekinteni az oldalt?

Igen, "pending approval" az állapota, és addig olyan, mintha nem is lenne... nem tudom meddig tart ez az állapot... :)

Jaaa, ertem.

Újabb fikáznivaló... :)

A http://www.javakocsma.hu oldalon a híreket lehet körbeszaglászni, hogy megfel-e az úri közönség kényes ízlésének (akár a hozzáadást is ki lehet próbálni, bár az még nincs kész, de erőforrásnak lehet használni a "/news/java_forum_20_portal_motor/head_image" szöveget, és akkor ez is jó lesz elvileg. Elsősorban az AJAX háttér működése lenne fókuszban, illetve a JavaScript nélküli működés (vagyis JavaScript nélkül oldalújratöltéssel azonos funkciók használata).

Rogton egy aprosag: a min/max mintha fel lenne cserelve

Pontositas az elozohoz: js nelkuli mukodesnel tapasztalhato.

Az uj forumnal esetleg megoldhato a felhasznalo a legutolso hozzaszolasat szerkeszthesse, amig mas nem szolt hozza? Haszon ficsor tudna lenni.

Masik aprosag:
1) minimalizalom az elso hirt
2) maximalizalom az elso hirt
3) rakattintok a helpre
Firebugban az eredmeny:

POST http://www.javakocsma.hu/ajax/javaforum/twoColumnLeftnull/news/56/WindowState/maximized/PortletMode/help/PortletMode/help (206ms)
xmlDoc has no properties
return xmlDoc.getElementsByTagName(tagName)[count].childNodes[0].nodeValue;

Adalek az elozohoz (ugy laccik ma ez igy megy): mind Firefoxban, mint Operaban ez a jelenseg

A maximalizálás és a minimalizálás nem megy még megfelelően (a max-hoz nincs még JS), a min után pedig a normal nem működik jól, de ezt majd megjavítom.

Ezek szerint maga a tartalom jól működik (IE, FF és Opera alatt) és ez egyelőre örömmel tölt el... :)

Szerintetek... a fórum hogy nézzen ki?
Én kétféle nézetet szeretnék:

• Kellene egy mostanihoz hasonló témakör - téma lebontás.
• Kellene egy olyan, ami vegyesen tartalmazza az utolsó témákat lapozhatóan.
  

Látványos lenne némi ikonmagyarázat is (üres boríték - egy hozzászólás a témán belül; boríték - több hozzászólás; halvány boríték - régi hozzászólások; lángoló boríték - friss hozzászólások; stb). Az álláshírdetéseket teljesen külön szeretném szervezni, azok
majd később kerülnek sorra, tehát nem a fórumba lennének integrálva.

És a lényeg, szeretnék valami olyasmit, mint ami például a http://it.news.hu fórumában van, tehát lehessen avatart vagy fotót tenni a hozzászólás mellé, illetve szeretnék bevezetni valamiféle pontrendszert (a'lá http://www.javablackbelt.com/), ami ikonszerűen mutatja a hozzászóló tudását akár a megválaszolt témák számát, pontjait, gyorslinket a CV oldalára, bemutatkozó oldalára, stb-stb.

A fórumban az FCKeditor-t le szeretném cserélni valami sokkal kisebbre, erre jó lenne némi tapasztalatféle, hogy milyen célszerű, mivel a fórumban alapvetően három dolog szokott lenni: szövegkiemelés (bold,italic,underline,strike), linkek illetve nagyon ritkán képek (de a képeket akár el is felejthetjük, szükséges?). Ezen túl néha felsorolás, meg ilyesmi szok lenni. Illetve ami nincs és kellene: forráskód feltöltése vagy inline syntax highlight forráskódra, illetve formázás forráskódra.

Jó ötlet a hozzászólás szerkesztése is, ekkor jelezném valami ikonnal, hogy szerkesztetett, és csak addig szerkeszthető, amíg nem jön a témában újabb hozzászólás.

Mi van még? Ja, RSS. Az RSS-t a fejlécből lehoznám a fórum témák mellé, tehát lehetne kérni egyedi RSS-t témákra vagy témakörökre, és gondolkodom az email értesítésen is (ha valakinek az jobban kézreáll).

Nos, akkor ezen lehet megin' rágódni... :)

Először egy költői kérdés: a fórum egy elég általános dolog. Nem lehet hogy van valami beépíthető, testreszabható fórum portlet amit csak be kéne emelni a portálba? Elvileg ez a lényege a portleteknek. Nem?

Az index fórumon azt szokták lánggal jelezni, amikor sok hozzászólás érkezik egy bizonyos időintervallumon belül. (flame van, vagy parázs vita.) Ez is hasznos feature lehet itt is, bár nem túl fontos. Hasznos lehet még egy embernek megnézni az eddigi hozzászólásait is

Az értékelés / csillagozás mintha már régebben felmerült volna a hátrányaival együtt. Nem minden hozzászólást lehet vagy érdemes értékelni. Bár végülis ki lehet próbálni, aztán majd meglátjuk hogyan működik. A javablackbelt-en kicsit más szerepe van a csillagozásnak, mert az nem fórum. Nekem az a megoldás is tetszik,ami a sun fórumon van, hogy egy kérdés feltevésekor fel lehet ajánlani valamiféle pontokat és aki megválaszolja annak oda lehet adni őket.

A hozzászólások visszamenőleges szerkesztését én nem támogatnám, legfeljebb addig amíg nem jött rá válasz. De inkább addig sem.

Először egy költői kérdés: a fórum egy elég általános dolog. Nem lehet hogy van valami beépíthető, testreszabható fórum portlet amit csak be kéne emelni a portálba? Elvileg ez a lényege a portleteknek. Nem?

Lehet, hogy csak én nyúltam mindig rossz helyre, de a "gyári" és szabványos portleteknek van kettő igen erős hiányossága: az egyik a használt adatforrás és/vagy EJB; a másik pedig a jogkezelés. Most, hogy belemélyedtem a portlet témakörébe, megértettem, hogy miért nem megy egy LifeRay portlet az Exo alatt, és miért nem működik jól egy JBoss portlet a LifeRay alatt. Szabvány ide-vagy-oda, ezek valamilyen szinten el akarnak érni egy adatbázist, és itt jelenleg hatalmas káosz van, és a JSR-286 se old meg semmit ezen a téren... de lehet, hogy csak rosszul látom... :)

Az, hogy JSR-168 kompatibilis portált csinálgatok, attól még nem fog benne menni minden portlet, főleg, ha egy csomó plusz szolgáltatást vár el (mint a LifeRay portletek)... a cél inkább az, hogy az illesztési felület jó része definiált legyen... de igazából saját portleteket gondolok fejleszteni, amelyek nem biztos, hogy menni fognak más portálon belül... de kis módosítással mehetnének. :)

Nem feltétlen célom minden hozzászólást értékelni, de ami sokat segített, az pontozható lenne. Opcionális. A blackbelt oldalt, mint ikon minta gondoltam bemutatni (mert kis helyen elfér egy színes öv és - a regisztáció idejével együtt - jól mutatja az illető tudását).

Portletbol adatbazist elerni? Eleg nagy butasagnak tunik. Nem inkabb csak lookup kene egy ejb-re, aztan annak fuggvenyeit hivogatni? Az adatbazzisal meg jatszon az ejb.

Portletbol adatbazist elerni? Eleg nagy butasagnak tunik. Nem inkabb csak lookup kene egy ejb-re, aztan annak fuggvenyeit hivogatni? Az adatbazzisal meg jatszon az ejb.

Nem gondoltad tovább, csak hátrébb toltad a problémát. A portlethez tartozó szolgáltatás (ami az EJB szerver oldalán van), azt ki írja meg, honnan kapja meg az adatforrást, mi van akkor, ütközik az entitások neve, hogyan "heggeszted" a portlet entitásához a belépett felhasználó adatait, stb, stb? :)

Másrészt mi van akkor, ha a portlet konténer nem EJB környezetben fut? Márpedig nagyon sok konténer nem EJB, csak egy JSP/Servlet konténer kell a futásához... oda hogy teszed be az EJB-s portleted? Vagy viszont, hogy teszed be egy EJB-s portálba a JDBC-s portleted? :)

Ezért mondtam, hogy ez a része nagyon nincs kitalálva és szabvány által megvezetve.

A portlethez tartozó szolgáltatás (ami az EJB szerver oldalán van), azt ki írja meg
Ammenyiben ugy akarsz valamit kiadni a kezeid kozul, hogy az egy portalba beagyazhato legyen, akkor nyilvan megirod a portleteket + az tenyleges logikat. Ha meg nincs hozza irva portlet, akkor a programot berakod egy masik webcontext ala, es egy iframes portlettel be tudod pakolni. Persze ez egy kicsit eros, de azt hiszem, h a portlet speci ezt nem akarta megoldani.

honnan kapja meg az adatforrást
Ugyebar a nagykonyv szerint a szolgaltatasokat, es eroffasokat JNDI ala illik beregisztralni, aztan majd a kliensek onnan kikeresik a maguknak valo bejegyzets. Konkretan nem tudom, h a j2ee descriptoroknal van-e lehetoseg jndi mappingra (jboss valamelyik spec xml-jeben mintha lattam volna), de talan nem olyan nehezkes megirni azt a rutint, ami init parameterbol kibogarassza a jndi nevet.

mi van akkor, ütközik az entitások neve,
Szerintem te is tudod mi van ilyenkor. Suru szitkozodas, es fogaknak csikorgatasa. Ez a jelenseg nem csak j2ee kornyezetben fordul elo. PHP-ban pl bevett szokas, hogy prefixelik a tabla neveket, amit configbol kaparnak elo. Ezt talan itt is meg lehet oldani. Meg aztan be lehet rakni kulon semaba is a draga tablakat.

"heggeszted" a portlet entitásához a belépett felhasználó adatait,
Valamilyen szinten van erre tamogatas a j2ee kornyezetben. Nem ismerem ugyan a security reszt, de az descriptorokban lattam mindenfele security, es role mapping reszeteket, itt talan lehet ilyen magiat alkalmazani (talan nem). Ha esetleg arra gondolsz, hogy kiirni, mi a kedves felhasznalo neve, msn cime, lab merete, stb, stb, talan erezheto, hogy ezek olyan egyedi informaciok, amit nem lehet egy altalanos felulet moge bujatni. Persze meg lehet probalkozni egy altalanos user kezelo keretrendszer kidolgozasaval (ami pontosan leirja, h milyen modon lehet megtudni a fentebb emlitett labmeretet), es annak szabvanyositasaval, mert akkor barki, aki hasznalja ezt a keretrendszert, ezeket az informaciokat ki tudja iratni.

Másrészt mi van akkor, ha a portlet konténer nem EJB környezetben fut? Márpedig nagyon sok konténer nem EJB, csak egy JSP/Servlet konténer kell a futásához... oda hogy teszed be az EJB-s portleted?

Termeszetesen hulyeseget nem akarunk csinalni. Egyebkent van egy olyan allat, hogy Spring framework, aminek van egy marha jopofa bean kontenere, ami beledobalja az adott objektumba a fuggosegeket. Ez sokat tud segiteni egy ilyen probleman.

Vagy viszont, hogy teszed be egy EJB-s portálba a JDBC-s portleted? :)
Siman? Ha be van egetve a jdbc info a portletbe, akkor csak kezet razni tudok a kedves fejlesztovel, ha valami konfigban van a kapcsolodasi info, akkor nem latom a problemat, ha meg jndi-bol veszi ki, akkor meg - ugy hiszem - nincs tul nagy problema.

Ezért mondtam, hogy ez a része nagyon nincs kitalálva és szabvány által megvezetve.
Kicsit talan eroltett voltak valaszok, nem vitatom. Ugy hiszem azert, hogy a Suni a portlet fogalom megalkotasaval nem egy komplett rendszerintegracios megoldast akartak szallitani, hanem csak egy megjelenitesre alkalmas eszkot szerettek volna kesziteni. Ha fentebb felvetett kerdeseket megoldana portlet, akkor mindenki boldog lenne. Van egy php-ban irt crm rendszerunk? Es van mellette egy doson futo szamlazo programunk? Sebaj! Irunk ra ket portletet, es egybol fajdalom nelkul, es tokeletesen megy a ket rendszer kozott az adatcsere.

Ertem a problemakat, amiket felvetettel, de ezek mar inkabb rendszerintegracios kerdesek, es ezt ugyanmar ne egy nyamvadt portlet kontener oldja meg.

Így egyben próbálom leírni, hogy mi a probléma a portletekkel és mi az, ami nem megoldás az általad felsorolt javaslatok között.

Nos, a portlet egy zárt, jól definiált dolog. Önmagában hordozza a megjelenítést, az adminisztrációs felületet, az "üzleti logikát" és a DAO réteget. Viszont nincs definiálva, hogy a DAO az tulajdonképpen mi. Ha végignézed a portlet specifikációt, nem látsz benne olyat, hogy a portlet hol tudja - illetve hol kell - elkérni a portáltól az adatforrást, illetve az sincs benne, hogy a DAO az JDBC, EJB, valami más ORM vagy kis kínaiak vésik kőbe. Egyszerűen definiál egy folyamatot, hogy a portál meg fogja hívni valamikor a portlet render metódusát, illetve a render előtt meghívja az actionProcess metódusát, ahol a portlet kap egy request és egy response példányt. Ennyi. Hogy honnan veszi az adatait, hova írja, mit csinál velük, az a portált nem érdekli. Nincs benne a specifikációban.

Entitás név ütközése nem ilyen egyszerű dolog ugye, mivel hiába más a csomagnév (hu.javaforum.entity.Forum és com.liferay.entity.Forum) a JPA azonos táblanevet fog ebből generálni... a séma pedig ismét érdekes dolog, mivel Oracle esetén a séma nem az a séma, ami MySQL vagy PgSQL esetén. Ha pedig Oracle-ről van szó, figyelembe kell venni, hogy bármilyen entitás neve maximum 30 karakter lehet (táblanév, mezőnév, idegen kulcs név, index név, stb).

A "felhasználók hozzáheggesztése" alatt azt értem, hogy ha JPA van a háttérben, akkor a portlet által létrehozott entitásnak látnia kell a portál által szolgáltatott felhasználókat kezelő entitás osztályát, hogy azt fel tudja használni. Ez igencsak nem fordítási időben fog eldőlni, vagy minden egyes portálhoz hozzá kell fordítani a portletet, amit eladni szándékozol. Vagy a portlet a specifikáció szerint egy felhasználónevet fog látni, mást nem.

A probléma még mindig fennáll, hogy a LifeRay például nem EJB-s portlet konténer, a JBoss pedig igen. Ezek között soha nem lesz olyan, hogy portleteket tudjanak cserélni, mivel teljesen rá van idomítva a portlet a konténerére. Nyílt forrás esetén megvan a lehetőség, hogy kis módosítással mehessen a dolog, de csak úgy hozzádobni nem lehet.

Nemtom, én ezeket a problémákat nem rendszerintegrációs gondnak látom, hanem annak, hogy a portlet specifikáció nem alkalmas arra, hogy egy általam megírt - Hello World programot túlhaladó -  portlet akárhol működhessen mindenféle módosítások nélkül.

Nos, a portlet egy zárt, jól definiált dolog. Önmagában hordozza a megjelenítést, az adminisztrációs felületet, az "üzleti logikát" és a DAO réteget. Viszont nincs definiálva, hogy a DAO az tulajdonképpen mi.
Nos, asszem itt van a lenyegi kulonbseg. En nezetemben a portlet a view retegben helyezkedi el. Osszes felelosege az, hogy a felhasznalotol jovo adatokat ellenorizze (szam-e a szam, nincs-e sql ugyeskedes, minden adat megvan), a megfelelo uzleti folyamatokat elinditsa, es a folyamatok eredmenyet megjelenitse. Az egesz rendszerbol azt a par feluletet latja, amin keresztul komminkal vele (a rendszerrel). Azt se tudja, h mi az a DAO, es nem foglalkozik vele, ha kis kinaik egy tal rizsert vesik a kobe a forum hozzaszolasokat. :) Ha csak a suni altal emlegetett technologiakat nezzuk, akkor nyilvan EJB-t hasznal, de itt is csak az uzleti homlokzatokat. Ezeket az EJB-ket JNDI-n keresztul szerzi meg, es szepen a porlet manualban le van irva, hogy EJB-ket hasznal ilyen, es ilyen neven. Ne feledjuk, hogy a sun szemlelete szerint a Servlet/JSP is EJB-hez nyul, akik majd dolgoznak. Itt is errol van szo. Ugyanugy nem tudsz egy war-t betolni, ha csak Servlet kontenered van.
Kicsit az az erzesem, h a portletrol ugy gondolkodsz, mint egy model 1 Delphi app lenne. Az esemenykezelo fuggvenybe pakolnad bele tokkal-vonoval a teljes funkcionalitast.

Entitás név ütközése nem ilyen egyszerű dolog ugye, mivel hiába más a csomagnév (hu.javaforum.entity.Forum és com.liferay.entity.Forum) a JPA azonos táblanevet fog ebből generálni... Es mi akadalyoz meg abban, hogy egy masik semaba/adatbazisba generald bele az entitasokat? Oke, hogy igy nem fogod tudni az egyik forum tablait osszekapcsolni a masik felhasznalo kezelo tablaival, de ez a kapcsolat amugy se letezhetne, csak ha kezzel megirod a kodot, ami ezt a kapcsolatot kezeli.

A "felhasználók hozzáheggesztése" alatt azt értem, hogy ha JPA van a háttérben, akkor a portlet által létrehozott entitásnak látnia kell a portál által szolgáltatott felhasználókat kezelő entitás osztályát, hogy azt fel tudja használni. Termeszetesen. De ilyen eros kotodesnel ne is vard, h rugalmas lesz a portleted. Ha pl megnezed a servlet specit, mindent besuvaszottak interfacek moge, igy a servletek nem dependelnae ra egyetlen-egy konkret HttpServletRequest megvalositasra. De amint elkezdenem castolni mondjuk a tomcat implementaciojara, levalaszthatatlanul hozzakotnem magam a kontenerhez. Nyilvan nem futnek jetty alatt. Lehet itt is el kene abszrahalni a felhasznalot. Persze a portlet speci (es sehol a j2ee) nem hatarozza meg egzaktul, hogy mi is az a felhasznalo, csak annyira, hogy a jogosultsagok ellenorizhetoek legyenek.

A probléma még mindig fennáll, hogy a LifeRay például nem EJB-s portlet konténer, a JBoss pedig igen. Ezek között soha nem lesz olyan, hogy portleteket tudjanak cserélni, mivel teljesen rá van idomítva a portlet a konténerére. Nyílt forrás esetén megvan a lehetőség, hogy kis módosítással mehessen a dolog, de csak úgy hozzádobni nem lehet. Nyilvan, ha EJB-t hasznalsz, akkor kell egy EJB kontener (hmm, letezik embed EJB kontener?). Ugyanez az analogia megtalalhato a JSP-nel is. Ha nincs JSP kontener, akkor fust a programnak.

A problema itt a fuggosegek feloldasa. Ha a portletem hasznal log4j-t, bsf-et, es velocity-t, akkor nem fog mukodni, ha ezek nincsenek meg. Hiaba van autoja az embernek, ha nincs benzin, nem hasznalhato. Ahhoz, hogy a portleted egy kontenerben hasznalhato legyen, szallitania kell a kontenernek a portleted fuggosegeit is.

Nos, asszem itt van a lenyegi kulonbseg. En nezetemben a portlet a view retegben helyezkedi el.

Az egy dolog, hogy a te nézetedben mi a portlet, amikor a specifikáció szerint nem így van... :)
A portletnek van view komponensre, ezt adja vissza az általad implementált TePortleted.render(renderRequest,renderResponse); van egy control komponense, amelyet a TePortleted.processAction(actionRequest,actionResponse) implementál; és van egy model komponensre, amely teljesen szabadon hever, nincs specifikálva. Viszont szükségszerűen el kell érned valami adatbázist, ami egyátalán nincs benne a specifikációban.

Kicsit az az erzesem, h a portletrol ugy gondolkodsz, mint egy model 1 Delphi app lenne. Az esemenykezelo fuggvenybe pakolnad bele tokkal-vonoval a teljes funkcionalitast.

Olvastad a JSR-168 specifikációt (illetve a JSR-286 specifikációt)? :)
Nekem olyan érzésem van, hogy nem tudod mi is egy portlet... :)

Ahhoz, hogy a portleted egy kontenerben hasznalhato legyen, szallitania kell a kontenernek a portleted fuggosegeit is.

Akkor vissza is értünk oda, ahonnan indultunk: a portlet specifikáció nem tartalmazza, hogy egy portlet milyen módon és milyen adatbázishoz kapcsolódik. Így pedig nem megoldott a portletek hordozhatósága portlet konténerek között. Pont.

Az egy dolog, hogy a te nézetedben mi a portlet, amikor a specifikáció szerint nem így van... :)
En csak annyit lattam a speciben, hogy "...provide a presentation layer to Information Systems.". Ellenben sehol nem lattam olyat, hogy a portletnek at kell lognia a tobbi retegbe. Persze olyat sem, hogy nem kell. Az, hogy en nem akarok a portletre tobb feleloseget raharitani, csak amennyit korabban is irtam (adat ellenorzes, felhasznalo fele prezentalas), jozan paraszti megfontolas. A tapasztalat azt mutatja, hogy jobban karbantarthato, atlathatobb rendszert kapunk, ha szetvalasztjuk a feleloseget, es nem probaljuk meg egy retegbe, egy objektumba belezsufolni (mint azt sokan sajna teszik).

Viszont szükségszerűen el kell érned valami adatbázist, ami egyátalán nincs benne a specifikációban.
Szerintem abban megegyezhetunk, hogy "hivatalosan" jndi-n kereszul szerzi meg a kapcsolatot.

Olvastad a JSR-168 specifikációt (illetve a JSR-286 specifikációt)? :) 168-at igen, 286-ot nem.
Akkor vissza is értünk oda, ahonnan indultunk: a portlet specifikáció nem tartalmazza, hogy egy portlet milyen módon és milyen adatbázishoz kapcsolódik. Így pedig nem megoldott a portletek hordozhatósága portlet konténerek között. Pont. Ugy tudom erre van a JNDI kitalalva.

En csak annyit lattam a speciben, hogy "...provide a presentation layer to Information Systems.". Ellenben sehol nem lattam olyat, hogy a portletnek at kell lognia a tobbi retegbe.

Nos, tehát úgy gondolod, hogy a portlet specifikáció csak megjelenítést, az üzleti logika valahol máshol van? Ezzel az a baj, hogy se a JBoss portál, se a LifeRay portál, se a Sun portál készítői nem e filozófia szerint készítenek portetet. Az általam látott portletek kompakt módon - a specifikáció szerint - mindent tartalmaznak, ami kell a működésükhöz... igaz, hogy csak a saját portálukkal működnek együtt, de akkor is visznek mindent, mind a három (négy réteget).

De beszéljünk konkrétumokról. Ha adnod kellene nekem egy fórum portetet, akkor mit adnál a kezembe?

Velhetoleg egy ear filet, amiben benne lenne warkent a megfelelo portlet(ek) (gondolom warkent kell deployolni), es egy ejb-jar file, amiben benne lenne a forum logika. Ha tudomasom van arrol, hogy ez a forum egy oldal nagyobb oldal resze lesz, es integralhatonak kell lennie, akkor igyekeznek arra figyelni, hogy a megfelelo feluleteken belem tudjanak tolni fuggosegeket.

Nos, akkor kaptam tőled egy ear-t, amiben van ugye egy portlet war és egy EJB jar, megmondtad valahol, hogy mi az adatforrásod neve, beállítom az AS-en, és mindenki boldog. Itt ez a bökkenő, hogy valahol meg tudod mondani, de nincs ennek sehol helye.

A másik probléma az, hogy miképpen is használjak egy LifeRay portetet, ha az így kezdődik:

import com.liferay.portal.kernel.util.Constants;
import com.liferay.portal.kernel.util.ParamUtil;
import com.liferay.util.bridges.jsp.JSPPortlet;
import com.liferay.util.servlet.SessionMessages;
[...]
public class GoogleSearchPortlet extends JSPPortlet {

De ha ezen túllépünk, és megnézünk egy olyan LifeRay portletet, amelyben adatokat tárol adatbázisban, akkor láthatjuk, hogy a portletben van egy connection.properties, amely tárolja az adatforrás adatait, és kutyaközönséges JDBC hívásokkal kezel adatbázist. Ugyanez JBoss portál esetén például teljesen másképp van, tehát hiába tennék én egy JBoss portletet LifeRay portálba, meg se tudna szólalni, mert a LifeRay alapvetően nem EJB portál.

De nézzük például a LifeRay másik portlet példáját, ahol jogosultságot kezel:

<portlet:defineObjects />
<liferay-theme:defineObjects />
<%
long groupId = themeDisplay.getPortletGroupId();
String name = portletDisplay.getRootPortletId();
String primKey = portletDisplay.getResourcePK();
String actionId = "VIEW";
%>
Do you have the VIEW permission for this portlet?
<b>
<c:choose>
        <c:when test="<%= permissionChecker.hasPermission(groupId, name, primKey, actionId) %>">
[...]

Mint látható, teljesen "szabványos", a portlet specifikációban előírt példányokat látjuk, ha ezt átteszem Exo alá, az ijedtében maga alá csinál... Ezért mondom azt, hogy hiába jól definiált specifikáció a kiskapura, ha a nagykapu tárva-nyitva áll.

A portletek hordozhatosaganak a lenyege, hogy csak azt hasznald ami specikikalva van. GenericPortlet van es akutyat nem erdekli hogy a JSPPortlet is GenericPortlet mert meg amellett valami mas is... Persze ekkor elfelejtheted a kontenerspacifikus csodakat, de majdnam jol fog mukodni mindenhol. Ott lesz problem ahhol tobb portlet fog egymassal kommunikalni..... Az meg az eltero belso session implementaciokbol ered..... Troger megoldas elvenni a webservertol a session kezelest de minden "gyari" implementacio ezt teszi ha jol tudom azert hogy tobb webapot is tudjanak hasznalni.... Tehat van Generic porttlet es nem kommunikalunk session-on kerezstul portletek kozott akkor tutti a dolog... elemben meg ahany kontener annyi implementacio. Na elso korben ennyi most itt mellett a masik gepen gyilkonnak 1000el ezt latnom kell...

Olyan ez mint az auto meg a motor... mind a kettovel tudsz utazni.... de a motottal elmesz az autok mellett a dugoban.... viszont eso ellen nem ved.....

Itt ez a bökkenő, hogy valahol meg tudod mondani, de nincs ennek sehol helye. Dehogynem. Init parameter, vagy valami altalam kitalalt config file, amit aztan a telepitesi utmutatoban leirok.

import com.liferay.portal.kernel.util.Constants;
import com.liferay.portal.kernel.util.ParamUtil;
import com.liferay.util.bridges.jsp.JSPPortlet;
import com.liferay.util.servlet.SessionMessages;
[...]
public class GoogleSearchPortlet extends JSPPortlet {

Ugyan biztos benne van a hiba, de az itt felhozott csomagokbol nekem nem ugy tunik, hogy itt egy JSR168 specifikacio altal meghatarozott portlet forraskodja kezdodik. Az ilyenektol pedig nem feltetlen erdemes elvarni, hogy teljesen mas feluletet elvaro rendszerbe beillesztheto legyen. Ha ilyen van, akkkor lehet csinalni az mindenfele Wrapper osztalyokat, amivel be lehet illeszteni (mar ha sikerul a felulet megfeleltetes.)

De ha ezen túllépünk, és megnézünk egy olyan LifeRay portletet, amelyben adatokat tárol adatbázisban, akkor láthatjuk, hogy a portletben van egy connection.properties, amely tárolja az adatforrás adatait, és kutyaközönséges JDBC hívásokkal kezel adatbázist. Ugyanez JBoss portál esetén például teljesen másképp van, tehát hiába tennék én egy JBoss portletet LifeRay portálba, meg se tudna szólalni, mert a LifeRay alapvetően nem EJB portál.
Konyorgom! A fejleszto balfaszsagat ne kenjuk mar ra egy specifikacio esetleges hianyossagara. Mutatnek en is egy peldat:

import java.sql.*;
import sunw.util.*;

public class Main {

	public static void main(String[] args) {
		DriverManager.registerDriver(new com.mysql.jdbc.DriverDriver());
		DriverManager.getConnection("mysql://localhost/mydb", "root" ,"");
	}
}

Szar az egesz java speci, ez a kod csak sunos implementacion fut, csak mysqlel, raadasul localhoston lehet csak, es meg root felhasznalonak is kell lennie (raadasul jelszo nelkul). Meg veletlenul se a kedves fejleszto a hulye, mert beleegette ivhegeszovel az elerhetosegeket. De nézzük például a LifeRay másik portlet példáját, ahol jogosultságot kezel:
Ha jol megnezzuk, akkor talalhato a peldaban egy >liferay-theme:defineObjects /< tag. Nevebol itelve liferay specifikus dolgokat tartalmazhat, ami miatt nem csoda, ha exo alatt eldobja magat.

A rendszer, amivel jelenleg dolgozon JBoss alatt fut. Ezt nem is nagyon lehet atemelni mashova, mert a rendszer bizonyos komponensei (hatterben futo periodikus szogaltatasok) kemenyen kotodnek a JBosshoz (konkretan jboss osztalyokbol vannak leszarmaztatva). Hogy mindez miert van, nem tudom, de mindenki tisztaban van vele, hogy ezzel a rendszer megserti a hordozhatosagot.

Nyilvan nem tul konnyu olyan portleteket kibocsajtani, ami docceno mentesen bedobalhato barhova. Ha nem figyel oda az ember, akkor konnyen olyan fuggosegei lesznek ami meggatolja a hordozhatosagot. Az altalad felhozott peldakbol pedig nekem ez tunt fel, elnezest, ha nem ez volt a celod vele.

Nyilvan nem tul konnyu olyan portleteket kibocsajtani, ami docceno mentesen bedobalhato barhova. Ha nem figyel oda az ember, akkor konnyen olyan fuggosegei lesznek ami meggatolja a hordozhatosagot. Az altalad felhozott peldakbol pedig nekem ez tunt fel, elnezest, ha nem ez volt a celod vele.

A célom az volt, hogy rámutassak, sehol nem találni olyan portetet, amely hordozható, és funkcionálisan használható, illetve különösebb heggesztés nélkül használható más portál rendszerben, mint ahova szánták. És próbáltam az okait kideríteni, és úgy láttam, ez az oka, vagyis a specifikáció túl tág volta (más is így gondolja, ahogy olvastam fórumokat). A JSR-286 alapvető baja pedig az, hogy a sok cég, akik bábáskodnak, mind készen vannak egy JSR-168 alaptól túlmutató portlet implementációval, és nincs közös nevezőjük.

Szóval a lényeg az, hogy hiába van JSR-168 portálom, nem tudok se egy LifeRay, se egy JBoss fórum portletet felhasználni... :)

JPA/adatbázis kérdés.

Szeretnék pár dologhoz címkéket rendelni, például hírekhez (jpa, glassfish, j2ee, stb), fórumhoz (lásd előbb), cikkekhez, blogokhoz, ilyesmihez. Hogy lenne célszerű: csinálni egy közös "címke" entitást, amely címkéihez hozzárendelem (több-a-többhöz) a fenti dolgokat, vagy használjam a JPA String[] típusát, amely ugye nem lesz kereshető adatbázis szinten, és azt sem tudom hirtelen, hogy miképp tudnám kigyűjteni az X címkéhez tartozó dolgokat, illetve erőforrászabálásilag mennyire problémás...

Vélemény?

Mivel sokan esetleg nem követtétek napi szinten a http://www.javakocsma.hu oldalon a portál készülését, pár információmorzsát megosztanék a JavaForum2.0 nevű portál motorról:

• A portál back-end teljes egészében Java EE 5, azon belül EJB3 alapokon készül, UML tervekkel és dokumentációval.
• A portál front-end JSR-168, vagyis Portlet 1.0 kompatibilis (illetve lesz) portál motor, amely EJB hívásokkal kommunikál a back-end üzleti logikával. A front-end ezért a HTTP protokollon és a Portlet implementáción kívül alig tartalmaz üzleti logikát, minden lényeges rész a back-end oldalán van.
• Elvileg minden Java EE 5 kompatibilis alkalmazás szerveren képes működni, és bármilyen JPA kompatibilis adatbázis motoron létrehozza a szükséges struktúrát... tesztelve Glassfish v2 és PostgreSQL alatt van igazából.
• Elvileg képes futtatni bármilyen portletet, gyakorlatilag erre nem fordítottam túl sok időt, még jópár osztályt implementálni kell hozzá a portlet interfészek közül.
• JavaScript nélkül a portletek eseményei oldalújratöltéssel futnak le, JavaScript jelenléte esetén viszont csak az adott portlet töltődik újra a háttérben, amely kényelmesebb használatot tesz lehetővé, pluszban a portál képes néha újratölteni egyes portleteket, ha "esemény" van.

A fent említett http://www.javakocsma.hu portálon a Java Fórum design alatt készül az új 2.0 verziójú Java Fórum, amely fel van készítve AJAX működésre, a design eléggé szét van esve, de nem ez a lényeg, a portál arculata eléggé át lesz szabva:

• A főoldal egy "dashboard" jellegű layout-ot kap, a mostani hírek helyén hírek és cikkek lesznek, de más stílusban, a legfrissebb újdonság mindig nagyobb méretű lesz, alatta még négy ilyen közepes méretben, majd alatta felsorolva még tíz, összesen 15 (most 16 van a hírek között), és persze RSS típusonként. Ez a hírpanel alatti portlet három részre fog oszlani:
  • egy oszlop a további hírekkel, a portlet tetején kereső sávval, hogy lehessen a hírek között keresni, a portlet alján lapozó, hogy végig lehessen lapozni az összes régi hírt
    
  • egy oszlop a friss cikkekkel, kereséssel lapozással
  • egy oszlop friss tudástár bejegyzésekkel, kereséssel, lapozásal
• A főoldal jobb oldalán a megszokott belépés, az "utolsó aktivitás" megszűnik, alatta a fórum utolsó hozzászólásai, kereséssel és lapozással
• A fórum az eddigi kettő szint helyett több szintes lesz, a témáknak lesznek gazdái, akár moderátorai, az ábrázolás még nem alakult ki, de a témák mostantól "megoldhatók" lesznek, a megoldásért pedig pont járhat. Minden fórum témára kérhető lesz RSS.
• A fórum hozzászólásoknál meg fog jelenni a hozzászóló avatar-ja (lehet fotó is), illetve a javablackbelt mintájára különféle színű "karateöv" ikon.
• Lesz üzenetkezelés, tehát lehet majd magánüzeneteket írni.

Első körben kb ennyi, elvileg január elsejétől az új portál fog működni, remélhetőleg minél kevesebb hibával. Egyéb ötlet, javaslat, satöbbi?

Átmigráltam a javaforum.hu mostani felhasználóit a javakocsma.hu alá, ezért ott is be lehet lépni a megszokott adatokkal. A fórum portlet elkészült, akinek 2-3-4 percnyi ideje: a http://www.javakocsma.hu/javaforum/6/forum portál oldalon próbálgassa kicsit a fórumot, és írja meg ide az észrevételeit. Ha minden jól megy, akkor a napokban átmigrálom bővebb tesztként a mostani fórum tartalmat is, és akkor is meg lehet szaglászni az eredményt.

A design egyelőre nem prioritásos, de lehet azt is javasolni, teljesen rugalmas vagyok a design ügyében is... :)

Amit meg én fogok csinálni... :P

Betöltöttem a meglévő fórum tartalmat a javakocsma.hu fóruma alá... :)

Ez az uzenet tartalma/cime tul rovid ez tenyleg jo? mert igy pl nem tudok majd cdak egy :) -t irni....

Javítottam kettőre, hogy legyen benne valami. A lényege nem tudom mi, alapvetően az üzenet egyértelmű megtalálását szolgálja, vagy a fene tudja. Lehet, hogy kivágom a francba az üzenet címét... :)

Nos, elvileg a teljes fórum át van migrálva, és került bele lapozás (külön üzenetre és külön témakörre). A régi fórum tudását lefedi az újabb fórum, most kellene pár vélemény, hogy mi is legyen pontosan a fórumban megvalósítva.

Ami még hiányzik, de mindenképpen lesz:

• RSS egyedi témakörönként (akár altémákkal együtt)
• Permalink az üzenetekhez
• A hozzászólásoknál felhasználói adatok (avatar, pár plusz infó, Java tudásszint, üzenetküldés, stb).
• Üzenetek utólagos szerkesztése (korlátozva, például +30 perc vagy következő üzenet előtt)
• Moderálás (moderált témakörök)

Amin gondolkodom:

• FCKEditor mentes fórum?
• Syntax highlight (van erre valami lib vagy API?)
• Rendezési módok (használná valaki)?

Egyéb ötlet?

Üdv, esetleg még a fórum hozzászólásnál legyen kiírva, hogy hanyadik üzenet, esetleg azt, hogy melyik másik üzenetre a válasz. Ne lehessen duplán posztolni.

Más: biztos, hogy jó technológiákat használsz a motorhoz? A klasszikus JSP + JDBC -vel nem lenne egyszerűbb? Nem kéne küzdeni a különféle framework-ökkel, hanem imperatívan le lehetne írni, hogy hogy és mit akarsz az adatbázisból kinyomni a képernyőre?

-Az FCKEditor mentes változat hasznos lehet, főleg ha valaki PDA-n nyomja.
-A hozzászólásoknál jó lenne egy link az előzmény hozzászólásra. A link szövege lehetne a referált hozzászólás szerzőjének neve.

Az üzenet sorszámát, az előzmény üzeneteket felírtam a Todo listára... a duplázás elvileg kiszűrhető, de gyakorlatilag most nem szűröm ki, ha AJAX módban fut a portál, akkor nem is igazán lehet duplázni (frissítés), a JS nélküli módban persze előfordulhat, de... majd meglátjuk mennyire okoz problémát.

FCKEditor helyett viszont kellene pár ötlet, hogy egy csökkentett tudású szerkesztő mit tudjon (szöveg idézése, url megadás, bold, italic, underlined, pár font méret, kód jelölése, syntax highlight, smile ikonok, stb).

Azért nem klasszikus JSP + JDBC, mert nem javaforum.hu portált akarok csinálni, hanem egy univerzális portált, amit később másra is fel tudok használni... Egyébként úgy néz ki, hogy az EJB + JPA nem lassabb, mint a JDBC... persze vannak problémák, amelyek nehezen oldhatók meg, de igen gyorsan lehet fejleszteni, és nagyon rugalmas tud lenni a back-end.

FCK helyet en meg mindig tinyMCE parti vagyok, azt lehet konfiguralni hogy mit akarszbenne vannak a default packageban peldak is ra....

Igazából az ilyen editoroktól meg akarok fórum szinten szabadulni. Nem kell a funkcionalitása. Az FCKEditort is le lehet korlátozni, satöbbi, de majd kiderül... :)

Syntax highlight (van erre valami lib vagy API?)
Erre pl jo megoldast tud nyujtani a SyntaxHighlighter (http://code.google.com/p/syntaxhighlighter/), ami kliens oldalon, csak js felhasznalasaval szinezgeti a kodot.

Nyitottam egy bugtracker oldalt, ami jelenleg php alapokon megy, mert nem találtam nyormális és ingyenes Java alapú eszközt... aki tud, szóljon... :)

A lényeg, hogy az alábbi címen lehet majd a Java Fórum 2.0 hibáit és felhasználói igényeket bejelenteni: http://traq.enaplo.hu

Az oldalon szabad a regisztráció, a program nevet, emailt és jelszót kér, semmi többet. Igyekszem nagyjából kialakítani az adatbázisát, hogy lefedjem alprojektekkel a teljes Java Fórum 2.0 működést és portletet.

Szeretném, ha a január elsejei átállás a lehető legkevesebb zökkenővel történjen, akinek van ideje így az ünnepek előtt és között, kérem, hogy tesztelje és próbálja, írjon javaslatokat... köszönöm.

Az oldalon szabad a regisztráció, a program nevet, emailt és jelszót kér, semmi többet. Igyekszem nagyjából kialakítani az adatbázisát, hogy lefedjem alprojektekkel a teljes Java Fórum 2.0 működést és portletet.

Nos, sikerült anonymous logint csinálni, így már név nélkül is bejelenthető hiba vagy egyéb kérés. Alapból az egyszerű bejelentő jön fel, ez felcserélhető egy bővebb űrlappal.

Két projekt van jelenleg:

• Java Fórum 2.0 portál, amelynél a portál rendszer működését érintő hibák és funkciók szerepelnek
• javaforum.hu, amely kifejezetten a javaforum.hu portál felépítését és megjelenítését érintő hibák szerepelnek

A hiba bejelentésénél három dolgot kell megadni helyesen, a kategóriát, a reprodukálhatóságot, és a súlyosságot. A magyarítás itt-ott vicces néha, de talán sikerül eltalálni mindegyiknél az értelmes típust... :)

Nagyjából a két ünnep közötti időszakra tenném a teljes migrálást, januárban már mindenképpen az új portált szeretném üzemben látni... addig igyekszem naponta összefoglalni a fejleményeket. :)

A "vélemények a cikkekről" című fórumot kezdtem volna éppen böngészgetni, de a topikok üresen jelennek meg. Azért ide írom, mert gondolom ez nem hiba, hanem valamilyen szinten tervezett működés. Azóta megnéztem néhány másik topikot és jelennek meg hozzászólások.

Ha már itt vagyok írom, hogy a böngésző-vissza gomb elég érdekesen működik. Gondolom az a filozófia, hogy az oldalon lévő "vissza" linkeket kell majd használni. Ebben az esetben érdemes lenne több helyre is kitenni ezeket a "vissza" linkeket az oldalakon. Nemcsak a topiklista alá, hanem esetleg fölé is.

A "vélemények a cikkekről" című fórumot kezdtem volna éppen böngészgetni, de a topikok üresen jelennek meg.

Igen, nem volt benne üzenet. Felírtam hibalistára.

Ha már itt vagyok írom, hogy a böngésző-vissza gomb elég érdekesen működik. Gondolom az a filozófia, hogy az oldalon lévő "vissza" linkeket kell majd használni.

Ennek az a háttere, hogy a portlet (jelen esetben a fórum) JavaScript segítségével újratöltődik a háttérben. Ha kikapcsolod a JavaScript-et a böngészőben, az oldal akkor is működik, de a teljes oldal újratöltődik, ez esetben viszont a címsor az aktuális állapotot tartalmazza. Egyelőre nem találtam megoldást arra, hogy JavaScript-el újraírhassam a böngésző címsorát.

Ebben az esetben érdemes lenne több helyre is kitenni ezeket a "vissza" linkeket az oldalakon. Nemcsak a topiklista alá, hanem esetleg fölé is.

Felvettem a hibalistára ezt is.

Elvileg működik a regisztráció a http://www.javakocsma.hu oldalon (a belépés ablak alsó felében). Akinek adódik ideje ebben az ünnepi hangulatban, kipróbálhatná, hogy sikerül-e regisztrálnia magát, és utána be tud-e lépni azzal a névvel. Köszönöm.

Regisztracio sikerult, belepni sikerult, beallitasoknal Nagy hiba... nagyon nagy hiba...

Ja, mindezt kikapcsolt js-el, es ovele: Opera/9.23 (X11; Linux i686; U; en)

Regisztracio sikerult, belepni sikerult, beallitasoknal Nagy hiba... nagyon nagy hiba...

Köszönöm, látom felhasználót, a beállítások még nincsenek megvalósítva, idővel az is menni fog. Már csak hét nap és át kell álnom az újabb portálra, a legalapvetőbb funkciókat csináljuk meg, a többi majd januárban... a fórum elvileg jó, de majd jelentősen átszervezem a témastruktúrát, a hírek modul is kész, ott még a migrációt kell megoldanom, a többi része a portálnak nem prioritásos, de azon is dolgozunk... :)

Köszönöm, hogy kipróbáltad!

nálam ugyanez, engedélyezett js-sel, FF 2.0... de regisztrációnál rögtön beléptetett, aztán kilépés után is simán be tudtam lépni újra, szóval az műxik.

Úgy néz ki, hogy a regisztráció jól működik. Köszönöm.

A mostani helyzet szerint működik a belépés, a regisztráció, a fórum (kis hiányossággal), a hírek (nincs migráció). Ami nem működik, az a cikkek, a tudástár, a cégtár és a blog portlet, de ezek is el fognak készülni. Elvileg lesz egy kis design remake is, de ez még folyamatban... :)

Lenne jelentkező "tesztelő" feladatra? Szeretném korrekt módon vinni a Java Forum 2.0 portál fejlesztését, és ehhez jó lenne olyan személy, aki a hibajegyeket lezárja, miután tesztelte a megoldás működését. :)

Jöjjön egy kérdés a fájlok tárolásáról... :)
Jelen esetben úgy van tervezve a Java Fórum 2.0 portál, hogy a képek (hírek, cikkek, illetve fórum képei és állományai) adatbázisba kerül, bináris formában (BLOB). Ezügyben van sok-sok érv és ellenérv... :)

Érvek ellene:

• lassabb, több erőforrást von el
• nagy méretű az adatbázis, nagy méretű a mentése
• nem minden adatbázis motor támogatja megfelelően

Érvek mellette:

• Nem kell fájlrendszer jogokkal foglalkozni
• Kompakt az erőforráskezelés
• Elég az adatbázist menteni

Egyéb érv és ellenérv? Ti hogy csinálnátok?

EJB speci szerint ejb-bol nem illik a java.io.*-t hasznalni (gondolom nio-t sem). Szoval ez a db mellett szol. Apropo, mivan, ha muszaj filet olvasnom ejb-bol? Van valami megoldas erre?

Apropo, mivan, ha muszaj filet olvasnom ejb-bol? Van valami megoldas erre?

Szerintem olvashatsz, bár ekkor olyan helyről kell olvasnod, amely elérhető a cluster összes nodejáról, ez simán megoldható, nem okoz szerintem problémát.

Inkább az írás az, ami problémásabb, hiszen hova is írsz, hogyan írsz, mit teszel a tranzakció kezelésével? :)

Szerintem a "jobb" adatbázis-kezelők jobban kezelik a bináris adatokat, mintha direkt io-t használnál. A másik érdekes dolog, hogy - ha jól emlékszem - csak abban a környezetben használhatsz io-t, ahol a classloadered fut. Kérdés, hogy J2EE környezetben - ahol nem tudod, hogy az EJB-d melyik classloaderben töltődik - hogyan fogod a jogokat kezelni?

Szóval egyértelműen DBMS. Persze lehet, hogy az RDBMS fájlrendszerben tárolja a LOB-okat. :-D

Nos, a migrálási terv szerint a http://www.javaforum.hu december 31-én délután 14 óra után leáll (tájékoztató szöveg marad a helyén), az IP címeket átállítom az új szerverre, amely nagyjából 24 óra alatt fog minden DNS szerver felé elterjedni. Úgy érzem, hogy kevés látogatót fogunk elveszteni, ha szilveszter éjjelén és az újév délelöttjén nem érhető el a portál... :)

A portál leállítása után az összes adatot átmigrálom az új rendszerbe (felhasználói adatok, fórum és hírek), így probléma nélkül kell megtörténjen az átállás.

A főoldalon a hírek (dashboard layout) nagyjából összeállt, nem ez lesz a végleges design, de ötleteket várok, ha van jobb elképzelés. A fórum rész egyelőre szét van zuhanva layout szempontjából, design pedig egyátalán nincs rajta. Itt is várok ötleteket a layout és a design kapcsán, ami még biztos elkészül, az egy - jelenleg is látható "friss hozzászólások" nézet, amely továbbra is megmarad. De érdemes lenne elgondolkodni egy újabb fórum struktúrán.

A  hírekhez kész az RSS, a fórumhoz is migráltam a régi RSS modult, de ezt mindenképpen ki szeretném egészíteni témakörre bontható RSS csatornával.

A társalgó menüpontot eltávolítom, a kutya se használta gyakorlatilag, néha verődött össze valami kis csapat és dumáltak, de erre van jobb módszer. Ezt a részt ki szeretném váltani valami szakmai kollaborációs instant message szoftverrel, ha van rá igény.

A tudástár és feladattár egyelőre nincs migrálve, és lehet, hogy meg fog szűnni. Van benne sok információ, amelynek valamilyen más formában adunk lehetőséget, de ez még a jövő zenéje (ötletek jöhetnek :).

A cégtár egyelőre nincs migrálva, kissé más formában de vissza fog térni, itt kissé rá fogok feküdni a reklámra, minél több cég ismerje meg, és később talán még valami pénzféle is befolyhat ebből az irányból.

A linktár egyelőre nincs migrálva, ide egy wiki szerű, szabadon szerkeszthető oldalt képzeltem el.

A rólunk migrálva lesz.

Egyelőre ennyi, mindenkinek buék, és majd kiderül, hogy megy-e minden jól... :)

Esetleg amig a DNS atirodnak, addig a regi oldalra kirakni egy redirectet, hogy a kedvens delikvensek oda talaljanak? Vagy gondolod, h mindenki annyira mak lesz januar 1-en, h nem fognak beesni? Nincs itt egy igazi kocka se?

Esetleg amig a DNS atirodnak, addig a regi oldalra kirakni egy redirectet, hogy a kedvens delikvensek oda talaljanak?

Az a baj, hogy nem ez az egy dolog fut a gépen, és így csak IP alapon tudom megcímezni az új gépet (illetve a javakocsma.hu domain már oda mutat... hm).

Vagy gondolod, h mindenki annyira mak lesz januar 1-en, h nem fognak beesni? Nincs itt egy igazi kocka se?

Szerintem addigra a legtöbb szerver már átveszi... nem tudom, akinek annyira fontos, az beleír magának a hosts fájba... :)

Hogyan van utemezve az design rendbe rakasa?

Folyamatban van az új design, elvileg a héten meglesz... :)

Az új portál már nem jelentkezteti be automatikusan a felhasználót (ha lényeges, akkor implementálom ezt is), viszont a session élettartama két nap lett, így ha valaki naponta visszanéz azonos böngészőből, akkor belépve marad.

Tettem a hírekhez megjegyzés írási lehetőséget, viszont ezek nem szerepelnek az RSS-ben. Szerintetek tegyem bele az RSS-be, ha igen, akkor milyen formában? Legyen külön megjegyzés RSS minden hírre, vagy egy aggregált RSS, ahol a hírekkel együtt jönnek a megjegyzések is?

Nagyon jó, hogy a hírekhez fűzött megjegyzés együtt van a hírrel, viszont nem lehet észrevenni ha valaki ír valamit. RSS-ben is jó lenne, de méginkább a jobb oldali hasábban.

Esetleg még arra gondoltam, hogy a híreknél a keskeny jobb oldali panelben jelennének meg a hírek megjegyzései (egyszerűen csak melyik hír, ki és mikor jellegű lista. És lehetne magasabb a hírek blokk. És így végülis lehet külön RSS a megjegyzésekre. Vélemény?

Azt látom, hogy hány darab van benne, csak azt nem, hogy mennyire újak.

Igen, az profi lenne. Pl. 20 hír a bal oldalon, ahogy most megjelenik, és jobbra a vélemények.

Nos, elvileg elkészült... tessék megkritizálni. Egyelőre AJAX letöltéskor nem ugrik a hivatkozott megjegyzésre a böngésző... új oldalon megnyitva igen. Nem tudom, hogy lehetne innerHTML-be töltött tartalom esetén a pozícióra ugratni a böngészőt. Ötlet?

A jelenlegi lapozó úgy működik, hogy a legfrissebb lap a 0-10, viszont bevillant egy olyan ötlet, hogy a számozást meg kellene fordítani, hiszen ha egy kereső beindexeli, akkor az első üzenetek felől számozott lapozás mindig azonos marad. Ti is így gondoljátok? :)

A hírek fórumtéma megszűnt, tartalmát átmigráltam a hírek megyjegyzéseihez.

Jó lenne az az autologin.
Nekem még mindig böngésző zárásig él a süti. (Firefox)

Felírtam a traq oldalra: http://traq.javaforum.hu/view.php?id=27

Elvileg működik az autologin (traq.javaforum.hu/view.php), tesztelést szeretnék kérni. :)

Sziasztok.

Nem tudtam már megállni, hogy egy szó nélkül hagyjam az "új" javaforumot.

Gábor ne sértödj meg a "stiluson" (ahogy majd irok.:), de ez totál katasztrófa.

Nem értem miért kellett ezt a félig kész munkát, amiben hemzsegnek a hibák,
tele van nem müködő, vagy hibásan müködő funkciókkal, dolgokkal elinditani.

A forum rész ugy szar ahogy van: bonyolult, összevisszaság uralkodik benne, áttekinthetetlen..
Amit nem értek..  miért nem tudtál kiindulni bevált receptből.. mint amilyen a BB forumok.. és itt nem
a funkciókra gondolok, hanem kinézet, vagy alapvetű müködés.

A beléptetés is szar.. már egy ideje. Ilyen orditó hibát elkövetni szégyen.. hol müködik, hol nem..
(Debian/Firefox) minden harmadikra sikerül.. na és hogy a Beállítások mellett állandó Kijelentkezés
nem szúr szemet!

A főoldal valami katasztrófa.. szintén az "áttekinthetetlen és gusztustalan valami" fiókba tartozik.

Ez csak pár az orditó hibákbók és megoldásokból.. az aprókkal nem is foglalkozom.. mint a csillag
annyi van belőlük.

Tudom nem kellemes kritikát olvasni, föleg akkor ha az embernek sok munkája van benne, de szerintem
nem lett volna szabad ezt a férc munkát feltenni, föleg egy programozási nyelv-el foglalkozó oldalra.

Ami kiverte a biztositékot nálam és irtam le a véleményem, hogy mikor ma beirtam a javaforum.hu-t www
nélkül, akkor WEBIDEA fő lapja jött be.

Üdv.
Frimen

Frimen azért nem vagy semmi...
Nem tudom, hogy te mit szólnál, ha szétugatnánk a te munkáidat! Ha nem tetszik, attól még nem kell ilyen ocsmány módon leugatni valakinek a munkáját. Szerintem Gábor egyértelműen tisztázta, hogy nem végleges változatról van szó és folyamatosan fejleszti.

A webidea-s oldalról meg annyit, hogy arról én tehetek, nem állt át egyből a domain. Ennyi.

Ugatást kéretik a büdös kukába ordibálni... : )

Kössz!

Nos, a kritika jó dolog, el szoktam fogadni. Az új Java Fórum lehetett volna jobb is, most ilyen lett, de jobb lesz idővel.

Ha egyik helyről máshova kerül egy domain akkor lehetnek problémák, vannak is, ami el fog múlni, ez van.

Az oldal design fog javulni (remélem hamarosan), és azzal se lesz probléma.

Ha az oldal működésével van problémád, akkor kérlek írd fel hibajegyként, ezzel többet segítesz, mintha magadban tartod, majd kifakadsz... köszönöm... :)

A hozzászólások címe megjelenik a jobb oldalon látható listában, így a későbbiekben kéretik kitölteni az üzenet tartalma szerint... :)

A következő alkalom az algoritmus szerint március 19-én lenne, ami a húsvét előtti (nagy)szerda. Szerintetek probléma ez? Vagy szerdán még úgy is dolgozik mindenki?

Kicsit átalakítanám a portálon a cikkeket, a híreket és a wiki jellegű részeket (bár ebből még nincs minden migrálva).

A híreknél maradna a jelenlegi struktúra, elsősorban újdonságok és Java kapcsolatos hírek lennének itt, esetleg hosszabb esszék megvitatható dolgokkal kapcsolatban.
A cikkeknél tervezek egy olyan blokkot, amely a programozást kezdetétől egészen a Java EE 5 tudásának végéig lenne valamilyen logikus sorrendben. Nehéz lesz, de szeretnék erre időt szakítani a következő egy évben... :)

Ami nem fér bele a fenti blokkba, abból lennének az egyedi - címkével ellátott, kategorizált - cikkek.

Ezen túl szeretnék egy cikk terjedelmű, egy konkrét témával foglalkozó "Tippek, trükkök" jellegű részt, ahol mindenféle okosság lenne összegyűjtve.
A főoldalon szeretnék egy olyan dashboard-ot, amibe ezeket a fentieket és a fórumot is össze tudom vonni.

Vélemény?

A cikkeknél tervezek egy olyan blokkot, amely a programozást kezdetétől egészen a Java EE 5 tudásának végéig lenne valamilyen logikus sorrendben. Nehéz lesz, de szeretnék erre időt szakítani a következő egy évben... :)

Én nagyon támogatnám akár egy külön Tutorial szekció megjelenését is (a cikkek mellett). A cikkekbe mehetnének az önálló, egy témát körüljáró/bemutató írások, a Tutorial meg legyen rendes oktatóanyag, amiből okulni lehet. Jó lenne, ha ott is elérhető lenne a több szint, hogy például egy sorozat elemei ne egyesével jelenjenek meg. Hozzá lehetne fűzni  (láncként a toronyórára ;-) ) comment részt, ahol az adott tutoriallal kapcsolatos kérdéseket fel lehet tenni (mint a híreknél is lehet hozzászólni). Ezt ugyan lehet a rendes fórumban is, de ha ott vannak rögtön alatta azok a problémák, amibe egyszer valaki már belefutott, akkor a lusta programozók (akiknek macerás kikeresni a fórumban, hogy feltette-é már valaki ezt a kérdést ezzel a tutoriallal kapcsolatban) talán könnyebben boldogulnak...

A hosszabb és megvitatásra szánt esszék elférhetnének a cikkek között (márcsak a műfaj miatt is), viszont ha van rá még egy pár perc kapacitás :-P, akkor érdemes lenne a hírekben tudatni, hogy megjelent egy ilyen cikk, itt és itt olvasható, vélemények welcome. Vagy valami.

Ezen túl szeretnék egy cikk terjedelmű, egy konkrét témával foglalkozó "Tippek, trükkök" jellegű részt, ahol mindenféle okosság lenne összegyűjtve.

Lehet, hogy még korán van, de ezt nem teljesen értem... Vonzónak hangzik a Tippek, trükkök", de hogyan is képzeled el pontosan?

Főoldalon dashboard - a friss fórum bejegyzések és a hírek már ott vannak, és most lenne a többi részhez is egy "Újdonságok a honlapon" féleség (mondjuk linkekkel az adott újdonságra)?

Hajrá :)

Én egy - majdhogynem - könyv jellegű írást szeretnék, amelyet esetleg úgy formázok, hogy PDF-be lehessen exportálni, kinyomtatni satöbbi, de mivel online, lehet rá reagálni és a tartalma utólag is könnyen módosítható. Nem a klasszikus cikk kategória lenne, hanem online könyv... :)

Az online könyv minden részéhez szeretnék megjegyzésfűzési lehetőséget, akár kiegészítést, akár újabb példát hozzá lehessen fűzni. Tehát nem a fórumot akarom terhelni ezzel a megjegyzésekkel, hanem a hírekhez hasonlóan on-the-place megjegyzéseket szeretnék... :)

Ami ebből a könyvből kilóg, abból lenne cikk vagy cikksorozat.

Valamiert en nekem ugy remlik, hogy annak idejen a motor open szoszra meghirdetve. Ha igaz, akkor merre lehet fellelni a szoszt?

svn.javaforum.hu/svn/javaforum2.0/

Minden kritikát és észrevételt örömmel fogadok... :)