[J2EE] RAD en Web application development

Pagina: 1
Acties:

  • -FoX-
  • Registratie: Januari 2002
  • Niet online

-FoX-

Carpe Diem!

Topicstarter
Teneerste ontwikkel ik zeer graag webapplicaties in Java. Ik maak dan ook gretig gebruik van een aantal frameworks die het werk een stuk vergemakkelijken; Mijn keuze van frameworks ligt doorgaans bij Struts/Spring/Hibernate, verder ANT en JUnit.

Ik heb echter enorm het gevoel dat RAD en J2EE web application development niet zo goed samengaan. Zeker op het gebied van 'time is money'.

Voorbeeld
Af en toe doe ik ook wel eens mee aan de ontwikkeling van een webapplicatie, buiten mijn uren in een fulltime job (ook voornamelijk web app dev.). Nu zijn dit ook meestal webapplicaties voor de gewone KMO zeg maar. Meestal maak ik vooraf eerst een estimatie van de tijd/kostprijs (en zit daar vaak goed mee) en ik krijg ook wel geregeld te horen dat het te lang zou duren of de kostprijs te hoog zou zijn.
Een PHP variant zou bijvoorbeeld maar de helft van de tijd in beslag nemen... en dan ook nog eens half zo goedkoop zijn.

Software kwaliteit, uitbreidbaarheid, schaalbaarheid, ... heeft de klant weinig oren naar of het interesseert hem gewoon niet; als het maar werkt.


Hoe gaan jullie om met dergelijke situaties?

Laten jullie dergelijke potentiëlen gewoon aan je voorbijgaan, schakelen jullie over naar een scripting variant, of hoe reageren jullie doorgaans hierop?

Of ligt het aan mij en is het ontwikkelen van J2EE webapplicaties helemaal niet trager dan een of andere scripting variant?

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

-FoX- schreef op vrijdag 03 juni 2005 @ 11:47:
Ik heb echter enorm het gevoel dat RAD en J2EE web application development niet zo goed samengaan. Zeker op het gebied van 'time is money'.
Dat gevoel heb ik ook wel eens (wel vaker dan eens) bij Java. Bij het bedrijf waar ik werk zijn we qua techniek al een eind vooruit gegaan (hibernate/spring). Maar er zijn nog veel dingen waarbij ik het gevoel heb: weinig functionaliteit erbij.. maar toch veel tijd kwijt.

Op dit moment heb ik dat gevoel voornamelijk bij:
-ontwikkelen van de weblayer (nu Maverick+JSP, toekomst Tapestry/JSF)
-db koppeling (allemaal losse tools en jezelf 10 keer herhalen.. maar deze tijd valt in het niets bij het vorige punt).
Of ligt het aan mij en is het ontwikkelen van J2EE webapplicaties helemaal niet trager dan een of andere scripting variant?
Ik heb geen ervaring met scripting omgevingen, maar ik weet wel dat de ontwikkeling van java applicaties veel en veel sneller kan. Ik denk ook dat het verstandig is om van blueprints en andere 'best' practices af te stappen. Don`t pay for whay you don`t use. Ik ben zelf ook vaak tijd kwijt aan niet gebruikte 'features' van een of ander platform waarvan de inhoud me eigelijk niet interesseerd en die ik ook niet gebruik.

[ Voor 18% gewijzigd door Alarmnummer op 03-06-2005 12:03 ]


  • ronaldmathies
  • Registratie: Juni 2001
  • Niet online
Mijn ervaring is dat het nier veel langer duurt dan andere talen.

Alleen wat ik wel heb is dat ik voor veel componenten in mijn webpagina zelf custom JSF tags heb ontwikkeld. (bijvoorbeeld tabbladen, tabellen met sortering en paging erin, menu/submenu, etc..).
Ikzelf ben begonnen met Struts maar ben nu langzamerhand een nieuw basis framework aan het maken in JSF. En ik kan hier nog veel sneller mee ontwikkelen dan dat ik met Struts kon. Zeker op gebied van custom components is JSF veel flexibeler en krachtiger.

Hier een simpel voorbeeld:

