[J2EE] Webapplicaties en &#039;best practices&#039;

maandag 10 januari 2005 14:13

-= Tja =-

-FoX- schreef op maandag 10 januari 2005 @ 12:42:
ANT: Fantastische tool die het build/deploy proces zoveel vereenvoudigd!! Ik vraag me overigens wel af ofdat ik de enige ben die het totaal niet leuk vind om deze build-scripts te schrijven? Als ze eenmaal geschreven zijn, ben ik er echter wel altijd heel blij mee
Grote problemen heb ik eigenlijk nog niet echt gehad met Ant, buiten een aantal dependency problemen, maar deze waren dan ook wel vrij snel opgelost.

ANT is erg prettig om te hebben, maar in de toekomst wil ik zeker even kijken naar Maven. Ik zit vooral met het feit dat de projecten eenvoudig op alle develop-bakken moet kunnen draaien en ik wil verhinderen dat in het project alle tools die nodig zijn meegecopieerd moeten worden. Verder wil ik het versie gebeuren van de jars ook verbeteren.

Hibernate: ORM framework die het persistentie gedeelte een stuk makkelijker maakt. Ik zou me hier nog graag in willen verdiepen, vooral betreffende caching & transactions. Ik heb soms wel de indruk dat Hibernate téveel queries wil uitvoeren, terwijl dit niet altijd nodig is (te wijten aan de mapping files die de objecten aan elkaar linkt).

Check Ibatis ook ff.

JUnit: Het schrijven van unit-testen voor je applicatie. Heeft al meermaals zijn voordelen bewezen en je ziet onmiddelijk of je ergens je code breekt. Het 'moeilijke' aan JUnit vond ik vooral het verzinnen van de testcases. Soms had ik echt het gevoel van: "Zouden dit alle testen zijn.. of vergeet ik er nog wat?" waarop de betrouwbaarheid van je testen wel wat achteruit gaat imho.

Wat ik 'jammer' vind is dat je met unit testen in omgevingen waarin je veel declaratief doet niet alles kunt testen. Met een unit test kan je eenvoudig controleren of na het overmaken het bedrag van 1 rekening is verlaagd en die van een ander verhoogt. Maar je controleert niet of bv security goed staat, of dat de transacties goed gaan, of dat de concurrency goed gaat. Het kan dus een vals gevoel van veiligheid scheppen (en dat vind ik dus vervelend).

Spring: Weet ik nog niet zoveel over te vertellen, too much to find out! Maar ism een ORM framework als Hibernate is het wel leuk in gebruik. Daar waar Hibernate soms vreemde exceptions throwt, worden deze nu mooi gewrapt in Spring runtime exceptions. Voor de rest handelt Spring ook voor een groot deel je Hibernate code af, waardoor je code er weer een stuk cleaner uitziet.

Zie mijn sig hoe ik over Spring denk

IntelliJ IDEA: Just a nice tool...

Niets kom in de buurt van IDEA. Alle andere IDE`s (vanuit de optiek van een klopper) komen niet in de buurt. Eclipse.. tja.. misschien zit die er het dichtste bij. Maar het is het gewoon niet. Het kan niet zoveel als IDEA of je moet het toevoegen mbv een niet werkende plugin. Xml validatie (mbv schema) codecompletion, syntax checking (allemaal nog in de xml). Class completion (in de XML). Speciale XML ANT support. En dan heb ik het alleen nog maar over de XML

IDEA is gewoon de enigste.

[ Voor 4% gewijzigd door Alarmnummer op 10-01-2005 14:05 ]

Acties:

maandag 10 januari 2005 14:40

Moderator Devschuur®

!litemod

ANT
*steekt hand op*. Gelukkig hebben we bij ons al meerdere projecten en is het bouwen van een groot ant script niet meer dan een paar stukken uit andere projecten copypasten. Vervolgens aanpassen aan de juiste behoeften en klaar. We zijn echter overgestapt naar maven (als in de meeste projecten zijn omgebouwd, maar nog niet mijn projecten dus echt veel kan ik er nog niet over vertellen). Het schijnt dat je hierdoor veel dingen echt maar 1 keer hoeft te schrijven.

Struts/Tiles
Ik ben inderdaad ook wel tegen i18n issues aangelopen, maar heb ze allemaal op een redelijk nette manier weten op te lossen (als in zonder lelijke hacks). Ik ben daarom wel erg benieuwd wel deel je niet is gelukt. Misschien heb ik hier dan nog wel wat liggen.

Qua validatie gebruik ik gewoon de validator. Enige nadeel hiervan is dat het je dwingt om al je reesource messages in 1 bestand te doen. Gelukkig komt hier weer ant om de hoek kijken. Die laat ik enkele globale resources en applicatie/project specifieke mergen tijdens de build.

Het 'dubbele actie probleem door de bak of reload button' weet ik erg goed te omzeilen door 'redirect="true"' te gebruiken waardoor een clientside redirect wordt gegenereerd. Tokens heb ik daarvoor nog neit nodig gehad.

Hibernate
Zeer hoog op mijn todo lijstje om eens mee te beginnen. Helaas moet ik met een ejb project bezig op het werk en als ik al prive bezig ben is dat met een project dat geen database verbinding heeft (of iig niet tot de core onderdelen hoort).

JUnit
Ik moet binnenkort bezig met het toevoegen van allerlei tests aan al bestaande projecten van mij. Eens even kijken of ik tijdens die conversie mijn enthousiasme weet te behouden

..

Log4J
Ik zie neit in wat mensen hier complex aan vinden. Bij het declareren van je variabelen een logger aanmaken (desnoods al in een bovenliggende class zodat deze via overerving gewoon beschikbaar is) en loggen maar. De standaard instelling laat het al keurig in een bestand terecht komen. Via wat simpele configuratie aanpassingen laat je al je eigen logmessages adhv het package name in een appart bestand terecht komen enz enz. Veel simpeler kan het imho niet worden.

Ja het automatisch mailen van dit en dat en andere bijbehorende acties wordt natuurlijk complexer, maar dat is ook wel logisch. Dat heb je ook waneer je het op een andere manier wilt doen.

Spring
Zie Hibernate. Maar Alarmnummer zit me al de hele tijd te 'stalken'

om hier eens wat meer in te verdiepen.

IntelliJ IDEA
Heerlijk. Kost wel iets, maar is elke euro waard imho.Toch wel grappig af en toe dat dingen die je als IntelliJ gebruiker als 'granted' beschouwd niet eens of nog maar net in veel gebruikte andere IDE's zitten (refactoring in VS. Ik was verbaasd).

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'

Acties:

Bbfreak

ANT

Erg handige tool. Makkelijk in gebruik. Scheelt een hoop tijd.

Hibernate & Spring & Log4J & JUnit

Moet ik snel mee beginnen

IDE

Eclipse. Goed uitbreidbaar en te integreren met JBoss.
Duidelijke en goed te gebruiken GUI. Meer heb ik niet nodig.

EJB

Dit wil ik even apart noemen. Heb er op school een project mee gedaan.
En toen is gebleken hoe groot, misschien lomp, het wel niet is.
Je leest ook veel dat EJB overkill is en anders kan.
Graag zou ik willen weten waarom en hoe ik het anders aan kan pakken.

Ben nu bezig in:
* Rod Johnson 1

En wil graag lezen:
* Rod Johnson 2, No EJB

Zijn goed leesbare boeken en zo te lezen ben ik niet de enige die dat vindt

In die eerste laat hij al blijken dat hij EJB niet alles vindt.
In die tweede doet hij het helemaal zonder EJB. Lijkt me interessant.

Twitter @cmeerbeek / Halo Waypoint Profile

maandag 10 januari 2005 14:58

Acties:

maandag 10 januari 2005 16:03

-= Tja =-

Bbfreak schreef op maandag 10 januari 2005 @ 14:40:
EJB

Dit wil ik even apart noemen. Heb er op school een project mee gedaan.
En toen is gebleken hoe groot, misschien lomp, het wel niet is.
Je leest ook veel dat EJB overkill is en anders kan.
Graag zou ik willen weten waarom en hoe ik het anders aan kan pakken.

Zie spring en Rod Johnson 2, No EJB (Hij is een van de hoofddudes van Spring)

Janoz schreef op maandag 10 januari 2005 @ 14:13:
Spring
Zie Hibernate. Maar Alarmnummer zit me al de hele tijd te 'stalken' om hier eens wat meer in te verdiepen.

Schijnbaar niet genoeg want anders was je het nu ook aanhet promoten

IntelliJ IDEA
Heerlijk. Kost wel iets, maar is elke euro waard imho.Toch wel grappig af en toe dat dingen die je als IntelliJ gebruiker als 'granted' beschouwd niet eens of nog maar net in veel gebruikte andere IDE's zitten (refactoring in VS. Ik was verbaasd).

Je ontdekt iedere keer wel weer iets nieuws.. wauw... kan dat ook?

[ Voor 44% gewijzigd door Alarmnummer op 10-01-2005 15:15 ]

Acties:

Verwijderd

ik ben nu ook al een tijdje bezig met java2. nou wil ik meer met j2me en j2ee gaan werken. nou vraag ik me af of er goede boeken zijn over j2ee en eventuel over j2me (weet dat dit hier niet thuis hoort)?

ik ben nu net begonnen met junit. ik weet nog niet alles maar kan je daadwerkelijk echt alles testen met junit? en tot welke coverage kan het gaan? maar als je een volledige testbasis hebt dan moet het geen probleem zijn denk ik:).

is er misschien een Log4J tutorial ergens te vinden?

mijn dank is groot

maandag 10 januari 2005 16:10

Acties:

Verwijderd

weet er iemand een mooie tutorial van junit want die cookbook op hun site is ook niet alles

thx
alot
Tom

maandag 10 januari 2005 16:10

Acties:

whoami

Bbfreak schreef op maandag 10 januari 2005 @ 14:40:
ANT

Erg handige tool. Makkelijk in gebruik. Scheelt een hoop tijd.

Ik was daarnet ff bezig met NAnt (de .NET tegenhanger dus), maar zo handig vind ik dat nu ook weer niet...
Een beetje manueel xml config files gaan maken etc.....

Ik heb net FinalBuilder gedownloaded, en dat is toch wat handiger. Je kan makkelijk een build-script maken adhv een grafische interface.
Een nadeel is wel dat dat niet gratis is (je kan wel een gratis, fully featured demo versie downloaden die 30 dagen geldig is).
Blijkbaar is het ook zo dat, bij het builden van een .NET solution 'devenv' aangeroepen wordt, wat dus wil zeggen dat je VS.NET moet geinstalleerd hebben.
Ik dacht dat NAnt dat niet deed bij een solution task.

https://fgheysels.github.io/

maandag 10 januari 2005 16:19

Acties:

maandag 10 januari 2005 19:05

-= Tja =-

whoami schreef op maandag 10 januari 2005 @ 16:10:
[...]

Ik was daarnet ff bezig met NAnt (de .NET tegenhanger dus), maar zo handig vind ik dat nu ook weer niet...
Een beetje manueel xml config files gaan maken etc.....

Ik heb er in dit geval niet zo`n probleem mee. Ik vind juist die XML-visualiserende gui`s zo`n drama. En als je een 'concrete' gui gaat maken zit je altijd vast aan de mogelijkheiden die daar in zitten verwerkt. Als je een nieuwe task toevoegt, hoe moet je gui die dan visualiseren? XML opmaak is de enigste echte optie.

Acties:

dinsdag 11 januari 2005 10:13

Carpe Diem!

Topicstarter

Michali schreef op maandag 10 januari 2005 @ 13:30:
Mooie post / topic

Zelf krijg ik binnenkort mijn eerste Java boek binnen, dus ik kan nog weinig vertellen. Hoe lang ben je al met Java bezig, in welke volgorde heb je de bovenstaande zaken geleerd en wat zou ik je anders doen als je het eens opnieuw zou doen (met huidige kennis)?

