[Java] webbased frameworks

[Verwijderd]

flowerp schreef op woensdag 21 februari 2007 @ 22:40:
Maar goed, tegenwoordig heb je in je web layer wel degelijk altijd toegang tot de servletContext, dat is tenminste als je de huidige view technology gebruikt (JSF). Gebruik je nog ouderwetse 'puur' JSP pagina's..

Je doet het nu wel heel erg voorkomen alsof jsp het ouderwetse 'niet meer gebruiken' beestje is en jsf het 'eureka parade' paardje van nu is. Leuk voor een poof-of-concept dat jsf, maar daar blijft het ook echt wel bij. Dat hele jsf is simpelweg één grote beperking met abstractie op plekken waar je het niet nodig hebt.

flowerp schreef op woensdag 21 februari 2007 @ 22:40:
In de Java EE 5 weblayer (JSF dus), kun je overal de faces context oproepen. Deze wordt via aan static methode uit threadlocal storage gehaald. Vanaf de faces context kun je de external context oproepen. Omdat je er via een static method bij kan, betekent dit dat je er vanaf elke bean bij kan, hoewel method calls diep je ook zit.

Wat enkel smerige onbegrijpbare constructies kan opleveren. 'Dependency lookup' is zo ongelooflijk ... euh ... ejb2.0

[flowerp]

Verwijderd schreef op woensdag 21 februari 2007 @ 23:10:
[...]
Je doet het nu wel heel erg voorkomen alsof jsp het ouderwetse 'niet meer gebruiken' beestje is en jsf het 'eureka parade' paardje van nu is.

??? JSF is gewoon de default view technology in Java EE 5.

Los van of er betere of slechtere alternatieven zijn gebruiken zeer veel mensen en shops altijd gewoon als eerste hetgeen standaard in Java zit. Mischien dat Velocity als templating engine ook beter was dan JSP; toch gebruikt iedereen eerst JSP. Pas als je wat meer weet (lees minstens een jaar verder bent) kijkt je eens naar alternatieven.

Leuk voor een poof-of-concept dat jsf, maar daar blijft het ook echt wel bij.

Poof(?)-of-concept my ass. Het concept van JSF (component based web framework) is zeker een blijvertje. Het andere grote web platform (Asp.NET) doet exact hetzelfde. Java is met JSF wat later, maar de industrie begint nu enorm op gang te komen. Component libs (tomahawk, icefaces, ADF/trinidad & tobago) en zeer interesante extenties (Seam, facelets) schieten als paddenstoelen uit de grond.

Dat hele jsf is simpelweg één grote beperking

Grapjas! JSF is 1 van de meest uitbreidbare frameworks die ik ooit heb gezien. Werkelijk elk aspect is wel pluggable en/of vervangbaar. Je kunt aan standaard gedrag dingen toevoegen of vervangen. Dingen als Seam en facelets zijn -zeker- geen desperate alternatieven vanuit de opensource wereld "omdat de grote boze bureaucratische" sun het weer eens niet goed doet, maar zijn valide uitbreidingen geheel zoals bedoeld in de core spec van JSF.

Wat enkel smerige onbegrijpbare constructies kan opleveren. 'Dependency lookup' is zo ongelooflijk ... euh ... ejb2.0

Je -hoeft- dit niet te gebruiken. Sterker nog, het is een last resort alternatief. In de gehele JSF API krijg je over in je componenten gewoon een faces context object mee als dat nodig is. Omdat duidelijk was dat veel mensen deze functionaliteit toch ergens nodig hebben, is er de mogelijkheid. Je kunt het misbruiken, maar dat kan met alles. Spaarzaam gebruiken dus en er is niets aan het handje.

[momania]

flowerp schreef op donderdag 22 februari 2007 @ 00:29:
[...]


??? JSF is gewoon de default view technology in Java EE 5.

Ik moet me hier toch volledig aansluiten bij mark platvoet. Het mag dan wel de default zijn, maar ik vind het niet echt een verbetering toevoegen.
Mij idee bij een web framework (ieder framework) is dat het je programmeer werk makkelijker moet maken, met betere abstractie mogelijkheden etc, etc. Bij JSF krijg ik dezelfde kriebels als dat ik naar bv Tapestry kijk. Idee is leuk, maar werkzaam... niet echt.
Ik zweer vandaag de dag ook bij Wicket als web framework. Tenminste een framework waar je normale html kan gebruiken, event based, gedrag ook van alles aan te passen en dat in simpele pojo's

[edit]
Maar we gaan nu redelijk offtopic Maar even wachten op een reactie van de TS wat hij nou precies wil.

[ Voor 6% gewijzigd door momania op 22-02-2007 01:00 ]

[Verwijderd]

flowerp schreef op donderdag 22 februari 2007 @ 00:29:
JSF is gewoon de default view technology in Java EE 5.

Los van of er betere of slechtere alternatieven zijn gebruiken zeer veel mensen en shops altijd gewoon als eerste hetgeen standaard in Java zit. Mischien dat Velocity als templating engine ook beter was dan JSP; toch gebruikt iedereen eerst JSP. Pas als je wat meer weet (lees minstens een jaar verder bent) kijkt je eens naar alternatieven.

De default maakt helemaal niet dat er een bepaalde richting in wordt geslagen. Er zijn andere factoren die vele malen zwaarder wegen, waaronder:
- noodzaak (een framework moet een bestaand probleem oplossen)
- kennis (waarom met jsf beginnen als er een prima werkend alternatief is)
- kennis/geld (aanbod van ontwikkelaars)
- geld (waarom investeren in een techniek als je met het huidige alles kunt bereiken)
- ....

en ergens onderaan de lijst, na een hele tijd niets, komt de 'default'.

flowerp schreef op donderdag 22 februari 2007 @ 00:29:
Poof(?)-of-concept my ass. Het concept van JSF (component based web framework) is zeker een blijvertje. Het andere grote web platform (Asp.NET) doet exact hetzelfde. Java is met JSF wat later, maar de industrie begint nu enorm op gang te komen. Component libs (tomahawk, icefaces, ADF/trinidad & tobago) en zeer interesante extenties (Seam, facelets) schieten als paddenstoelen uit de grond.

Dus ik moet allemaal third party libs onder de knie krijgen die mij een oplossing bieden die net niet aansluit bij de wensen van de klant. Een project bestaat uit uitzonderingen. En dat is waar component based meuk simpelweg tekort schiet.

flowerp schreef op donderdag 22 februari 2007 @ 00:29:
Grapjas! JSF is 1 van de meest uitbreidbare frameworks die ik ooit heb gezien. Werkelijk elk aspect is wel pluggable en/of vervangbaar. Je kunt aan standaard gedrag dingen toevoegen of vervangen. Dingen als Seam en facelets zijn -zeker- geen desperate alternatieven vanuit de opensource wereld "omdat de grote boze bureaucratische" sun het weer eens niet goed doet, maar zijn valide uitbreidingen geheel zoals bedoeld in de core spec van JSF.

Flauwmodus: dan heb je vast heel weinig frameworks gezien

Uitbreiden, vervangen en alles wat maar van het standaard pad afwijkt maakt het binnen een project een risico. Juist uitbredingen zorgen ervoor dat kennis schaars is en ontwikkelkosten omhoog gaan. Het is niet voor niets dat er omgevingen zoals RoR zijn: KISS all the way.

flowerp schreef op donderdag 22 februari 2007 @ 00:29:
Je -hoeft- dit niet te gebruiken.

Dit is wel een van de grootste drogredenen die ontwikkelaars zo nu en dan gebruiken.

[flowerp]

Verwijderd schreef op donderdag 22 februari 2007 @ 09:41:
- kennis (waarom met jsf beginnen als er een prima werkend alternatief is)

offtopic:
Omdat dat de basis van concurentie is? En dat alternatief (asp.net) is helemaal niet bruikbaar in de Java wereld, dus ik snap niet echt waar je heen wilt.

Heb je eigenlijk JSF wel eens -echt- gebruikt? Of blaat je gewoon het bij sommige zo populaire "alles van Sun is zwaar, lomp, en bloated" mantra na?

[Verwijderd]

flowerp schreef op donderdag 22 februari 2007 @ 23:06:
Omdat dat de basis van concurentie is? En dat alternatief (asp.net) is helemaal niet bruikbaar in de Java wereld, dus ik snap niet echt waar je heen wilt.

Met en prima werkend alternatief doel ik op bijvoorbeeld jsp. Maar daar zou je ook van alles in kunnen vullen zoals struts, velocity, spring web mvc, etc..
Ht gaat om de kennis die je hebt en wat je daarmee kan bereiken. Jsf voegt simpelweg niets toe.

flowerp schreef op donderdag 22 februari 2007 @ 23:06:
Heb je eigenlijk JSF wel eens -echt- gebruikt? Of blaat je gewoon het bij sommige zo populaire "alles van Sun is zwaar, lomp, en bloated" mantra na?

Gedraag je.

[JKVA]

Verwijderd schreef op donderdag 22 februari 2007 @ 09:41:
Flauwmodus: dan heb je vast heel weinig frameworks gezien
[...]
Dit is wel een van de grootste drogredenen die ontwikkelaars zo nu en dan gebruiken.

En jij gaat nu roepen dat flowerp zich moet gedragen? Jouw opmerkingen zijn komen op mij ook niet altijd even respectvol over...

Verwijderd schreef op vrijdag 23 februari 2007 @ 07:40:
[...]
Gedraag je.