HTML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
<vh:table border="0" cellspacing="0" cellpadding="3">
    <vh:tr>
        <vh:td colspan="2">
            <vh:datatable 
                width="400" 
                list="#{languageHandler.languages}" 
                variable="var"
                paginatorselectedpage="#{languageHandler.selectedpage}"
                paginatorrowsperpage="5"
                paginatormargin="4"
                actionlistener="#{languageHandler.processAction}"
                enablerowevents="false">
                <vh:column sortable="true" sortfield="#{var.code}">
                    <vh:header styleclass="dGHLeft" onmouseoverstyleclass="dGHLeft dGHLeftOnMouseOver" onmouseoutstyleclass="dGHLeft dGHLeftOnMouseOut">
                        <h:outputText value="#{applicationmessages['label.code']}"/>
                    </vh:header>
                    <vh:value styleclass="dGVLeftRequired" onmouseoverstyleclass="dGVLeftRequired dGVLeftOnMouseOverRequired" onmouseoutstyleclass="dGVLeftRequired dGVLeftOnMouseOutRequired">
                        <h:inputText id="code" value="#{var.code}" required="true" styleClass="requiredgrid">
                            <f:validateLength maximum="255"/>
                            <vh:validateemail/>
                        </h:inputText><vh:br/>
                        <h:message for="code" infoClass="messageinfo" warnClass="messagewarn" errorClass="messageerror" fatalClass="messagefatal"/>
                    </vh:value>
                </vh:column>
                <vh:column sortable="true" sortfield="#{var.name}">
                    <vh:header styleclass="dGHMiddle" onmouseoverstyleclass="dGHMiddle dGHMiddleOnMouseOver" onmouseoutstyleclass="dGHMiddle dGHMiddleOnMouseOut">
                        <h:outputText value="#{applicationmessages['label.description']}"/>
                    </vh:header>
                    <vh:value styleclass="dGVMiddleRequired" onmouseoverstyleclass="dGVMiddleRequired dGVMiddleOnMouseOverRequired" onmouseoutstyleclass="dGVMiddleRequired dGVMiddleOnMouseOutRequired"> 
                        <vh:table border="0" cellspacing="0" cellpadding="0">
                            <vh:tr>
                                <vh:td valign="top">
                                    <vh:togglearea open="${pageContext.request.contextPath}/global/image/arrow_down.gif"
                                               close="${pageContext.request.contextPath}/global/image/arrow_right.gif"
                                               for="naam"
                                               smallwidth="100px"
                                               smallheight="30px"
                                               largewidth="200px"
                                               largeheight="200px"/>
                                </vh:td>
                                <vh:td>
                                    <h:inputTextarea id="naam" value="#{var.name}" style="width: 100px; height: 30px;" cols="24" rows="32" required="true" styleClass="requiredgrid">
                                        <f:validateLength maximum="255"/>
                                    </h:inputTextarea>
                                </vh:td>
                            </vh:tr>
                        </vh:table>
                        <h:message for="naam" infoClass="messageinfo" warnClass="messagewarn" errorClass="messageerror" fatalClass="messagefatal"/>
                    </vh:value>
                </vh:column>
                <vh:column sortable="true" sortfield="#{var.prlsCode}">
                    <vh:header styleclass="dGHMiddle" onmouseoverstyleclass="dGHMiddle dGHMiddleOnMouseOver" onmouseoutstyleclass="dGHMiddle dGHMiddleOnMouseOut">
                        <h:outputText value="#{applicationmessages['label.pro.logboek.code']}"/>
                    </vh:header>
                    <vh:value styleclass="dGVMiddle" onmouseoverstyleclass="dGVMiddle dGVMiddleOnMouseOver" onmouseoutstyleclass="dGVMiddle dGVMiddleOnMouseOut"> 
                        <h:inputText id="prlsCode" value="#{var.prlsCode}" size="24" styleClass="normalgrid">
                            <f:validateLength maximum="255"/>
                            <vh:validateequal for="code" label="#{applicationmessages['label.code']}"/>
                        </h:inputText><vh:br/>
                        <h:message for="prlsCode" infoClass="messageinfo" warnClass="messagewarn" errorClass="messageerror" fatalClass="messagefatal"/>
                    </vh:value>
                </vh:column>
                <vh:column sortable="true" sortfield="#{var.default}">
                    <vh:header styleclass="dGHMiddle" onmouseoverstyleclass="dGHMiddle dGHMiddleOnMouseOver" onmouseoutstyleclass="dGHMiddle dGHMiddleOnMouseOut">
                        <h:outputText value="#{applicationmessages['label.default']}"/>
                    </vh:header>
                    <vh:value styleclass="dGVMiddle" onmouseoverstyleclass="dGVMiddle dGVMiddleOnMouseOver" onmouseoutstyleclass="dGVMiddle dGVMiddleOnMouseOut" align="center">
                        <h:selectBooleanCheckbox value="#{var.default}"/>
                    </vh:value>
                </vh:column>
                <vh:column>
                    <vh:header styleclass="dGHRight" onmouseoverstyleclass="dGHRight dGHRightOnMouseOver" onmouseoutstyleclass="dGHRight dGHRightOnMouseOut">
                        <vh:nbsp/>
                    </vh:header>
                    <vh:value styleclass="dGVRight" onmouseoverstyleclass="dGVRight dGVRightOnMouseOver" onmouseoutstyleclass="dGVRight dGVRightOnMouseOut">
                        <vh:datatablecommandbutton value="#{messages['button.remove']}" actionlistener="#{languageHandler.processAction}" eventid="remove" arg0="#{var.id}"/>
                        <vh:datatablecommandbutton value="#{messages['button.copy']}" actionlistener="#{languageHandler.processAction}" eventid="copy" arg0="#{var.id}"/>
                    </vh:value>
                </vh:column>
            </vh:datatable>
        </vh:td>
    </vh:tr>
    <vh:tr>
        <vh:td>
            <h:commandButton id="add" value="#{messages['button.add']}" actionListener="#{languageHandler.processAction}"/>
        </vh:td>
        <vh:td align="right">
            <h:commandButton value="#{messages['button.store']}" action="#{languageHandler.store}"/>
            <h:commandButton value="#{messages['button.cancel']}" action="#{languageHandler.cancel}"/>
        </vh:td>
    </vh:tr>
</vh:table>