Je kan best beginnen om de standard API onder de knie te krijgen. Eens je deze onder de knie hebt, zou ik pas verder kijken naar je mogelijkheden zoals distributed/web/micro/..
Als je kiest om de richting van het web uit te gaan, dan raad ik je volgende stappen aan:
* Begin eerst met het leren van JSP's/Servlets en probeer zo iets simpels op te zetten.
* Verder kan je dan ANT erbij betrekken, Custom tags, ...
* Dan ga je eens kijken naar Struts en hun MVC aanpak
* ... Telkens als je het gevoel hebt een framework ongeveer te kennen, dan pas zou ik verder uitkijken naar overigen. Het Spring framework is bvb een framework waar je in het begin best niet kan naar kijken omdat je dan sowieso al een aantal concepten mist.

Janoz schreef op maandag 10 januari 2005 @ 14:13:
Struts/Tiles
Ik ben inderdaad ook wel tegen i18n issues aangelopen, maar heb ze allemaal op een redelijk nette manier weten op te lossen (als in zonder lelijke hacks). Ik ben daarom wel erg benieuwd wel deel je niet is gelukt. Misschien heb ik hier dan nog wel wat liggen.

Echt een groot issue is het niet, maar om bijvoorbeeld ervoor te zorgen dat je een message.key in je tiles-layout pagina plaatst, die dan afhankelijk van i18n deze titel zal internationaliseren? Lukt me niet, ik neem dan meestal een algemene titel of de naam van de applicatie..

Qua validatie gebruik ik gewoon de validator. Enige nadeel hiervan is dat het je dwingt om al je reesource messages in 1 bestand te doen. Gelukkig komt hier weer ant om de hoek kijken. Die laat ik enkele globale resources en applicatie/project specifieke mergen tijdens de build.

Het 'dubbele actie probleem door de bak of reload button' weet ik erg goed te omzeilen door 'redirect="true"' te gebruiken waardoor een clientside redirect wordt gegenereerd. Tokens heb ik daarvoor nog neit nodig gehad.

Bepaal je die redirect dan in je actions? Ik heb soms het gevoel (is ook weer een tijdje geleden), dat hij niet écht een redirect uitvoerd.. maar heel zeker ben ik hier niet van.

Spring
Zie Hibernate. Maar Alarmnummer zit me al de hele tijd te 'stalken' om hier eens wat meer in te verdiepen.

Hij zal ook niet stoppen totdat je eens verslaafd bent.. en probeer er dan nog maar eens vanaf te geraken!

Acties:

Verwijderd

-FoX- schreef op maandag 10 januari 2005 @ 19:05:

[...]

Echt een groot issue is het niet, maar om bijvoorbeeld ervoor te zorgen dat je een message.key in je tiles-layout pagina plaatst, die dan afhankelijk van i18n deze titel zal internationaliseren? Lukt me niet, ik neem dan meestal een algemene titel of de naam van de applicatie..

<tiles:useAttribute name="jouwTitle" id="jouwTitel" scope="page" classname="java.lang.String" ignore="false"/>
...
<bean:message key="<%= jouwTitle %>"/><%-- misschien hou je niet zo van die syntax, maar het werkt iig..%>

[...]

Bepaal je die redirect dan in je actions? Ik heb soms het gevoel (is ook weer een tijdje geleden), dat hij niet écht een redirect uitvoerd.. maar heel zeker ben ik hier niet van.

redirect is een attribuut van je XML <forward name=.. path=... redirect="true" />
Maar je kan het ook in je action nog wijzigen indien je echt wil. Een refresh kan dan geen problemen meer opleveren.

Ik heb geen Hibernate/Spring ervaring, maar ik vraag me reeds lang 1 ding af ivm Hibernate vs EJB:

Als je op een CMP een setter aanroept komt die waarde automatisch in de DB, als je dat met een Hibernate POJO doet gebeurt dat enkel na een Session.save().
Hoe pakken jullie dat aan? Als je vergeet te saven is er niets persistents gebeurd. Stel dat je de acthernaam van een persoon en al zijn afstammelingen wijzigt. Moet je dan elke POJO apart saven (telkens een query?). Ergens lijkt me dit niet zo makkelijk op te lossen als bij EJB waar je gewoon data 'set' en niet moet omkijken. Alles wordt op het einde doorgeduwd richting DB.

Verder ben ik natuurlijk sterk te spreken over de OO mogelijkheden van Hibernate die EJB (tot nu toe) niet biedt. Discriminator values, components, ... maken het werken met hibernate wel vlotter dan met EJB. Ik moet ze enkel nog eens praktisch proberen toepassen.

Verder lijkt het me veel makkelijker om Hibernate gebaseerde code te unit testen. Een reden waarom ik de laatste tijd een beetje naar WebWork2 aan het lonken ben (maar dat werkt dan niet echt echt samen met Tiles, en sitemesh lijkt me niet zo soepel bij echt ingewikkelde templates).

Hoe pakken jullie het data probleem voor unit tests aan? onze unit tests moeten hun eigen wijzigingen weer ongedaan maken in de DB. Als een test faalt/het 'repareren van de data' niet lukt zal de test de volgende keer falen. Wij hebben een apart schema met testdata hiervoor.
Hoe leveren jullie de testgegevens aan?

dinsdag 11 januari 2005 10:39

Acties:

dinsdag 11 januari 2005 10:45

Carpe Diem!

Topicstarter

Verwijderd schreef op dinsdag 11 januari 2005 @ 10:13:
Hoe pakken jullie het data probleem voor unit tests aan? onze unit tests moeten hun eigen wijzigingen weer ongedaan maken in de DB. Als een test faalt/het 'repareren van de data' niet lukt zal de test de volgende keer falen. Wij hebben een apart schema met testdata hiervoor.
Hoe leveren jullie de testgegevens aan?

Dan moet je echt eens een keer naar DBUnit kijken. Dit framework is gemaakt voor dergelijke testen. Als je je testen aanvat, zal DBUnit de test-data gebruiken (die je bvb in een XML file specifieert), je Unit testen worden uitgevoerd op basis vand deze 'testdata' en na je testen zal de originele data, onaangetast, in de DB staan. Je zal dus niet meer met extra DB's of speciale TESTtabellen moeten werken

[ Voor 3% gewijzigd door -FoX- op 11-01-2005 10:40 ]

Acties:

dinsdag 11 januari 2005 10:58

Spring is te gek, declaratieve transacties / security, Hibernate Templates, etc, etc te veel. Lees dit artikel en je weet een stuk meer over hoe Spring (en JSF) werkt op de achtergrond -> http://www.martinfowler.com/articles/injection.html

Daarom is JSF ook zo onwijs koel, de configuratie van JSF lijkt zeer veel op die van Spring, daarom zijn ze ook goed te combineren.

Hibernate + Spring is ook een Super Combo! Trouwens.

Wat alarmnummer al zei, je vergeet Maven

[ Voor 6% gewijzigd door Stephan Oudmaijer op 11-01-2005 10:56 ]

Acties:

dinsdag 11 januari 2005 15:39

-= Tja =-

CK schreef op dinsdag 11 januari 2005 @ 10:45:
Spring is te gek, declaratieve transacties / security, Hibernate Templates, etc, etc te veel. Lees dit artikel en je weet een stuk meer over hoe Spring (en JSF) werkt op de achtergrond -> http://www.martinfowler.com/articles/injection.html

$_/-\o_$

Daarom is JSF ook zo onwijs koel, de configuratie van JSF lijkt zeer veel op die van Spring, daarom zijn ze ook goed te combineren.

En voor de mensen die het nog niet weten, er is zelfs speciale JSF/Spring glue.
http://jsf-spring.sourceforge.net

Ik heb trouwens zelf 0.0 ervaring met JSF.

[ Voor 5% gewijzigd door Alarmnummer op 11-01-2005 11:05 ]

Acties:

dinsdag 11 januari 2005 15:47

dit kun je gebruiken als je alleen de Spring managed beans in je JSF config wilt aangeven:

code:

1
2
3

<application>
<variable-resolver>org.springframework.web.jsf.DelegatingVariableResolver</variable-resolver>
</application>

simpelweg de variable-resolver opgeven in het <application> deel van je JSF config. Nu kun je op de volgende manier Spring variables gebruiken in je JSF config:

code:

<managed-bean>
    <description>JSF ContentManager</description>
    <managed-bean-name>jsfContentManager</managed-bean-name>
    <managed-bean-class>nl.errorsoft.cms.web.content.ContentManagerActionHandler</managed-bean-class>
    <managed-bean-scope>session</managed-bean-scope>
<managed-property>
     <property-name>contentManager</property-name>
     <value>#{contentService}</value>
   </managed-property>  
</managed-bean>

die #{contentService} verwijst dus naar een managed bean uit m`n Spring config.

Als het niet duidelijk is geef maar een gil

[ Voor 11% gewijzigd door Stephan Oudmaijer op 11-01-2005 15:39 ]

Acties:

dinsdag 11 januari 2005 16:12

Carpe Diem!

Topicstarter

JSF, ik heb er nooit echt naar gekeken.. Waarschijnlijk omdat ik al redelijk met Struts overweg kan en niet dadelijk de behoefte heb om over te schakelen. Ik lees af en toe wel eens een artikel waarin JSF vs Struts wordt aangetoond en die meningen verschillen nogal eens..

Is er iemand die beiden al intensief gebruikt heeft? En de positieve punten van ieder framework eens onder elkaar kan/wil zetten?

Misschien geen relevante vraag, maar waarom zou iemand voor dit project kiezen voor Struts en voor dat andere project voor JSF?

Acties:

woensdag 12 januari 2005 10:36

Hier een stukje over JSF wat ik voor het bedrijf heb geschreven waar ik werk:

Een nieuwe technologie voor het ontwikkelen van webapplicaties gebasseerd op het Model-View-Controller pattern is Java ServerFaces. Deze technologie is in maart 2003 aan het publiek voorgesteld. Sinds maart 2004 is versie 1.1 beschikbaar, dit is een zogenaamde “maintenance release” waar veel bugs uit versie 1.0 zijn opgelost. In versie 2.1 zullen nieuwe componenten worden geïntroduceerd. Deze versie (JSR252) is eind 2004 in de Early Draft fase.

Java ServerFaces is afhankelijk van de Servlet 2.3 en de JSP 1.2 API. In andere woorden, JSF is afhankelijk van een J2EE container die minimaal aan de J2EE 1.3 specificaties voldoet. Het plaatje hieronder toont de afhankelijkheden van JSF met betrekking tot andere API´s.

Figuur 9 JSF afhankelijkheden van andere API´s.

Java ServerFaces kan gezien worden als een doorontwikkeling van het Struts framework. Dit is niet zo vreemd aangezien de maker van Struts, Craig McClanahan, een van de medebedenkers is van de JSF specificaties. JSF is het door Sun aanbevolen (en ontwikkelde) framework voor het ontwikkelen van Model-View-Controller gebaseerde webapplicaties. JSF zal dan ook worden opgenomen als onderdeel van toekomstige J2EE specificaties. Een groot voordeel van JSF boven Struts is dat JSF een standaard is.

Het Struts framework biedt een aantal krachtige functionaliteiten welke in JSF ook aanwezig zijn (maar dan meestal in een iets andere vorm). Zo vinden we in JSF, overeenkomstig met Struts, ondersteuning voor:
· meertaligheid, ook wel internationalization genoemd. Dit maakt het mogelijk om zonder aanpassing van de code een applicatie in meerdere talen weer te geven;
· validatie framework voor het valideren van gebruikers invoer;
· tag-libraries die gebruikt kunnen worden om data uit het model in de view weer te geven, zonder hierbij gebruik te maken van Scriplets.

Daarnaast biedt JSF :
· een user-interface component framework, maakt het mogelijk eigen componenten te bouwen en te hergebruiken;
· event-handling model, het standaard Java event model kan voor webapplicaties worden gebruikt;
· een flexibel render mechanisme. Maakt het mogelijk om verschillende soorten uitvoer te genereren, zoals HTML, WML, etc.