En serieus, vind jij nou echt dat die Spring MVC alternatieven beter zijn dan JSF? Ik ben de afgelopen 1,5 jaar zo goed als fulltime bezig met JSF en ja, ik geef toe, de leercurve is hoog. En ja, niet altijd even doorzichtig, maar aan de andere kant vind ik Spring MVC dat ook niet. En bij JSF krijg je er tenminste nog goede dingen voor terug, zoals dat je vanaf over een paar weken Trinidad kunt gebruiken, of Backbase, of IceFaces, of nog een andere...

Als jij graag Spring MVC gebruikt, doe dat en laat de rest gewoon JSF gebruiken als ze dat willen.

<plz, einde offtopic, het is geen framework war, het gaat over een poort opvragen>

En in principe kan dat niet, tenminste niet op een 100% failsafe manier...

[Verwijderd]

JKVA schreef op vrijdag 23 februari 2007 @ 10:42:
En jij gaat nu roepen dat flowerp zich moet gedragen? Jouw opmerkingen zijn komen op mij ook niet altijd even respectvol over...

Het was toch erg duidelijk dat mijn opmerking een grapje was ("flauwmodus" en ). De andere is simpelweg een drogreden en dus bloedserieus.
Suggeren dat ik een sun-bloated-meeblater is simpelweg kinderachtig ontwijk gedrag.

JKVA schreef op vrijdag 23 februari 2007 @ 10:42:
En serieus, vind jij nou echt dat die Spring MVC alternatieven beter zijn dan JSF? Ik ben de afgelopen 1,5 jaar zo goed als fulltime bezig met JSF en ja, ik geef toe, de leercurve is hoog. En ja, niet altijd even doorzichtig, maar aan de andere kant vind ik Spring MVC dat ook niet. [...]

Ik claim helemaal niet dat de alternatieven beter. Wat ik beter vind lijkt me al helemaal irrelevant. Maar puur objectief gezien is jsf een weinig toevoegende techniek (gezien de eerder genoemde argumenten).

JKVA schreef op vrijdag 23 februari 2007 @ 10:42:
Als jij graag Spring MVC gebruikt, doe dat en laat de rest gewoon JSF gebruiken als ze dat willen.

Al zou je assembly willen gebruiken om je web pagina in elkaar de flansen, fine with me.

[ Voor 21% gewijzigd door Verwijderd op 23-02-2007 11:24 ]

[flowerp]

Verwijderd schreef op vrijdag 23 februari 2007 @ 11:21:
Ik claim helemaal niet dat de alternatieven beter. Wat ik beter vind lijkt me al helemaal irrelevant. Maar puur objectief gezien is jsf een weinig toevoegende techniek (gezien de eerder genoemde argumenten).

Wat jij beter vind is irrelevant maar objectief is jsf weinig toevoegend? Dat laatste lijkt me meer jouw persoonlijke mening eerlijk gezegd.

Maar alle smart remarks en mogelijke onbeleefdheden ten sprijt heb je nog steeds niet de kern vraag beantwoord Mark; heb je JSF nou wel eens echt gebruikt?

[Verwijderd]

hoe irrelevant het antwoord ook is, het antwoord is: ja

[ Voor 92% gewijzigd door Verwijderd op 24-02-2007 00:12 ]

[flowerp]

Verwijderd schreef op zaterdag 24 februari 2007 @ 00:10:
hoe irrelevant het antwoord ook is, het antwoord is: ja

En was dat echt voor een behoorlijk realworld project (zeg minimaal een half jaar waarbij je het echt intensief gebruikte), of was het meer iets hello worlds achtig om voor je zelf eens te kijken was het was?


ps
92% changes voor die ene line?

[Verwijderd]

Ik snap niet waarom je je wilt beroepen op mijn ervaring met JSF? Dat geeft enkel aan dat jij niet kunt vertellen wat de toegevoegde waarde is. Als het echt zo fantastisch is als dat jij het wilt doen voorkomen dan moet je dat kunnen in een paar simpele regels.

Gezien mijn eigen ervaring met JSF kan ik gewoon gegrond kanttekeningen plaatsen bij het gehele circus. En dat doe ik dan ook getuige de eerder genoemde argumenten. JSF lost nou eenmaal geen bestaand probleem op, of wel soms?

[flowerp]

Verwijderd schreef op zaterdag 24 februari 2007 @ 00:35:
Ik snap niet waarom je je wilt beroepen op mijn ervaring met JSF?

Omdat mijn ervaring is dat 90% van de mensen die zeggen dat JSF slecht is er geen enkele ervaring mee hebben. Je moet toegeven dat het in de Java wereld erg in de mode is om alles wat van Sun komt, behalve dan de JDK zelf, af te branden. Elk produkt uit de stal van Sun is bij voorbaat bloated, zwaar en in een ivoren toren tot stand gekomen. Het dient geen enkele functie dan vendors rijk te maken, omdat alleen zij er wat aan hebben.

Bij bijna elk ding wat Sun maakt wordt ook altijd het EJB2 argument aangeroepen. JSF is slecht, want EJB2 was lomp. Het slaat totaal nergens op, maar sommige mensen roepen het. Andere mensen horen het, en gaan het naroepen. Als je het maar vaak genoegt hoort, ga je het vanzelf geloven.

Dat geeft enkel aan dat jij niet kunt vertellen wat de toegevoegde waarde is.

Dat heb ik toch al gedaan? Zie ook andere threads van mij.

Het voordeel is een standaard web componenten framework. Dit maakt herbruikbare componenten mogelijk. Dingen als bi-directionele databindings maken een zeer elegante manier van werken mogelijk.

Een simpel voorbeeld is het inputText component:

XML:

<h:inputText value="#{myBean.value}" />

Dit is een bi-directionele databinding. Het component trekt z'n waarde uit myBean.value, maar bij een submit wordt de ingevoerde waarde in myBean.value gestopt. Heel mooi is ook dat je aan zo'n component validators en converters kunt hangen. Bv,

XML:

<h:inputText value="#{myBean.value}" >
    <f:validateLongRange minimum="10" maximum="75" />
</h:inputText>

Als ik dit handmatig op een pagina moet zetten (met html en scriptlets) ben ik zeer veel aan het neuzelen met request parameters en zelf IDs toekennen. Vooral bij veel inputs en pagina's die frequent worden aangepast, raak je al snel het overzicht kwijt van wat bij wat hoort. Het bovenstaande vind ik veel overzichtelijker en voegt gewoon echt iets toe voor mij.

Met hetzelfde gemak plaats je ook veel complexerer componenten, zoals een progressbar.

XML:

<x:progressBar percentage="#{myBean.percentage}" progressText="#{myBean.text" />

Hiermee staat er dan een progressbar op mijn pagina die onderhuids bij mijn bean periodiek een percentage en een voortgangs text ophaalt. Met het zelfde gemak zet ik ook gewoon meerdere hiervan op mijn pagina, en het component in samenwerking met JSF zorgt ervoor dat er geen clashes komen tussen IDs en clientside variablen.

Deze manier van werken is niet alleen beter onderhoudbaar, het maakt het werk voor mij ook gewoon veel makkelijker. Ik schrijf een simpele bean (pojo) die progress informatie levert en ik koppel er in een handomdraai een progresbar aan. Elegant & simpel.

Daarnaast, vanwege het feit dat JSF een spec is bestaat de mogelijkheid dat vele organisaties een implementatie van JSF kunnen maken. Alleen dat al is ook een toegevoegde waarde. Het feit dat het een standaard onderdeel van Java is maakt het zeer aantrekkelijk voor anderen om zelf componenten te maken die dan iedereen kan gebruiken.

Bovendien is JSF zelf een soort meta framework. In de core is het redelijk simpel, maar het dient als basis om meer geavanceerde frameworks op te bouwen, en dat dan op een manier die samenwerking belooft ipv een wildgroei van kleine frameworkjes die het wiel telkens opnieuw uitvinden. Zoals eerder gezegd, de core komt bijvoorbeeld met een hele kleine set van componenten. Meer geavanceerde kun je zelf toevoegen.

Een aantal dingen kun je ook met JSP taglibs doen, maar de manier van eventhandeling en statesaving is dan specificiek voor jouw eigen versie van een component. Samenwerking met andere JSP taglibs is dan moeilijk of onmogelijk. Juist het standaard open protocol is belangrijk.

Gezien mijn eigen ervaring met JSF kan ik gewoon gegrond kanttekeningen plaatsen bij het gehele circus.

En geef jij dan eens een concreet voorbeeld van wat er slecht is aan JSF? Probeer dan iets anders te zeggen als "het is zwaar, het is lomp, de kwaliteit is slecht", want dat is het soort prietpraat wat iedereen kan uiten ergens over zonder er verstand van te hebben.

[momania]

flowerp schreef op zaterdag 24 februari 2007 @ 22:40:
[...]
Een simpel voorbeeld is het inputText component:

XML:

<h:inputText value="#{myBean.value}" />

Dit is een bi-directionele databinding. Het component trekt z'n waarde uit myBean.value, maar bij een submit wordt de ingevoerde waarde in myBean.value gestopt. Heel mooi is ook dat je aan zo'n component validators en converters kunt hangen. Bv,

Ik heb nieuws voor je, er zijn frameworks die dat nog simpeler doen
In Wicket is zo'n input gewoon standaard html met alleen een referentie naar een bean(value):

HTML:

<input type="text" wicket:id="beanValue"/>

Geen geneuzel met taglibs, etc...

Met hetzelfde gemak plaats je ook veel complexerer componenten, zoals een progressbar.

XML:

<x:progressBar percentage="#{myBean.percentage}" progressText="#{myBean.text" />

Hiermee staat er dan een progressbar op mijn pagina die onderhuids bij mijn bean periodiek een percentage en een voortgangs text ophaalt. Met het zelfde gemak zet ik ook gewoon meerdere hiervan op mijn pagina, en het component in samenwerking met JSF zorgt ervoor dat er geen clashes komen tussen IDs en clientside variablen.

Dat doe ik dus gewoon met :

HTML:

<span wicket:id="progress"></span>

Weer standaard html, met alleen een id dat refereerd naar een bean in de code. Ik hoef niet specifiek te zeggen dat heen progressbar is, of welke bean value eraan hangt, etc. De gehele progress bar polulate ik in de code, dus ik hoef niet in de template te zeggen van welk bean ik de value wil gebruiken als tekst, zoals jij met jsf wel moet
Ik kan dus ook later met een wijziging de code het zo aanpassen dat dit html blok een textbox laat zien met progress, zonder dat ik daar de template voor hoef aan te passen... nu jij weer

[Verwijderd]

flowerp schreef op zaterdag 24 februari 2007 @ 22:40:
Omdat mijn ervaring is dat 90% van de mensen die zeggen dat JSF slecht is er geen enkele ervaring mee hebben. Je moet toegeven dat het in de Java wereld erg in de mode is om alles wat van Sun komt, behalve dan de JDK zelf, af te branden. Elk produkt uit de stal van Sun is bij voorbaat bloated, zwaar en in een ivoren toren tot stand gekomen. Het dient geen enkele functie dan vendors rijk te maken, omdat alleen zij er wat aan hebben.

Ik roep dan ook helemaal niet dat jsf slecht is. Je haalt er allemaal uitspraken bij die in dit topic simpelweg niet gemaakt zijn.
[...]

flowerp schreef op zaterdag 24 februari 2007 @ 22:40:
Dat heb ik toch al gedaan? Zie ook andere threads van mij.

Nee dat heb je niet gedaan. Je hebt enkel verteld dat jsf "mooi, uitbreidbaar, etc is", maar niet wat het toevoegd. En vergeef mij als ik daarvoor niet andere threads voor uit ga pluizen.

flowerp schreef op zaterdag 24 februari 2007 @ 22:40:
Het voordeel is een standaard web componenten framework. Dit maakt herbruikbare componenten mogelijk. Dingen als bi-directionele databindings maken een zeer elegante manier van werken mogelijk.

[..]voorbeeld knip[..]

Je legt steeds uit wat je er mooi aan vindt maar niet wat het toevoegd. Persoonlijk iets een mooie structuur vinden hebben is natuurlijk een non-argument. Struts kwam duidelijk op omdat men een probleem had met het scheiden van de logica. Spring mvc pakt het tight-coupling probleem van Struts aan. Velocity/Wicket pakken de overhead van jsp's aan. Het zijn allen frameworks die duidelijk vanuit een probleem steling een oplossing bieden. Ik heb het idee dat dit volledig mist bij jsf.

Het enige wat ik tot nu toe gehoord heb zijn "herbruikbare componenten". En dat is voor menig webapp een compleet nutteloze feature. Zoals reeds vermeld, een project bestaat uit uitzonderingen. Het realiseren van die uitzonderingen kosten in jsf gewoon ongelooflijk veel tijd. Het is niet voor niets dat pragmatische stromingen helemaal niet meer de focus leggen op herbrukbaarheid maar op "get the job done as simple as possible".

flowerp schreef op zaterdag 24 februari 2007 @ 22:40:
Daarnaast, vanwege het feit dat JSF een spec is bestaat de mogelijkheid dat vele organisaties een implementatie van JSF kunnen maken. Alleen dat al is ook een toegevoegde waarde. Het feit dat het een standaard onderdeel van Java is maakt het zeer aantrekkelijk voor anderen om zelf componenten te maken die dan iedereen kan gebruiken.

Compleet te verwaarlozen. De componenten zullen nooit precies aansluiten bij je wensen en je zult ze dus altijd moeten tweaken. Het belang van een bedrijf om uberhaupt een component te maken is vrij laag, er valt weinig aan te verdienen. Je verzand al snel in die meuk van Oracle waarbij je helemaal vastgeroest zit binnen de spullen van 1 aanbieder. Tevens, was het niet zo dat over taglibs exact hetzelfde werd geroepen...

flowerp schreef op zaterdag 24 februari 2007 @ 22:40:
Bovendien is JSF zelf een soort meta framework. In de core is het redelijk simpel, maar het dient als basis om meer geavanceerde frameworks op te bouwen, en dat dan op een manier die samenwerking belooft ipv een wildgroei van kleine frameworkjes die het wiel telkens opnieuw uitvinden. Zoals eerder gezegd, de core komt bijvoorbeeld met een hele kleine set van componenten. Meer geavanceerde kun je zelf toevoegen.

Een aantal dingen kun je ook met JSP taglibs doen, maar de manier van eventhandeling en statesaving is dan specificiek voor jouw eigen versie van een component. Samenwerking met andere JSP taglibs is dan moeilijk of onmogelijk. Juist het standaard open protocol is belangrijk.

Ik snap niet wat je hier wilt vertellen, ik zie en betoog met een conclusie die over iets heel anders gaat. Volgens mij kan ik op de plek van 'JSF' nu een willekeurig ander framework neerzetten, laten we het is proberen:

Bovendien is Struts zelf een soort meta framework. In de core is het redelijk simpel, maar het dient als basis om meer geavanceerde frameworks op te bouwen, en dat dan op een manier die samenwerking belooft ipv een wildgroei van kleine frameworkjes die het wiel telkens opnieuw uitvinden. Zoals eerder gezegd, de core komt bijvoorbeeld met een hele kleine set van componenten. Meer geavanceerde kun je zelf toevoegen.

flowerp schreef op zaterdag 24 februari 2007 @ 22:40:
En geef jij dan eens een concreet voorbeeld van wat er slecht is aan JSF? Probeer dan iets anders te zeggen als "het is zwaar, het is lomp, de kwaliteit is slecht", want dat is het soort prietpraat wat iedereen kan uiten ergens over zonder er verstand van te hebben.

Ik haal dit citaat nog maar even aan om te benadrukken dat ik jsf helemaal niet slecht vind. En uistspraken over "zwaar, lomp en slechte kwaliteit" verzin je er elke post bij, die komen niet uit mijn vingers. Ik ben enkel geinterresseerd in de vraag waarom een project team jsf zou moeten inzetten: Welk voordeel daarmee behaald wordt. Dat voordeel is er wat mij betreft niet of nauwelijks aanwezig.

[flowerp]

momania schreef op zondag 25 februari 2007 @ 01:40:

HTML:

<span wicket:id="progress"></span>

Weer standaard html, met alleen een id dat refereerd naar een bean in de code.

Standaard HTML?

Een span element dat opeens via een scoped ID magisch een progressbar wordt? Dat is toch niet standaard HTML joh?

Ik hoef niet specifiek te zeggen dat heen progressbar is, of welke bean value eraan hangt, etc. De gehele progress bar polulate ik in de code

Uhm, maar de JSF pagina -is- helemaal geen code. Dat is toch puur een layout van componenten?

In een layout van componenten wil ik natuurlijk componenten hebben, en aan de componenten bind ik events of handlers. Vele desktop technieken werken ook zo (het "visual" in Visual C++ of Visual Basic komt hier bijvoorbeeld vandaan). Het is een techniek die eigenlijk al zo oud is als de weg naar rome, maar voor het web zijn we een stukje terug in de tijd gegaan kwa manier van coden. JSF, maar ook bv ASP.NET hebben deze beproefde manier van werken terug gebracht.

Ik zeg daarbij niet primair dat Wicket onzin is. Eigenlijk wil ik helemaal niet iets slechts over Wicket zeggen!

Waar het hier om gaat is dat JSF ten opzichte van J2EE 1.4 daadwerkelijk iets toevoegd. Dat het een mooie en ellegante manier van werken is, en dat het een voordeel is dat het in een standaard is vastgelegd via een specificatie.

Of iemand anders liever Struts 2.0, Stripes, Spring MVC, Tapestry, Turbine, Cocoon, WebWork, Wicket of weet ik wat liever gebruikt is zijn of haar goed recht.

Ik kan dus ook later met een wijziging de code het zo aanpassen dat dit html blok een textbox laat zien met progress, zonder dat ik daar de template voor hoef aan te passen... nu jij weer

Hahaha Tjsa, ja... zelf -wil- ik liever mijn componenen in mijn componenten layout hebben eigenlijk. Maar in JSF kan het ook zeer zeker anders. De truuk is namelijk dat je serverside een component tree hebt, net zoals je bv die clientside ook hebt in DOM. Net zoals met Javascript kun je dus programmatisch nodes toevoegen, verwijderen, knippen, plakken etc.

Ik weet niet of dat helemaal is wat je bedoeld (en ik wil dit eigenlijk ook niet een Wicket vs JSF war laten worden, dat is welliswaar een interesante maar toch echt andere disucssie).

Anyway, als extreem voorbeeld kan ik dit in JSF doen:

XML:

<h:form binding="#{backingBean.bind}" >
  <!-- geen componenten hier -->
</h:form>

pseudo:

Java:

public void bind( UIComponent root ) {
    Button button = new UIButton();
    progressBar bar = new UIProgressBar();
    root.addChild ( button );
    root.addChild ( bar );
}

Op deze manier kan ik in code dynamisch componenten toevoegen. Via de component tree kan ik dus ook bestaande componenten (die in de layout gedefineerd zijn) opzoeken en manipuleren. Ik gebruik dat spaarzaam, maar hiermee kan ik bijvoorbeeld bij een click op een button het parent component van een andere styling voorzien in code, bv een rode achtergrond geven ofzo.

[BalusC]

^^^ posts zijn afgesplitst van [JAVA] Is het mogelijk om je poort op te vragen?.

Ik kan me grotendeels in de woorden van flowerp vinden. Maar ik ga hier verder geen woorden over vuil maken

[ Voor 37% gewijzigd door BalusC op 25-02-2007 15:47 ]

[flowerp]

Verwijderd schreef op zondag 25 februari 2007 @ 11:16:
Je legt steeds uit wat je er mooi aan vindt maar niet wat het toevoegd. Persoonlijk iets een mooie structuur vinden hebben is natuurlijk een non-argument.

Het feit dat iets een elegante (mooie) structuur heeft voegt wel degelijk iets toe. Tuurlijk wat mooi is is persoonlijk, maar blijkbaar vinden toch wel veel mensen het mooi. Als iets mooi is, -en- functioneel, dan werk je er gewoon met meer plezier mee.

Toegevoegde dingen in andere frameworks:
Struts [...]
Spring mvc [...]
Velocity/Wicket [...]

Wat JSF 'op z'n minst' deed is het beste van alle bestaande frameworks pakken en die vastleggen in een standaard. Een van de grootste kritiek punten op Java blijft dat je uit 10.000 frameworks kunt kiezen, of liever gezegd moest kiezen want in Java EE zelf zat geen web framework.

Vanaf Java EE 5 is het simpel. Je begint gewoon standaard met JSP en JSF. Dat voldoet voor heel veel dingen uitstekend. Denk je het zelf beter te weten, dan ga je natuurlijk voor Wicket.

Hmm, of mischien toch voor Spring MVC, of voor... [vul zelf maar in]

Compleet te verwaarlozen. De componenten zullen nooit precies aansluiten bij je wensen en je zult ze dus altijd moeten tweaken.

Dus in SWT of Swing schrijf jij ook -perse- je eigen tabpane, je eigen scrollbar, je eigen progressbar, je eigen ... ?

Standaard componenten (widgets) werken wel degelijk. Sommige mensen vinden het leuk om componenten te schrijven, andere bouwen liever business software. Door een standaard af te spreken over wat een component is laat je deze groepen allebei doen waar ze goed in zijn.

Volgens mij kan ik op de plek van 'JSF' nu een willekeurig ander framework neerzetten, laten we het is proberen:

[probeerd Struts te positioneren als meta framework]

Dat werkt natuurlijk niet. Struts is geen meta framework, er zijn geen andere frameworks die bouwen op Struts op de manier waarop dat in JSF gebeurd. Daarnaast is ook Struts geen standaard; er bestaat geen spec van.

[Verwijderd]

flowerp schreef op zondag 25 februari 2007 @ 16:43:
Het feit dat iets een elegante (mooie) structuur heeft voegt wel degelijk iets toe. Tuurlijk wat mooi is is persoonlijk, maar blijkbaar vinden toch wel veel mensen het mooi. Als iets mooi is, -en- functioneel, dan werk je er gewoon met meer plezier mee.

Blijft een subjectief verhaal, veel mensen vinden het minder mooi (Ik val overigens zelf onder de categorie mensen die het wel mooi vinden).

flowerp schreef op zondag 25 februari 2007 @ 16:43:
Wat JSF 'op z'n minst' deed is het beste van alle bestaande frameworks pakken en die vastleggen in een standaard. Een van de grootste kritiek punten op Java blijft dat je uit 10.000 frameworks kunt kiezen, of liever gezegd moest kiezen want in Java EE zelf zat geen web framework.

Waarop basseer je dat het beste van de genoemde frameworks in jsf zit?

flowerp schreef op zondag 25 februari 2007 @ 16:43:
Vanaf Java EE 5 is het simpel. Je begint gewoon standaard met JSP en JSF. Dat voldoet voor heel veel dingen uitstekend. Denk je het zelf beter te weten, dan ga je natuurlijk voor Wicket.
Hmm, of mischien toch voor Spring MVC, of voor... [vul zelf maar in]

Onwikkelen heeft vrij weinig te maken met het beter denken te weten. Zoals je een loodgieter geen tegels laat zetten en een php team geen java laat ontwikkelen, zo laat je ook geen prima functionerend wicket team met jsf aan de slag gaan. Het zijn drempels in het huidige ontwikkelproces die forceren dat er naar een andere techniek gekeken wordt om die drempels weg te nemen. Op dit moment heb je nog steeds niet duidelijk kunnen maken wat die drempels nu zijn die jsf met de vloer gelijk maakt.

flowerp schreef op zondag 25 februari 2007 @ 16:43:
Dus in SWT of Swing schrijf jij ook -perse- je eigen tabpane, je eigen scrollbar, je eigen progressbar, je eigen ... ?

Standaard componenten (widgets) werken wel degelijk. Sommige mensen vinden het leuk om componenten te schrijven, andere bouwen liever business software. Door een standaard af te spreken over wat een component is laat je deze groepen allebei doen waar ze goed in zijn.

De vergelijking met swt/swing gaat absoluut niet op. Een website wil zich vaak onderscheiden van andere websites, terwijl een desktop applicatie moet aansluiten bij het systeem. Een web-widget zal dus altijd moeten worden aangepast aan de wensen van een klant. En dat gaat vaak verder dan enkel wat kleurtjes en formatting.

Ja het klinkt allemaal heel rooskleurig dat alle groepen doen waar ze het beste in zijn. Maar we zullen het zien of het daadwerkelijk op significante schaal gaat gebeuren. We kunnen het wel makkelijk roepen, maar kijkend naar het verleden zien we dat dit vrij weinig gebeurd.

flowerp schreef op zondag 25 februari 2007 @ 16:43:
Dat werkt natuurlijk niet. Struts is geen meta framework, er zijn geen andere frameworks die bouwen op Struts op de manier waarop dat in JSF gebeurd. Daarnaast is ook Struts geen standaard; er bestaat geen spec van.

Als het hangt om de term "meta-framework" dan valt jsf ook af. Spring of uiteraard Keel verdienen dat label dan duidelijk wel. Het enige wat jsf zegt is: "ik wil dat je jsfs babbelt". Het zegt niet: "ja hoor, ik babbel ook <insert framework>."

En specs hebben echt niet de waarde die ze zouden moeten hebben. Ik weet niet hoeveel jaar we al html hebben, maar er is geen brouwser die het correct ondersteund. De waarde van een spec zou ik in deze dan ook niet zo zwaar aan tillen.


Maar de vraag die ik al een tijdje beantwoord probeer te krijgen, maar wat klaarblijkelijk toch een lastige is: "Welk bestaand probleem lost jsf voor mij op?"

[flowerp]

Verwijderd schreef op zondag 25 februari 2007 @ 17:29:
(Ik val overigens zelf onder de categorie mensen die het wel mooi vinden).

Nou, dan is dat tenminste een positief iets!

Waarop basseer je dat het beste van de genoemde frameworks in jsf zit?

Dat was (is) een expliciet mision statement van JSF. Sun heeft juist samenspraak met de community gezocht (doen ze trouwens altijd met JSR's) en ernaar gestreeft een best of breed samenstelling te maken uit hetgeen al in de community aanwezig was. Oa de leidende persoon achter Struts heeft veel bijgedragen aan JSF.

Daarnaast is het ook gewoon duidelijk te zien, mischien dat JSF voor sommigen ook niets toevoegd aan wat er al op de markt was, maar het blijft ook niet achter. Dat was -juist- de bedoeling. Nooit heeft ergens gestaan dat JSF een radikaal betere of slimmere techniek zou gaan worden. Vanaf het begin is gezecht dat JSF de aanwezige best practices zou gaan standaardiseren.

Het zelfde hebben ze overigens gedaan met JPA. Dat voegt ansich niets toe aan Hibernate. Sterker nog, het -is- bijna Hibernate, alleen nu vastgelegd in een spec. Voor velen is dat toch een groot voordeel.

zo laat je ook geen prima functionerend wicket team met jsf aan de slag gaan.

Maar waar zeg ik dat Wicket mensen op JSF moeten overgaan?

Een Wicket team, zeker als het prima functioneerd, heeft die keuze al lang geleden gemaakt en kan lekker doorgaan met Wicket gebruiken.

JSF is er juist als de default view techniek in Java EE; een goede default keuze voor iniedergeval de nieuwkomers. Dat wil niet zeggen dat JSF alleen voor nieuwkomers is. Ook geavanceerde developers kunnen voor JSF kiezen, maar die zullen wellicht de 100 andere bestaande frameworks ook meenemen in hun overweging.

Op dit moment heb je nog steeds niet duidelijk kunnen maken wat die drempels nu zijn die jsf met de vloer gelijk maakt.

De keuze tussen 100 andere frameworks mischien? Dat is -echt- een drempel voor heel veel mensen.

Een website wil zich vaak onderscheiden van andere websites, terwijl een desktop applicatie moet aansluiten bij het systeem.

Dat is toch wel vrij grote onzin.

Ten eerste alsof een desktop applicatie zich niet zou willen onderscheiden t.o.v. z'n concurenten, en ten tweede is juist een consequente look wat mensen willen. Niets rare kunstzinnige flash websites, maar gewoon blauwe linkjes, search box rechtsboven in, menu links, etc etc. (ik noem maar wat op, maar ik weet dat onze webdesigners een hele reeks regels hebben waaraan websites moeten voldoen om door users makkelijk gevonden te worden, zie ook het boekje "don't make me think": http://www.amazon.com/Don...k-Usability/dp/0789723107)

Ja het klinkt allemaal heel rooskleurig dat alle groepen doen waar ze het beste in zijn. Maar we zullen het zien of het daadwerkelijk op significante schaal gaat gebeuren. We kunnen het wel makkelijk roepen, maar kijkend naar het verleden zien we dat dit vrij weinig gebeurd.

Nou, voor ASP.NET (die wat eerder hiermee begonnen) zijn er al vrij veel componenten te krijgen. Voor JSF komt het overduidelijk op gang. Voor desktop toolkits (MFC, Qt, GTK, etc) zijn er meer voorbeelden te vinden dan ik zou kunnen opnoemen.

Als het hangt om de term "meta-framework" dan valt jsf ook af. Spring of uiteraard Keel verdienen dat label dan duidelijk wel. Het enige wat jsf zegt is: "ik wil dat je jsfs babbelt". Het zegt niet: "ja hoor, ik babbel ook <insert framework>."

Je snapt het niet. De term "meta-framework" slaat er op dat je binnen de onderliggende architectuur veel uitbreidingen kunt doen. Default maak je een layout d.m.v. taglibs en een JSP template. Echter, de spec vermeld nadrukkelijk dat dit niet de enige mogelijkheid is. Daardoor dat er ook zoiets als Faceles kon ontstaan. JSF is agnostic voor welke template engine er gebruikt wordt. Ook is JSF output agnostic. Binnen de zelfde architectuur kun je ook totaal andere renderings maken. Iemand kan met een SVG renderkit en bijbehorende widgets een SVG rendering maken gebasseerd op een XUL layout.

Daarnaast is bijna alles in JSF pluggable. Daardoor is ook zoiets als Seam mogelijk, en kan zelfs Spring nog wat leuke truukjes uithalen. Hoe JSF van een view ID naar een component tree gaat is pluggable, hoe en waar JSF state opslaat is pluggable, etc etc. Dit zijn allemaal core functionaliteiten die je kunt vervangen of uitbreiden.

De gewone gebruiker zal -natuurlijk-(!) deze dingen niet gaan vervangen en moet dat ook niet willen, maar voor framework bouwers biedt het zeer veel handvaten. Daarom kun je JSF dus een meta framework noemen; het bevat tools en mogelijkheden om andere frameworks mee te bouwen. Hoe leuk je Struts ook kunt uitbreiden door slimme hacks, het is niet expliciet bedoeld als tool om andere frameworks mee te bouwen.

Ik weet niet hoeveel jaar we al html hebben, maar er is geen brouwser die het correct ondersteund. De waarde van een spec zou ik in deze dan ook niet zo zwaar aan tillen.

[Verwijderd]

Ik kort hier en daar even wat in hoor, anders worden het van die lappen tekst.

flowerp schreef op zondag 25 februari 2007 @ 18:39:
Dat was (is) een expliciet mision statement van JSF. [...]
Daarnaast is het ook gewoon duidelijk te zien, mischien dat JSF voor sommigen ook niets toevoegd aan wat er al op de markt was, maar het blijft ook niet achter. [...] Vanaf het begin is gezecht dat JSF de aanwezige best practices zou gaan standaardiseren.

Het zelfde hebben ze overigens gedaan met JPA. Dat voegt ansich niets toe aan Hibernate. Sterker nog, het -is- bijna Hibernate, alleen nu vastgelegd in een spec. Voor velen is dat toch een groot voordeel.[...]

Conclusie: Het lost dus 'voor velen' niets op. Sterker nog, door de extra abstractie is de overhead enkel toegenomen. Het lijkt me dat een goed framework juist werk uit handen neemt.

flowerp schreef op zondag 25 februari 2007 @ 18:39:
Maar waar zeg ik dat Wicket mensen op JSF moeten overgaan?
[...]
JSF is er juist als de default view techniek in Java EE; een goede default keuze voor iniedergeval de nieuwkomers. Dat wil niet zeggen dat JSF alleen voor nieuwkomers is. Ook geavanceerde developers kunnen voor JSF kiezen, maar die zullen wellicht de 100 andere bestaande frameworks ook meenemen in hun overweging.

"waar zeg ik dat jij zegt dat wicket mensen.. bla bla" Ik maakte die vergelijking om aan te geven dat het weinig zin heeft om naar jsf te kijken. Ik denk dat nieuwkomers juist helemaal niet gebaat zijn bij jsf. Je schuift je logica achter allemaal abstracte lagen, daarbij neemt de kans dat je het verkeerd doet alleen maar toe.

flowerp schreef op zondag 25 februari 2007 @ 18:39:
Ten eerste alsof een desktop applicatie zich niet zou willen onderscheiden t.o.v. z'n concurenten, en ten tweede is juist een consequente look wat mensen willen. Niets rare kunstzinnige flash websites, maar gewoon blauwe linkjes, search box rechtsboven in, menu links, etc etc. (ik noem maar wat op, maar ik weet dat onze webdesigners een hele reeks regels hebben waaraan websites moeten voldoen om door users makkelijk gevonden te worden, zie ook het boekje "don't make me think": http://www.amazon.com/Don...k-Usability/dp/0789723107)

Wat mensen willen (bezoekers) is niet hetzelfde als wat marketing wil. Het is wel naief om te denken dat klanten(website eigenaren) eenheidsworst willen. Dus nee wat ik zei is geen onzin.

flowerp schreef op zondag 25 februari 2007 @ 18:39:
Nou, voor ASP.NET (die wat eerder hiermee begonnen) zijn er al vrij veel componenten te krijgen. Voor JSF komt het overduidelijk op gang. Voor desktop toolkits (MFC, Qt, GTK, etc) zijn er meer voorbeelden te vinden dan ik zou kunnen opnoemen.

Dus de 100 verschillende frameworks die zo hoogdrempelig zouden zijn verplaatsen zich nu naar de componenten. Ik vind het geen vooruitgang.

flowerp schreef op zondag 25 februari 2007 @ 18:39:
Je snapt het niet. De term "meta-framework" slaat er op dat je binnen de onderliggende architectuur veel uitbreidingen kunt doen.

Nee, jij snapt het niet. een meta-framework zorgt voor een transparante wisselwerking tussen andere componenten/frameworks. Als ik voor de wisselwerking dingen moet doen (lees code typelen) dan is alles een meta-framework.

flowerp schreef op zondag 25 februari 2007 @ 18:39:

[flowerp]

Verwijderd schreef op zondag 25 februari 2007 @ 19:11:
Ik kort hier en daar even wat in hoor, anders worden het van die lappen tekst.
[...]
Conclusie: Het lost dus 'voor velen' niets op.

Toch wel, omdat de andere frameworks wellicht niet altijd alles tegelijk bieden.

Sterker nog, door de extra abstractie is de overhead enkel toegenomen.

Er is in JSF zowieso niet meer abstractie dan het geen je al ziet in diverse bestaande frameworks. Daarnaast is de abstractie niet iets wat overhead veroorzaakt. Of je nu 5 of 10 methods in je stacktrace hebt staan (want dat is waarmee abstractie primair je systeem belast), is vrij irrelevant in de huidige systemen. De meeste abstractie lagen ansich doen namelijk niet bijster veel (zwaar) werk. Zie het als een functie die je opdeeld in 2 andere functies:

Java:

public void myMethod () {

   statement1;
   statement2;
   // ...
   statement n;
}

vs

Java:

public void myMethod() {
   doBar();
   doFoo();
}

public void doBar() {
   statement1;
   statement2;
   // ...
   statementHalfOfN;
}

public void doFoo() {
   statementHalfOFNPlus1;
   // ...
   statementN
}

Moderne systemen blazen door dit soort abstractie lagen alsof het niets is.

Op welke specificieke overhead in JSF doel je precies?

Ik denk dat nieuwkomers juist helemaal niet gebaat zijn bij jsf. Je schuift je logica achter allemaal abstracte lagen, daarbij neemt de kans dat je het verkeerd doet alleen maar toe.

Voor de echte beginners valt dat ook wel mee. Heb je wel een het geprutst gezien wat ze nu in PHP of JSP + scriptlets bakken? JSF duwt ze tenminste meteen al in de richting van een correct model. Er kan ook in situaties minder mis gaan. Een beginner plaatst gewoon een kant en klare progressbar op z'n page. Laat je een beginner echter dit zelf maken, met onderhuidse AJAX calls, verbindingen tussen javascript variablen en jsp variablen (waarbij ze altijd denken dat je meteen de waarde toekent, en niet bij stil staan dat het via een text representatie gaat), etc etc zijn er -veel- meer fouten te maken.

Daarnaast gaat het ook om mensen die best wel kunnen programmeren, die met MFC hebben gewerkt of met Qt, of met Asp.net. Die komen nieuw in Java aan en worden GEK van al die keuzen die ze moeten maken.

JSF biedt dan een zeer aardige default keuze waar je je moeilijk een buil aan kunt vallen. Mischien is Wicket beter, maar als iemand gewoon met JSF begonnen is is dat zeker ook geen slechte keuze.

Wat mensen willen (bezoekers) is niet hetzelfde als wat marketing wil. Het is wel naief om te denken dat klanten(website eigenaren) eenheidsworst willen.

Ten eerste is een klant niet altijd een website eigenaar. Je kunt ook gewoon websites (web applicaties) bouwen en die zelf exploiteren toch? Of denk je dat bijvoorbeeld Hyves haar website laat ontwikkelen door 3den?

Ten tweede wil iemand dat zijn website wat oplevert. Als je een webshop hebt wil je dat mensen kopen, en dat bereik je alleen door een consequente interface die gelijk is aan andere sites. Laat mensen niet hoeven na te denken hoe ze iets bij jou moeten bestellen.

Dus de 100 verschillende frameworks die zo hoogdrempelig zouden zijn verplaatsen zich nu naar de componenten. Ik vind het geen vooruitgang.

Ik wel. Componenten kun je door elkaar gebruiken, binnen hetzelfde framework. Eens gekozen voor een framework kun je niet zomaar wisselen. Als voorbeeld, vroeger gebruikte ik de standaard JSF datatable. Daar zaten wat nadelen aan. Ik kon deze echter zo vervangen door de Tomahawk versie.

Standaard componenten model... geen probleem dus

[Verwijderd]

flowerp schreef op zondag 25 februari 2007 @ 19:44:
Op welke specificieke overhead in JSF doel je precies?

Op de overhead van bestanden die je moet onderhouden natuurlijk. Het loskoppelen van problemen is iets waar ik zelf een groot voorstander van ben, maar ik ben me gelijktijdig wel bewust van het feit dat een applicatie er niet transparanter door wordt. De workflow van een standaard php is gewoon ongelooflijk transparant en door de meeste ontwikkelaars echt prima te volgen. Voor een simpel jsf formulier met convertors, validator, action handlers, etc, moet je toch alle kanten op springen.

flowerp schreef op zondag 25 februari 2007 @ 19:44:
JSF duwt ze tenminste meteen al in de richting van een correct model. Er kan ook in situaties minder mis gaan.

Jsf duwt helemaal niemand in de juiste richting. Dat is nog altijd de programmeur. Een programmeur die nu de gehele filosofie van een jsf als bagage bij zich moet hebben.

flowerp schreef op zondag 25 februari 2007 @ 19:44:
JSF biedt dan een zeer aardige default keuze waar je je moeilijk een buil aan kunt vallen. Mischien is Wicket beter, maar als iemand gewoon met JSF begonnen is is dat zeker ook geen slechte keuze.

Maar dit argument geldt dan ook voor een willekeurig in te vullen framework.

flowerp schreef op zondag 25 februari 2007 @ 19:44:
Ten eerste is een klant niet altijd een website eigenaar. Je kunt ook gewoon websites (web applicaties) bouwen en die zelf exploiteren toch? Of denk je dat bijvoorbeeld Hyves haar website laat ontwikkelen door 3den?

En wat is je punt, want dat je niet alles over een kam kan scheren is 'common knowledge' en dus ook vrij zinloos om aan te halen.

flowerp schreef op zondag 25 februari 2007 @ 19:44:
Ten tweede wil iemand dat zijn website wat oplevert. Als je een webshop hebt wil je dat mensen kopen, en dat bereik je alleen door een consequente interface die gelijk is aan andere sites. Laat mensen niet hoeven na te denken hoe ze iets bij jou moeten bestellen.

Je hoeft mij niet te vertellen waar de uiteindelijke gebruiker het meest bij gebaat is. Maar wat je als ontwikkelaar graag ziet is nou eenmaal verre van de werkelijkheid. De werkelijkheid is simpelweg dat sites verschillen en dat de klant dat ook nog eens graag wil.

flowerp schreef op zondag 25 februari 2007 @ 19:44:
Ik wel. Componenten kun je door elkaar gebruiken, binnen hetzelfde framework. Eens gekozen voor een framework kun je niet zomaar wisselen. Als voorbeeld, vroeger gebruikte ik de standaard JSF datatable. Daar zaten wat nadelen aan. Ik kon deze echter zo vervangen door de Tomahawk versie.

Ik heb eens in een hobby project geswitched van jsp naar velocity. Geen probleem. Maar even zonder dolle, wisselen van implementatie is echt een zwaar overated feature. Als je tijdens de ontwikkeling van een project 10 keer van implementatie moet wisselen dan moet je je toch eens gaan afvragen of je wel goed bezig bent. En nee, het gaat niet om het feit dat het kan, het betekent enkel dat ik een onnodige abstractie laag tussen mijn logica en view heb zitten.


_{Nog even voor de duidelijkheid: jsf vind ik een mooie techniek. Maar mijn persoonlijke mening en zakelijke mening komen niet altijd overeen. Mijn zakelijke mening hierin is gewoon een pragmatische, en dat is wat ik hier op het moment neerzet.}

[flowerp]

Verwijderd schreef op zondag 25 februari 2007 @ 20:36:
[...]
Op de overhead van bestanden die je moet onderhouden natuurlijk.

En dat is een specificiek nadeel van JSF???

De workflow van een standaard php is gewoon ongelooflijk transparant en door de meeste ontwikkelaars echt prima te volgen

???

Ik weet niet helemaal hoe ik dit moet rijmen met eerdere comments van jou in threads als Imago, toekomst en mogelijkheden: Java, .NET of PHP?.

Maar als we het alleen op deze thread houden dan stel je eerst dat JSF als framework niets toevoegd, en nu zeg je eigenlijk dat we maar helemaal geen frameworks moeten gebruiken en dat we aan de PHP moeten?

En ongelooflijk transparant? Ongelooflijke spaghetti zul je bedoelen! Heb je wel eens PHP pagina's (of JSP's in PHP-style) moeten doorlezen of onderhouden? In een 2 pagina web site'je is het mischien nog te overzien, maar bij elke niet triviale web applicatie wordt het al ongelooflijk snel een ongelooflijke grote berg spaghetti. Meestal wordt aan het begin van de page 20 parameters uit de request gehaald, daarna vinden er batterijen testen plaats en wordt van alles aan nieuwe variabelen toegekent. Daarna staat er een stuk business logic, met weer nieuwe variablen en testen, dan wordt er nog een SQL query gedraait, en vervolgens wordt er geittereerd ergens over en HTML geoutput.

Alleen zijn die plekken waar HTML naar de response gaat niet allemaal op het einde. Een dergelijke pagina kan meestal aan de hand van de uitkomst van testen diverse compleet andere pagina's worden. De benodigde HTML staat dan op alle mogelijke plekken. 1 gehele pagina zie je er dan ook met geen mogelijkheid in.

Ook heel leuk zijn al die verschillende parameters die uit de request gehaald worden. Sommige komen van externe bronnen, maar sommige worden op de pagina's zelf als postback gebruikt. Bij hergebruik van (stukken van) de pagina weet je nooit wat nou wel of niet meegenomen moet worden, en zit je een half uur variablen te tracken om te zien wat waar vandaan komt.

Helemaal lachen wordt het met het hergebruik van validatie code en helemaal business code. Die staat midden op elke pagina en moet dus bij gebruik elders telkens copy-pasted worden. Moet er iets veranderd worden, dan mag dat handmatig op elke pagina apart. Dit gebeurd nooit op identieke wijze, zodat je overal kleine inconsistenties krijgt.

Ik heb een vrij lange tijd 'het geluk' gehad om diverse projecten te mogen waar men op een dergelijke manier werkte. Pure JSP's + scriptlets of PHP pagina's gaan bijna altijd automatisch na verloop van tijd naar een dergelijke structuur. Vergeleken met die pagina's is JSF een verademing vergelijkbaar toen we op de x86 niet meer met 16bit segmenten hoefte te programmeren. De enige die JSF in dat licht gezien niet leuk vond was onze lokale drogisterij. De omzet van hoofdpijnstillers nam radikaal af nadat wij op JSF overstapte.

. Voor een simpel jsf formulier met convertors, validator, action handlers, etc, moet je toch alle kanten op springen.

Die vind ik juist enorm clean. Op de template pagina staat alleen maar een grafische layout van componenten. Validators zijn juist enorm clean en simpel. Zie mijn voorbeeld hierboven, wat is er nou moeilijk aan dat je b.v. meteen bij een input element de range instelt met een tag?

Vergelijk dat met de JSP+scriptlet way, waar je de lezer van je pagina blootstelt aan namen van parameters die eigenlijk private (intern) zouden moeten zijn voor het impliciete 'component' wat je probeerd te maken. Dan ga je opeens meerdere testen doen op de variable, maar door alle andere coden op de page zie je niet meteen dat het een validatie betreft. Soms is er ook wat meer logica nodig dan alleen een simpele if test. De clutter die dat veroorzaakt is vrij groot.

Jsf duwt helemaal niemand in de juiste richting. Dat is nog altijd de programmeur.

JSF doet dat wel degelijk. In JSP + scriptlets (of PHP) is de sky the limit. Je hebt de ultieme vrijheid. Helaas kunnen de meesten programmeurs niet zo goed met die vrijheid om gaan. In JSF heb je zowieso al een scheiding tussen je layout, je navigation rules, en je busines logic.

Een programmeur die nu de gehele filosofie van een jsf als bagage bij zich moet hebben.

Gelukkig is die "filosofie" dan wel vrij standaard, namelijk gewoon het MVC model met daaraan gekoppeld de logische Composite en Observer design patterns. Een hele mond vol met technische termen, maar in de praktijk werkt het erg makkelijk. Bijna elke desktop toolkit is opgebouwd rond deze 3 hoekstenen en miljoenen programmeurs werken hier mee. Het is ook voortgekomen uit jarenlange eerdere ervaring met andere programmeer modellen.

Toen web applicaties in kwamen was er helaas niet direct support voor deze manier van ontwikkelen. Dat kwam voornamelijk omdat het web eigenlijk helemaal niet bedoeld was om "web applicaties" te ondersteunen. Het programmeer model was dan ook een flinke stap terug.

Maar dit argument geldt dan ook voor een willekeurig in te vullen framework.

Als dat willekeurige framework gebundeld was met standaard Java EE wel, anders niet. 'Toevallig' is JSF gebundeld met standaard Java EE en daarmee de eerste en makkelijkste keuze voor iemand.

Ik heb eens in een hobby project geswitched van jsp naar velocity. Geen probleem. Maar even zonder dolle, wisselen van implementatie is echt een zwaar overated feature.

Wisselen van een gehele JSF implementatie zul je niet zo snel doen, maar het is veilig om te weten dat er meedere vendors voor dezelfde spec zijn.

Dat was echter niet waar het punt om ging. Jij stelde dat je ipv wisselen tussen frameworks, bij JSf moet kiezen tussen componenten libs. Dat is echter zeker niet hetzelfde. Bij een framework wissel (bv tapestry naar webwork) moet je -alles- wisselen. Bij componenten kun je gewoon specifieke componenten uit diverse libs door elkaar heen gebruiken. Dat kan en is nadrukkelijk geen bad practice. Sterker nog, het is de hele reden waarom er een componenten spec is; een universele API om componenten samen te laten werken.

Je kunt gewoon de datatable van tomahawk met de inputtext van de RI gebruiken en daaronder nog de progressbar uit de BP lib.

Geen probleem...

De voordelen van een universele componenten spec.

Ga jij maar eens proberen om op 1 pagina Struts, WebWork en Wicket samen te laten werken. Dat is niet alleen moeilijk, het is dikwijls ook nog eens onzinnig en wordt door velen gezien als een bad practice.

Conclusie: kiezen tussen frameworks is nadrukkelijk niet hetzelfde als kiezen tussen component libs.

[RobIII]

Dit lijkt me meer een discussie voor SEA
PRG>>SEA

[chris]

Verwijderd schreef op zondag 25 februari 2007 @ 20:36:
Op de overhead van bestanden die je moet onderhouden natuurlijk. Het loskoppelen van problemen is iets waar ik zelf een groot voorstander van ben, maar ik ben me gelijktijdig wel bewust van het feit dat een applicatie er niet transparanter door wordt. De workflow van een standaard php is gewoon ongelooflijk transparant en door de meeste ontwikkelaars echt prima te volgen. Voor een simpel jsf formulier met convertors, validator, action handlers, etc, moet je toch alle kanten op springen.

Hier ben ik ook wel erg benieuwd naar. Ik kan er niet echt chocola van maken. Wat bedoel je precies met bestanden onderhouden? En maak je nou echt de vergelijking tussen php en jsf? Ja, je kan met beide webpagina's schrijven, maar er zit nogal een groot verschil tussen. En ik denk dat je in JSF makkelijker een formulier met converters, validators, action handlers en Ajax doet dan in PHP. En ik heb jaren lang in PHP gewerkt, en nog maar een paar keer met JSF.

PHP is erg leuk en simpel als je een applicatie wil bouwen die niet al te complex is met een beperkt aantal developers. Zo gauw je applicatie echt groot wordt wil je toch meer dingen automatisch gaan doen. Zo wil je strong typing, goede (gratis?) IDE's, mogelijkheid tot aansluiting op bestaande componenten (erg belangrijk), goede unit-testing support, etc.

Ik ken ook veel meer grote bedrijven die Java gebruiken dan PHP. Natuurlijk zijn er ook zat bedrijven die PHP gebruiken, maar het staat volgens mij niet in verhouding. Daar zijn goede redenen voor.

[Verwijderd]

flowerp schreef op maandag 26 februari 2007 @ 00:29:
En dat is een specificiek nadeel van JSF???

Nee dat zeg ik toch helemaal niet. Ik wordt er echt een beetje moe van dat je absoluut geen moeite doet om ook maar enigszins begrijpend te lezen. Ik heb het over de toegevoegde waarde, additioneel op de meuk die we al hebben. Die is nihil. En dat blijf je feitelijk bevestigen met ongelooflijke lappen tekst over wat jij er zo mooi aan vind. Maar dat jij ergens van onder de indruk bent is absoluut geen argument dat het ingezet moet worden op een project. En ik ben dus opzoek naar goede argumenten waarom je het in zou moeten zetten. Maar die argumenten blijven uit.

flowerp schreef op maandag 26 februari 2007 @ 00:29:
Ik weet niet helemaal hoe ik dit moet rijmen met eerdere comments van jou in threads als Imago, toekomst en mogelijkheden: Java, .NET of PHP?.

Dat valt prima te rijmen, ik heb het daar juist over een samenvoeging van talen. Het beste uit elke wereld. Niet zo starrig blijven zweren bij 1 techniek zonder dat je het objectief kunt onderbouwen.

flowerp schreef op maandag 26 februari 2007 @ 00:29:
Maar als we het alleen op deze thread houden dan stel je eerst dat JSF als framework niets toevoegd, en nu zeg je eigenlijk dat we maar helemaal geen frameworks moeten gebruiken en dat we aan de PHP moeten?

En ongelooflijk transparant? Ongelooflijke spaghetti zul je bedoelen!

Wat ongelooflijke zwart-wit houding, er dient altijd gezocht te worden naar een juiste balans.

En tevens weer zo'n compleet non argument "spaghetti zul je bedoelen". Beetje populistisch geblaat. Transparant in de zin dat je logica simpelweg in 1 bestand staat. Doorgaans toch wel door een willekeurige ontwikkelaar prima te begrijpen.

[Confusion]

Verwijderd schreef op maandag 26 februari 2007 @ 07:44:
En tevens weer zo'n compleet non argument "spaghetti zul je bedoelen". Beetje populistisch geblaat.

Nou, na een paar keer geprobeerd te hebben een populair stuk PHP code te hacken, heb ik het opgegeven. Er was telkens werkelijk geen touw aan vast te knopen, zelfs als de ontwikkelaars 'code is poetry' als motto hebben. Een fatsoenlijke scheiding tussen presentatie en logica zou een hoop helpen.

[Alarmnummer]

Persoonlijk krijg ik nog steeds een enorme hoofdpijn van eigelijk alle java presentation layer frameworks. Ik krijg hoofdpijn van Spring MVC (laatst een halve dag bezig geweest om een klant op weg te helpen) maar als ik naar de alternatieven kijk dan heb ik nog steeds niet iets van 'woehoe'. Het beste dat ik de afgelopen tijd heb gezien is GWT, en voor applicaties met niet al te veel gebruikers (typische intranet apps) ga ik het zeker overwegen. In de rest van de gevallen laat ik die nare taak liever over aan andere mensen.

ps:
Ik heb gebruikt:
Spring-MVC (erg uitgebreid en daarom ook vrij ingewikkeld)
Maverick (wel erg spartaans)
Wicket
Tapestry (per release meer bloat)
Struts (bah)

*is meer een backend programmeur*

Mensen vinden concurrency control complex.. nou.. als je uit de voeten kunt met al die presentation layer frameworks (en al dat gepiel met Strings) dan moet concurrency control peanuts zijn.

[ Voor 4% gewijzigd door Alarmnummer op 26-02-2007 10:18 ]

[Marcj]

Confusion schreef op maandag 26 februari 2007 @ 08:57:
[...]

Nou, na een paar keer geprobeerd te hebben een populair stuk PHP code te hacken, heb ik het opgegeven. Er was telkens werkelijk geen touw aan vast te knopen, zelfs als de ontwikkelaars 'code is poetry' als motto hebben. Een fatsoenlijke scheiding tussen presentatie en logica zou een hoop helpen.

Ik heb laast met symfony gewerkt en ik moet zeggen dat het daar wel gehoorlijk goed gedaan is. Hierbij is het MVC model wel goed toegepast in PHP met object orientatie. Al zou ik voor grotere projecten niet graag PHP willen gebruiken, alleen al omdat het niet gecompileerd wordt zoals java.

Verder moet ik eerlijk zeggen dat ik als student (bijna afgestudeerd ) nog niet veel ervaring heb met grotere projecten, waarbij iets als JSF oid nodig was. Dit is wel iets wat ik hierna mee wil gaan proberen te werken natuurlijk

edit: Heeft iemand al ervaring met Struts 2? Dit ziet er zo op het eerste gezicht wel mooi uit.

[ Voor 6% gewijzigd door Marcj op 26-02-2007 09:55 ]

[momania]

Marcj schreef op maandag 26 februari 2007 @ 09:54:
[...]
edit: Heeft iemand al ervaring met Struts 2? Dit ziet er zo op het eerste gezicht wel mooi uit.

Het is niet echt een veel beter framework geworden imo. Er zijn wel wat verbeteringen in aangebracht, maar je bent met een framework als Struts(2) gewoon te veel bezig met zaken waar je je helemaal niet mee bezig wilt houden. (request, response, session, etc)

[Schweino]

offtopic:
(wegens gebrek aan DM of e-mail): Mark Platvoet, wat heb je voor avatar?

[Tijgertje84]

Java Web Frameworks...

Alhoewel ik in mijn topicpost wel een overzichtje heb met alle frameworks en is mijn doel misschien algemener....