Dit is een scherm met een tabel erin, hierin zitten een aantal kolommen. één met e-mail validatie en een maximum lengte. kolom twee heeft een toggle functie (klik op de toggle en het invoerveld wordt vergroot) en een maximum lengte validatie. kolom drie heeft een maximum lengte validatie en als er wat ingevuld is dan moet dit dezelfde waarde hebben als kolom één. kolom vier heeft twee knoppen waarbij de eerste knop de mogelijkheid geeft de regel te verwijderen en de tweede knop de mogelijkheid geeft de regel te kopieren naar een nieuwe regel. daarnaast zijn alle kolommen sorteerbaar op de laatste na. en onder de tabel is een reeks aan pagina nummers.

Dit voorbeeld heb ik in 8 minuten gemaakt waarbij de data op de server volledig afgehandeld wordt.

Mijn custom componenten zijn in dit geval:

De tabel (incl. sorteren).
De knoppen (geven een event met opgegeven argumenten).
De e-mal validatie.
De validatie of het ene veldt gelijk is aan het andere veldt.
Het scherm. (UI achtig scherm)

Ik hoef nul, nul javascript te schrijven (wordt gegenereerd)

Veel mensen die beginnen met J2EE Web Applicaties door alleen een basis framework te bruiken zoals bijvoobeeld Struts, alleen maken ze vaak geen componenten. En daar zit hem juist de kracht van Java.

3015 Wp-z 5360 Wp-nno op 2 x SMA-SB3600 TL-21, Warmtepomp: ERSC-VM2CR2 / PUHZ-SHW140 YHA, WTW Q350, EV Kia Ev6 GT-Line


  • -FoX-
  • Registratie: Januari 2002
  • Niet online

-FoX-

Carpe Diem!

Topicstarter
ronaldmathies schreef op vrijdag 03 juni 2005 @ 12:03:
Mijn ervaring is dat het niet veel langer duurt dan andere talen.
Niet veel, maar toch wel langer dus?
Alleen wat ik wel heb is dat ik voor veel componenten in mijn webpagina zelf custom JSF tags heb ontwikkeld. (bijvoorbeeld tabbladen, tabellen met sortering en paging erin, menu/submenu, etc..).
Ikzelf ben begonnen met Struts maar ben nu langzamerhand een nieuw basis framework aan het maken in JSF. En ik kan hier nog veel sneller mee ontwikkelen dan dat ik met Struts kon. Zeker op gebied van custom components is JSF veel flexibeler en krachtiger.
Ok, op dit punt ben je nu misschien wel sneller.. maar deze componenten heb je ook moeten ontwikkelen. Op zich niet zo'n probleem aangezien deze achteraf weer 100% herbruikbaar zijn.
Veel mensen die beginnen met J2EE Web Applicaties door alleen een basis framework te bruiken zoals bijvoobeeld Struts, alleen maken ze vaak geen componenten. En daar zit hem juist de kracht van Java.
Ik vermoed dus ook dat het grootste deel van de tijd verloren gaat aan de web front-end. En de misschien wel verouderde aanpak die Struts gebruikt (of andere MVC webframeworks).

Misschien is het wel eens tijd voor een goede OWM (Object Web Mapper)??!?

Naast dit feit, verlies ik ook nog wel eens tijd aan het opzetten van ANT build scripts, het Hibernate systeem... maar dus voornamelijk wel het web gedeelte mappen met het achterliggende OO gedeelte.

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

-FoX- schreef op vrijdag 03 juni 2005 @ 12:25:
[...]
Naast dit feit, verlies ik ook nog wel eens tijd aan het opzetten van ANT build scripts, het Hibernate systeem... maar dus voornamelijk wel het web gedeelte mappen met het achterliggende OO gedeelte.
Ik heb een template opgezet die voor de meeste projecten met een paar kleine wijzigingen meteen toepasbaar is. Alle projecten die ik de laatste tijd heb opgezet zijn grotendeels gelijk qua structuur.. (handig)

  • Stephan Oudmaijer
  • Registratie: Oktober 2000
  • Laatst online: 16-08-2023
Hibernate mapping files genereer ik meestal vanuit een database met Hibernate Synchronizer. Maar als straks die nieuwe (JBoss) Hibernate Tools uit zijn dan kan het daar ook eenvoudig mee.

Code genereer ik grotendeels met een eigen gemaakte tool. Gewoon Entiteiten opgeven en door de generator rammen et voila. Al het custom werk programmeer ik er met de hand wel bij. M`n toolje genereert ook zaken als de Spring configuratie en de faces-config, scheelt een boel geklooi.

Meeste werk zit hem toch in die ellendige web userinterfaces, dat kost gewoon altijd veel tijd.

Maar ik ben het opzich niet eens dat J2EE altijd veel tijd kost, het feit is gewoon dat er te weinig RAD tools zijn voor bijvoorbeeld Hibernate, Spring etc. Das jammer....

  • -FoX-
  • Registratie: Januari 2002
  • Niet online

-FoX-

Carpe Diem!

Topicstarter
Alarmnummer schreef op vrijdag 03 juni 2005 @ 12:47:
[...]
Ik heb een template opgezet die voor de meeste projecten met een paar kleine wijzigingen meteen toepasbaar is. Alle projecten die ik de laatste tijd heb opgezet zijn grotendeels gelijk qua structuur.. (handig)
Dergelijk iets is uiteraard zeer handig en zal je vast wel een hele hoop tijd besparen. Maar het feit blijft wel dat je iets dergelijk op moet zetten, in the first place, om productief te zijn.

Daarenboven beschik ik niet over jouw template systeem, zodat ik er feitelijk niets mee ben. Als je het langs de andere zijde bekijkt, kunnen andere ontwikkelomgevingen soortgelijke templatesystemen ook toelaten.

Nu weet ik ook wel dat de voordelen die een java systeem/platform heeft, niet opwegen tegen deze kleinere vertragingen (zeker in grote projecten). Maar had toch graag zelfs de kleinste projecten ermee willen kunnen opzetten in no-time.
Het is misschien wel een idee om systematisch de grote vertragingen (bvb Struts) er langzaam aan uit te werken.

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

-FoX- schreef op vrijdag 03 juni 2005 @ 15:55:
[...]

Dergelijk iets is uiteraard zeer handig en zal je vast wel een hele hoop tijd besparen. Maar het feit blijft wel dat je iets dergelijk op moet zetten, in the first place, om productief te zijn.
Dat is zo. Zonder een template project zou ik zelfs bij kleine projecten zeker nog een dag of 2 a 3 kwijt zijn om alles goed op te zetten. Het vervelende is dat je dan zelfs tussen de projecten nog allerlei grote verschillen hebt. De afgelopen half jaar heb ik aan een 5/6 tal projecten meegewerkt en alle projecten zijn door mij (qua code en scripts) opgezet en alle projecten hebben nagenoeg dezelfde structuur. Verder hou ik het template systeem wel up to date. Als ik bij een project nieuwe kennis heb opgedaan dat ik in de toekomst in de template zou kunnen gebruiken, dan verwerk ik het erin.

  • Antediluvian
  • Registratie: Maart 2002
  • Laatst online: 04-05 10:30
Wat mij opvalt is dat J2EE applicaties meestal beter gestructureerd zijn. Daardoor kost het inderdaad ook wat meer tijd maar de onderhoudbaarheid van het geheel gaat er flink op vooruit.

Zoals velen hier reeds opmekten kost de weblayer vrij veel tijd maar dit doet de programmeur zichzelf aan.
Zo is er bv de gewoonte in J2EE om geen code (scriptlets) in jsp pagina's te gebruiken. Dus wordt er gebruik gemaakt van het MCV model wat extra configuratie (controller) vereist. Echter is het soms veel eenvoudiger en sneller om wel gewone java scriptlets te gebruiken in jsp pagina's. Maar dit word als dan slecht gebruik beschouwd in J2EE terwijl dit in andere platforms als normaal word beschouwd.

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

Antediluvian schreef op zondag 05 juni 2005 @ 12:44:
Zo is er bv de gewoonte in J2EE om geen code (scriptlets) in jsp pagina's te gebruiken. Dus wordt er gebruik gemaakt van het MCV model wat extra configuratie (controller) vereist. Echter is het soms veel eenvoudiger en sneller om wel gewone java scriptlets te gebruiken in jsp pagina's. Maar dit word als dan slecht gebruik beschouwd in J2EE terwijl dit in andere platforms als normaal word beschouwd.
Ben ik helemaal met je eens. In veel weblayer frameworks zie je allerlei verkapte vormen van 'programmeren' via attributen en zelf bedachte tags. Doe me dan een plezier een schrijf dan gewoon java.

Bij J2EE wordt te veel gezegd (check de gigantische hoeveelheid met boeken mbt j2ee architectuur). Tip: ignore where author is Sun. Sun maakt over het algemeen dikke troep (in ieder geval wel voor kleinere projecten). te zware specificaties.. onwerkbare praktische situaties.. Sun moet java-vm`s bouwen en laat de rest maar aan anderen over.

Mijn favoriete tools:
Hibernate (niet van Sun)
Spring (niet van Sun)
en ben nu steeds meer gesharmeerd aan het raken van Tapestry (ook niet van Sun)

En verder erger ik me al tijden aan de grote complexiteit. Je bent niet meer in control (en alhoewel dat ook niet altijd noodzakelijk is), het is een fout uitgangspunt om het dan nooit meer te zijn. Check trouwens maar eens een gemiddelde stacktrace op een j2ee applicatie.

[ Voor 31% gewijzigd door Alarmnummer op 05-06-2005 13:35 ]


Verwijderd

Alarmnummer schreef op zondag 05 juni 2005 @ 13:26:
Ben ik helemaal met je eens. In veel weblayer frameworks zie je allerlei verkapte vormen van 'programmeren' via attributen en zelf bedachte tags. Doe me dan een plezier een schrijf dan gewoon java.
Ben ik niet met je eens. Je kunt je ook de vraag stellen of je vanuit je controller dan wel de juiste data aanlevert. En meestal is dat domweg niet het geval.

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

Verwijderd schreef op zondag 05 juni 2005 @ 17:15:
[...]
Ben ik niet met je eens. Je kunt je ook de vraag stellen of je vanuit je controller dan wel de juiste data aanlevert.
Dan mijn vraag: hoeveel ervaring heb jij er mee?

Uiteraard kan je alles in de view al helemaal klaarzetten voor de controller, maar dat geeft hele stugge oplossingen waarin de opmaak van data in code vastligt en niet meer in de html pagina. Afgezien van dit probleem ga je enorm complexe controllers krijgen als je in de view geen view-logica meer kunt plaatsen.

In het team waarin ik werk, heb ik niet veel problemen met scriptlets. Iedereen bij ons die kan java programmeren (zelfs onze gui/graphics dude). Dus als je in zo`n klein team scriptlets gaat uitsluiten ga je onnodig allerlei dingen ingewikkeld maken. Bij grote bedrijven waar gui pipo`s helemaal 0.0 kennis van java hebben, kan ik het me voorstellen, maar in kleine team waarin iedereen kennis van zaken heeft is het imho onnodig.

[ Voor 28% gewijzigd door Alarmnummer op 05-06-2005 19:49 ]


Verwijderd

Heb je een voorbeeld van een dergelijke scriptlet, dat praat wat makkelijker...

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

Bv een tabel met wat grafische meuk op basis van de inhoud van de cellen. Bv een overzicht van personen met een man teken bij de mannen, en een vrouw teken bij de vrouwen. Je kan uiteraard het plaatje via de controller in elkaar laten zetten, maar dan stop je het weg in de code van de controller terwijl het enkel een stukje view logica is.

code:
1
2
3
4
5
<%if(persoon.isMan())%{> 
      <img ..... man.gif>
<%}else{%>
      <img .... vrouw.gif>
<%}%>


En dit kan je wel mooie versleutelen in allerlei tags, vb (Tapestry... syntax klopt niet helemaal trouwens):

code:
1
2
3
4
5
6
7
8
<span jwcid="@condition">
      <span jwcid="@if" condition="ognl:persoon.man">
           <img man.gif>
     </span>
     <span jwcid="@otherwise">
           <img vrouw.gif>
    </span>
</span>


Maar het principe is hetzelfde. Je bent nu via een obscure manier aan het programmeren onder het mom van: hier staat geen java code. Maar het is gewoon nog steeds programmeren.

De view is een dynamisch iets en zal dynamische elementen moeten hebben voordat er iets dynamisch uit komt. En je kan voor de niet-programmeurs het wel minder 'heavy' laten lijken door geen keiharde java code erin te zetten en te waarschuwen "poten afblijven van die gekke tags". Maar ik denk niet dat het mogelijk is om de logica volledig uit de view te trekken. En ook al is het mogelijk dan is het voor veel kleine bedrijven waarin iedereen kan programmeren, denk ik ook onwenselijk.

[edit]
Dit wil trouwens niet zeggen dat de Tapestry aanpak naad is. Ik zat ook even zo van.. hmmm.. programmeren via tags.. en dat beter noemen.. dat vind ik getuigen van gebrek aan inzicht. Maar ik ben er intussen achter dat de Tapestry templates hele krachtige features zijn. Zonder losse java bestanden kan je krachtige template-functies definieren waarmee je bv een template kan maken die rows van een table renderen.

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
<table jwcid="table@contrib:Table"
    width="90%"
    source="ognl:documentList"
    columns="id:id.toString(),acties">
</table>

<span jwcid="actiesColumnValue@Block">
    <a  jwcid="@DirectLink"
        listener="ognl:listeners.downloadAction"
        parameters="ognl:components.table.tableRow.id.value">Download</a>
    |<a jwcid="@DirectLink"
        listener="ognl:listeners.infoAction"
        parameters="ognl:components.table.tableRow.id.value">Info</a>
</span>

[ Voor 48% gewijzigd door Alarmnummer op 05-06-2005 21:56 ]


Verwijderd

Aangezien je dit soort view problematiek prachtig kunt oplossen met JSTL kun je ook prachtig je view valideren. En ik heb het idee dat het de integriteit en leesbaarheid van je jsp niet te goede komt als je continu gaat escapen. Mijn xml editor geeft nu braaf aan welke tags vereist zijn en levert me ook code completion, dus dat ontwikkeld tevens RAD.

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

Verwijderd schreef op zondag 05 juni 2005 @ 21:52:
Aangezien je dit soort view problematiek prachtig kunt oplossen met JSTL kun je ook prachtig je view valideren.
Maar je geeft nu zelf ook toe dat je niet alle data uit de controller haalt en dat was dus ook precies hetgeen ik wou ontkrachten.

Verwijderd

Dat komt omdat je nu pas specifiek bent over het doel scriptlets. Je geeft nu pas aan dat je enkel over view logica spreekt. De opmerking die ik in eerste instantie plaatste ging daar neit over. We doen iig beide geen mutaties meer over de data die we uit de controller hebben aangeleverd gekregen.

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

Verwijderd schreef op zondag 05 juni 2005 @ 22:05:
Dat komt omdat je nu pas specifiek bent over het doel scriptlets. Je geeft nu pas aan dat je enkel over view logica spreekt. De opmerking die ik in eerste instantie plaatste ging daar neit over. We doen iig beide geen mutaties meer over de data die we uit de controller hebben aangeleverd gekregen.
Dat zou ook wel een hele slechte zaak zijn ;)

Verwijderd

Alarmnummer schreef op zondag 05 juni 2005 @ 21:42:
code:
1
2
3
4
5
<%if(persoon.isMan())%{> 
      <img ..... man.gif>
<%}else{%>
      <img .... vrouw.gif>
<%}%>
Deze hele simpele vorm van scriptlets, waarbij een scriptlet precies 1 regel is en alleen uit een simpele conditie of iteratie bestaat, zou ik eigenlijk bijna geen scriptlet willen noemen. Hoewel ik absoluut tegen scriptlets in JSPs ben, sta ik deze wel toe. Je kunt dit 1:1 vervangen door JSTL, waarmee je alleen de syntax veranderd, niet de logica of het design.