Waar binnen het Struts framework eigenlijk geen plaats is voor het MVC Model is hiervoor in het JSF framework wel een duidelijke plaats. Het Model wordt gerepresenteerd door zogenaamde managed-beans, dit zijn gewone JavaBeans die niet afhankelijk zijn van een specifieke API. De Controller wordt gerepresenteerd door een centrale Servlet, de FacesServlet. Deze is verantwoordelijk voor het kiezen van de juiste view, en de afhandeling van gebruikers acties. De View bestaat uit JSP´s aangevuld met tag-libraries.

Kiezen: Struts of JSF?
Bij de implementatie van MVC in de presentatielaag geeft Solidium de voorkeur aan een betrouwbaar en algemeen geaccepteerd framework. Hierbij zijn Struts en JSF de twee frameworks die de voorkeur hebben. Een belangrijk vraag is dan wanneer voor welke techniek te kiezen, JSF of Struts. De volgende overwegingen spelen in deze vraag een rol:
Voordelen van Struts:
· Uitgebreide IDE support in tools als WSAD;
· Volwassen, bestaat al een tijd, en heeft zich al bewezen.
Nadelen van Struts:
· Weinig UI componenten beschikbaar;
· Vermoedelijk weinig verdere ontwikkeling.
Voordelen van Java ServerFaces:
· Meer en uitgebreidere ”rich” UI componenten;
· Event-driven model;
· Is een standaard;
· Heeft meer toekomst.
Nadelen van Java ServerFaces:
· Nog niet alle IDE´s bieden op het moment van schrijven ondersteuning voor JSF;
· Relatief nieuwe techniek.

Solidium doet de volgende aanbevelingen met betrekking tot het gebruik van JSF in J2EE projecten:
· Voor bestaande Struts projecten geldt: blijf bij Struts, ga geen bestaande Struts applicaties ombouwen naar JSF. Daarvoor is geen zinnige business case te maken;
· Voor bestaande Struts projecten waar de UI flinke wijzigingen zal moeten ondergaan: bouw de nieuwe componenten in JSF, en combineer Struts en JSF met behulp van de Struts-Faces bibiliotheek, maar laat bestaande Struts componenten in takt;
· Voor nieuwe projecten: hier geldt dat het gebruik JSF de voorkeur heeft.

Dit geeft je een goed beeld van JSF.

Voor meer info: http://publib-b.boulder.ibm.com/abstracts/sg246361.html?Open

Acties:

Arnout

Sinds een aantal maanden ben ik bij een J2EE project betrokken, hierbij mijn bijdrage:

CruiseControl
Verzorgt automatische builds en unit tests en mailt deze resultaten rond. Checkt source uit bij wijzigingen. Lijkt een optionele uitbreiding, maar na verloop van tijd raak je hieraan gewend. Het heeft als voordeel dat integratie minder tijdrovend is, en dat integratie fouten in een zo vroeg stadium ontdekt worden (=direct na het inchecken).

Clover
Clover test de "coverage" (=dekking) van je JUnit (DBUnit) testen. Elke developer krijgt regelmatig zijn score te horen. Wij werken hier volgens test-driven-development, dat wil zeggen: je verzint eerst de testcase alvorens daadwerkelijk te coderen. Dit lijkt op het eerste gezicht tijdrovend, maar na verloop van tijd kost het minder tijd om goed te coderen.
Clover hebben we nog niet in de automatische builds zitten maar dit is eenvoudig te realiseren.

JTest
JTest gebruiken we om coding standards te handhaven die we afgesproken hebben. Daarnaast test JTest op mogelijke constructies die tot fouten leiden (JTest genereerd zelf uitgebreide JUnit tests).

woensdag 12 januari 2005 13:53

Acties:

woensdag 12 januari 2005 23:10

Carpe Diem!

Topicstarter

CK schreef op dinsdag 11 januari 2005 @ 16:12:
Kiezen: Struts of JSF?
Bij de implementatie van MVC in de presentatielaag geeft Solidium de voorkeur aan een betrouwbaar en algemeen geaccepteerd framework. Hierbij zijn Struts en JSF de twee frameworks die de voorkeur hebben. Een belangrijk vraag is dan wanneer voor welke techniek te kiezen, JSF of Struts. De volgende overwegingen spelen in deze vraag een rol:
Voordelen van Struts:
· Uitgebreide IDE support in tools als WSAD;
· Volwassen, bestaat al een tijd, en heeft zich al bewezen.
Nadelen van Struts:
· Weinig UI componenten beschikbaar;
· Vermoedelijk weinig verdere ontwikkeling.

Waarom vermoed je dat er aan Struts weinig verder zal worden ontwikkeld?

Voordelen van Java ServerFaces:
· Meer en uitgebreidere ”rich” UI componenten;
· Event-driven model;
· Is een standaard;
· Heeft meer toekomst.
Nadelen van Java ServerFaces:
· Nog niet alle IDE´s bieden op het moment van schrijven ondersteuning voor JSF;
· Relatief nieuwe techniek.

Kan je een aantal voorbeelden geven van rich UI componenten die Struts bvb niet heeft?

Acties:

donderdag 13 januari 2005 08:07

-FoX- schreef op woensdag 12 januari 2005 @ 13:53:
[...]

Waarom vermoed je dat er aan Struts weinig verder zal worden ontwikkeld?

[...]

Kan je een aantal voorbeelden geven van rich UI componenten die Struts bvb niet heeft?

De maker van Struts heeft dit zelf gezegd

Struts is zoals het is, hij zal zelf JSF meer promoten en pushen.

Rich componenten: Je kunt je eigen componenten bouwen en hergebruiken. Je bent niet gebonden aan de standaard componenten. IBM bijvoorbeeld heeft al een hele berg van die componenten ontwikkeld.

Zie die link naar dat Redbook maar eens.

Acties:

Verwijderd

CK schreef op woensdag 12 januari 2005 @ 23:10:
[...]

De maker van Struts heeft dit zelf gezegd Struts is zoals het is, hij zal zelf JSF meer promoten en pushen.

Rich componenten: Je kunt je eigen componenten bouwen en hergebruiken. Je bent niet gebonden aan de standaard componenten. IBM bijvoorbeeld heeft al een hele berg van die componenten ontwikkeld.

Zie die link naar dat Redbook maar eens.

[quote]

Struts gaat dichter bij JSF gaan leunen, maar de ontwikkeling stopt niet (McCLannahan zit niet voor niets in het expert team voor JSF).