[ Voor 12% gewijzigd door Tijgertje84 op 26-02-2007 16:37 ]

[Confusion]

Aangezien de discussie een beetje geluwd lijkt en gezien het onderwerp van dit topic: iemand ervaring met het 'nieuwste' grote broertje in de Apache web-framework familie: Shale?

[JKVA]

Confusion schreef op maandag 26 februari 2007 @ 17:14:
Aangezien de discussie een beetje geluwd lijkt en gezien het onderwerp van dit topic: iemand ervaring met het 'nieuwste' grote broertje in de Apache web-framework familie: Shale?

Ik heb er voor mijn huidige project weleens een PoCje mee gedaan, maar dat is alweer een jaar geleden en toen was de tooling support/kwaliteit nog zeer matig. Er zitten wel handige dingen in, zoals een page init systeem en een dialog framework.

Maar dat zit ook in Apache Trinidad. Ik ken de Apache mentor van dat project en die wist te melden dat ze tegen een release aan zitten, dus ik probeer Shale niet meer denk ik. Ik ga meteen over op Trinidad...

[Confusion]

Trinidad is toch 'niets anders' dan JSF geimplementeerd als Apache MyFaces en de componenten die Oracle gedoneerd heeft? Dat blijft, in feite, redelijk 'plain' JSF toch? Ik had de indruk gekregen dat Shale weer een stapje verder in gebruiksvriendelijkheid ging; ik heb in ieder geval iemand enthouasiast gehoord over Shale's 'Clay'. Overigens heb ik het idee dat dat redelijk veel op Wicket lijkt, in de zin dat je componenten alleen een 'jsfid' geeft en verder HTML babbelt.

[JKVA]

Confusion schreef op dinsdag 27 februari 2007 @ 08:52:
Trinidad is toch 'niets anders' dan JSF geimplementeerd als Apache MyFaces en de componenten die Oracle gedoneerd heeft? Dat blijft, in feite, redelijk 'plain' JSF toch? Ik had de indruk gekregen dat Shale weer een stapje verder in gebruiksvriendelijkheid ging; ik heb in ieder geval iemand enthouasiast gehoord over Shale's 'Clay'. Overigens heb ik het idee dat dat redelijk veel op Wicket lijkt, in de zin dat je componenten alleen een 'jsfid' geeft en verder HTML babbelt.

Ja ok, maar daar gebruik ik Facelets voor. Super extensie voor JSF. Ik kan niet meer zonder.Het werkt stukken fijner dan JSP. Eigenlijk niet vergelijkbaar zelfs, zo groot is het verschil.

---

https://facelets.dev.java.net/

[ Voor 2% gewijzigd door JKVA op 27-02-2007 12:40 . Reden: ff de url erbij gezet. :) ]

[flowerp]

Confusion schreef op dinsdag 27 februari 2007 @ 08:52:
Trinidad is toch 'niets anders' dan JSF geimplementeerd als Apache MyFaces en de componenten die Oracle gedoneerd heeft?

Nee, volgens mij niet helemaal. Trinidad is ten eerste niet een JSF implementatie zelf. Het draait gewoon op Myfaces, en in principe op elke andere JSF implementatie (waaronder dus de RI). De ADF componenten donatie van Oracle zijn in het project opgenomen. Net zoals veel mensen hier anti-Sun zijn (omdat het een groot bedrijf is), zijn er ook sommige mensen automatisch anti-Oracle. Vandaar dat de ADF componenten hernoemt zijn naar Tobago. Het geheel heet dan Trinidad & Tobago.

Dat blijft, in feite, redelijk 'plain' JSF toch?

Ik heb Trinidad zelf nog niet gebruikt, maar het is wel duidelijk dat het niet zomaar just another componenten set is. 1 van de opmerkelijke dingen is dat het met een layout manager komt. Ik wilde dit al eerder in deze thread noemen, maar in vergelijking met traditionele desktops toolkits is dat iets wat nog mist in JSF. Ten tweede gebruikt deze componenten lib ook z'n eigen renderkit en dat is dan ook meteen de enige renderkit die supported wordt.

Dit zal ongetwijfeld een groot voordeel hebben, maar het nadeel is wel dat een layout die je met trinidad & tobaco componenten maakt als een geheel andere layout wordt gezien dan bv HTML (vergelijkbaar met b.v. de SWT, XUL en Telnet render targets). Het gevolg is dat je dus (voor zover ik weet) niet trinidad met componenten uit andere libs kunt mixen. Tenzij er natuurlijk ook andere componenten komen die de specifieke renderkit van Trinidad supporten.

Hierboven zei ik dat kiezen tussen componenten libs niet zoiets is als kiezen tussen frameworks, maar bij trinidad komt het er dus inderdaad wel een beetje op neer. Een beetje omdat je op 1 bepaalde pagina alleen maar Trinidad componenten mag gebruiken, maar al je andere JSF stuff (backing beans, navigation rules, view handlers, converters, etc) kun je gewoon blijven gebruiken.

Dit alles wel op voorbehoud van correctheid. Zoals ik al zei, ik heb trinidad nog zelf niet geprobeerd maar volg het al wel een tijdje.

Wat opzich een indirect nadeel is aan het Trinidad project is dat het Myfaces team maar een beperkt aantal resources heeft. Hun JSF implementatie (Myfaces) is op een wat oudere pre-release versie blijven hangen. Dit is kwa specs een versie voor de versie die officieel in Java zelf zit. Vanwege Trinidad en eigenlijk ook vanwege Tomahawk staat die officiele JSF versie (1.2) op een vrij laag pitje. Er gebeurd wel iets, maar echt spectaculair is het niet op dat gebied.

[JKVA]

flowerp schreef op dinsdag 27 februari 2007 @ 23:22:
[...]
Nee, volgens mij niet helemaal. Trinidad is ten eerste niet een JSF implementatie zelf. Het draait gewoon op Myfaces, en in principe op elke andere JSF implementatie (waaronder dus de RI). De ADF componenten donatie van Oracle zijn in het project opgenomen. Net zoals veel mensen hier anti-Sun zijn (omdat het een groot bedrijf is), zijn er ook sommige mensen automatisch anti-Oracle. Vandaar dat de ADF componenten hernoemt zijn naar Tobago. Het geheel heet dan Trinidad & Tobago.

Dat is waar. Eén van de doelstellingen van Trinidad is 100% implementatie onafhankelijkheid en als ik me niet vergis, is dat momenteel het geval.
Qua naamgeving weet ik het niet zeker, volgens mij gaat het gewoon naast Tobago en Tomahawk draaien, onder MyFaces. De kans bestaat ook nog dat het een top level project wordt, maar dat lijkt me sterk.

[...]
Ik heb Trinidad zelf nog niet gebruikt, maar het is wel duidelijk dat het niet zomaar just another componenten set is. 1 van de opmerkelijke dingen is dat het met een layout manager komt. Ik wilde dit al eerder in deze thread noemen, maar in vergelijking met traditionele desktops toolkits is dat iets wat nog mist in JSF. Ten tweede gebruikt deze componenten lib ook z'n eigen renderkit en dat is dan ook meteen de enige renderkit die supported wordt.

Dit zal ongetwijfeld een groot voordeel hebben, maar het nadeel is wel dat een layout die je met trinidad & tobaco componenten maakt als een geheel andere layout wordt gezien dan bv HTML (vergelijkbaar met b.v. de SWT, XUL en Telnet render targets). Het gevolg is dat je dus (voor zover ik weet) niet trinidad met componenten uit andere libs kunt mixen. Tenzij er natuurlijk ook andere componenten komen die de specifieke renderkit van Trinidad supporten.

Idd, een Telnet client zit er ook in. Hoe verzinnen ze het.

Hierboven zei ik dat kiezen tussen componenten libs niet zoiets is als kiezen tussen frameworks, maar bij trinidad komt het er dus inderdaad wel een beetje op neer. Een beetje omdat je op 1 bepaalde pagina alleen maar Trinidad componenten mag gebruiken, maar al je andere JSF stuff (backing beans, navigation rules, view handlers, converters, etc) kun je gewoon blijven gebruiken.

Dit alles wel op voorbehoud van correctheid. Zoals ik al zei, ik heb trinidad nog zelf niet geprobeerd maar volg het al wel een tijdje.

Dat is ook mijn idee. Eveneens onder voorbehoud.

Wat opzich een indirect nadeel is aan het Trinidad project is dat het Myfaces team maar een beperkt aantal resources heeft. Hun JSF implementatie (Myfaces) is op een wat oudere pre-release versie blijven hangen. Dit is kwa specs een versie voor de versie die officieel in Java zelf zit. Vanwege Trinidad en eigenlijk ook vanwege Tomahawk staat die officiele JSF versie (1.2) op een vrij laag pitje. Er gebeurd wel iets, maar echt spectaculair is het niet op dat gebied.

Zover ik weet staat het development team van MyFaces helemaal los van Trinidad. Sterker nog, bijna heel Trinidad zijn Oracle gasten. Dat was, zover ik begrepen heb, tevens het grootste tegenargument om uit de Incubator te komen, omdat daar een eis aan zit die zegt dat niet het complete team van 1 partij mag komen o.i.d.

Je hebt wel gelijk dat ze eens mogen opschieten met een JSF 1.2 implementatie, maar aan de andere kant geef ik denk ik nog steeds de voorkeur aan MyFaces als ik moet kiezen tussen MyFaces 1.1.5 en RI 1.2.