Als je het op deze manier beperkt houd is er niks mis mee. Het enige voordeel van een tag alternatief (zoals bijvoorbeeld JSTL), is dat je door de beperktheid ervan niet in de verleiding komt om hele lappen java code in JSPs te gaan zetten. Het is een soort bescherming tegen jezelf.

Je ziet in de praktijk dat minder gediciplineerde programmeurs toch nog even snel dat stukje logica in de web layer er bij gaan zetten, zeker als een deadline er aan zit te komen. Als er dan na de dead-line geen refactoring plaats vind (denkwijze van niet gediciplineerde programmeur: "het werkt nu goed, waarom zou ik het gaan refactoren"), dan gaat de logica in de JSP pagina groeien en groeien.

/me heeft wel JSPs gezien waarbij de scriptlet code zelfs voor een class nog te lang was geweest. :X

[ Voor 3% gewijzigd door Verwijderd op 06-06-2005 17:02 ]


Verwijderd

Verwijderd schreef op maandag 06 juni 2005 @ 11:32:
Als je het op deze manier beperkt houd is er niks mis mee. Het enige voordeel van een tag alternatief (zoals bijvoorbeeld JSTL), is dat je door de beperktheid ervan niet in de verleiding komt om hele lappen java code in JSPs te gaan zetten. Het is een soort bescherming tegen jezelf.
Het grootste voordeel van JSTL is validatie. De "verleiding" bestaat immers ook in JSTL middels het scriptlet element.

  • chris
  • Registratie: September 2001
  • Laatst online: 11-03-2022
Serieus, ik had er laatst een topic over geopend, maar waarom kijken jullie niet eens naar Ruby on Rails. Doe mij een plezier, ga er een halve dag naar kijken en kom er achter dat complexe web-applicaties ook snel en straight-forward gemaakt kunnen worden.

Verwijderd

chris schreef op maandag 06 juni 2005 @ 13:01:
Serieus, ik had er laatst een topic over geopend, maar waarom kijken jullie niet eens naar Ruby on Rails. Doe mij een plezier, ga er een halve dag naar kijken en kom er achter dat complexe web-applicaties ook snel en straight-forward gemaakt kunnen worden.
Als we snel crappy code op willen leveren pakken we wel php. Alles kan, maar we willen reusable code die toch volgens rad geschreven is. JSF behoort dat probleem grotendeels te tekkelen maar daar is mijn ervaring domweg niet groot genoeg voor om er iets zinnigs over te zeggen.

Stel je straks ook voor dat we alle J2EE applicaties in Groovy moeten pennen?

  • Antediluvian
  • Registratie: Maart 2002
  • Laatst online: 04-05 10:30
Ik heb Ruby on Rails al eens vluchtig bekeken en het zag er zeer indrukwekkend uit maar om daarin nu een grote webapplicatie te schijven ...

Volgens mij is het niet mogelijk (of zeer moeilijk) om met RAD goed gestuctureerde en reusable code te bekrijgen. Het leuke van java is dat er heel veel frameworks bestaan die het ontwikkelprocess versnellen maar waarbij het geheel toch overzichtelijk en gestructureerd blijft.

Het gebruik van dergelijke frameworks brengen natuurlijk ook een aantal nadelen met zich mee. Zo word het geheel complexer en moet je veel tijd investeren in het leren correct gebruiken van het framework.

Er bestaan zoveel (goede en minder goede) frameworks voor J2EE zodat het soms zeer moeilijk is om de juiste keuze te maken welk framework je in een bepaalde situatie best gebruikt. Stel dat je er dan één kiest (bv Struts) dan mag je na zoveel tijd terug opnieuw beginnen omdat er een nieuwer/beter framework (bv Spring MVC) beschikbaar is.

Verwijderd

@Antediluvian
Hoewel ik het eens ben met de strekking van je verhaal is je voorbeeld een beetje ongelukkig gekozen aangezien Spring alles behalve wil vervangen...

  • -FoX-
  • Registratie: Januari 2002
  • Niet online

-FoX-

Carpe Diem!

Topicstarter
Antediluvian schreef op maandag 06 juni 2005 @ 14:51:
Volgens mij is het niet mogelijk (of zeer moeilijk) om met RAD goed gestuctureerde en reusable code te bekrijgen. Het leuke van java is dat er heel veel frameworks bestaan die het ontwikkelprocess versnellen maar waarbij het geheel toch overzichtelijk en gestructureerd blijft.

Het gebruik van dergelijke frameworks brengen natuurlijk ook een aantal nadelen met zich mee. Zo word het geheel complexer en moet je veel tijd investeren in het leren correct gebruiken van het framework.

Er bestaan zoveel (goede en minder goede) frameworks voor J2EE zodat het soms zeer moeilijk is om de juiste keuze te maken welk framework je in een bepaalde situatie best gebruikt. Stel dat je er dan één kiest (bv Struts) dan mag je na zoveel tijd terug opnieuw beginnen omdat er een nieuwer/beter framework (bv Spring MCV) beschikbaar is.
Maar waarom is het in de eerste plaats nodig dat er zoveel frameworks bestaan? Als er 1 goede standaard zou zijn, zou toch gelijkertijd iedereen 'tevreden' zijn. Begrijp me niet verkeerd, ik ben heel blij dat frameworks als Spring/Hibernate bestaan, ze maken het leven van de developer zoveel makkelijker. Ook zijn er een aantal kleinere frameworks waar ik zeer tevreden mee ben zoals displaytag. Maar langs de andere kant, zouden dergelijke tot de standaard moeten uitgroeien.

De dotNET variant maakt RAD wel stukken makkelijker. Ik heb er nog niet echt ervaring mee.. maar naar hetgeen ik opvang moet ik dat toch wel concluderen. Uiteindelijk zal dit ook voor Java moeten gebeuren, alleen zie ik dit nog niet zo snel gebeuren.

Waar ligt volgens jullie de voornaamste oorzaak voor de ontbrekende RAD functionaliteit? Is het in de IDE's, enkel voor een bepaalde tier, ... ??

Verwijderd

Je hebt net het grote nadeel van opensource in een paar woorden omschreven.

  • -FoX-
  • Registratie: Januari 2002
  • Niet online

-FoX-

Carpe Diem!

Topicstarter
Verwijderd schreef op maandag 06 juni 2005 @ 14:56:
@Antediluvian
Hoewel ik het eens ben met de strekking van je verhaal is je voorbeeld een beetje ongelukkig gekozen aangezien Spring alles behalve wil vervangen...
Niet perse. Hij heeft het over Spring MVC die wel duidelijk tot doel heeft bestaande MVC frameworks te vervangen omdat die van Spring beter is :Y)
De overige Spring componenten hebben dit doel niet, bvb ORM. Zij maken wel gebruik van bestaande ORM implementaties (Hibernate, JDO, ...).

  • Antediluvian
  • Registratie: Maart 2002
  • Laatst online: 04-05 10:30
Verwijderd schreef op maandag 06 juni 2005 @ 14:56:
@Antediluvian
Hoewel ik het eens ben met de strekking van je verhaal is je voorbeeld een beetje ongelukkig gekozen aangezien Spring alles behalve wil vervangen...
Sping MVC is wel degelijk een vervanger voor Struts. Je kan natuurlijk ook Struts gebruiken icm Spring maar Spring MVC is imho een betere keuze. Quote uit de online Spring reference doc:
"Thus, if you can live with Struts' architectural flaws, it can still be a viable choice for the web layer"
-FoX- schreef op maandag 06 juni 2005 @ 15:06:
De dotNET variant maakt RAD wel stukken makkelijker. Ik heb er nog niet echt ervaring mee.. maar naar hetgeen ik opvang moet ik dat toch wel concluderen. Uiteindelijk zal dit ook voor Java moeten gebeuren, alleen zie ik dit nog niet zo snel gebeuren.
Dat is tegelijk de zwakte als de sterkte van java. Je hebt keuze.

Bij .NET is er enkel de Microsoft way. Dit is zeer makkelijk, je moet jezelf niet afvragen of er iets anders beter is of niet, maar wat als de Microsoft way je niet bevalt. Veel alternatieven heb je niet.

Volgens mij komt hier ook wel verandering door projecten zoals NHibernate en NSpring. De .NET varianten van de J2EE frameworks.

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

Verwijderd schreef op maandag 06 juni 2005 @ 14:56:
@Antediluvian
Hoewel ik het eens ben met de strekking van je verhaal is je voorbeeld een beetje ongelukkig gekozen aangezien Spring alles behalve wil vervangen...
Spring MVC != Spring. Spring MVC is een weblayer framework net zoals Struts.

  • Antediluvian
  • Registratie: Maart 2002
  • Laatst online: 04-05 10:30
:) 3 replies binnen 3 minuten op een foute stelling over Spring. Zijn we aanhangers of niet :9

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

-FoX- schreef op maandag 06 juni 2005 @ 15:06:

Maar waarom is het in de eerste plaats nodig dat er zoveel frameworks bestaan? Als er 1 goede standaard zou zijn, zou toch gelijkertijd iedereen 'tevreden' zijn.
:D Ik denk dat een beetje diversiteit goed is.

Ten 1e wordt er veel nieuwe kennis opgedaan. Struts was in het begin een verbetering omdat je daarvoor alles met de hand moest doen. Door struts en andere frameworks is er veel ervaring op gedaan en kunnen nieuwe frameworks ontwikkeld worden, zie bv JSF. De hoofdontwikkelaar van Struts speelt ook een belangrijke rol in de JSF ontwikkeling en er wordt geleerd van fouten die gemaakt zijn met Struts.

Een ander voorbeeld is EJB. EJB is een heel leuk idee en het is beter dan alles met de hand te doen. Maar intussen zijn er betere alternatieven, zie bv Spring. Spring heeft ook geleerd van de fouten van EJB.
Begrijp me niet verkeerd, ik ben heel blij dat frameworks als Spring/Hibernate bestaan, ze maken het leven van de developer zoveel makkelijker. Ook zijn er een aantal kleinere frameworks waar ik zeer tevreden mee ben zoals displaytag. Maar langs de andere kant, zouden dergelijke tot de standaard moeten uitgroeien.
Als het een standaard gaat worden krijg je veel meuk waarin je niet geinteresseerd bent en krijg je alsnog een framework die log en lomp is om mee te werken. Kijk naar de extreem uitgebreide specs van JSF.

[ Voor 5% gewijzigd door Alarmnummer op 06-06-2005 15:26 ]


Verwijderd

-FoX- schreef op maandag 06 juni 2005 @ 15:06:
De dotNET variant maakt RAD wel stukken makkelijker. Ik heb er nog niet echt ervaring mee.. maar naar hetgeen ik opvang moet ik dat toch wel concluderen. Uiteindelijk zal dit ook voor Java moeten gebeuren, alleen zie ik dit nog niet zo snel gebeuren.
Het grote voordeel van dotNet is dat het 1 standaard is die door 1 partij neergezet wordt. Het is dus voor iedereen duidelijk op welke API en framework je je moet richten en welke IDE je moet gebruiken. Daarbij is er meteen grotendeels support voor het totaal concept van geheel dotNet. Op het java platform zag je dat sun de VM, Java taal en basic libs maakte en geen IDE of web platform. Vervolgens zijn er meerdere partijen op gedoken om de gaten op te vullen, met als gevolg dat je veel frameworks en veel IDEs hebt.

Aan de ene kant is keuze leuk en nuttig, aan de andere kant versnipperd het je development communitie. Als je bijvoorbeeld iemand hebt die goed bekend is met JSF, dan moet die persoon opeens toch weer veel details gaan bijleren als ie opeens op een Struts project gezet wordt. Iemand die Struts goed kent zal weer moeite moete doen om dingen van Spring, Tapestry, Maverick, "Displaytag", of wat dan ook te leren.

Al deze dingen halen toch een beetje de snelheid uit het developpen. Daarbij komt dat je altijd twijfel hebt. Je kunt nu voor Struts gekozen hebben, maar is Tapesty toch niet beter? Ook zal de tool support navenant versnipperd zijn. Ook tool vendors moeten hun resources verdelen. Als er alleen maar struts was hadden we nu wellicht de perfecte WYSIWYG editors en wizards gehad daarvoor. Nu zie je echter dat veel IDEs alle frameworks een beetje supporten, maar geen eentje echt uitmuntend. Dit haalt de RAD toepasbaarheid (die veelal op grafische editors en wizard gebasseerd is) toch een beetje onderuit.

Nu is Sun zelf eindelijk met een 'eigen' web framework gekomen: JSF.

De tool support komt slechts heel mondjesmaat op gang, maar de belofte is er. Omdat JSF een specificatie is en niet direct een platform, heeft dit in principe wat meer potentieel. Verlopig wachten veel mensen toch J2EE 1.5 af (met daarin JSF 1.2), hopende dat de tool support zo rond December dit jaar wat beter op gang gekomen is en de grootste bugs (content interweaving etc) eruit zijn zoals beloofd.
Waar ligt volgens jullie de voornaamste oorzaak voor de ontbrekende RAD functionaliteit? Is het in de IDE's, enkel voor een bepaalde tier, ... ??
Kort samengevat IMHO: 1 standaard. Web Layer. Tool Support.

Verwijderd

Alarmnummer schreef op maandag 06 juni 2005 @ 15:25:
Als het een standaard gaat worden krijg je veel meuk waarin je niet geinteresseerd bent en krijg je alsnog een framework die log en lomp is om mee te werken. Kijk naar de extreem uitgebreide specs van JSF.
Dit kan waar zijn, maar hoeft dat niet te zijn. Een uitgebreide spec hoeft niet tot een log en lomp framework (of welke technology dan ook) te leiden. Neem bijvoorbeeld de J2EE spec. Sun implementeerd zijn eigen spec met iets wat zo log is dat ik niet 1 team ken die het gebruikt, zelfs niet nu het gratis te gebruiken is (Sun Application Server 8). Aan de andere kant heb je daar dan een Orion of Jetty die exact dezelfde spec implementeren en zo licht zijn als het maar kan.

Op een heel ander gebied zie je het met de UML. De (meta) spec die daar achter ligt en behoorlijk veelomvattend en complex, maar UML zelfs is in de basis redelijk simpel te gebruiken. Er zijn wel wat complexere mogelijkheden, maar die hoef je absoluut niet mee te nemen.

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

Verwijderd schreef op maandag 06 juni 2005 @ 15:37:
[...]
Dit kan waar zijn, maar hoeft dat niet te zijn. Een uitgebreide spec hoeft niet tot een log en lomp framework (of welke technology dan ook) te leiden. Neem bijvoorbeeld de J2EE spec. Sun implementeerd zijn eigen spec met iets wat zo log is dat ik niet 1 team ken die het gebruikt, zelfs niet nu het gratis te gebruiken is (Sun Application Server 8). Aan de andere kant heb je daar dan een Orion of Jetty die exact dezelfde spec implementeren en zo licht zijn als het maar kan.
Dat komt omdat jetty alleen maar een servlet container is. En verder is Sun enorm goed in het schrijven van enorm gecompliceerde specs zelfs zonder een implementatie, kijk naar EJB.
Op een heel ander gebied zie je het met de UML. De (meta) spec die daar achter ligt en behoorlijk veelomvattend en complex, maar UML zelfs is in de basis redelijk simpel te gebruiken.
Yep.. maar in diagrammen wil je juist eenvoud en beperk je je meestal tot een kleine beschrijving.

Verwijderd

..nevermind, geen tijd en zin in de discussie..

[ Voor 86% gewijzigd door Verwijderd op 06-06-2005 16:21 ]


Verwijderd

Verwijderd schreef op maandag 06 juni 2005 @ 16:15:
..nevermind, geen tijd en zin in de discussie..
Nja, laat dan ook maar. Ik heb zelf ook weinig tijd.
Pagina: 1