[java] Waarom weblayer zo veel lastiger dan Swing*

[Alarmnummer]

Het valt me op dat het ontwikkelen van webapplicaties echt vele malen gecompliceerder is dan swing applicaties. Ik doel hierbij niet zozeer op alle zaken onder weblayer (want dat is absoluut geen enkel probleem), maar eigelijk alleen de weblayer. Ik heb nog niet echt mijn vinger op de zere plek kunnen leggen.

Wat mij veel tijd kost (als je alle state in webpagina`s en de db hebt) is om de state voor formulieren op de webpagina vast te leggen en om deze state later weer terug te krijgen in java (misschien dat werken met 'pagina`s' in een sessie om de state bij te houden dit probleem kan oplossen) Het is niet zozeer een probleem om beans te vullen vanuit webrequests.. maar het schiet gewoon niet lekker op. Ik vind de afstand tussen de onderdelen zo groot (je loopt bv met zoveel te kutten). En verder loop je overal met stringetjes te pielen om weer bij andere pagina`s ed uit te komen.. ik vind het onduidelijk en het remt mijn ontwikkelsnelheid.

In Swing zet ik de meest ingewikkelde applicaties in de korste keren in elkaar, maar met webpagina`s blijf ik maar aankloten en heb gewoon enorm de indruk dat ik door gebrekkige tools nog geen fractie van mijn tijd echt effectief benut. Dingen die me in Swing nog geen kwartier kosten, kosten me een halve dag op een webpagina.

Wie kent dit gevoel en weet hoe ik dit probleem het beste kan oplossen? Wie heeft professionele ervaring met Swing en kan mij een platform adviseren waarin je wel hebt gevoel hebt effectief te werken. En verder wil ik ook niet in 10.000 config files lopen knoeien, want dat is ook alles behalve motiverd en duidelijk.

Wij gebruiken trouwens JSP`s + Maverick.

[ Voor 10% gewijzigd door Alarmnummer op 24-05-2005 13:55 ]

[-FoX-]

Simpelweg omdat er bij het bouwen van webapplicaties vele extra's om de hoek komen kijken en je moet rekening houden met de 'standaarden'.

Er zijn echter een aantal web frameworks die de omschakeling van Swing -> Web tot een minimum willen beperken. Zo is er bijvoorbeeld Echo (en binnenkort Echo2 ) die het ontwikkelen van webapps net zo eenvoudig maakt als het ontwikkelen van Swing applicaties.. en deze manier van ontwikkeling ook net zo goed probeert te benaderen. Een ander groot voordeel is dat Echo wel een redelijke community heeft.. zo is er bijvoorbeeld ook Echopoint, dat voorziet in een heel deel componenten voor het Echo framework, die je op een Swing manier kan benaderen.

Frameworks zoals Echo bieden volgens mij wel een enorm grote vooruitgang in het ontwikkelen van webapplicaties, voornamelijk omdat de overgang naar web development op deze manier wel heel klein gemaakt wordt. Voor de rest zijn de kickstart applicaties zoals Appfuse ook wel een grote vooruitgang, vooral omdat het opzetten van deze Java webapplicaties meestal veel tijd in beslag nemen (Vandaar ook de populariteit van bvb PHP of RubyOnRails).

Ik hoop dat de J2EE 5 spec veel verbetering met zich meebrengt, het ziet er iig veelbelovend uit, maar er zijn toch nog een heleboel dingen die gemakkelijker gemaakt kunnen worden (XML hell, overcomplexe api's zoals JAAS bvb, ...) Dit zijn allemaal zaken die het wel heel moeilijk maken om snel gestart te raken met een Java webapplicatie.

[Alarmnummer]

-FoX- schreef op dinsdag 24 mei 2005 @ 13:57:
Simpelweg omdat er bij het bouwen van webapplicaties vele extra's om de hoek komen kijken en je moet rekening houden met de 'standaarden'.

Lees mijn verhaal even goed. Ik heb 0.0 problemen met de zaken onder de weblayer. Alleen het bouwen van de weblayer kost mij (te) veel tijd.

Een ander groot voordeel is dat Echo wel een redelijke community heeft.. zo is er bijvoorbeeld ook Echopoint, dat voorziet in een heel deel componenten voor het Echo framework, die je op een Swing manier kan benaderen.

Ik was zelf ook al ff naar Tapestry aan het kijken maar kon daar zo snel ook nog geen wijs uit worden. Ik zal echo eens bekijken.

Voor de rest zijn de kickstart applicaties zoals Appfuse ook wel een grote vooruitgang, vooral omdat het opzetten van deze Java webapplicaties meestal veel tijd in beslag nemen (Vandaar ook de populariteit van bvb PHP of RubyOnRails).

Lees mijn verhaal aub ff goed. Ik heb geen problemen met de zaken onder de weblayer.. Met Spring en Hibernate is dat peanuts.. Maar de weblayer.. dat is de oorzaak van mijn vertraging. In een dag of wat zet ik alles behalve de weblayer helemaal in elkaar en ik zit week(en) op de weblayer. Ik moet er veel te veel bij nadenken.. steeds dingen vertalen en bij elkaar zoeken.. steeds opnieuw dezelfde dingen weer uitdokteren maar er geen goeie oplossing voor vinden en dit is zwaar vermoeiend. Ik ben na een paar uurtjes weblayer bakken net zo gaar als een hele dag technische problemen oplossen.

[ Voor 23% gewijzigd door Alarmnummer op 24-05-2005 14:05 ]

[turkosh]

Ik ben al een tijdje bezig met Struts Framework (+J2EE + JSP), en heb hetzelfde gevoel. Je gebruikt Struts-config.xml om de jsp aan een action en een form te koppelen. Dus dat betekent dat je voor 1 pagina al 3 bestanden moet bewerken.
Het implementeren van een jsp pagina en het koppelen van de logica tussen de pagina en het backend voelt ook als een hels karwei.

Kortgezegd: Er ontbreekt gewoon iets, waardoor ik ook het gevoel heb van liever een swing ofzo.

[-FoX-]

Alarmnummer schreef op dinsdag 24 mei 2005 @ 14:01:
Lees mijn verhaal even goed. Ik heb 0.0 problemen met de zaken onder de weblayer. Alleen het bouwen van de weblayer kost mij (te) veel tijd.

Ik heb je verhaal goed gelezen, ik stuurde dan ook aan op de front-end en niet zozeer op de gehele webapplicatie. Er komen bij de weblayer veel extra zaken om de hoek kijken waar je rekening mee moet houden (request, session state, ...), maar dat hoort er, op dit moment, nu eenmaal bij.

Ik was zelf ook al ff naar Tapestry aan het kijken maar kon daar zo snel ook nog geen wijs uit worden. Ik zal echo eens bekijken.

Echo moet je zeker eens bekijken, heb er met een collega van mij eens een simpele proof-of-concept rond opgezet.. en het beviel ons wel eigenlijk. Vooral vanuit het standpunt van een Swing developer lijkt het ons een zeer aangenaam framework (bye bye JSP's )

Lees mijn verhaal aub ff goed. Ik heb geen problemen met de zaken onder de weblayer.. Met Spring en Hibernate is dat peanuts.. Maar de weblayer.. dat is de oorzaak van mijn vertraging. In een dag of wat zet ik alles behalve de weblayer helemaal in elkaar en ik zit week(en) op de weblayer. Ik moet er veel te veel bij nadenken.. steeds dingen vertalen en bij elkaar zoeken.. steeds opnieuw dezelfde dingen weer uitdokteren maar er geen goeie oplossing voor vinden en dit is zwaar vermoeiend. Ik ben na een paar uurtjes weblayer bakken net zo gaar als een hele dag technische problemen oplossen.

De weblayer is ook niet gelijk een andere layer, zaken zoals usability en web-gui komt ook nog eens om de hoek kijken.. je kan deze laag dan ook niet vergelijken met een service laag of een andere technice laag... maar bekijk Echo maar eens; denk wel dat deze aansluit bij de manier van aanpak die jij wenst.

[faabman]

Wat bedoel je precies met de weblayer? Bedoel je daarmee de clientside zaken zoals xHTML, javascript en CSS?

[Alarmnummer]

-FoX- schreef op dinsdag 24 mei 2005 @ 14:14:
[...]

Ik heb je verhaal goed gelezen, ik stuurde dan ook aan op de front-end en niet zozeer op de gehele webapplicatie. Er komen bij de weblayer veel extra zaken om de hoek kijken waar je rekening mee moet houden (request, session state, ...), maar dat hoort er, op dit moment, nu eenmaal bij.

Dit vind ik een slecht uitgangspunt. Soms ben je een hogere abstractie laag nodig. Als je met corba bezig gaat, ga je je toch ook niet druk maken omdat ze bv gebruik maken van tcp. Hetzelfde geld voor webpagina`s. Soms kan het handig zijn dat je erbij kunt komen en om er inzicht in te hebben, maar op het moment dat je er iedere keer mee in aanraking komt is er iets mis.

Echo moet je zeker eens bekijken, heb er met een collega van mij eens een simpele proof-of-concept rond opgezet.. en het beviel ons wel eigenlijk. Vooral vanuit het standpunt van een Swing developer lijkt het ons een zeer aangenaam framework (bye bye JSP's )

Tja.. en dat is dus ook meteen mijn argument tegen Echo. Als het aan mij lag was het fuck JSP`s. Helaas wil je het ontwerp van een website niet in java vastleggen maar gewoon in html/jsp.

De weblayer is ook niet gelijk een andere layer, zaken zoals usability en web-gui komt ook nog eens om de hoek kijken

Dat kom je in een swing layer ook tegen. Hoe kan het dat ik in Swing in nog geen fractie van de tijd een pagina in elkaar kan zetten tov een webpagina. Ik wil deze snelheid van ontwikkeling ook hebben als ik webpagina`s ga ontwikkelen. Dus: In swing kan het wel eenvoudig.. het moet dus een weblayer ook eenvoudig te doen zijn.

[ Voor 6% gewijzigd door Alarmnummer op 24-05-2005 14:29 ]

[Alarmnummer]

faabman schreef op dinsdag 24 mei 2005 @ 14:22:
Wat bedoel je precies met de weblayer? Bedoel je daarmee de clientside zaken zoals xHTML, javascript en CSS?

Eigelijk alle boven je business laag.-> Controllers, servlets, views, dispatchen, actions..Alle dingen die weblayers zoals Struts, Maverick etc voor je doen.

HTML/CSS is geen probleem. Ik hoef alleen de basis html code te schrijven en iemand anders maakt het wel mooi. Het gaat puur om het bouwen van een 'dynamische' gui waar je dus allerlei serverside acties voor moet uitvoeren.

[ Voor 19% gewijzigd door Alarmnummer op 24-05-2005 14:27 ]

[Standeman]

Ik vermoed twee dingen...

1) je hebt gewoon meer ervaring met Swing waardoor je je daar meer thuis voelt en beter je weg kan vinden. Ik ben al een kleine 3 jaar web-developer en sinds kort ook wat met swing aan het doen.. Zeker in het begin moest ik heeel erg wennen aan het ontbreken van bijv. het request / response. Nu gaat het wel, maar ik heb sommige dingen nog niet helemaal door (bijv. events e.d.).

2) Webapplicaties werken volgens het request/response systeem en dat heeft Swing niet (zoals je al wist ). Hierdoor moet je het hele zaakje ontkoppelen waardoor je voor geen controle hebt over wat er op de client site gedaan wordt. Hierdoor kost het wat meer moeite om een strakke flow neer te zetten dan m.b.v. Swing. Overigens moet je voor elke actie een request laten doen naar de server om je state bij te houden, data op te slaan, etc.. erg omslachtig dus.

[TukkerTweaker]

Het is inderdaad nogal complex ja, voor een paar simpele acties heb je vaak al een shitload aan configuratie.
Maar toch denk ik dat de Spring MVC implementatie je al veel reperterend werk uit handen neemt. Ik denk dat het deels inherent is aan het http protocol waardoor de complexiteit toeneemt, je hebt in tegenstelling tot Swing gewoon veel minder controle over user interface.

[faabman]

Misschien dat een techniek als AJAX (oftewel xmlhttprequests ) je kan helpen bij het vergroten van je invloed op je applicatie? Backbase heeft een platform ontwikkeld wat integreert met Java...

[JaWi]

IMHO is het probleem dat je verantwoordelijkheden die eigenlijk aan de client toebehoren aan de server-zijde uit moet programmeren, simpelweg omdat je daar de juiste faciliteiten daarvoor hebt (die ontbreken aan de client-zijde). Strict genomen is het gebruik van XHMTL/CSS/JS aan clientzijde (nog) niet voldoende om serieuze, en vooral nette, applicaties te fabrieken. (Nu is Swing ook niet heiligmakend, maar dat terzijde...)

[-FoX-]

Alarmnummer schreef op dinsdag 24 mei 2005 @ 14:23:
Tja.. en dat is dus ook meteen mijn argument tegen Echo. Als het aan mij lag was het fuck JSP`s. Helaas wil je het ontwerp van een website niet in java vastleggen maar gewoon in html/jsp.

Waarom? Omdat je het zo gewend bent?
Je wil webapplicaties ontwikkelen met het gemak van Swing? Echo geeft je de volledige controle over de look-and-feel hoor, bekijk de demo applicaties maar eens (Je legt het meeste vast in CSS, de vormgeving in panels, net zoals bij Swing).

Dat kom je in een swing layer ook tegen. Hoe kan het dat ik in Swing in nog geen fractie van de tijd een pagina in elkaar kan zetten tov een webpagina. Ik wil deze snelheid van ontwikkeling ook hebben als ik webpagina`s ga ontwikkelen. Dus: In swing kan het wel eenvoudig.. het moet dus een weblayer ook eenvoudig te doen zijn.

Swing/Webapplicaties verschillen te fel van elkaar om dezelfde structuur van ontwikkelen te bieden. Jij hebt misschien veel sneller een Swing applicatie in elkaar geboxt, terwijl een ander hetzelfde resultaat bereikt in ongeveer evenveel tijd met een webapp. (Enkel de view dan).

[Alarmnummer]

Standeman schreef op dinsdag 24 mei 2005 @ 14:38:
Ik vermoed twee dingen...

1) je hebt gewoon meer ervaring met Swing waardoor je je daar meer thuis voelt en beter je weg kan vinden. Ik ben al een kleine 3 jaar web-developer en sinds kort ook wat met swing aan het doen.
. Zeker in het begin moest ik heeel erg wennen aan het ontbreken van bijv. het request / response. Nu gaat het wel, maar ik heb sommige dingen nog niet helemaal door (bijv. events e.d.).

Op de manier zoals wij nu bezig zijn tov Swing zijn er wel erg grote verschillen. Wij hebben alle state in pagina`s en in de db staan. Het is veel werk om bij submitten van vorm de state eerst weer in het java geheugen te krijgen. Verder is flow tussen pagina`s en pagina aanroepen gewoon erg vervelend met allerlei url`s waar die info in staat. Dit is enorm onderhouds gevoelig en imho ook enorm gammel. Ik heb veel liever typesafe messages die je in een centrale controller gooit en dat de juiste handler (weer een pagina) die message gaat verwerken. Dit ook helemaal typesafe.. geen geouwehoer meer met strings ed..

2) Webapplicaties werken volgens het request/response systeem en dat heeft Swing niet (zoals je al wist ). Hierdoor moet je het hele zaakje ontkoppelen waardoor je voor geen controle hebt over wat er op de client site gedaan wordt. Hierdoor kost het wat meer moeite om een strakke flow neer te zetten dan m.b.v. Swing. Overigens moet je voor elke actie een request laten doen naar de server om je state bij te houden, data op te slaan, etc.. erg omslachtig dus.

Tja.... ik denk dat je met javascript wel een heel stuk zou komen.

Mijn problemen zijn denk ik het volgende:
1) alle state staat in de html pagina dus iedere keer java->html en html->java. Statefull pagina`s zouden veel ellende kunnen schelen. Met statefull bedoel ik een java-pagina-object bij iedere html-pagina hoort waarin alle bijbehorende java objecten staan. Zo gauw de gebruiker iets op een html pagina doet, dat automatisch het juiste java-pagina weer terug gevonden kan worden. (Zoiets zie je geloof ik bij JSF)

2) pagina aanroepen laten doen via java objecten en niet meer helemaal in de html.

dus ipv:
<a href="persoonform?action=edit&persoon=21">edit</a>
een:
<a href="editpersoonmessage234">edit</a>

Die message234 is dan een id naar een echt message object:

code:

class EditPersoonMessage extends Message{
      Persoon _persoon;
}

Op het moment dat je dan op de knop drukt, kan de juiste message object opgezocht worden. Daarna kan de centrale controller de handler van deze message opzoeken, de bijgehorende pagina aanmaken en hem deze message geven.

[ Voor 21% gewijzigd door Alarmnummer op 24-05-2005 15:39 ]

[ronaldmathies]

Als je Swing zo makkelijk vindt waarom kijk je dan niet eens naar JSF (Java Server Faces), ik ben hier nu een tweetal maanden mee bezig en ik heb inmiddels een paar mooie componenten gemaakt en het is echt verdomd makkelijk. Daarnaast is het een eitje om de frontend te maken in combinatie met de server side. Alles gaat zo goed als automatisch. Hiervoor heb ik drie jaar met Struts gewerkt en dat is in vergelijking met JSF gewoon beroerd.

Het kost alleen even om het door te hebben maar als je het eenmaal door hebt dan is het echt snel ontwikkelen.

Mijn grootste custom component is een tabel waarin automatisch sorteren zit (meerdere kolommen, oplopend en aflopend). De tabel kan enterable zijn, dit kost verder geen moeitje of extra programmeer werk. Er zit row highlighting op (op regel en kolom niveau). En daarnaast zit er ook nog een paging automatisch op. (resultaten lijst pagina nummering).

Daarnaast kan je knoppen op regel niveau toevoegen die als er op gedrukt wordt automatisch een event server side laten afgaan met de regel nummer en eventuele custom velden als argumenten.

Er zit een listener mogelijkheid op voor regel selecties, header selecties en pagina nummer selecties.

[Varienaja]

Alarmnummer schreef op dinsdag 24 mei 2005 @ 14:01:
Ik was zelf ook al ff naar Tapestry aan het kijken maar kon daar zo snel ook nog geen wijs uit worden. Ik zal echo eens bekijken.

Op m'n werk gebruiken we sinds een half jaar Tapestry, maar dat deden vooral mijn collega's. Zelf ben ik nu een hobby-projectje begonnen in Tapestry, en dat vlot al heel aardig. Het is niet echt moeilijk, maar een boek of voorbeeld erbij is wel noodzakelijk. En verder vooral flink oefenen.

Met tapestry houd je heel handig de code en de ui gescheiden.

[Alarmnummer]

ronaldmathies schreef op dinsdag 24 mei 2005 @ 15:42:
Als je Swing zo makkelijk vindt waarom kijk je dan niet eens naar JSF (Java Server Faces), ik ben hier nu een tweetal maanden mee bezig en ik heb inmiddels een paar mooie componenten gemaakt en het is echt verdomd makkelijk.

Staat op mijn lijstje samen met Tapestry.

Ik het begrepen dat ze beide veel elementen van Swing hadden overgenomen. Alleen dat JSF veel 'zwaarder' was dan Tapestry (qua configuratie). Maar JSF heeft als voordeel dat het een spec van Sun is.

Daarnaast is het een eitje om de frontend te maken in combinatie met de server side. Alles gaat zo goed als automatisch.

Dat wil ik ook

Daarnaast kan je knoppen op regel niveau toevoegen die als er op gedrukt wordt automatisch een event server side laten afgaan met de regel nummer en eventuele custom velden als argumenten.

Dat klinkt idd goed.

Er zit een listener mogelijkheid op voor regel selecties, header selecties en pagina nummer selecties.

Dat is idd een stuk handiger dan zelf de hele tijd te dispatchen en dat is had ik bij ons ook al voorgesteld. Ik hoop dat we binnenkort een gaan kijken naar een framework waar we een tijd mee vooruit kunnen en die ons echt tijd gaat besparen.

[Verwijderd]

ronaldmathies schreef op dinsdag 24 mei 2005 @ 15:42:
Mijn grootste custom component is een tabel waarin automatisch sorteren zit (meerdere kolommen, oplopend en aflopend). [...]

Hmmm, beetje offtopic, maar met zoiets ben ik zelf ook bezig. Ik zelf maak gebruik van een XML beschrijving van de tabel, inclusief mogelijkheden voor plug-in code (bv per column voor sorteren, of voor renderen). Paging heb ik natuurlijk ook, alsmede wat explicitere synchronisatie (als de user een paar keer back drukt en er op een rij geclickt wordt dan wordt de achterliggende datasource overnieuw gequeried voor de juiste data).

Voorderest heb ik als extra feature dat een datasource parameterizable kan zijn: Je kunt "opties" declareren (ook weer via plug-ins) die je koppelt aan 'parameters' (generieke interface van de datasource). Zo kun je heel eenvoudig voor bijvoorbeeld een table met gebruikers een selectie drop-down laten zien die een bepaalde soort gebruiker kiest. Declaratief in je XML (kan inline in je JSF tag) zeg je alleen wat je datasource is, en een lijstje met params die deze kan verwerken.

Ik kwam er pas achter dat er een ander project is dat ook zoiets doet: displaytag, maar goed nu zit ik al redelijk ver met mijn eigen project. Ik hoop het binnen afzienbare tijd op sf te releasen

Back-on topic:

JSF is volgens mij inderdaad precies waar de TS naar op zoek lijkt te zijn.

[Verwijderd]

Check JSF, komt mijns inziens redelijk dicht bij Swing. Je zit alleen nog wel met een zooi config bestanden. Zoals jezelf al aangeeft wat gewenst is: aan elke JSF pagina zit een java object gekoppeld waarin je de fields en acties definieert die in de pagina voorkomen.
In het begin is het wel ff wat uitzoek werk, maar ik heb nog wel een test projectje voor je liggen.
In een weekend had ik een site draaiende met een stuk of 8 pagina's i.c.m. swing en hibernate.

[misfire]

In tegenstelling tot wat de topic titel suggereert lijkt je vraag in te houden dat je op zoek bent naar een Java Web framework waarin je op ongeveer dezelfde manier kunt werken als in Swing, en niet naar redenen waarom dit alleen maar lastiger zou kunnen.

Ten eerste: waarom gebruiken jullie in vredesnaam nog Maverick?

De suggesties Tapestry en JSF zouden ook mijn eerste antwoord zijn als je op zoek bent naar een Swing-achtig Web Framework. Als je ze tegen elkaar afzet krijg je dit:

Tapestry: geeft je maximale controle over je HTML. Is conceptueel simpeler dan JSF. Heeft minimale tooling nodig om effectief te kunnen worden gebruikt. Bevat een API die je soms het beste ondersteboven kunt houden voordat je hem snapt.

JSF: is een uniform model voor verschillende presentatietechnieken (weet niet of dit handig voor jullie s). Is een standaard. Heeft serieuze tooling nodig voor effectief gebruik. Is waarschijnlijk het meest breed ondersteund.

De belangrijkste factor voor de keuze is denk ik hoe je team in elkaar zit. Tapestry erkent heel duidelijk een onderscheid tussen de "HTML dude" en de "Java guy". Je hebt iemand die heel graag HTML wilt maken, en niets van Java snapt, en omgekeerd iemand die Java objecten wilt maken, maar niet met HTML van doen wilt hebben. JSF erkent eigenlijk alleen maar de Java guy. De vraag is dus: heb je HTML dudes in je team?

[Alarmnummer]

In tegenstelling tot wat de topic titel suggereert lijkt je vraag in te houden dat je op zoek bent naar een Java Web framework waarin je op ongeveer dezelfde manier kunt werken als in Swing, en niet naar redenen waarom dit alleen maar lastiger zou kunnen.

Het lijkt me niet dat ik op zoek ben naar een lastigere oplossing Ik zet in Swing in notime de mooiste interfaces in elkaar (en ook de gekste interfaces met allerlei dynamische gegenereerde onderdelen), maar met Webinterfaces is het maar een stuk gepiel, geknoei en gepruts. De mooiste patterns kan ik loslaten op info van een scherm naar het andere scherm te krijgen en de grootst mogelijke moeite heb ik om informatie van een pagina naar de andere pagina over te krijgen. Enorm stuk geprutst met url`s bv.

misfire schreef op dinsdag 24 mei 2005 @ 20:30:
Ten eerste: waarom gebruiken jullie in vredesnaam nog Maverick?

Omdat het nog gebruikt werd/wordt. We werken met een klein team en iedereen is daar goed bekend met Maverick en mijn collega`s kunnen er redelijk mee overweg. We hebben de afgelopen tijd alles behalve de weblayer al vernieuwd/verbeterd (spring/hibernate/eigen platform zaken) en de weblayer is ook wat opgepoetst (handige controllers ed voor maverick).

Als het aan mij ligt schieten we maverick meteen af. Ik heb het gevoel met iets vergelijkbaars als assembler te prutsen.

De belangrijkste factor voor de keuze is denk ik hoe je team in elkaar zit. Tapestry erkent heel duidelijk een onderscheid tussen de "HTML dude" en de "Java guy". Je hebt iemand die heel graag HTML wilt maken, en niets van Java snapt, en omgekeerd iemand die Java objecten wilt maken, maar niet met HTML van doen wilt hebben. JSF erkent eigenlijk alleen maar de Java guy. De vraag is dus: heb je HTML dudes in je team?

Iedereen bij ons is sowieso thuis in de techniek. Sommige mensen zijn trouwens wel heel veel meer thuis in html en goed grafisch ontwerp (deze rol is niet aan mij toevertrouwd naar het roze pantervel /mooie bloemetjes wallpaper incident

Ik had begrepen dat JSF nogal log was tov Tapestry, maar dat er voor JSF weer betere IDE integratie zou zijn (oa in de vorm van WYSIWHG editors).

[ Voor 33% gewijzigd door Alarmnummer op 25-05-2005 08:31 ]

[Verwijderd]

Alarmnummer schreef op woensdag 25 mei 2005 @ 07:56:
(deze rol is niet aan mij toevertrouwd naar het roze pantervel /mooie bloemetjes wallpaper incident

Klinkt erg!

Ik had begrepen dat JSF nogal log was tov Tapestry,.

Niet perse log. Het is ook een standaard, dus je kan voor een andere implementatie kiezen dan die van Sun. Op dit moment heeft alleen Apache met MyFaces een goed alternatief naast de RI van Sun, maar in de toekomst is het niet uitgesloten dat er net zoals met een application server 10-tallen verschillende implementaties komen.

maar dat er voor JSF weer betere IDE integratie zou zijn (oa in de vorm van WYSIWHG editors)

Het is meer dat ik de toekomst veel IDE integratie zal gaan komen. De meeste IDEs zijn er nu nog mee bezig en veel bieden alleen een wat simpele config tool of visuele flow layout. WYSIWYG editors (zoals bijvoorbeeld in Visual Studio, dat je de GUI van een dialoog of form kan maken door er componenten heen te slepen), zie je nog erg weinig.

Vergeet ook niet dat JSF nog steeds ontzettend nieuw is. In de ogen van de meeste managers/systeembeheerders is JSF pas een maandje of 3 uit.

[Alarmnummer]

Ik heb net ff wat dingen in Tapestry in elkaar gezet. Jezus..wat is dat een verademing zeg. Ik kan direct pagina`s aanroepen, typesafe argumenten meegeven en argumenten eenvoudig tussen pagina`s delen.

[Alarmnummer]

Ik heb gisteren en vandaag wat formulieren en overzichten in elkaar gezet. Eerst ging het wat stroef maar dat kwam omdat ik een paar fouten had gemaakt (had wel graag gezien dat ik wat meer errors zou krijgen). Maar ik heb alles nu goed aan de praat en ik vlieg met hoge snelheid door mijn schermen heen. Tapestry = dus wat ik zocht.. Er is nog wel heel veel te leren aan tapestry en een gedeelte is op dit moment ook nog 'magic' maar ik denk dat de combo Spring/Hibernate en nu Tapestry mijn combo gaat worden

[Verwijderd]

Ja je zegt het zelf al, hibernate en spring. Spring mvc is struts alleen dan veel beter. Maar de config 'hell' ontkom je niet aan:
- *.hbm.xml
- applicationContext.xml
- *-servlet.xml
- web.xml
- *.properties (ResourceBundle)

[Verwijderd]

Alarmnummer schreef op zaterdag 28 mei 2005 @ 08:24:
Tapestry = dus wat ik zocht.. Er is nog wel heel veel te leren aan tapestry en een gedeelte is op dit moment ook nog 'magic' maar ik denk dat de combo Spring/Hibernate en nu Tapestry mijn combo gaat worden

Maar nog steeds niet JSF uitgeprobeerd

[Alarmnummer]

Verwijderd schreef op maandag 30 mei 2005 @ 10:42:
[...]
Maar nog steeds niet JSF uitgeprobeerd

De algemene klacht die ik over JSF heb gehoord is dat het log is mbt configuratie en dat is nou net waar ik een hekel aan heb. Ik heb dit weekend wat schermen in elkaar gezet en goed achter de boeken/documentatie gezeten en heb nu wel een aardige indruk. Tot zover ben ik er erg over te spreken.. zeker aangezien ook nog betere Spring integratie komt (zelfs nu was het peanuts) en er komt support voor pageflow systeem van Spring.

En verder heb ik gewoon te weinig tijd om meerdere platformen tot op de bodem uit te zoeken.

[ Voor 8% gewijzigd door Alarmnummer op 30-05-2005 10:49 ]