(linkje: http://www.theserverside.com/news/thread.tss?thread_id=29861 )

Eenvoudige User componenten kun je reeds maken met een ww:component of ww:action achtige tag zoals in de webwork tags (het ene is gewoon een velocity template invoegen, het andere heeft er een action achter zitten). Ze zijn niet zo uitgebreid als de JSF components denk'k, maar ze tonen volgens mij een mooi principe....
(action tag: http://cvs.sourceforge.ne...k/Action_Tag.html?rev=1.2)

vrijdag 14 januari 2005 07:38

Acties:

vrijdag 4 februari 2005 00:24

[quote]Verwijderd schreef op donderdag 13 januari 2005 @ 08:07:
[...]

Struts gaat dichter bij JSF gaan leunen, maar de ontwikkeling stopt niet (McCLannahan zit niet voor niets in het expert team voor JSF).

(linkje: http://www.theserverside.com/news/thread.tss?thread_id=29861 )

Eenvoudige User componenten kun je reeds maken met een ww:component of ww:action achtige tag zoals in de webwork tags (het ene is gewoon een velocity template invoegen, het andere heeft er een action achter zitten). Ze zijn niet zo uitgebreid als de JSF components denk'k, maar ze tonen volgens mij een mooi principe....
(action tag: http://cvs.sourceforge.ne...k/Action_Tag.html?rev=1.2)

lees ook: http://struts.apache.org/proposals/struts-faces.html

Acties:

Verwijderd

CK schreef op dinsdag 11 januari 2005 @ 16:12:

Solidium doet de volgende aanbevelingen met betrekking tot het gebruik van JSF in J2EE projecten:
· Voor bestaande Struts projecten geldt: blijf bij Struts, ga geen bestaande Struts applicaties ombouwen naar JSF. Daarvoor is geen zinnige business case te maken;
· Voor bestaande Struts projecten waar de UI flinke wijzigingen zal moeten ondergaan: bouw de nieuwe componenten in JSF, en combineer Struts en JSF met behulp van de Struts-Faces bibiliotheek, maar laat bestaande Struts componenten in takt;
· Voor nieuwe projecten: hier geldt dat het gebruik JSF de voorkeur heeft.

En wat zou je (Solidium) dan aanraden voor projecten die om grote legacy J2EE aps gaan die alleen servlets en/of jsp's met scriptlets gebruiken?

Wij hebben nu zelf 2 klanten die een j2ee legacy application hebben. Het is een tijd terug ontwikkeld in de begin dagen van J2EE. Ik heb van de week alvast even door de source kunnen bladeren en in het ene geval gebruikt men uitsluitend servlets (met gare html gen functions), en in het andere geval gebruikt men voornamelijk jsp's met veel scriptlets erin, maar ook wel een flink aantal beans die werk verrichten en enkele servlets. De stap naar nieuwere technologieen heeft men blijkbaar nooit durven te maken.

Nu zit ik dus met het dillema of ik voor uitbreiding van voornamelijk die 2de application (veel jsp's met scriptlets) een business case zal gaan opstellen dat -voor- dat er uitgebreid gaat worden, het geheel eerst naar JSF omgezet zal gaan worden. Zou dit redelijk te doen moeten zijn?

vrijdag 4 februari 2005 07:39

Acties:

woensdag 8 juni 2005 11:19

-= Tja =-

Hmm... ik zou me minder druk maken om die weblayer meer meer concentreren op de algehele interne structuur van de applicatie. Zorg dat je dat eerst goed boven water hebt...

Ook al switch je van servlets naar iets beter controleerbaars... als de ondergrond bagger is ben je nog nergens. Als je niet de mogelijkheid hebt om de interne structuur aan te passen, zou ik gaan denken aan een facade voor de hele meuk zodat je in ieder geval wel een duidelijke 'service' ingang hebt. Hiermee verhinder dat je maar door blijft roeren in ouwe bagger.

[ Voor 57% gewijzigd door Alarmnummer op 04-02-2005 08:07 ]

Acties:

woensdag 8 juni 2005 12:10

Carpe Diem!

Topicstarter

Janoz schreef op maandag 10 januari 2005 @ 14:13:
Het 'dubbele actie probleem door de bak of reload button' weet ik erg goed te omzeilen door 'redirect="true"' te gebruiken waardoor een clientside redirect wordt gegenereerd. Tokens heb ik daarvoor nog neit nodig gehad.

Ik stuit vandaag tegen dit probleem. Een redirect werkt natuurlijk wel, maar ik vraag me af hoe je dan nog aan je ActionMessages geraakt?

offtopic:
Vond het onnodig om hier een nieuw topic voor te starten

Acties:

woensdag 8 juni 2005 12:12

Moderator Devschuur®

!litemod

Dat is inderdaad weer een ander verhaal, ikzelf gebruik action messages eigenlijk nauwelijks. De meeste feedback geef ik al middels clientside validatie. Feedback als 'Element is succesvol verwijderd' bovenaan een lijst geef ik niet omdat dit meestal ook wel aan het missende element in de lijst te zien is.

Naar een oplossing voor dit probleem ben ik trouwens wel benieuwd. Ik heb nu al een tijdje niet meer met Struts gewerkt, maar binnenkort zitten er weer en heleboel Struts projecten aan te komen bij een nieuwe werkgever.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'

Acties:

woensdag 8 juni 2005 13:00

Carpe Diem!

Topicstarter

Ik doe het nu op volgende manier:

Java:

Locale userLocale = (Locale) session.getAttribute(org.apache.struts.action.Action.LOCALE_KEY);

MessageResources msg = getResources(request);
String message = msg.getMessage(userLocale , "msg.added");
session.setAttribute("actionMessage", message);

Met dan in mijn JSP:

Java:

<logic:present name="actionMessage" scope="session">
    <p><bean:write name="actionMessage"/></p>
    <% session.removeAttribute("actionMessage"); %>
</logic:present>

Maar er is vast wel een betere manier? Zodat het gewoon kan afgehandeld worden met de html-tags

Acties:

woensdag 8 juni 2005 21:47

Moderator Devschuur®

!litemod

Dat was ook het idee dat in eerste instantie bij mij op kwam, maar het geeft problemen wanneer dezelfde gebruiker meerdere pagina´s met actionmessages opvraagt. Een in de sessie opgeslagen actionmessage kan immers overschreven worden door een ander request dat gelijktijdig uitgevoerd wordt. Nu zal dit in de praktijk niet vaak voorkomen, maar de kans bestaat wel.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'

Acties:

CubicQ

Maar als het alleen om je message gaat is het de vraag in hoeverre dat functioneel ook echt een probleem is: een gebruiker gaat blijkbaar op twee schermen tegelijk iets doen, en dan is er een kleine kans dat op 1 van de twee schermen een verkeerde message komt te staan.

Zelf zijn we in een project tegen hetzelfde aangelopen, en daar hebben we besloten dat we dit risico aanvaarden, omdat dit in de praktijk eigenlijk geen problemen oplevert (en wanneer het wel een probleem oplevert 1) de gebruiker zelf niet-standaard dingen aan het doen is en 2) er aan de achterkant van het systeem niets mis gaat, het gaat puur om een statusmelding).

woensdag 8 juni 2005 22:24

Acties:

woensdag 6 juli 2005 15:19

Moderator Devschuur®

!litemod

Helemaal mee eens. Waar het mij meer om ging is dat je wel bewust moet zijn van het feit dat dit probleem op zou kunnen treden. Wanneer je bijvoorbeeld framesets gebruikt is het probleem al weer ietsje reëler.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'

Acties:

woensdag 6 juli 2005 15:23

Ik ben momenteel bezig met een onderzoek waarin ik een aantal frameworks met elkaar vergelijk. Het gaat hier eigenlijk specifiek om STRUTS en JSF. Hierbij kom ik regelmatig tegen dat JSF eigenlijk nog geen volledig framework is maar eigenlijk voornamelijk voor de presentatielaag wordt gebruikt.
Er wordt op een aantal paginas wel gesproken over het feit dat JSF STRUTS langzaam gaat vervangen maar dat hiervoor wel veel extra functionaliteit moet worden toegevoegd aan STRUTS.
In andere bronnen kom ik weer tegen dat JSF een goed framework is dat volledig los van STRUTS prima kan worden gebruikt bij systeemontwikkeling.

Is het nou zo dat JSF inmiddels dusdanig ver is doorontwikkeld dat het STRUTS binnekort kan gaan vervangen of is JSF eigenlijk nog steeds erg gericht op het ontwikkelen van de presentatielaag en verder eigenlijk vrij zwak in de rest?

"Hippopotomonstrosesquippedaliophobia" is the term used to describe the fear of long words.

Acties:

woensdag 6 juli 2005 15:36

-= Tja =-

Struts is in principe ook voor de presentatie laag, maar er wordt ten onrechte vaak logica in gepropt. Op het moment dat je logica in structs-actions gaat plaatsen treden er allerlei beperkingen op: slecht remote interface aan kunnen bieden, slecht kunnen wisselen van presentatie laag, slecht te integreren binnen andere systemen (maar dat had ik ook al beetje gezegd bij die remote interface)

In principe zou je gerust wat struts doet in zijn actions in de eventhandlers van JSF kunnen doen. Voor kleine projecten valt hier wel iets voor te zeggen trouwens..

Acties:

woensdag 6 juli 2005 15:47

Dus voor projecten op kleine schaal kan JSF eventueel dienen als vervanger voor STRUTS. Maar mag ik hieruit de conclusie trekken dat JSF (voorlopig althans) niet gezien moet worden als volwaardig vervanger van STRUTS?
Want ik begrijp uit jou reactie dat dit voor grote(re) projecten namelijk niet geld.

"Hippopotomonstrosesquippedaliophobia" is the term used to describe the fear of long words.

Acties:

woensdag 6 juli 2005 15:51

-= Tja =-

Johny58 schreef op woensdag 06 juli 2005 @ 15:36:
Dus voor projecten op kleine schaal kan JSF eventueel dienen als vervanger voor STRUTS. Maar mag ik hieruit de conclusie trekken dat JSF (voorlopig althans) niet gezien moet worden als volwaardig vervanger van STRUTS?
Want ik begrijp uit jou reactie dat dit voor grote(re) projecten namelijk niet geld.

Ik weet daar niet genoeg van. Maar Struts en JSF zijn geen volledige applicatie frameworks. Hun inzetbaarheid is vrij beperkt (en dat is ook absoluut niet erg, want er zijn genoeg andere tools die die rollen vervullen).

Verder kan JSF ook voor grote projecten gebruikt worden. Struts is in principe een beetje verleden tijd aan het worden (alhoewel het nog wel veel gebruikt wordt).

Hoe ziet de structuur van je applicatie er op dit moment uit (Welke tools gebruik je.. ejb/or mappers etc etc)

[ Voor 13% gewijzigd door Alarmnummer op 06-07-2005 15:50 ]

Acties:

woensdag 6 juli 2005 15:51

Ik weet er nog minder van

Ik ben niet bezig met een applicatie, maar slechts met een onderzoek naar manieren waarop een applicaties gemaakt zouden kunnen worden. En dan is het eigenlijk nog specifieker een onderzoek naar het maken van alleen de presentatielaag. Dit stuk wou ik alleen behandelen als een soort van algemeen overzicht van de methodes die ik behandel.

"Hippopotomonstrosesquippedaliophobia" is the term used to describe the fear of long words.

Acties:

momania

iPhone 30! Bam!

-FoX- schreef op woensdag 08 juni 2005 @ 12:12:
Ik doe het nu op volgende manier:
Java:
1
Locale userLocale = (Locale) session.getAttribute(org.apache.struts.action.Action.LOCALE_KEY);

offtopic:
Die kan je in een Action ook gewoon zo ophalen hoor:

Java:

1	Locale userLocale = getLocale(request);

Neem je whisky mee, is het te weinig... *zucht*

woensdag 6 juli 2005 16:02

Acties:

woensdag 6 juli 2005 16:13

Carpe Diem!

Topicstarter

Johny58 schreef op woensdag 06 juli 2005 @ 15:51:
Ik weet er nog minder van
Ik ben niet bezig met een applicatie, maar slechts met een onderzoek naar manieren waarop een applicaties gemaakt zouden kunnen worden. En dan is het eigenlijk nog specifieker een onderzoek naar het maken van alleen de presentatielaag. Dit stuk wou ik alleen behandelen als een soort van algemeen overzicht van de methodes die ik behandel.

Misschien moet je dit artikel maar eens bekijken: PDF: Java Web Frameworks?
Verder kan je zowel JSF als Struts gebruiken voor volwaardige applicaties te maken. Waar de ene component based is, is de andere request based. Maar Struts en JSF zijn niet de enige webframeworks hoor.

offtopic:
Die kan je in een Action ook gewoon zo ophalen hoor:
Java:
1
Locale userLocale = getLocale(request);

Ok, je hebt gelijk

Wicket is nog een relatief nieuw framework, iemand hier al ervaringen mee? Op het eerste zicht lijkt het wel wat..

[ Voor 8% gewijzigd door -FoX- op 06-07-2005 16:04 ]

Acties:

woensdag 6 juli 2005 16:14

-= Tja =-

-FoX- schreef op woensdag 06 juli 2005 @ 16:02:
[...]

Wicket is nog een relatief nieuw framework, iemand hier al ervaringen mee? Op het eerste zicht lijkt het wel wat..

Ik ben er naar aan het kijken. Ik ben nog niet helemaal content over Tapestry:
-het is complex. Alhoewel ik er zelf niet zoveel problemen mee heb zijn we (het bedrijf waar ik werk) bang dat de meeste developers er niet (snel) mee uit de voeten kunnen.
-en er zit veel meuk wat ik niet gebruik.
-documentatie en houding van de mensen staat me ook niet aan.

Ik ben intussen wel achter een paar dingen gekomen die ik zeker niet wil missen in een eventueel nieuw framework. Oa interpage calls... en calls op de page zelf. Verder wil ik voornamelijk een java oo model en zeker niet te veel xml files. Ik denk dat wicket aan deze eisen voldoet.. maar ik moet me er nog meer in verdiepen.

[ Voor 14% gewijzigd door Alarmnummer op 06-07-2005 16:14 ]

Acties:

woensdag 6 juli 2005 19:54

-FoX- schreef op woensdag 06 juli 2005 @ 16:02:
Misschien moet je dit artikel maar eens bekijken: PDF: Java Web Frameworks?
Verder kan je zowel JSF als Struts gebruiken voor volwaardige applicaties te maken. Waar de ene component based is, is de andere request based. Maar Struts en JSF zijn niet de enige webframeworks hoor.

[...]

Dankje, mooi artikel, die had ik nog niet

Ik heb wel een hele hoop andere artikels over zaken die hier omheen hangen etc...
En ik weet ook wel dat er meer webframeworks zijn maar dat is niet mijn opdracht

"Hippopotomonstrosesquippedaliophobia" is the term used to describe the fear of long words.

Acties:

woensdag 6 juli 2005 21:03

-= Tja =-

Verwijderd schreef op woensdag 06 juli 2005 @ 18:43:
[...]
Helemaal onze bedoeling. Drie van Wicket's ontwikkelaars zijn Nederlanders. Komen net terug van JavaOne in San Fransisco waar we een Wicket presentatie hadden, en we (ik) meedeed aan de web framework smackdown.

Verder hebben we voor Wicket een aantal weken geleden 1.0 uitgebracht, wat betekent dat het in basis feature complete is, en dat het stabiel is voor productie systemen (bedrijf waar ik werk, Topicus heeft al enkele producties draaien). Maar nu, voor 1.1 wordt het pas leuk! We hebben inmiddels als core javascript en css support ingebouwd, wat betekent dat je componenten als bijv. datepickers kan bouwen met javascript en css afhankelijkheden, en dat je deze kan gebruiken zonder er ook maar enige kennis van te hebben, en zonder dat je nog eens apart in je header moet opnemen dat deze files dienen te worden gebruikt.

Het is erg belangrijk dat de componenten volledig geconfigureerd kunnen worden. Wij willen onze html dynamisch kunnen maken en niet dynamische componenten html laten genereren (de manier van denken is dus in de omgekeerde richting). Op basis van een grafisch ontwerp moet een html versie gebouwd worden die dus volledig voldoet. Bij Tapestry was het in veel gevallen domweg niet mogelijk om ze goed te configureren (zie bv hun Table). In dat opzicht (en meerdere) heb ik ook mijn vertrouwen in Tapestry verloren en dat is dus een 100% must als we voor een nieuw platform gaan.

Verder hebben we voor 1.1 core ajax support op stapel staan (je kan nu wel ajax gebruiken, maar het is nog niet mooi geintegreerd)

Ajax interesseerd me nog niet zoveel eigelijk.

, en zaken als navigatiemenu componenten en makkelijkere interpagina navigatie etc.

Die eenvoudige interpage calls zijn imho een must. Verder moet het ook eenvoudig zijn om methodes op de page aan te roepen zonder moeilijk te doen. Op dit moment maken we voor een groep met gerelateerde functies een controller en veel functies op een pagina is gewoon een nachtmerrie omdat je dus een zooi controllers nodig bent en allerlei backing objecten met een enorme zooi parameter-code. Ik wil vanuit de html dit gewoon kunne doen:

wicket-html:
<link call="setHaarkleur(persoon,haarkleur)">Verander persoon naar haarkleur<link>

echte html:
<a href="myPage.setHaarkleur(com.beheer.Persoon::21,com.beheer.Kleur:19)">Verander haarkleur van jan naar geel</a>

En dan op de page een methode:

public void setHaarkleur(Persoon p, Kleur k){
...
}

Dit is imho erg belangrijk omdat ik me dan een enorme lading controllers bespaar + omdat ik het nog langer verdom om in allerlei achterlijke bochten te wringen (veel webframework bouwers zijn imho volledig het pad kwijt, oa Maverick). Ik kan in Swing in een uur doen wat ik in Maverick in een dag doe. En dat is puur en alleen omwille van de weblayer..Ik krijg echt zo veel hoofdpijn van onze huidige aanpak (alhoewel dat met tapestry wel een stuk is verbeterd)

Oja.. het moet uiteraard ook eenvoudig zijn om te objecten te serializen naar html en andersom. Ik wil niet zelf nog 1 keer zo`n conversie doen, maar dit moet werken zoals dit bij Tapestry is geregeld (als het goed werkt), dat is een eis.

Verder gaan we bouwen aan portlet support. Ik heb morgen een afspraak met Ate Douma (jawel, weer een Nederlander) die voor het Apache Jetspeed2 project actief is om het over te brainstormen.

Doen we nog niets mee.

We kunnen natuurlijk alle hulp gebruiken die we kunnen krijgen, dus iedereen die dit leest, probeer Wicket eens uit en laat ons weten wat je er van vindt!

Eelco Hillenius

Het staat op mijn programma om eens te proberen.. aangezien Tapestry het niet gaat redden. Dus nu jullie kans

[edit]
Wat ik me trouwens afvraag is waarom er zoveel kritiek is op JSP. Ok.. de synax kan zo nu en dan kut zijn met al dat escaping. Maar ik krijg 3 extreem belangrijke dingen:
-Ik kan de jsp`s compileren -> fouten worden eruit gehaald (dit kan ik 'compiletime' doen als ik wil)
-Het refactored! Ik durf bijna geen webpagina meer aan te passen omdat je zoveel werkt met strings om info ergens vandaan te halen en dit dus niet mee veranderd. In dat op zicht is het werken met die strings weer terug naar de vorige eeuw
-het is duidelijk. Ipv in tags stiekum toch te gaan programmeren, doe je het meteen maar. Uiteraard moet je oppassen met de hoeveelheid logica dat je erin zet (imho alleen view gerelateerde logica), maar als je het goed gebruikt dan vind ik het echt een stuk beter dan programmeren dan het geneuzel met tags (zoals bij Tapestry en Wicket). (Tenzij ze soms iets extra`s bieden dat je niet met JSP kan.. zoals met tapestry zijn templates).

[ Voor 35% gewijzigd door Alarmnummer op 06-07-2005 20:31 ]

Acties:

Verwijderd

[quote]Alarmnummer schreef op woensdag 06 juli 2005 @ 19:54:
[...]

Wij willen onze html dynamisch kunnen maken en niet dynamische componenten html laten genereren (de manier van denken is dus in de omgekeerde richting).
[/qoute]

Wicket gaat uit van de markup, waar je in feite componenten aan koppelt.

DIe eenvoudig interpage calls dat is imho een must. Verder moet het ook eenvoudig zijn om methodes op de page aan te roepen zonder moeilijk te doen. Op dit moment maken we voor een groep met gerelateerde functies een controller en veel functies op een pagina is gewoon een nachtmerrie omdat je dus een zooi controllers nodig bent en allerlei backing objecten met een enorme zooi parameter-code. Ik wil vanuit de html dit gewoon kunne doen:

wicket-html:
<link call="setHaarkleur(persoon,haarkleur)">Verander persoon naar haarkleur<link>

echte html:
<a href="myPage.setHaarkleur(com.beheer.Persoon::21,com.beheer.Kleur:19)">Verander haarkleur van jan naar geel</a>

En dan op de page een methode:

public void setHaarkleur(Persoon p, Kleur k){
...
}

Dit is niet de manier waarop je het in Wicket zou doen. Het is een ontwerpkeuze van Wicket om geheel geen code in de HTML toe te staan (Tapestry staat dit nog wel toe door die Ognl expressies), maar de scheiding helemaal clean te houden (zie onder jsp opmerkingen voor reden).

Je zal dus alles in Java moeten doen, en bijvoorbeeld een link als:

Persoon p;
Color c;
add(new Link("setHaarKleur"){
onClick() {
setHaarKleuk(p, c);
}
});

Als je de concrete haarkleur in je HTML wil kunnen instellen, kun je dat momenteel doen door custom componenten te maken die attributen uitvragen. Zelfs jouw link voorbeeld zou kunnen, maar je moet dat zelf implementeren in je eigen link klasse. En daar zit je waarschijnlijk niet op te wachten.

Ik kan me een nuttige nieuwe feature voorstellen die ongeveer werkt als de informal parameters van Tapestry. Dit zou betekenen dat voor ieder attribuut een match wordt geprobeerd op het component in kwestie, en dat als een match is gevonden, de attribuut waarde op de component property wordt gezet. Uitdaging hierbij is wel om dit efficient te maken. Maar als je het wat vindt (eigenlijk vind ik het zelf wel een goed idee) kun je het voorstellen als een RFE. Bouwen zal niet al te moeilijk zijn verwacht ik.

Dit is imho erg belangrijk omdat ik me dan een enorme lading controllers bespaar + omdat ik het nog langer verdom om in allerlei achterlijke bochten te wringen (veel webframework bouwers zijn imho volledig het pad kwijt, oa Maverick). Ik kan in Swing in een uur doen wat ik in Maverick in een dag doe. En dat is puur en alleen omwille van de weblayer..

Ik ben ook een van de ontwikkelaars van Maverick. Noem het het leer effect. En wees blij dat je Struts niet gebruikt, wat nog een graad erger is dan Maverick (form beans overerving, validatie, tiles). Ik heb destijds Baritus gemaakt om het leven wat te verzachten, maar er is natuurlijk een reden dan ik altijd verder ben gaan zoeken naar andere frameworks. Overigens ben ik niet degene die Wicket heeft opgestart, dat is door Jonathan Locke gedaan, die eerder aan AWT en Swing heeft gewerkt, en onlangs door Microsoft was ingehuurd om aan Avalon te werken.

Maar wat je beschrijft is wat helaas de defacto standaard is momenteel: web mvc cq model 2 frameworks (Struts, Maverick, WebWork, SpringMVC). Allemaal dezelfde zut. Wat ik ook erg vindt is dat je er niet goed van leert programmeren. Met Swing (maar ook met Wicket, Echo en Tapestry) ben je veel meer met OO bezig dan met die procedurele model 2 frameworks.

Wat ik me trouwens afvraag is waarom er zoveel kritiek is op JSP. Ok.. de synax kan zo nu en dan kut zijn met al dat escaping. Maar ik krijg 3 extreem belangrijke dingen:
-Ik kan de jsp`s compileren -> fouten worden eruit gehaald (dit kan ik 'compiletime' doen als ik wil)
-Het refactored! Ik durf bijna geen webpagina meer aan te passen omdat je zoveel werkt met strings om info ergens vandaan te halen en dit dus niet mee veranderd. In dat op zicht is het werken met die strings weer terug naar de vorige eeuw
-het is duidelijk. Ipv in een verkapte vorm van tags stiekum toch te gaan programmeren, doe je het meteen maar. uiteraard moet je oppassen met de hoeveelheid logica dat je erin zet (imho alleen view gerelateerde logica), maar als je het goed gebruikt dan vind ik het echt een stuk beter dan programmeren dan het geneuzel met tags (zoals bij Tapestry en Wicket). (Tenzij ze soms iets extra`s bieden dat je niet met JSP kan.. zoals met tapestry zijn templates).

Topicus maakt aan de lopende band web applicaties, en neemt ook veel jonge (onervaren) mensen aan. Mijn voornaamste probleem met JSP's is dat je JavaCode kunt opnemen in je JSP's. En - zeker onervaren ontwikkelaars - kiezen dan altijd voor de makkelijkste weg, en copy-pasten de hele bende aan elkaar met java code in de JSP's. Tuurlijk KUN je het clean houden met veel discipline, maar ik moet de eerste productie JSP pagina /zonder/ java code nog zien. En onze ervaring (en van die gigantische hoeveelheid mensen die ook anti-JSP zijn) is dat het altijd slecht onderhoudbare troep oplevert.

Wellicht heb je nu ook het voordeel dat JSP's eindelijk volwassen zijn (althans dat hoop ik). Meermaals meegemaakt dat we problemen hadden met taglib pooling implementaties of code generatie die verschilden tussen verschillende servers, zodat we bugs hadden in onze productie systemen, die we niet hadden tijdens ontwikkeling.

En tenslotte webdesigners. Persoonlijk schrijf ik het liefste Java code, en houdt mij zo ver van design af als ik kan. Gelukkig hebben we bij Topicus mensen rondlopen die wel goed zijn in design, dus meestal laten we voor, na of tijdens de bouw zo'n knakker meedraaien voor de layout etc. Ik kan je vertellen dat zij niet vrolijk worden van JSP's (of Velocity etc). Voor hun is het ideaal om puur met de look bezig te zijn, en zich niet te hoeven bekommeren om parameters, loops, en custom tags waar ze niets van begrijpen. Ze zijn op hun best met Dreamweaver of GoLive, en de cleane scheiding van Wicket helpt daarbij enorm. Serieus, onze laatste projecten - met Wicket - hebben we helemaal op die manier gedaan en dat werkte perfect. Onze designers blij, want die konden helemaal los op de looks. Onze java devs blij, omdat ze eindelijk niet teveel met de layout hoefden bezig te zijn.

woensdag 6 juli 2005 21:34

Acties:

woensdag 6 juli 2005 22:02

-= Tja =-

[b][message=23738068,noline]Eelco12 schreef op woensdag 06 juli 2005 @ Dit is niet de manier waarop je het in Wicket zou doen. Het is een ontwerpkeuze van Wicket om geheel geen code in de HTML toe te staan (Tapestry staat dit nog wel toe door die Ognl expressies), maar de scheiding helemaal clean te houden (zie onder jsp opmerkingen voor reden).

Je zal dus alles in Java moeten doen, en bijvoorbeeld een link als:

Persoon p;
Color c;
add(new Link("setHaarKleur"){
onClick() {
setHaarKleuk(p, c);
}
});

Als je de concrete haarkleur in je HTML wil kunnen instellen, kun je dat momenteel doen door custom componenten te maken die attributen uitvragen. Zelfs jouw link voorbeeld zou kunnen, maar je moet dat zelf implementeren in je eigen link klasse. En daar zit je waarschijnlijk niet op te wachten.

Het probleem is dat er soms een variabel aantal links op een pagina staat, bv bij een overzicht. Wat is dan de manier van werken? Eerst de links maken en daarna de links ophalen (vind ik persoonlijk een slechte manier omdat er een grote afstand zit tussen het bouwen en gebruiken en je allerlei loop problematiek meerdere keren moet herhalen). Of adviseren jullie een bouwlink factorymethod die je parametriseerd met de juiste info, en waar je alleen gaat lopen in je velocity. Dit lijkt mij een betere aanpak.

Maar persoonlijk vind ik mijn oplossing (dus de call direct in de html) zo slecht nog niet.

Ik ben ook een van de ontwikkelaars van Maverick.

Goed argument voor een collega/werkgever (die niet van maverick af wil). Zelfs een van de makers geeft toe dat het een hoofdpijn veroorzaker is

Maar wat je beschrijft is wat helaas de defacto standaard is momenteel: web mvc cq model 2 frameworks (Struts, Maverick, WebWork, SpringMVC). Allemaal dezelfde zut.

Idd.. ik heb deze kritiek ook geuit op het Spring forum. niet iedereen was het daar eens mee, maar bij Spring zijn ze vrij goed om te ver door te slaan. Een beetje tegengas geven kan daar geen kwaad.

Wat ik ook erg vindt is dat je er niet goed van leert programmeren. Met Swing (maar ook met Wicket, Echo en Tapestry) ben je veel meer met OO bezig dan met die procedurele model 2 frameworks.

Precies. En verder zijn het gewoon tijd en motivatie vreters. Als ik met Maverick aan de slag moet zit ik zo van "zucht"... ik weet dat het simpeler kan. Het probleem is dat ze bij ons nogal verknocht aan Maverick zijn aangezien ze het al zo lang gebruiken en iedereen ermee kan werken. Verder ben ik ook een van de weinigen met een grondige kennis van Swing en wordt mijn aversie van webpagina`s bouwen geschoven onder dat webpagina`s dan niets voor mij zijn (mijn kennis zit meer in de onderliggende lagen). Het zijn niet de webpagina`s die mij problemen vooroorzaken, het is zijn die achterlijke model2 implementaties (zoals maverick).

Topicus maakt aan de lopende band web applicaties, en neemt ook veel jonge (onervaren) mensen aan. Mijn voornaamste probleem met JSP's is dat je JavaCode kunt opnemen in je JSP's. En - zeker onervaren ontwikkelaars - kiezen dan altijd voor de makkelijkste weg, en copy-pasten de hele bende aan elkaar met java code in de JSP's. Tuurlijk KUN je het clean houden met veel discipline, maar ik moet de eerste productie JSP pagina /zonder/ java code nog zien.

Ik ben een enorme zeiker op het gebied van code, maar onze JSP`s bevatten aleen maar view logica. het is zwaar verboden om in de jsp`s andere dingen te doen. Verder hebben we een laagje over maverick gezet waarmee transacties voor eenvoudige applicaties ook erg eenvoudig te regelen zijn en waardoor mensen sowieso al geen andere dingen dan view-logica in jsp plaatsen (werken met transacties is daar een stuk lastiger).

En tenslotte webdesigners. Persoonlijk schrijf ik het liefste Java code, en houdt mij zo ver van design af als ik kan. Gelukkig hebben we bij Topicus mensen rondlopen die wel goed zijn in design, dus meestal laten we voor, na of tijdens de bouw zo'n knakker meedraaien voor de layout etc. Ik kan je vertellen dat zij niet vrolijk worden van JSP's (of Velocity etc). Voor hun is het ideaal om puur met de look bezig te zijn, en zich niet te hoeven bekommeren om parameters, loops, en custom tags waar ze niets van begrijpen. Ze zijn op hun best met Dreamweaver of GoLive, en de cleane scheiding van Wicket helpt daarbij enorm.

Jullie maken toch gebruik van velocity als basis omgeving? Ik kan me vrij goed voorstellen dat veel html editors er over gaan struikelen. Bij Tapestry had je tenminste 'echte' html syntax met wat onherkenbare html tags. Maar bij wicket heb je gewoon velocity code in je html.. Ik kan me goed voorstellen dat daar toch klachten over komen.

Serieus, onze laatste projecten - met Wicket - hebben we helemaal op die manier gedaan en dat werkte perfect. Onze designers blij, want die konden helemaal los op de looks. Onze java devs blij, omdat ze eindelijk niet teveel met de layout hoefden bezig te zijn.

Het voordeel bij ons is dat ook de designers wel een paar regeltjes java kunnen schrijven. Dus die laten zich niet zo snel uit het veld slaan met niet-html zaken.

Nog een vraag:
Ik zie dat Wicket statemanagement doet door gewoon alle pagina-objecten maar in een sessie te zetten. Voor sommige pagina`s kan dat handig zijn, maar als je zit met external-url`s (url die je aan een ander kan geven en de state wordt weer volledig opgebouwd) dan kan dit een drama zijn. Bij de nieuwste versie van Tapestry kan je alle onderdelen externalizen door hun state te bewaren in de url. Als dit goed uitgevoerd wordt, vind ik dat een zeer krachtige oplossing voor het externalizen van state. Ik heb op jullie site gelezen dat vanaf 1.1 hier wat aan gedaan gaat worden, maar zijn de ideeen al iets concreter?

[ Voor 8% gewijzigd door Alarmnummer op 06-07-2005 21:49 ]

Acties:

Verwijderd

Alarmnummer schreef op woensdag 06 juli 2005 @ 21:34:
[...]

Jullie maken toch gebruik van velocity als basis omgeving? Ik kan me vrij goed voorstellen dat veel html editors er over gaan struikelen. Bij Tapestry had je tenminste 'echte' html syntax met wat onherkenbare html tags. Maar bij wicket heb je gewoon velocity code in je html.. Ik kan me goed voorstellen dat daar toch klachten over komen.

Euhm, nee. Zelfs niet een beetje. We zijn zelfs nog cleaner dan Tapestry in de zin dat we ipv jcwId, dat geen valide html is, we wicket:id gebruiken, wat een namespace is, en helemaal geen scripting toestaan. Puur HTML dus. Wel is het zo dat ik een uitbreiding 'VelocityPanel' heb gemaakt voor CMS achtige toepassingen. Maar dat behoort niet tot de core.

[...]

Het voordeel bij ons is dat ook de designers wel een paar regeltjes java kunnen schrijven. Dus die laten zich niet zo snel uit het veld slaan met niet-html zaken.

Die van ons kunnen dat opzich ook wel, net als PHP etc. Maar zoals de meeste java programmeurs die ik ken (incl. ondergetekende) niet graag veel met HTML werken, werken de meeste designers die ik ken liever niet met scripting etc.

Nog een vraag:
Ik zie dat Wicket statemanagement doet door gewoon alle pagina-objecten maar in een sessie te zetten.

We houden in het sessie object een lijst met laatst gebruikte (bijv. 10) pagina objecten bij. Note hierbij dat het sessie object een abstractie is, waardoor je kan besluiten om de sessie gegevens in een cache of database ipv je http sessie object bij te houden.

Voor sommige pagina`s kan dat handig zijn, maar als je zit met external-url`s (url die je aan een ander kan geven en de state wordt weer volledig opgebouwd) dan kan dit een drama zijn. Bij de nieuwste versie van Tapestry kan je alle onderdelen externalizen door hun state te bewaren in de url. Als dit goed uitgevoerd wordt, vind ik dat een zeer krachtige oplossing voor het externalizen van state. Ik heb op jullie site gelezen dat vanaf 1.1 hier wat aan gedaan gaat worden, maar zijn de ideeen al iets concreter?

Allereerst... veel mensen denken dat client state saving gunstig is voor performance en schaalbaarheid. Dit is slechts zelden het geval. De rekensom is makkelijk, meer server geheugen tegenover meer processor gebruik (serialiseren en zippen, en het weer reconstrueren van de state) en bandbreedte (geserialiseerde state info... kijk maar eens wat er met .NET of JSF over de lijn gaat). Meestal is processor/ bandbreedte eerder een probleem dan geheugen. Na een sessie over schaalbaarheid op JavaOne van een Oracle knakker (weet niet meer hoe hij heet, maar hij post veel op the server side), heb ik deze tradeoffs nog eens expliciet bediscuseerd met hem, en de conclusie was ook hier weer dat server side state meestal te prefereren is boven client side.

Ok, dat gezegd, willen we hier wel support voor gaan inbouwen in Wicket. Overigens kun je nu al bookmarkable pages aanroepen met parameters etc, maar volledig customizable client state management wordt nog niet ondersteund. We hebben er discussies over op de mailinglist (deze week iets van 20 posts), en we hebben het er vandaag offline nog over gehad. Tis een moeilijke, vooral omdat dit alleen maar goed kan werken met posts. En we willen gebruikers niet (zoals JSF) dwingen alles in een form te stoppen, en alles via posts te laten verlopen. Daarnaast willen we een default mechanisme aanbieden dat werkt met object serialisatie, maar je daarnaast de mogelijkheid geven te optimaliseren door een eigen translatie te verschaffen.

woensdag 6 juli 2005 22:16

Acties:

woensdag 6 juli 2005 23:11

-= Tja =-

Verwijderd schreef op woensdag 06 juli 2005 @ 22:02:
Allereerst... veel mensen denken dat client state saving gunstig is voor performance en schaalbaarheid. Dit is slechts zelden het geval.

Die discussie wil ik ook niet starten. het gaat mij erom dat het eenvoudig moet zijn om state in url`s te coderen (automatisch). Als je werkt met componenten (krijg je automatisch met grotere systemen), dan met het eenvoudig voor alle componenten zijn (indien nodig) om externalizebare url`s te maken. Het probleem is dat zo`n component geen weet heeft wat om hem heen zit en ik wil ook niet dat zo`n component dat weet.

Daarom lijkt mij het handig als van een pagina gevraagd kan worden om zijn volledige state in een url te coderen en daarop eventueel de wijzigingen (die door het indrukken van de link worden uitgevoerd) erin te verwerken. Op deze manier kan een hele pagina met meerdere componenten eenvoudig externaliseerbaar gemaakt worden.

Ik heb net dit probleem met Tapestry voor de kiezen gehad en ik heb met de hand de state van de omgeving aan het component meegegeven. Maar dit zou ook volledig geautomatiseerd moeten kunnen.

Tis een moeilijke, vooral omdat dit alleen maar goed kan werken met posts. En we willen gebruikers niet (zoals JSF) dwingen alles in een form te stoppen, en alles via posts te laten verlopen.

Hoezo? Je kunt toch bij het binnenkrijgen van zo`n external link alle onderdelen voeren met de parameters die ze er de vorige keer in hebben gezet?

vb:
<a href="state={page=10,query=java+xml},action=page.gotoPage(11)}">Volgende pagina</a>

de opbouw:
<link state="urlstate" action="page.gotoPage(11)">Volgende pagina</link>

[ Voor 8% gewijzigd door Alarmnummer op 06-07-2005 22:27 ]

Acties:

Verwijderd

Alarmnummer schreef op woensdag 06 juli 2005 @ 22:16:
[...]

vb:
<a href="state={page=10,query=java+xml},action=page.gotoPage(11)}">Volgende pagina</a>

de opbouw:
<link state="urlstate" action="page.gotoPage(11)">Volgende pagina</link>

[/quote]

Parameters als page=10,query=java+xml doorgeven is een eitje. Je kan gewoon met bookmarkable pages werken, en deze parameters meegeven, zodat ze in de constructor van de betreffende pagina's beschikbaar zijn.

Het nadeel van deze manier van werken is echter (hoewel iedereen het natuurlijk zelf moet weten, want fout is het ook niet) dat je niet in objecten denkt. In wicket kun je van alles in je pagina hebben staan, en dat is automatisch beschikbaar als state. Bij het navigeren naar andere pagina's kun je ook iedere willekeurige state meegeven.

Een centraal uitgangspunt bij Wicket is het werken met models. Ieder component heeft (potentieel) een model (instantie van IModel) dat bedoeld is voor het voeren van de view en intake van de controller.

woensdag 6 juli 2005 23:33

Acties:

donderdag 7 juli 2005 10:52

-= Tja =-

Verwijderd schreef op woensdag 06 juli 2005 @ 23:11:
Parameters als page=10,query=java+xml doorgeven is een eitje. Je kan gewoon met bookmarkable pages werken, en deze parameters meegeven, zodat ze in de constructor van de betreffende pagina's beschikbaar zijn.

Ok.. maar als je het eenvoudig wilt maken dat een pagina externizable moet worden, dan moet het eenvoudig zijn dat de onderdelen op pagina hun state kunnen coderen in een url zonder dat die componenten weten welke andere componenten ook op die pagina staan. En dat is hetgeen ik wou laten zien.

Het moet eenvoudig zijn om de volledige state van een pagina (inclusief zijn componenten en eventueel hun componenten) te coderen in een url. En het moet eenvoudig zijn om deze info weer terug te pompen in de objecten. Ipv dat je de session gebruikt als objectopslag, gebruik je nu de url hiervoor.

Het nadeel van deze manier van werken is echter (hoewel iedereen het natuurlijk zelf moet weten, want fout is het ook niet) dat je niet in objecten denkt.

Vind ik hier nog wel meevallen. Het werken met die parameters is niet iets dat een developer zou hoeven doen. Het enigste wat je zou moeten doen is: pagina externaliseer je state in een url.. en dan zou je dat kunnen verrijken met de commando die je daarna zou willen uitvoeren. In java en in de html hoef je hier niets terug van te zien..alleen in de gegeneerde html staan die parameters..

Een centraal uitgangspunt bij Wicket is het werken met models. Ieder component heeft (potentieel) een model (instantie van IModel) dat bedoeld is voor het voeren van de view en intake van de controller.

Maar hoe goed werkt dit als op je pagina meerdere componenten staan? Een van deze componenten is toevallig een pagable overzicht (met volgende/vorige pagina bookmarkable links). In de url`s voor die links moet alle state gecodeerd worden van alle componenten en dat terwijl de componenten niet van elkaars bestaan afweten.

Acties:

BalusC

Carpe diem

Ik heb zelf alleen professionele ervaring met Websphere Studio Application Developer (Eclipse-based), dit is een erg krachtig tool dat praktisch alles aan boord heeft / kan hebben. Ik kom hiermee eigenlijk niks tekort. Er is altijd wel ergens een plugin voor

WAS+WSAD zijn inderdaad vrij log en overkill om thuis/privé mee te beginnen/werken. Naast Websphere heb ik eigenlijk geen ervaring met andere frameworks. In de zomervakantie wil ik eens beginnen met privé J2EE stuff (icm MySQL of Oracle als RDBMS), dus ik zit nu rond te kijken naar freeware/goedkope tooltjes/IDE's vergelijkbaar met WSAD om privé te kunnen gebruiken. En ik ben o.a. Exadel Studio tegengekomen. Op heel GoT komt het woord "exadel" op het moment maar één keer voor. Heeft hier nog niemand ervaring mee? Is het té nieuw? Of heeft het onbekende gebreken? Of is het ook nog veel te log/zwaar/overkill als WSAD?

donderdag 7 juli 2005 11:20

Acties:

donderdag 7 juli 2005 21:32

Carpe Diem!

Topicstarter

BalusC schreef op donderdag 07 juli 2005 @ 10:52:
Ik heb zelf alleen professionele ervaring met Websphere Studio Application Developer (Eclipse-based), dit is een erg krachtig tool dat praktisch alles aan boord heeft / kan hebben. Ik kom hiermee eigenlijk niks tekort. Er is altijd wel ergens een plugin voor

WAS+WSAD zijn inderdaad vrij log en overkill om thuis/privé mee te beginnen/werken. Naast Websphere heb ik eigenlijk geen ervaring met andere frameworks. In de zomervakantie wil ik eens beginnen met privé J2EE stuff (icm MySQL of Oracle als RDBMS), dus ik zit nu rond te kijken naar freeware/goedkope tooltjes/IDE's vergelijkbaar met WSAD om privé te kunnen gebruiken. En ik ben o.a. Exadel Studio tegengekomen. Op heel GoT komt het woord "exadel" op het moment maar één keer voor. Heeft hier nog niemand ervaring mee? Is het té nieuw? Of heeft het onbekende gebreken? Of is het ook nog veel te log/zwaar/overkill als WSAD?

Ik werk momenteel ook met Rational Software Architect (opvolger wsad). Dit is een zeer goede tool, vooral voor WebSphere development, erg krachtig!
Ik heb ooit eens een demo van exadel gebruikt, maar ik vond dat toen niet zo geslaagd (1,5jaar geleden), het kan nu dus wel serieus verbeterd zijn.

Je zou ook eens kunnen kijken naar MyEclipse. Ik heb er zelf nooit mee gewerkt, maar ik hoor er toch goede dingen over.. ideaal voor j2ee development op het eclipse platform.

Verder is er natuurlijk nog DE tool op Java development gebied... IntelliJ IDEA.
Welke tool je moet kiezen is natuurlijk heel persoonlijk en kan je het beste doen door alle IDE's een tijdje te gebruiken.

Acties:

donderdag 7 juli 2005 23:49

-= Tja =-

-FoX- schreef op donderdag 07 juli 2005 @ 11:20:
[...]

Ik werk momenteel ook met Rational Software Architect (opvolger wsad). Dit is een zeer goede tool, vooral voor WebSphere development, erg krachtig!
Ik heb ooit eens een demo van exadel gebruikt, maar ik vond dat toen niet zo geslaagd (1,5jaar geleden), het kan nu dus wel serieus verbeterd zijn.

Je zou ook eens kunnen kijken naar MyEclipse. Ik heb er zelf nooit mee gewerkt, maar ik hoor er toch goede dingen over.. ideaal voor j2ee development op het eclipse platform.

Verder is er natuurlijk nog DE tool op Java development gebied... IntelliJ IDEA.
Welke tool je moet kiezen is natuurlijk heel persoonlijk en kan je het beste doen door alle IDE's een tijdje te gebruiken.

Het 'nadeel' aan idea is dat het alleen een 'editor' is.. dus perfect voor schrijven van code, maar het kan verder niets. Er zit totaal geen ondersteuning op voor allerlei grafische tools/plugins... ik heb er zelf niet zoveel problemen mee.. maar het kan een argument zijn om idea niet te kiezen.

Acties:

momania

iPhone 30! Bam!

-FoX- schreef op donderdag 07 juli 2005 @ 11:20:
[...]
Je zou ook eens kunnen kijken naar MyEclipse. Ik heb er zelf nooit mee gewerkt, maar ik hoor er toch goede dingen over.. ideaal voor j2ee development op het eclipse platform.

Ik werk zelf ook veel met WSAD, maar heb idd ook wel eens gewoon eclipse in combinatie met MyEclipse gebruikt en ik moet zeggen dat je bijna geen verschil merkt.

MyEclipse is echt enorm compleet en imo voor een zeer redelijke (zeg maar gerust goedkope) prijs aan te schaffen. Voor 'thuis projectjes' dus ideaal

Neem je whisky mee, is het te weinig... *zucht*

vrijdag 8 juli 2005 01:55

Acties:

KurtDB

momania schreef op donderdag 07 juli 2005 @ 23:49:
[...]

Ik werk zelf ook veel met WSAD, maar heb idd ook wel eens gewoon eclipse in combinatie met MyEclipse gebruikt en ik moet zeggen dat je bijna geen verschil merkt.

MyEclipse is echt enorm compleet en imo voor een zeer redelijke (zeg maar gerust goedkope) prijs aan te schaffen. Voor 'thuis projectjes' dus ideaal

Enige nadeel naar mijn mening aan MyEclipse is wat wij bij ons op 't werk de white toolbar of death noemen. Hij gaat elke XML-file met 'n dtd automagisch controleren. In plaats van het feit dat hij de dtd lokaal zou cachen (wat heel wat verschil zou maken qua performantie) gaat hij de hele file telkens weer ophalen. Hierbij komt 't dus regelmatig voor dat Eclipse totaal niet meer reageert en je toolbar dus wit wordt.

vrijdag 8 juli 2005 18:11

Acties:

vrijdag 8 juli 2005 23:37

-= Tja =-

Verwijderd schreef op woensdag 06 juli 2005 @ 23:11:

Heb je trouwens ook een overzicht van de voor en tegens van de model2 vs event-based web frameworks? Bij het bedrijf waar ik werk zijn we hevig in discussie over wat we nu gaan doen met maverick en waarom event based systemen nu zo (godsellendig veel) eenvoudiger zijn dan model2 based systemen. Aangezien jij een stuk meer ervaring ermee hebt dan wij, neem ik aan dat je de voor en tegens ook goed uit kunt leggen.

Acties:

zneek

Verwijderd schreef op vrijdag 08 juli 2005 @ 23:10:
[...]

Sure. Ik heb deze week de leads van Tapestry en JSF een mailtje gestuurd met de vraag of ze wat zagen in het gezamelijk schrijven van een artikel over component based vs model2 frameworks. Helaas geen antwoord gekregen; in San Fransisco leken ze hier wel in geinteresseerd, maar nu het JavaOne feest over is zit iedereen weer in de concurrentie modus blijkbaar.

Iig, het schrijven van een goed artikel kost behoorlijk wat tijd, dus dat kan ik niet zo even aanleveren. Ik zal wel dit weekeinde proberen een paar punten onder elkaar te zetten, en dat op dit forum te posten. Moet ik een nieuwe thread starten, of zal ik dat op deze doen?

Eelco

Kun je dan misschien ook iets schematisch op papier zetten over de werking? Of staat daar al ergens iets over? Ik probeer me voor te stellen hoe de structuur eruit ziet. Welke elementen zijn er betrokken bij een bepaalde functie/scherm/pagina? En wat doen ze precies?

[edit] Oh ja, ik kon ook niet iets vinden over het installeren/gebruiken. Wat moet ik er voor doen om dat Hello world voorbeeld eens te testen? Of moet ik dan de hele bende downen? Anders doe ik dat morgen of maandag ff. Al gevonden. De directe links vanaf de wicket homepage naar de new user guide werken niet, maar als je vanuit het linkermenu naar de Wiki gaat kun je er wel bij.

[ Voor 17% gewijzigd door zneek op 08-07-2005 23:49 ]

zaterdag 9 juli 2005 00:25

Acties:

zaterdag 9 juli 2005 00:30

-= Tja =-

Verwijderd schreef op vrijdag 08 juli 2005 @ 23:10:
[...]
Sure. Ik heb deze week de leads van Tapestry en JSF een mailtje gestuurd met de vraag of ze wat zagen in het gezamelijk schrijven van een artikel over component based vs model2 frameworks. Helaas geen antwoord gekregen; in San Fransisco leken ze hier wel in geinteresseerd, maar nu het JavaOne feest over is zit iedereen weer in de concurrentie modus blijkbaar.

Uiteraard. Niemand heeft belangstelling om samen tot een goeie oplossing te komen (zeker tapestry niet) en iedereen zal uiteraard zijn eigen ding gaan doen. Ik heb trouwens de discussie op the serverside even nagelezen... typisch.. echte tranentrekker. Dan vraag je je toch af waarom je het uberhaubt doet. Op javalobby zit net zo`n collectie met dombo`s.

Iig, het schrijven van een goed artikel kost behoorlijk wat tijd, dus dat kan ik niet zo even aanleveren. Ik zal wel dit weekeinde proberen een paar punten onder elkaar te zetten, en dat op dit forum te posten. Moet ik een nieuwe thread starten, of zal ik dat op deze doen?

Paar punten is voldoende hoor.. Heel artikel in elkaar zetten is te veel van het goeie om zo even in elkaar te zetten.. en ik denk dat het het handigste is om in dit forum te posten aangezien het niet altijd op prijs gesteld word om een nieuw topic op te starten over je eigen product.

En welk bedrijf werk je dan?

Het hotste en meest moderne bedrijf uit het noorden des lands Anchormen

Ruleengines? Zoekengines met gelikte flashinterfaces? Realtime systemen? You name it.. we make it

[ Voor 13% gewijzigd door Alarmnummer op 09-07-2005 00:29 ]

Acties:

zneek

Alarmnummer schreef op zaterdag 09 juli 2005 @ 00:25:

Het hotste en meest moderne bedrijf uit het noorden des lands Anchormen Ruleengines? Zoekengines met gelikte flashinterfaces? Realtime systemen? You name it.. we make it

Maar jammer genoeg niet met een up-to-date portfolio. Komt heel binnenkort

Druk druk druk. Werken met Maverick kost zoveel tijd dat we geen tijd meer hebben voor ons portfolio

zondag 10 juli 2005 17:21

Acties:

ari3

Maven: Structuur brengen in het hele dependency verhaal. Maven ontkoppeld tevens de projectdefinities van de IDE zodat iedere ontwikkelaar in het team zijn eigen IDE kan kiezen. Het heeft een zekere leercurve, maar als je eenmaal het licht gezien hebt wil je nooit meer terug naar Ant.

XDoclet: Genereren van beans en deploymentdescriptors op basis van annotaties. Werkt erg goed. Zo goed zelfs dat de toekomstige J2EE spec het idee heeft overgenomen. Voordeel: generatie van beans is losgekoppeld van de IDE. Er is een XDoclet Maven-plugin van productiekwaliteit.

CVS: CVS is natuurlijk een veteraan onder de versiebeheersystemen. Voordeel is dat het stabiel is en standaard ondersteuning vindt in diverse tools (Eclipse, Maven, Ant, etc.). Nadeel is dat het enigzins beperkt is. Bij refactoring (en dus het verplaatsen van bestanden) verlies je de historie van de bestanden.

Cygwin: Deze noem ik voornamelijk vanwege de enorme productiviteitswinst. Cygwin maakt namelijk de hele GNU-toolset zoals je die heb onder *BSD/Linux beschikbaar onder Windows. Hiermee wordt de commandline onder Windows bruikbaar.

"Kill one man, and you are a murderer. Kill millions of men, and you are a conqueror. Kill them all, and you are a god." -- Jean Rostand

zondag 10 juli 2005 18:53

Acties:

misfire

Wicket was voor mij een complete verrassing in het lijstje van de Web UI smackdown, maar toen ik las dat het pas 3 weken uit was snapte ik het wel.

Wat ik jammer vindt aan al die Web UI frameworks is dat ieder framework zijn sterke en zwakke punten heeft, maar er geen enkel framework écht boven de rest uitsteekt. Wicket lijkt in eerste instantie op een Tapestry redone, waar een aantal scherpe randjes van Tapestry zijn verwijderd. Tapestry is echter al jaren in productie, en kent met name in Amerika een aantal grote klanten, er is een redelijke Eclipse plug-in, en er zijn boeken. Als ik Wicket ga gebruiken dan mis ik dat allemaal, en het de verschillen met Tapestry zijn in mijn ogen niet zo heel groot. Waarom dan Wicket gebruiken?

Frameworks als JSF en Tapestry zijn pluggable. Waarom geen extensies schrijven voor deze frameworks om het leven wat makkelijker te maken (zoals Shale)?

Tenslotte wordt het argument gebruikt dat JSP evil is omdat je er Java in kunt schrijven. Ten eerste kan sinds J2EE 1.4 het gebruik van scriptlets worden verboden in JSP pagina's. Ten tweede ontstaan bad practices als het embedden van coden vaak doordat het vroeger moeilijker was om Java code aan de HTML te koppelen als je een strikte scheiding maakte. Met JSF is er nu ook een duidelijkere koppeling, die makkelijk is omdat er een brede toolsupport is/komt. Een paar belangrijke nadelen zijn hiervoor bij JSF weggenomen, helaas alleen niet het feit dat je JSF moet gaan zoeken naar een HTML tag, en je designers er dus niet blij van worden.

Als het argument is dat als je een junior op een JSP applicatie zet hij er een potje van maakt, dan denk ik dat een junior er ook een potje van maakt bij een Swing of Wicket applicatie. Juniors maken een gewoon een potje, maar als het goed is leren ze daar van.

Ik zal Wicket en andere Web frameworks zeker met interesse volgen. Als best practice zal ik voorlopig echter niet beschouwen. JSF en Tapestry bieden nu al vergelijkbare oplossingen die een stuk volwassener zijn.

zondag 10 juli 2005 20:10

Acties:

Verwijderd

misfire schreef op zondag 10 juli 2005 @ 18:53:
Wat ik jammer vindt aan al die Web UI frameworks is dat ieder framework zijn sterke en zwakke punten heeft, maar er geen enkel framework écht boven de rest uitsteekt. Wicket lijkt in eerste instantie op een Tapestry redone, waar een aantal scherpe randjes van Tapestry zijn verwijderd. Tapestry is echter al jaren in productie, en kent met name in Amerika een aantal grote klanten, er is een redelijke Eclipse plug-in, en er zijn boeken. Als ik Wicket ga gebruiken dan mis ik dat allemaal, en het de verschillen met Tapestry zijn in mijn ogen niet zo heel groot. Waarom dan Wicket gebruiken?

We horen vaker dat Wicket op Tapestry lijkt. Tapestry zonder XML zeg maar. Dit is echter slechts zeer op de oppervlakte. Niet alleen onder de motorkap is Wicket anders, ook in het gebruik is dat het geval. Wicket werkt bijvoorbeeld expliciet met model objecten bij je componenten. Tapestry heeft een ingewikkeld page pooling mechanisme waardoor je alleen instantie variabelen kunt gebruiken door ze te 'recorden', terwijl bij Wicket alle state beschikbaar is zonder dergelijke beperkingen. Er zijn behoorlijk meer verschillen. Maar... zelfs al zou het Tapestry zonder de ruige kantjes zijn, dan nog kunnen een paar kleine verschillen mega uitmaken in een project. Die paar detail kwesties van Ant vs Maven, Hibernate vs JDO, etc?

Frameworks als JSF en Tapestry zijn pluggable. Waarom geen extensies schrijven voor deze frameworks om het leven wat makkelijker te maken (zoals Shale)?

Allereerst heb ik mensen gezocht (bij het MyFaces project) om te gaan werken aan een non-JSP oplossing. De reacties waren lauw, en zo'n project heeft ook nog eens het nadeel dat het toch niet ondersteund zal worden door IDE's. Alternatieven beginnen nu langzaam op gang te komen (bijv. facelets), maar bieden wat mij betreft nog geen werkelijk alternatief. En of Shale een goed idee is... dat is zeker niet de hele wereld met je eens.

Tenslotte wordt het argument gebruikt dat JSP evil is omdat je er Java in kunt schrijven. Ten eerste kan sinds J2EE 1.4 het gebruik van scriptlets worden verboden in JSP pagina's.

Goede zaak! Dat was mij niet bekend. Helaas blijft het mixen van tags een even groot probleem.

Ten tweede ontstaan bad practices als het embedden van coden vaak doordat het vroeger moeilijker was om Java code aan de HTML te koppelen als je een strikte scheiding maakte. Met JSF is er nu ook een duidelijkere koppeling, die makkelijk is omdat er een brede toolsupport is/komt. Een paar belangrijke nadelen zijn hiervoor bij JSF weggenomen, helaas alleen niet het feit dat je JSF moet gaan zoeken naar een HTML tag, en je designers er dus niet blij van worden.

Mee eens, enige vooruitgang wordt er wel gemaakt. Er zijn echter 100.000 zaken die JSF voor mij iig niet aantrekkelijk maken. Het schrijven van componenten is nodeloos ingewikkeld. Je moet veel van de interne werking afweten om het goed te gebruiken (mixen van tags, de request processing cycle, hoe managed beans worden bijgehouden). Met een goede IDE wordt je een hoop uit handen genomen, dat is waar, maar noem me ouderwets: ik wil graag een framework gebruiken waarmee ik code schrijf die ook zonder IDE snel te begrijpen is en waarbij ik me geen zorgen hoef te maken of de component sets wel beschikbaar zijn in een andere IDE).

Trouwens, ik heb wel wat gespeeld met de tools die nu voor JSF beschikbaar zijn (SJ Creator). Ik weet niet wat jouw ervaringen hiermee zijn, maar ik zou er nog geen serieus project mee durven bouwen.

Als het argument is dat als je een junior op een JSP applicatie zet hij er een potje van maakt, dan denk ik dat een junior er ook een potje van maakt bij een Swing of Wicket applicatie. Juniors maken een gewoon een potje, maar als het goed is leren ze daar van.

Weer waar. Maar hoe beter de API, hoe minder ze er een potje van kunnen maken. JSF is daar niet bijzonder sterk in.

Ik zal Wicket en andere Web frameworks zeker met interesse volgen. Als best practice zal ik voorlopig echter niet beschouwen. JSF en Tapestry bieden nu al vergelijkbare oplossingen die een stuk volwassener zijn.

Jezelf op de hoogte houden van ontwikkelingen is altijd goed

Wicket is nog niet super volwassen, dat klopt. We werken er hard aan. Dat valt met JSF ook erg tegen trouwens, ik ben een avond met de leads van Shale en JSF opgetrokken, en /de/ reden voor het bestaan van Shale is het feit dat JSF op een hoop gebeiden nog niet goed is. Het is een bewuste strategie om Shale te gebruiken voor probeersels/ fixes die evt later in JSF kunnen worden geintegreerd. Tot zover het argument van volwassenheid.

We zijn er met Wicket niet op uit om de wereld te veroveren, dus als je tevreden bent met Tapestry/ JSF/ Shale is dat prima (hoewel naar mijn mening wel iedereen van model 2 frameworks af zou moeten). Wicket biedt een alternatief voor de mensen die Tapestry en JSF niet optimaal vinden. Tot die groep behoor ik natuurlijk zelf ook: voor Wicket /heb/ ik serieus naar JSF en Tapestry gekeken, maar Wicket kwam er toen al (september vorig jaar) als m'n favoriet uit (voor de duidelijkheid: ik ben niet de originele ontwikkelaar).

[ Voor 6% gewijzigd door Verwijderd op 10-07-2005 21:11 ]

maandag 11 juli 2005 07:56

Acties:

woensdag 13 juli 2005 15:47

-= Tja =-

Verwijderd schreef op zondag 10 juli 2005 @ 20:10:
[...]
We horen vaker dat Wicket op Tapestry lijkt. Tapestry zonder XML zeg maar. Dit is echter slechts zeer op de oppervlakte. Niet alleen onder de motorkap is Wicket anders, ook in het gebruik is dat het geval. Wicket werkt bijvoorbeeld expliciet met model objecten bij je componenten. Tapestry heeft een ingewikkeld page pooling mechanisme waardoor je alleen instantie variabelen kunt gebruiken door ze te 'recorden', terwijl bij Wicket alle state beschikbaar is zonder dergelijke beperkingen.

Maar bij Tapestry kan hierdoor wel de state van een pagina geextraheerd en geinjecteerd worden. In principe is het een jointpoint bij velden plaatsen met een afluister advice wat je misschien ook wel met bytecode enhancement zou kunnen realiseren (denk dat dit zonder extra metadata wel erg onduidelijk kan worden) Alhoewel de Tapestry implementatie geen schoonheids prijst verdient *moppelt iets over EJB en een gelijksoortige oplossing* het werkt wel. En met de nieuwe annotations hoef je daarvoor ook minder in die page files zitten te knoeien.

Maar het extraheren van de state kan Wicket nog niet en dat is eigelijk op dit moment nog mijn grootste punt van kritiek. Voor voor complexe pagina`s met meerdere componenten moet het eenvoudig zijn om de state eruit te kunnen trekken (en dat onder te brengen in bv een url).

Ik wil dat dit eenvoudig is en ik zit daarom ook te wachten op Wicket 1.1 waarin dit probleem opgelost gaat worden.

misfire
Ik zal Wicket en andere Web frameworks zeker met interesse volgen. Als best practice zal ik voorlopig echter niet beschouwen. JSF en Tapestry bieden nu al vergelijkbare oplossingen die een stuk volwassener zijn.

Ik heb begrepen (geen praktische ervaring) dat JSF nog veel meer configureerwerk is als Tapestry. Verder heb ik met 9 van de 10 specs die sun nog uitbrengt, dat het hele grote en loge specificaties zijn, gemaakt voor grote automatiseerders en tool developers, maar niet voor de programmeur. Ik wil lichte tools die aansluiten bij mijn manier van denken. En verder wil ik lichte tools omdat ik wil begrijpen als er iets misgaat. Niet staan roeren in 1500 regels stacktrace (alhoewel JBoss ook een grote producent van stacktraces is). En ik kan me dan concentreren op de zaken die echt interessant zijn: de problemen die ik moet oplossen. En niet op wat waardeloze tools..

[ Voor 48% gewijzigd door Alarmnummer op 11-07-2005 08:07 ]

Acties: