mboost-dp1
JSF / Java EE - Hvorfor
Nu har jeg arbejdet lidt med JSF her, og vil høre om der er nogen som rent faktisk kan give en god grund til at jeg overhovedet bør bruge 5min mere på dette her framework.
Som et simplet case eksemple, har jeg lavet en Quiz. Det kræver bruger input, data persistance imellem requests (session), og fejlmeddelser. Samtidig har jeg tilføjet noget localization.
For at vise min quiz, skal der en god række kode til. Koden basere sig så på hvilke variable der er sat i en backing bean, som skal gemmes i request eller session. Det kræver en fjollet masse test på et string resultat.
Men lad os kigge på noget kode. For at fremvise:
Quiz.jsf
Som så derudover kræver en klasse bagved, men en masse unødvendig kode som følge af java's bean model.
Og hertil kommer der så navigation rules i faces-config. Altså xml der ender med at blive håndskrevet.
Hvis jeg så f.eks. skal opdatere min JSF med en ny form for response skal jeg så
- Opdatere min Backing Bean med getters og setters for alle de eventuelle variable der er nødvendige for at bestemme hvad der vises i View.
- Opdatere mit frontend (JSP/JSF/HTML) med nogle ikke specielt flexible tags, som derudover kræver at der rent faktisk bygges logik ind i View (hvilket er rimelig modstridende med MVC konceptet)
- Opdatere min faces-config.xml *sigh*
Og som sagt, så er består ret meget af det overstående af Strings der tosses frem og tilbage, så muligheden for stærke typer og refractoring er stort set ikke eksisterende.
I PHP eller ASP.NET ville overstående kunne laves med halv så mange linjers kode, samt at der ville slet ikke være brug for at opdatere en XML fil der mapper POST requests frem og tilbage, da dette stort set kan automatiseres af en FrontController, som Zend (PHP) og ASP.NET MVC (ASP.NET) har indbygget.
Derudover er det meget mere simple at skrive rules, samt at der er support for GET mapping på et langt mere simple måde.
Til at slutte af med kan det også siges hvordan at serveren skal genstartes for hver enkelt lille ændring, og at f.eks. Tomcat (som jeg benytter) ikke har virtual directory muligheder, så hvis jeg ændre på en CSS værdi i Eclipse, skal jeg *stadigvæk* restarte serveren og recompile det hele.
Overordnet virker det utrolig fjollet, ikke særlig udviklervenligt, og har ingen features som PHP eller ASP.NET ikke har.
Vi snakkede om Refractoring i en anden tråd om emnet, men jeg kan kun se at der er MINDRE refractoring i dette her en i ASP.NET pga. en alting er string baseret i forhold til Managed Beans osv.
Det er jo stort set umuligt at lave noget som helst der indvolvere bruger-input uden at skulle ændre på faces-config. Hvorimod jeg absolut ikke synes jeg piller særlig meget ved web.config i ASP.NET eller zend_config i PHP.
Så hvis der er nogen som har nogle guldkorn for hvorfor det er værd overhovedet at lære denne teknologi, så sig frem.
At kunne supportere den er ikke et argument jeg er synderligt interasseret i. Så kunne jeg ligeså godt bruge min tid på at lære COBOL.
Som et simplet case eksemple, har jeg lavet en Quiz. Det kræver bruger input, data persistance imellem requests (session), og fejlmeddelser. Samtidig har jeg tilføjet noget localization.
For at vise min quiz, skal der en god række kode til. Koden basere sig så på hvilke variable der er sat i en backing bean, som skal gemmes i request eller session. Det kræver en fjollet masse test på et string resultat.
Men lad os kigge på noget kode. For at fremvise:
Quiz.jsf
<f:view>
<f:loadBundle var="locale" basename="website.resources.Localization" />
<h:form id="quiz">
<div>
<p>
<strong>
Question <h:outputText value="#{Quiz.questionIndex + 1}" /> /
<h:outputText value="#{Quiz.numQuestions}" />
</strong>
</p>
<h:outputText
styleClass="error"
rendered="#{Quiz.response == 'failure' && Quiz.allowingTries}"
value="#{locale['Quiz.WrongAnswer']}" />
<h:outputText
styleClass="error"
rendered="#{!Quiz.allowingTries}"
value="To Many Attemps (Max 3)" />
<h:outputText
styleClass="approved"
rendered="#{Quiz.response == 'complete'}"
value="#{locale['Quiz.Completed']}" />
<h:panelGroup rendered="#{Quiz.response != 'complete' && Quiz.allowingTries}">
<p>
<h:outputText value="#{Quiz.question}" /> =
<h:inputText styleClass="field" value="#{Quiz.answer}" />
</p>
<p>
<h:commandButton action="#{Quiz.answerQuestion}" value="Answer" />
</p>
</h:panelGroup>
</div>
</h:form>
</f:view>
Som så derudover kræver en klasse bagved, men en masse unødvendig kode som følge af java's bean model.
package website.quiz;
import java.util.*;
public class Quiz
{
private final int MAX_TRIES = 3;
private List<QuizQuestion> questions = new ArrayList<QuizQuestion>();
private int questionIndex = 0;
private QuizQuestion currentQuestion;
private String answer;
private String response;
private int numTries;
private boolean canTry = true;
public Quiz()
{
questions.add(new QuizQuestion("2 + 2","4"));
questions.add(new QuizQuestion("2 - 2","0"));
questions.add(new QuizQuestion("2 * 2","4"));
questions.add(new QuizQuestion("2 / 2","1"));
questions.add(new QuizQuestion("2^2","4"));
currentQuestion = questions.get(questionIndex);
}
public boolean isAllowingTries()
{
return canTry;
}
public void setAllowingTries(boolean canTry)
{
// read only
}
public String getResponse()
{
return response;
}
public void setResponse(String response)
{
// read only
}
public QuizQuestion getQuestion()
{
return currentQuestion;
}
public void setQuestion(QuizQuestion question)
{
// read only
}
public String getAnswer()
{
// always return blank
return "";
}
public void setAnswer(String answer)
{
this.answer = answer;
}
public int getQuestionIndex()
{
return questionIndex;
}
public void setQuestionIndex(int questionIndex)
{
// read only
}
public int getNumQuestions()
{
return questions.size();
}
public void setNumQuestions(int size)
{
// read only
}
public String answerQuestion()
{
if(numTries == MAX_TRIES)
{
canTry = false;
return "continue";
}
if(currentQuestion.getAnswer().equalsIgnoreCase(answer))
{
if(questionIndex == (questions.size() - 1))
{
response = "complete";
return response;
}
currentQuestion = questions.get(++questionIndex);
response = "continue";
return response;
}
else
{
numTries++;
response = "failure";
return response;
}
}
}
Og hertil kommer der så navigation rules i faces-config. Altså xml der ender med at blive håndskrevet.
<navigation-rule>
<from-view-id>quiz.jsf</from-view-id>
<navigation-case>
<from-action>#{Quiz.answerQuestion}</from-action>
<from-outcome>failure</from-outcome>
<to-view-id>quiz.jsp</to-view-id>
<redirect />
</navigation-case>
<navigation-case>
<from-action>#{Quiz.answerQuestion}</from-action>
<from-outcome>continue</from-outcome>
<to-view-id>quiz.jsp</to-view-id>
<redirect />
</navigation-case>
<navigation-case>
<from-action>#{Quiz.answerQuestion}</from-action>
<from-outcome>complete</from-outcome>
<to-view-id>quiz.jsp</to-view-id>
<redirect />
</navigation-case>
</navigation-rule>
Hvis jeg så f.eks. skal opdatere min JSF med en ny form for response skal jeg så
- Opdatere min Backing Bean med getters og setters for alle de eventuelle variable der er nødvendige for at bestemme hvad der vises i View.
- Opdatere mit frontend (JSP/JSF/HTML) med nogle ikke specielt flexible tags, som derudover kræver at der rent faktisk bygges logik ind i View (hvilket er rimelig modstridende med MVC konceptet)
- Opdatere min faces-config.xml *sigh*
Og som sagt, så er består ret meget af det overstående af Strings der tosses frem og tilbage, så muligheden for stærke typer og refractoring er stort set ikke eksisterende.
I PHP eller ASP.NET ville overstående kunne laves med halv så mange linjers kode, samt at der ville slet ikke være brug for at opdatere en XML fil der mapper POST requests frem og tilbage, da dette stort set kan automatiseres af en FrontController, som Zend (PHP) og ASP.NET MVC (ASP.NET) har indbygget.
Derudover er det meget mere simple at skrive rules, samt at der er support for GET mapping på et langt mere simple måde.
Til at slutte af med kan det også siges hvordan at serveren skal genstartes for hver enkelt lille ændring, og at f.eks. Tomcat (som jeg benytter) ikke har virtual directory muligheder, så hvis jeg ændre på en CSS værdi i Eclipse, skal jeg *stadigvæk* restarte serveren og recompile det hele.
Overordnet virker det utrolig fjollet, ikke særlig udviklervenligt, og har ingen features som PHP eller ASP.NET ikke har.
Vi snakkede om Refractoring i en anden tråd om emnet, men jeg kan kun se at der er MINDRE refractoring i dette her en i ASP.NET pga. en alting er string baseret i forhold til Managed Beans osv.
Det er jo stort set umuligt at lave noget som helst der indvolvere bruger-input uden at skulle ændre på faces-config. Hvorimod jeg absolut ikke synes jeg piller særlig meget ved web.config i ASP.NET eller zend_config i PHP.
Så hvis der er nogen som har nogle guldkorn for hvorfor det er værd overhovedet at lære denne teknologi, så sig frem.
At kunne supportere den er ikke et argument jeg er synderligt interasseret i. Så kunne jeg ligeså godt bruge min tid på at lære COBOL.
#3
Nu synes jeg altså god vi kan aflive den myte om at Java er det eneste som der laves Enterprise udvikling i.
PHP benyttes til rigtig mange supersize sider, og ASP.NET også.
Jeg ser stort set aldrig sider i Java EE, udtagen når de går ned og viser en 500 linjers ubrugelig stacktrace.
Nu synes jeg altså god vi kan aflive den myte om at Java er det eneste som der laves Enterprise udvikling i.
PHP benyttes til rigtig mange supersize sider, og ASP.NET også.
Jeg ser stort set aldrig sider i Java EE, udtagen når de går ned og viser en 500 linjers ubrugelig stacktrace.
Windcape (4) skrev:Nu synes jeg altså god vi kan aflive den myte om at Java er det eneste som der laves Enterprise udvikling i.
Jeg siger ikke at enterprise kun laves i JSF. Jeg gætter på at JSF primært bruges til enterprise.
Windcape (4) skrev:Jeg ser stort set aldrig sider i Java EE, udtagen når de går ned og viser en 500 linjers ubrugelig stacktrace.
Måske fordi det ikke er noget man reklamerer med? Vores brugere ved intet om at vores produkter har en Java front-end, medmindre de er nysgerrige. (Og spørger os.)
Jeg ved ikke hvorfor mange reklamerer med hvilken teknologi de har valgt. Eksempel: http://nyhederne.tv2.dk/krimi/article.php/id-21460...
Smukt, hvad gør de så hvis de skifter til noget andet end PHP? Jeg synes det er amatør-agtigt, på et eller andet plan.
#5
Det hænder dog at man ser .jsp, .jspx, .do, .jsf, .faces og som extension.
Men grundliggende har du ret - det er ikke så godt hvis ens URL'er afspejler ens valg af teknologi.
Et eksempel på et stort site osm har goofet med det er MySpace som har måttet mappe .cfm til ASP.NET da man skiftede fra ColdFusion til ASP.NET for at undgå at break URL'er.
Nogen gange kan man dog gætte lidt udfra Server HTTP header. Jeg vil antage at en site som bruger IBM HTTP Server har wen WAS bagved.
Det hænder dog at man ser .jsp, .jspx, .do, .jsf, .faces og som extension.
Men grundliggende har du ret - det er ikke så godt hvis ens URL'er afspejler ens valg af teknologi.
Et eksempel på et stort site osm har goofet med det er MySpace som har måttet mappe .cfm til ASP.NET da man skiftede fra ColdFusion til ASP.NET for at undgå at break URL'er.
Nogen gange kan man dog gætte lidt udfra Server HTTP header. Jeg vil antage at en site som bruger IBM HTTP Server har wen WAS bagved.
Det er vel også grunden til at folk ikke tror at PHP benyttes til Enterprise.myplacedk (5) skrev:Måske fordi det ikke er noget man reklamerer med?
Faktisk er den måde JSF fungere på ikke særlig optimal til at lave url-rewriting, og har mange problemer med deep-linking fordi alting er post per standard.
Windcape (4) skrev:#3
...
Jeg ser stort set aldrig sider i Java EE, udtagen når de går ned og viser en 500 linjers ubrugelig stacktrace.
De 500 liniers stacktrace er faktisk ganske brugbar, især når man skal fejlfinde hvad der går galt.
Jeg sporer en anelse bitterhed i din post, eller måske er det bare mig?
Du kan jo kigge på mængden af kode.Corholio (8) skrev:Jeg sporer en anelse bitterhed i din post, eller måske er det bare mig?
Hvis det ikke er til at blive bitter over, så ved jeg ikke hvad det er.
SUN påstår at det er en MVC architecture, men alligevel benytter de ikke standard routes mellem url og metoder, som Zend og ASP.NET MVC (Som nu er udkommet i v1.0, og dermed produktionsklar), gør.
Jeg forsøger at finde ud af om der er nogen grund til at man ville vælge Java EE som teknologi, fremfor alle de andre muligheder der er.
Jeg kan kun se ulempter i forhold til de andre sprog.
Derfor tråden, for at se om der er andre udviklere med erfaring i både Java EE og andre ting, der kan give deres mening om hvorfor det ikke er komplet tidsspilde og idioti at udvikle noget i JSF.
Argumenterne med refractoring og platformslåsning er allerede skudt væk.
Så vidt jeg kan se er det bare en legacy teknologi på niveau med COBOL, FORTRAN og lign.
Windcape (2) skrev:Men jeg vil dog gætte på et det rent faktisk er en niche teknologi,
Den slags kan jo undersøges.
dice.com er et stort job site - her er antal hits på nogle udvalgte søge ord:
Java 8202
J2EE 3506
JSP 1706
JSF 688
Struts 981
C# 3799
ASP.NET 2313
Web Forms 763
ASP.NET MVC 53
PHP 1413
Zend Framework 41
Symfony 14
Ruby Rails 222
Så kan du jo konkludere lidt om hvad der er niche.
Windcape (2) skrev:og der sandsyneligvis slet ikke er nogle webudviklere på newz.dk som arbejder med det til dagligt :)
(Til trods for de ret mange webudviklerer som er herinde.)
Som det fremgår af den respons du får, så er der nogle.
Men ikke så mange.
Den typiske JSF udvikler har nok en formel IT uddannelse, er mellem 30 og 45 år gammel og arbejder i den finansielle sektor.
Kategorien studerende og mellem 18 og 25 år vælger sjældent JSF. Vælger nok stort set aldrig JSF. Det bliver PHP eller ASP.NET.
Windcape (4) skrev:
Nu synes jeg altså god vi kan aflive den myte om at Java er det eneste som der laves Enterprise udvikling i.
PHP benyttes til rigtig mange supersize sider, og ASP.NET også.
PHP bruges til rigtigt mange ultra high volume web sites.
Men enterprise IT er altså ikke high volume web sites. PHP bruges næsten ikke til enterprise IT.
Windcape (9) skrev:Du kan jo kigge på mængden af kode.
Hvis det ikke er til at blive bitter over, så ved jeg ikke hvad det er.
Som forklaret i den forrige tråd, så er JSF absolut ikke det rigtige valg, hvis dit primære kriterie er så få og så små filer som mulige.
I så fald vil ASP eller PHP spagetti når det er værst nok være det optimale.
Men det er normalt ikke et kriterie man lægger vægt på i større IT projekter.
Windcape (9) skrev:Så vidt jeg kan se er det bare en legacy teknologi på niveau med COBOL, FORTRAN og lign.
Nej.
Mængden af JSF kode er i stor vækst.
Struts er ved at kunne kaldes legacy. Mest maintenance og enhancements af eksisterende apps.
Det jeg mener er problemet med mængden af JSF kode er hele problemet med Faces.config.
ASP.NET MVC, RoR, PHP (Zend) benytter alle routes der defineres med regulare expressions or lign. til at automatisk mappe url til methoder, samt properties.
I ASP.NET MVC er følgende muligt:
{controller}/{action}/{id}
Hvor {id} kan defineres med \d , så den kun accepterer integers.
Og så kan den mappes til
public ActionResult ViewProduct(int productId)
{
ViewData["Product"] = Product.Find(productId);
}
Og mere kode skal der ikke til.
I JSF skal jeg skrive omkring 30-40 linjers kode ekstra for at gøre overstående.
Hvordan folk kan synes det er smart er ufatteligt.
Derudover er det hele problemet med Standard JSF tags. Hvorfor spilde tiden på at lære endnu et markup system når der nu allerede findes HTML.
Samt et klodset forsøg på at lava Data Bindings.
Microsoft udviklede deres ASP.NET MVC på kortere tid end JSF, og jeg synes absolut at resultatet blev langt overlegnt.
Der virker ikke som en grund til at vælge Java, medmindre det er fordi at firmaets 10 web-udviklere ikke kender til andet, eller der er eksisterende løsninger i Java som skal supporteres.
ASP.NET MVC, RoR, PHP (Zend) benytter alle routes der defineres med regulare expressions or lign. til at automatisk mappe url til methoder, samt properties.
I ASP.NET MVC er følgende muligt:
{controller}/{action}/{id}
Hvor {id} kan defineres med \d , så den kun accepterer integers.
Og så kan den mappes til
public ActionResult ViewProduct(int productId)
{
ViewData["Product"] = Product.Find(productId);
}
Og mere kode skal der ikke til.
I JSF skal jeg skrive omkring 30-40 linjers kode ekstra for at gøre overstående.
Hvordan folk kan synes det er smart er ufatteligt.
Derudover er det hele problemet med Standard JSF tags. Hvorfor spilde tiden på at lære endnu et markup system når der nu allerede findes HTML.
Samt et klodset forsøg på at lava Data Bindings.
Microsoft udviklede deres ASP.NET MVC på kortere tid end JSF, og jeg synes absolut at resultatet blev langt overlegnt.
Der virker ikke som en grund til at vælge Java, medmindre det er fordi at firmaets 10 web-udviklere ikke kender til andet, eller der er eksisterende løsninger i Java som skal supporteres.
Windcape (13) skrev:Og mere kode skal der ikke til.
I et simpelt setup er det da vældigt smart. Men i et knap så simpelt setup betyder det jo ikke andet, end at du skal implementere det et andet sted.
Windcape (13) skrev:Hvorfor spilde tiden på at lære endnu et markup system når der nu allerede findes HTML.
Jeg kender ikke lige præcis JSF, men jeg bruger JSP på min arbejdsplads. Her er JSP-udviklerne meget glade for at bruge det markup system jeg har fundet på, frem for HTML og/eller Struts.
Fx. kan man med ét enkelt tag generere måske 50 linjers HTML. Og rigtigt mange brud på vores design-standard resulterer i en compile-fejl.
Ændringer i design-standarden kan i mange tilfælde implementeres ved at ændre i et custom-tag, i stedet for at ændre alle de steder det bliver brugt.
Det kaldes Helper methods.myplacedk (14) skrev:Fx. kan man med ét enkelt tag generere måske 50 linjers HTML. Og rigtigt mange brud på vores design-standard resulterer i en compile-fejl.
JSF er designet til at du slet ikke koder HTML, men laver 90% af alt markup med JSF.
Det minder rigtig meget om ASP.NET 1.1. Og som nogle måske kan huske, så havde ASP.NET 1.1 et ret elendigt output, og var ikke rart at arbejde med.
Simple kode kan også været advanceret. Der er absolut ingen grund til at tro at routes ikke kan hånterer alting bare fordi det ikke kræver 20 gange så meget kode ligesom Java.myplacedk (14) skrev:I et simpelt setup er det da vældigt smart. Men i et knap så simpelt setup betyder det jo ikke andet, end at du skal implementere det et andet sted.
Det er lidt ligesom at implementere f.eks. QuickSort i et funktionelt sprog, og så sammenligne med implementeringen i Java/C#.
Vi snakker om 1 linje versus 30. Og den ene linje er nemmere at læse siden det er pratisk talt samme formel.
Det er langt nemmere at overskue følgende:
"products/{id}/{action}"
End det er at overskue set sæt <nagivationrule> fra #1
Derudover skal du ikke spilde tid på at hardkode hver eneste route, da du kan benytte regulare expressions.
Der er ikke noget jamen, det ER smartere. Hvorfor Java udviklerer har en indbygget modvilje til at indrømme det forstår jeg ikke.
Windcape (15) skrev:Det kaldes Helper methods.
Nej, det hedder Custom Tags.
Windcape (15) skrev:Det minder rigtig meget om ASP.NET 1.1. Og som nogle måske kan huske, så havde ASP.NET 1.1 et ret elendigt output, og var ikke rart at arbejde med.
Så minder det overhovedet ikke om det jeg snakker om, for det giver et output præcist som jeg ønsker det.
Windcape (15) skrev:Der er ikke noget jamen, det ER smartere. Hvorfor Java udviklerer har en indbygget modvilje til at indrømme det forstår jeg ikke.
Det kunne jo være fordi java-udviklere løser nogle andre opgaver, hvor Java ER smartere.
Som sagt kan jeg godt se det smarte i det du snakker om. Jeg kan bare ikke se hvad jeg skulle kunne bruge det til.
Webudvikling i MVC arkitektur, der er ikke særlig meget forskel.myplacedk (16) skrev:Det kunne jo være fordi java-udviklere løser nogle andre opgaver, hvor Java ER smartere.
Som sagt kan jeg godt se det smarte i det du snakker om. Jeg kan bare ikke se hvad jeg skulle kunne bruge det til.
Spørgsmålet er bare hvor meget configuration du skal skrive manuelt. Java udviklerer vælger så at lave mere configuration, fordi de ikke tror på at det er muligt at skrive mindre, selvom det er bevist mange gange i andre frameworks / sprog.
myplacedk (16) skrev:Nej, det hedder Custom Tags.
Om du skriver <jsp:foobar text="hai" /> eller <% Html.Foobar("hai") %> er altså et fedt.
Forskellen er at <% Html.Foobar("hai") % er sprog typed, og du kan benytte refractoring.
Derudover laver dit View forhåbenlig ikke en compiler fejl, da du forhåbenlig ikke compiler dit view! Du kan højest checke det om i mod et scheme når du tester.
Hvis du kompilerer dine Views til Web --- no comments.
Jeg arbejder til dagligt med alt omkring WebSphere porteføljen, der er IBM' svar på et JEE-miljø (plus lidt mere).
Helt generelt vælger vores kunder WebSphere, når det er store tunge systemer (Læs: Enterprise). Systemerne er ofte tunge forretningskerner, integrations platforme (ESB), eller som workflow-engine.
Som oftest er det krav til skalering, brug af åbne standarder (rimelig relevant for din integrationsplatform), JEE-frameworket, transaktionssikkerhed, og stabilitet der gør udslaget, fremfor syntaksen i sproget, eller for den sags skyld antallet af konfigurationsfiler.
De kunder vi servicere ligger indenfor sundhed-, medicinal- og finanssektoren - hvilket betyder det er kunder, hvor udviklingspris og licenser er sekundære ift netop transaktionssikkerhed, skalering, stabilitet og evnen til at kommunikere med andre systemer.
Med al respekt for PHP-script og .NET-frameworket, så levere begge løsninger ikke noget der tilnærmelsesvis er ligeså åbent/standardiseret, skalérbart sikkert eller stabilt, som det efterhånden relativt modne JEE.
Netop fordi JEE ikke umiddelbart er til at udvikle de lynhurtige smarte websites, har IBM lavet deres sMASH, der blandt andet kan fortolke PHP.
Min pointe er alene, at valget af udviklingsmiljø, langt hen ad vejen er mere behovsdrevet, end drevet af antallet af linier du skal skrive som programmør. Det er bl.a. derfor at der stadig findes COBOL/PL1, til trods for deres forholdsvis statiske virke.
Helt generelt vælger vores kunder WebSphere, når det er store tunge systemer (Læs: Enterprise). Systemerne er ofte tunge forretningskerner, integrations platforme (ESB), eller som workflow-engine.
Som oftest er det krav til skalering, brug af åbne standarder (rimelig relevant for din integrationsplatform), JEE-frameworket, transaktionssikkerhed, og stabilitet der gør udslaget, fremfor syntaksen i sproget, eller for den sags skyld antallet af konfigurationsfiler.
De kunder vi servicere ligger indenfor sundhed-, medicinal- og finanssektoren - hvilket betyder det er kunder, hvor udviklingspris og licenser er sekundære ift netop transaktionssikkerhed, skalering, stabilitet og evnen til at kommunikere med andre systemer.
Med al respekt for PHP-script og .NET-frameworket, så levere begge løsninger ikke noget der tilnærmelsesvis er ligeså åbent/standardiseret, skalérbart sikkert eller stabilt, som det efterhånden relativt modne JEE.
Netop fordi JEE ikke umiddelbart er til at udvikle de lynhurtige smarte websites, har IBM lavet deres sMASH, der blandt andet kan fortolke PHP.
Min pointe er alene, at valget af udviklingsmiljø, langt hen ad vejen er mere behovsdrevet, end drevet af antallet af linier du skal skrive som programmør. Det er bl.a. derfor at der stadig findes COBOL/PL1, til trods for deres forholdsvis statiske virke.
Windcape (17) skrev:Webudvikling i MVC arkitektur, der er ikke særlig meget forskel.
Ja det er der jo så åbenbart alligevel.
Windcape (17) skrev:Spørgsmålet er bare hvor meget configuration du skal skrive manuelt.
Vi skriver ingen konfiguration manuelt, medmindre man foretrækker det frem for GUI.
Windcape (17) skrev:Java udviklerer vælger så at lave mere configuration, fordi de ikke tror på at det er muligt at skrive mindre
Nej, det er ikke derfor.
Windcape (17) skrev:Om du skriver <jsp:foobar text="hai" /> eller <% Html.Foobar("hai") %> er altså et fedt.
Nej. Det ER ikke det samme, og det HEDDER ikke det samme.
At der er voldsomt stort overlap i hvilke problemer det kan løse er så en anden ting.
Og lige på min arbejdsplads lige nu og her kan jeg i øvrigt bedre refactor mv. når det er custom tags.
Windcape (17) skrev:Derudover laver dit View forhåbenlig ikke en compiler fejl, da du forhåbenlig ikke compiler dit view! Du kan højest checke det om i mod et scheme når du tester.
Hvis du kompilerer dine Views til Web --- no comments.
Hvis du foretrækker at få dine fejl senere end compile-time...
Jeg foretrækker faktisk at få view fejl i test-time, ikke compile-time.
Det er ikke særlig konfigurerbare løsninger hvis man ikke kan ændre på View uden at recompile, samt at jeg absolut ikke synes det er korrekt implementering af MVC, da View ikke skal indeholde buisness logic overhovedet.
Hvis du skal udvikle et homebanking system, om du så skriver det i Java eller PHP, eller C# er lige meget, da du alligevel skal kalde de underliggende system moduler, som vel er skrevet i PL/1 (Danske Bank).
Men jeg kan godt se at jer som vælger Java, vælger det på baggrund af systemet, men ignorer brugeren.
Hvor folk der vælger asp/php gør det for at lave løsninger det er nice til brugerern.
At skrive et forum i JEE , eller en siden som newz.dk, er nok det dummeste man kan gøre.
Det er ikke særlig konfigurerbare løsninger hvis man ikke kan ændre på View uden at recompile, samt at jeg absolut ikke synes det er korrekt implementering af MVC, da View ikke skal indeholde buisness logic overhovedet.
Jeg synes ikke Java leverer noget overhovedet som gør at det er en smarterer platform til Web.Borg[One skrev:(18)]
Med al respekt for PHP-script og .NET-frameworket, så levere begge løsninger ikke noget der tilnærmelsesvis er ligeså åbent/standardiseret, skalérbart sikkert eller stabilt, som det efterhånden relativt modne JEE.
Netop fordi JEE ikke umiddelbart er til at udvikle de lynhurtige smarte websites, har IBM lavet deres sMASH, der blandt andet kan fortolke PHP.
Hvis du skal udvikle et homebanking system, om du så skriver det i Java eller PHP, eller C# er lige meget, da du alligevel skal kalde de underliggende system moduler, som vel er skrevet i PL/1 (Danske Bank).
Men jeg kan godt se at jer som vælger Java, vælger det på baggrund af systemet, men ignorer brugeren.
Hvor folk der vælger asp/php gør det for at lave løsninger det er nice til brugerern.
At skrive et forum i JEE , eller en siden som newz.dk, er nok det dummeste man kan gøre.
#20 Systemet, eller den underliggende teknik under javaplatformen, er helt klart en af de tunge vægte på skålen, og java er ikke alene et web-miljø, men står ofte som dedikeret applikationsserver, der er integreret ind i resten af dine systemer.
Homebanking idag, er ikke blot at hive lidt information fra mainframen, og så pakke det ind i noget html - et moderne system, skal helst integrere samtlige de produkter kunden har hos banken, altså i form af værdipapirer handel og opbevaring, lån hos realkredit-institutter, diverse forsikringer etc. Da en del af de transaktioner man danner, er decideret pengebærende, og du kan flytte rigtig store midler frem og tilbage, ligger der en del omkring identity management og access management - ikke mindst fordi bankrådgivere og kunder bruger det samme system, bare med forskellige adgange.
Jeg er ikke sikker på, du har lyst til at udvikle sådan et system i PHP, men .NET er da klart en kandidat...altså hvis det kan integreres til de bagvedliggende systemer, hvilket ofte er et større problem, end man lige tror. Så er der kun noget tilbage omkring transaktionssikkerhed, skalérbarhed etc. og bygger du et system, der skal håndtere et 3-cifret millardbeløb om året...så vil du gerne være sikker på at teknologien er gennemtestet og fungere.
Hvis du iøvrigt vælger WebSphere, kan du vælge at få den til at køre direkte på mainframen, med den stabilitet og skalérbarhed der dermed følger. Du kan også vælge at køre den på din AIX, din Linux, HPUX eller din Windows, eller hvad du nu har valgt af strategisk platform.
Det korte af det lange er, at en forretning aldrig vælger en bestemt type miljø, fordi programmøren synes det er herligt - som oftest er det en god kombination af time-to-market, pris, sikkerhed, skalérbarhed etc. der sætter scenen, og hvis time-to-market betyder mere end skalérbarhed, og man har kompetencerne i huset, jamen så har du da helt ret i, at java ikke er den mest åbenlyse platform...men sandsynligheden for at sådan et system er i enterprise-klassen, som jeg tænker det...den er også relativt begrænset, og både newz.dk eller et andet forum falder jo også lidt udenfor den kategori.
Hvis den endelig er det, så findes der jo deciderede portaler, der er skrvet til java, i IBM-terminologi, er det så WebSPhere Portal Server, hvor det altså er et portalframework og derved web-teknologi, der har været fokus på...og sgisme om ikke de har hørt om AJAX og PHP-fortolkning...sådan meget Web 2.0-agtigt. :)
Som skrevet i mit tidligere indlæg, hvis du absolut vil skrive sådan et newz 3.0, så er sMASH som jeg linker til, en klar kandidat. Der får du så både PHP's lethed, en del mashup-muligheder, og nåehja en underlignende java-maskine.
Efter min mening har alle systemerne deres berettigelse, men skal ses i den rette kontekst...og det er specielt i det lys, at der ofte sker fejl.
Homebanking idag, er ikke blot at hive lidt information fra mainframen, og så pakke det ind i noget html - et moderne system, skal helst integrere samtlige de produkter kunden har hos banken, altså i form af værdipapirer handel og opbevaring, lån hos realkredit-institutter, diverse forsikringer etc. Da en del af de transaktioner man danner, er decideret pengebærende, og du kan flytte rigtig store midler frem og tilbage, ligger der en del omkring identity management og access management - ikke mindst fordi bankrådgivere og kunder bruger det samme system, bare med forskellige adgange.
Jeg er ikke sikker på, du har lyst til at udvikle sådan et system i PHP, men .NET er da klart en kandidat...altså hvis det kan integreres til de bagvedliggende systemer, hvilket ofte er et større problem, end man lige tror. Så er der kun noget tilbage omkring transaktionssikkerhed, skalérbarhed etc. og bygger du et system, der skal håndtere et 3-cifret millardbeløb om året...så vil du gerne være sikker på at teknologien er gennemtestet og fungere.
Hvis du iøvrigt vælger WebSphere, kan du vælge at få den til at køre direkte på mainframen, med den stabilitet og skalérbarhed der dermed følger. Du kan også vælge at køre den på din AIX, din Linux, HPUX eller din Windows, eller hvad du nu har valgt af strategisk platform.
Det korte af det lange er, at en forretning aldrig vælger en bestemt type miljø, fordi programmøren synes det er herligt - som oftest er det en god kombination af time-to-market, pris, sikkerhed, skalérbarhed etc. der sætter scenen, og hvis time-to-market betyder mere end skalérbarhed, og man har kompetencerne i huset, jamen så har du da helt ret i, at java ikke er den mest åbenlyse platform...men sandsynligheden for at sådan et system er i enterprise-klassen, som jeg tænker det...den er også relativt begrænset, og både newz.dk eller et andet forum falder jo også lidt udenfor den kategori.
Hvis den endelig er det, så findes der jo deciderede portaler, der er skrvet til java, i IBM-terminologi, er det så WebSPhere Portal Server, hvor det altså er et portalframework og derved web-teknologi, der har været fokus på...og sgisme om ikke de har hørt om AJAX og PHP-fortolkning...sådan meget Web 2.0-agtigt. :)
Som skrevet i mit tidligere indlæg, hvis du absolut vil skrive sådan et newz 3.0, så er sMASH som jeg linker til, en klar kandidat. Der får du så både PHP's lethed, en del mashup-muligheder, og nåehja en underlignende java-maskine.
Efter min mening har alle systemerne deres berettigelse, men skal ses i den rette kontekst...og det er specielt i det lys, at der ofte sker fejl.
Windcape (20) skrev:Jeg foretrækker faktisk at få view fejl i test-time, ikke compile-time.
Yuck. Jeg vil da have besked hurtigst muligt, hvis jeg har lavet noget forkert.
Fx. har jeg indført nogle kontroller, som gør at visse fejl vises ved compile-time i stedet for under testen. Hvis fejlen ikke fanges under udviklerens egen test, gør det en enorm forskel.
Mine beregninger siger at en fejl som koster 2 minutter at opdage og rette når det sker compile-time, nemt koster 6 mandetimer hvis det først opdages under testen.
(Og jeg gider ikke høre noget om vores "ineffektive" test-system. Medmindre du kender det og selv har arbejdet med det, aner du ikke hvor effektivt det er.)
Og hvor compile-fejl ALTID opdages, kan andre fejl snige sig igennem meget grundige tests. og når først det er slut-brugeren der opdager fejlen, er prisen svær at beregne.
Windcape (20) skrev:Det er ikke særlig konfigurerbare løsninger hvis man ikke kan ændre på View uden at recompile
Det går ganske fint og usynligt. På det lokale testmiljø foregår det ligesom et simpelt PHP-setup: Jeg ændrer i en fil, jeg trykker gem, skifter over til browseren, trykker reload.
Windcape (20) skrev:samt at jeg absolut ikke synes det er korrekt implementering af MVC, da View ikke skal indeholde buisness logic overhovedet.
Jeg snakker ikke om business logic. Det ligger mange lag væk.
Windcape (20) skrev:Hvis du skal udvikle et homebanking system, om du så skriver det i Java eller PHP, eller C# er lige meget, da du alligevel skal kalde de underliggende system moduler, som vel er skrevet i PL/1 (Danske Bank).
Selv om det blot er en frontend, er der stor forskel på hvor fed (modsat "tynd") en frontend det er.
Fx. kan frontenden håndtere process-styring. Det kan være en 5-trins wizard hvor der kun er backend-kontakt før første trin og efter sidste trin.
Eller måske er der 100 backend-kald undervejs, hvor backenden ikke blander sig i sammenhængen mellem dem.
Selv om der ikke er business-logic i frontenden, kan der være meget logik alligevel. (Og selvfølgelig ikke i viewet.)
Windcape (20) skrev:Men jeg kan godt se at jer som vælger Java, vælger det på baggrund af systemet, men ignorer brugeren.
Brugeren har intet med det at gøre. Og hvis du mener "udvikleren": Selvfølgelig er det en faktor om man kan skabe et tilfredsstillende arbejdsmiljø, og om man overhovedet kan skaffe udviklere. Og det er da store faktorer. Men der er også mange andre.
At skaffe Java-udviklere er nemt nok. Og kan man ikke give dem et tilfredsstillende arbejdsmiljø, er det ikke Java's skyld.
Windcape (20) skrev:At skrive et forum i JEE , eller en siden som newz.dk, er nok det dummeste man kan gøre.
Du har åbenbart fanget noget alligevel. Enterprise-værktøjer bruges til enterprise-systemer.
Jeg mener også at .NET er den eneste rigtige pendant til Java, men medtager PHP i diskussionen siden det er et yderst udbredt sprog (som faktisk HAR applikations servere, det er hvad Zend tjener penge på).Borg[One skrev:(21)]Jeg er ikke sikker på, du har lyst til at udvikle sådan et system i PHP, men .NET er da klart en kandidat...altså hvis det kan integreres til de bagvedliggende systemer, hvilket ofte er et større problem, end man lige tror.
Ja, men med en service orienteret model, som JEE i den grad tilbyder, så bør man ikke have sine bruger-interfaces "enterprise".myplacedk (22) skrev:Du har åbenbart fanget noget alligevel. Enterprise-værktøjer bruges til enterprise-systemer.
Man bør jo netop som udvikler i et multi tier arkitektur undgå at couple sine ting. Og ved at benytte custom tags, laver du netop views du ikke kan exporterer til et andet system.
Så hvor at JEE måske kan være fint til applikationsserver der hoster web-services, så synes jeg absolut ikke det er ideelt til præsentationslaget, som web nu engang er ret meget af!
Derudover er koncepter som at forsøge at sætte et state på HTTP så dumme, er det er svært at fatte at SUN stadig forsøger på det.
Hvis du løber igennem en 5 trins wizard, så nytter det jo intet hvis brugeren mister alt data hvis de trykker på tilbage knappen i deres browser -- en teknologi fejl findes i blandt andet JSF!
Derudover bør man måske sig se lidt om mht. Enterprise, og kigge på alternativer, ellers ender man som Danske Bank "hvis ikke IBM kan, hvem kan så?" og står med fjerene i postkassen når systemet så går ned, og IBM fejler.
At afskrive alle andre teknologier end java, bare fordi de ikke er 10 år gamle og ligeså langsomme og besværlige at udvikle i, er ikke til at forstå.
Så jeg kan forstå hvorfor man måske ville vælge WebSphere som platform (jeg går ud fra at WebSphere er hvad Danske Bank benytter, da det er en del af deres kursus materiale.)
Men argumentet for at benytte JEE/JSF/WebSphere til nyudvikling kan jeg ikke finde. På det punkt ser det kun ud til at være en dårligere teknolgi end ASP.NET.
Fordi hvis ingen valgte nye teknolgier pga. features, ville vi stadigvæk kode alting i COBOL/ALGOL/ASM.
Men skal da nok blive sjovt at se JEE løsninger blive skaleret over på multi-core arhitecture. Og Web *vil* blive så stort og krævende at det er en nødvendighed.
Jeg har allerede vist det med worldofwarcraft.com som på ingen måde kan håndere det forventede pres (de bruger Tomcat).
Og modsat PHP/ASP.NET, så mister JEE alt information ved timeouts/fejl, pga. dets forsøg på at benytte et state, istedet for HTTPContext.
Men argumentation er godt, det er ihvertfald bedre end en chef der siger "det skal vi bruge fordi det er IBM som har lavet det".
Og også bedre end marketingsfolk og SUN der forsøger at promomere deres egne teknologier på outdated grimme websites, målrettet med chefer, og ikke udviklere.
Jeg vil bare gerne have andre udvikleres indtryk end mine egne, hvis jeg nogensinde skulle få indflydelse på valg af teknologi.
Hvilket er sandsynligt, når der skal skrives speciale :-)
Og også bedre end marketingsfolk og SUN der forsøger at promomere deres egne teknologier på outdated grimme websites, målrettet med chefer, og ikke udviklere.
Jeg vil bare gerne have andre udvikleres indtryk end mine egne, hvis jeg nogensinde skulle få indflydelse på valg af teknologi.
Hvilket er sandsynligt, når der skal skrives speciale :-)
Windcape (23) skrev:Og ved at benytte custom tags, laver du netop views du ikke kan exporterer til et andet system.
What? Det bliver da ikke meget lettere. Jo flere custom tags vi får lavet, jo tættere kommer vi på mit mål: At viewet grundlæggende bare er skærm-designet udtrykt i XML, i stedet for en tegning.
Uden custom-tags kunne vi ikke skrive hvad vi ville opnå, men kun hvordan det skal opnås. Og så bliver det da ikke meget sværere at flytte til et nyt system.
Jeg hører da gerne om det, hvis du har et bedre forslag. (Ikke at jeg vil benytte forslaget, evenen til at skifte platform er ikke 1. prioritet.)
Windcape (23) skrev:så synes jeg absolut ikke det er ideelt til præsentationslaget, som web nu engang er ret meget af!
Heh. ER "web" ikke et præsentationslag? Det var nok det du mente.
Windcape (23) skrev:Derudover er koncepter som at forsøge at sætte et state på HTTP så dumme, er det er svært at fatte at SUN stadig forsøger på det.
Jeg håber jeg misforstår dig, for jeg kan ikke lige se hvordan man kan have noget imod state.
Windcape (23) skrev:Hvis du løber igennem en 5 trins wizard, så nytter det jo intet hvis brugeren mister alt data hvis de trykker på tilbage knappen i deres browser -- en teknologi fejl findes i blandt andet JSF!
Det problem har vi ikke på vores system.
Windcape (23) skrev:At afskrive alle andre teknologier end java, bare fordi de ikke er 10 år gamle og ligeså langsomme og besværlige at udvikle i, er ikke til at forstå.
Jeg fatter ikke at du stadig tror, det er så simpelt. (Og at du tilsyneladende tror det er besværligt for alle.)
I øvrigt er Java en relativt ny teknologi, og C# er den nye dreng i klassen, som stadig ikke helt har fundet sin rolle. Det er i hvert fald en alternativ måde at se det på, som er lige så korrekt som din.
Det er nemt at se C# som noget godt etableret, og noget man kan tage for givet, hvis det har eksisteret siden starten af sin udvikler-karriere.
Men hvis du nu træder tilstrækkeligt mange skridt tilbage fra dit eget skrivebord, kan du se det fra samme synsvinkel som mig.
Windcape (23) skrev:Men skal da nok blive sjovt at se JEE løsninger blive skaleret over på multi-core arhitecture. Og Web *vil* blive så stort og krævende at det er en nødvendighed.
Et view som compiles er for komplekst, men noget som kræver multi-trådet er en nødvendighed? Javel så.
I øvrigt kører vi allerede multi-trådet, så jeg håber da du finder noget andet at grine af.
Windcape (23) skrev:Og modsat PHP/ASP.NET, så mister JEE alt information ved timeouts/fejl, pga. dets forsøg på at benytte et state, istedet for HTTPContext.
Okay. Lad lige være med at fortælle det til vores setup.
(Og hvis HTTPContext ikke er state, kan jeg nu se at vi ikke er enige om hvad "state" er.)
Ud fra hvad du beskriver, har du bare lavet din egen version af XSLT.myplacedk (25) skrev:Jeg hører da gerne om det, hvis du har et bedre forslag.
I enterprise systemer har folk det med at beskrive Web som en platform, og ikke kun præsentationslag.myplacedk (25) skrev:Heh. ER "web" ikke et præsentationslag? Det var nok det du mente.
Jeg mener ikke at man udvikler til web på samme måde som man udvikler til f.eks. en windows applikation.
Med state mener jeg at serveren har alting i sin hukommelse. Http har ikke et state, og alting skal reloades for hver side, dvs. uden cache vil du foretage et DB kald for hver side visning, hvor i en windows-applikation vil du kunne huske informationerne i memory (paging er et godt eksempel.)
JEE forsøger det med ApplicationServers, og ASP.NET forsøger det med ViewState. Hvor PHP benytter ingen af delene, men tillader at gøre de samme ting ligeså nemt.
At i kører frameworks / software de retter op på grundlæggende fejl i JEE er vel også at forvente :)myplacedk (25) skrev:Okay. Lad lige være med at fortælle det til vores setup.
Jeg snakker om ting som er grundlæggende fejl i teknologien.
Folk benytter det ene framework på det andet, for at få en optimal løsning. Da jeg læste op på JSF fandt jeg ud af at man skal have yderlige 2 frameworks installeret ovenpå JSF (som i sig selv er et framework) for at benytte det optimalt.
Det er problemer jeg ikke oplever med andre teknologier.
Og vi kan vel også nævne Google, jeg tvivler MEGET på at de kunne kører hele deres system i JEE :-)
Windcape (26) skrev:Det er problemer jeg ikke oplever med andre teknologier.
Det er ikke noget jeg oplever som et problem.
Windcape (26) skrev:vi kan vel også nævne Google
Det kan vi da godt. Men hvorfor skulle vi?
At ét firma ikke kan basere hele sit system på en bestemt teknologi, betyder intet for hvor god teknologien er.
Vi kan såmen heller ikke køre hele vores system med ren Java.
#27
Jeg synes jo det er en god pointe, som jeg er så pokkers ked af, at mange forretninger overhovedet ikke har øjne for.
Det er ikke sjældent jeg ser store firmaer, der stolt proklamere at de kører MS væg-til-væg, som om det er en fantastisk bulletproof strategi.
I virkeligheden, bør man nøje vurdere hvert enkelt system, og finde det der giver bedst mening.
Jeg har fungeret i en temmelig blå forretning, som Danske Bank iøvrigt også er kendt for - men selvom tingene var så blå, så var der stadig et tilpas stort imx af leverandøre, til at IBM ikke anså kampen for vundet, bare fordi de havde et produkt vi måske skulle bruge. Efter min mening fungerede den strategi langt bedre end en MS+SAP-så-er-vi-helgarderet-løsning...
Vi kan såmen heller ikke køre hele vores system med ren Java
Jeg synes jo det er en god pointe, som jeg er så pokkers ked af, at mange forretninger overhovedet ikke har øjne for.
Det er ikke sjældent jeg ser store firmaer, der stolt proklamere at de kører MS væg-til-væg, som om det er en fantastisk bulletproof strategi.
I virkeligheden, bør man nøje vurdere hvert enkelt system, og finde det der giver bedst mening.
Jeg har fungeret i en temmelig blå forretning, som Danske Bank iøvrigt også er kendt for - men selvom tingene var så blå, så var der stadig et tilpas stort imx af leverandøre, til at IBM ikke anså kampen for vundet, bare fordi de havde et produkt vi måske skulle bruge. Efter min mening fungerede den strategi langt bedre end en MS+SAP-så-er-vi-helgarderet-løsning...
Nemlig, så er vi ved at nå samme tankegang. (Hvor jeg så mener at Java ikke er den rigtige teknologi til præsentation).
Jeg ser faktisk mange som vælger XSLT oven på en SOA løsning, fordi at JSP/JSF/Structs er klodsede langsomme løsninger til præsentation.
Det eneste problem med det, er at man tilføjer *endnu* et ekstra lag som skal hånderes. Hvilket tager relativt meget af udviklernes tid.
Det er self. altid et spørgsmål om priorteringer, men jeg mener stadigvæk at udviklingstid HAR noget at sige i dag. Vi som udviklerer bør vælge et sæt of værktøjer det kræver så lidt arbejde og uddanelse som overhovedet muligt.
Ved at bruge custom tags kræver du at nye udviklerer skal læse dokumentation og lære nye ting.
Ved at bruge HTML, kan du forvente at de er 110% udlærte i det i det sekund de træder ind på kontoret.
Og det samme med valg af sprog/platform. Hvis man kigge på previews af Java 7, er det ikke svært at se at brugerne (udviklerne - that's us), gerne vil have samme features som .NET tilbyder, og derfor bliver mange af dem implementeret.
bean-modellen er så outdated det ikke er sjovt længerer.
Og da jeg snakkede multi-core tidligere tænkte jeg mere på threading over flere cores, som i dag kræver en form for funktionelt sprog (think Hashell, Lisp).
.NET har er allerede klar (Nemerle, F#), Java? ser ikke sådan ud.
Enterprise kan altså seriøst ikke være et udtryk for at gøre tingene på en gammeldags og velkendt måde, istedet for a adapterer til nye teknologier. (Jeg vil mene at JEE var den langsomste webteknolgi til at adopterer AJAX)
Jeg ser faktisk mange som vælger XSLT oven på en SOA løsning, fordi at JSP/JSF/Structs er klodsede langsomme løsninger til præsentation.
Det eneste problem med det, er at man tilføjer *endnu* et ekstra lag som skal hånderes. Hvilket tager relativt meget af udviklernes tid.
Det er self. altid et spørgsmål om priorteringer, men jeg mener stadigvæk at udviklingstid HAR noget at sige i dag. Vi som udviklerer bør vælge et sæt of værktøjer det kræver så lidt arbejde og uddanelse som overhovedet muligt.
Ved at bruge custom tags kræver du at nye udviklerer skal læse dokumentation og lære nye ting.
Ved at bruge HTML, kan du forvente at de er 110% udlærte i det i det sekund de træder ind på kontoret.
Og det samme med valg af sprog/platform. Hvis man kigge på previews af Java 7, er det ikke svært at se at brugerne (udviklerne - that's us), gerne vil have samme features som .NET tilbyder, og derfor bliver mange af dem implementeret.
bean-modellen er så outdated det ikke er sjovt længerer.
Og da jeg snakkede multi-core tidligere tænkte jeg mere på threading over flere cores, som i dag kræver en form for funktionelt sprog (think Hashell, Lisp).
.NET har er allerede klar (Nemerle, F#), Java? ser ikke sådan ud.
Enterprise kan altså seriøst ikke være et udtryk for at gøre tingene på en gammeldags og velkendt måde, istedet for a adapterer til nye teknologier. (Jeg vil mene at JEE var den langsomste webteknolgi til at adopterer AJAX)
Derudover troede jeg faktisk at det var planen at man gik VÆK fra applikationsservere, siden for en 5-6 år siden, for at designe software det ikke var implemeteringsspecifikt.
Jeg tvivler meget på at du kan benytte en WebSphere application på Tomcat uden at ændre mere end 5 linjers konfiguration.
Og så ryger undskyldningen med at Java kan køre på flere platforme ;)
Jeg tvivler meget på at du kan benytte en WebSphere application på Tomcat uden at ændre mere end 5 linjers konfiguration.
Og så ryger undskyldningen med at Java kan køre på flere platforme ;)
Windcape (13) skrev:Det jeg mener er problemet med mængden af JSF kode er hele problemet med Faces.config.
ASP.NET MVC, RoR, PHP (Zend) benytter alle routes der defineres med regulare expressions or lign. til at automatisk mappe url til methoder, samt properties.
Det sparer lidt linier.
Til gengæld exposer man sin applikations struktur.
Det er dårlig encapsulation.
Windcape (13) skrev:Derudover er det hele problemet med Standard JSF tags. Hvorfor spilde tiden på at lære endnu et markup system når der nu allerede findes HTML.
Nogen kan godt lide JSF tags.
Andre foretrækker HTML tags.
Sidstnævnte kategori bruger Facelets som view teknologi sammen med JSF.
Windcape (15) skrev:Simple kode kan også været advanceret. Der er absolut ingen grund til at tro at routes ikke kan hånterer alting bare fordi det ikke kræver 20 gange så meget kode ligesom Java.
Du kan også spare noget kode ved at bruge public fields og glemme alt om properties/getters&setters.
Det gør det ikke til en god ting.
Encapsulation er en god ting. Også selvom det kræver lidt mere kode.
Windcape (17) skrev:Spørgsmålet er bare hvor meget configuration du skal skrive manuelt. Java udviklerer vælger så at lave mere configuration, fordi de ikke tror på at det er muligt at skrive mindre,
Det er forkert.
Dem der har designet Struts og JSF kender udmærket både totalt spagetti kode uden konfiguration og diverse CoC/Rails frameworks.
De sidstnævnte findes også til Java: Wicket, Grails etc..
Men erfaringen viser at de konfigurations filer er nyttige i større projekter og Struts/JSF har aldrig interesseret sig for behovet for hello world web apps.
Borg[One skrev:(18)]Min pointe er alene, at valget af udviklingsmiljø, langt hen ad vejen er mere behovsdrevet, end drevet af antallet af linier du skal skrive som programmør.
Antal linier er normalt betydningsløst i et større projekt.
Hvis man smider et 500000 liniers projekt ind i COCOMO II får man at det vil tage 500000 timer. Hvis vi siger at halvdelen af tiden bruges af udviklere, så er det 2 linier i timen for udviklere.
Forskellen på at tænke i 59 minutter 40 sekunder og taste kode i 20 sekunder og tænke i 59 minutter 50 sekunder og taste kode i 10 sekunder er minimal.
Windcape (17) skrev:
Om du skriver <jsp:foobar text="hai" /> eller <% Html.Foobar("hai") %> er altså et fedt.
Der er ikke den store forskel på den tid det tager at taste det ind.
Men der er alverden til forskel på det i udvikling sog vedligeholdelsesmæssig henseende.
Det sidste er traditionel procedural programmering.
Det første er er objektorienteret.
Bag tags ligger der et hirakisk objekt træ.
Windcape (20) skrev:Jeg foretrækker faktisk at få view fejl i test-time, ikke compile-time.
Det er så i modstrid med alle gode principper for software udvikling. Jo tidligere i compile-link-run fasen man får fejlen jo bedre.
Windcape (20) skrev:Det er ikke særlig konfigurerbare løsninger hvis man ikke kan ændre på View uden at recompile, samt at jeg absolut ikke synes det er korrekt implementering af MVC, da View ikke skal indeholde buisness logic overhovedet.
Erfaringen viser at det som oftest er det sikreste at reloade hele app fremfor at reloade dele af en app.
Man kan godt compile view uden at den indeholder business logic.
Det kan du også gøre i ASP.NET hvis du vil.
Windcape (20) skrev:Hvis du skal udvikle et homebanking system, om du så skriver det i Java eller PHP, eller C# er lige meget, da du alligevel skal kalde de underliggende system moduler, som vel er skrevet i PL/1 (Danske Bank).
Jeg troede faktisk at Danske Bank havde opgivet at konvertere fra Cobol til PL/I, således at det var Cobol der skulle kommunikeres med.
Og det er ikke helt lige meget. Kommunikationen skal jo ske gennem noget.
Java har bedre support for 2PC, XA, mesage queues etc. end .NET og PHP (PHP er ret dårlig på det område og .NET er langt bedst til at snakke med andre MS produkter).
Windcape (20) skrev:At skrive et forum i JEE , eller en siden som newz.dk, er nok det dummeste man kan gøre.
Det var ihvertfald ikke specielt oplagt.
newz.dk har helt andre behov end f.eks. en finansiel institution:
- prisen meget vigtig
- ikke så stor en code base
- fejl betyder ikke så meget bare de kan rettes hen ad vejen
- intet integrations behov
o.s.v.
Der er lavet både standard CMS (Alfresco og OpenCMS) og store community løsninger (linkedin.com) i Java EE.
Men Alfresco er absolut i highend CMS klassen og linkedin.com har formentligt noget avanceret backend til at servicere de betalende kunder (recruitere).
Hvis jeg skulle designe en ny version af newz.dk ville det ikke blive en Java EE løsning.
Borg[One skrev:(21)]Hvis den endelig er det, så findes der jo deciderede portaler, der er skrvet til java, i IBM-terminologi, er det så WebSPhere Portal Server, hvor det altså er et portalframework og derved web-teknologi,
WebSphere Portal er en portal.
Og newz.dk kan med lidt god vilje også opfattes som en portal.
Men det er ikke helt samme type portal.
Jeg ville ikke foreslå WebSphere Portal til newz.dk.
Windcape (23) skrev:
Men skal da nok blive sjovt at se JEE løsninger blive skaleret over på multi-core arhitecture. Og Web *vil* blive så stort og krævende at det er en nødvendighed.
Øh????
Java EE løsninger i produktion kører nok stort set altid i cluster. Brug af fler CPU maskiner har været helt almindeligt i 10 år. Og idag kan man jo ikke købe en enkelt kerne CPU.
Windcape (26) skrev:Ud fra hvad du beskriver, har du bare lavet din egen version af XSLT.
Custom taglibs er ret langt fra XSLT.
Custom taglibs svarer mere til ASP.NET user controls.
Windcape (26) skrev:JEE forsøger det med ApplicationServers, og ASP.NET forsøger det med ViewState. Hvor PHP benytter ingen af delene, men tillader at gøre de samme ting ligeså nemt.
Jeg kan ikke helt se at det giver mening at sammenligne Java EE en application server med ASP.NET view state.
Windcape (29) skrev:Jeg ser faktisk mange som vælger XSLT oven på en SOA løsning, fordi at JSP/JSF/Structs er klodsede langsomme løsninger til præsentation.
Øh????
SOA løsninger har ikke nogen præsentation.
Windcape (29) skrev:
Ved at bruge custom tags kræver du at nye udviklerer skal læse dokumentation og lære nye ting.
Ved at bruge HTML, kan du forvente at de er 110% udlærte i det i det sekund de træder ind på kontoret.
Komplekse problemer kræver desværre komplekse løsninger.
Java EE er et ret omfattende emne, som tager mange år at sætte sig ind i.
Så naturligvis var det fedt hvis man kunne lære at udvikle den slags applikationer som Java EE bruges til på 14 dage.
Men sådan er virkeligheden ikke.
Windcape (29) skrev:Og det samme med valg af sprog/platform. Hvis man kigge på previews af Java 7, er det ikke svært at se at brugerne (udviklerne - that's us), gerne vil have samme features som .NET tilbyder, og derfor bliver mange af dem implementeret.
Java stjæler med arme og ben fra .NET - ligesom .NET stjæler med arme og ben fra Java.
Det kaldes udvikling.
Windcape (29) skrev:bean-modellen er så outdated det ikke er sjovt længerer.
Det er ellers samme model som man bruger i stort set alle sprog. Der er kun lidt syntaktisk forskel.
Windcape (29) skrev:
Og da jeg snakkede multi-core tidligere tænkte jeg mere på threading over flere cores, som i dag kræver en form for funktionelt sprog (think Hashell, Lisp).
.NET har er allerede klar (Nemerle, F#), Java? ser ikke sådan ud.
Øh????
Der er masser af funktionelle sprog for Java platformen: Scala, Jaskell (Haskell), Clojure (Lisp) etc..
Twitter bruger scala på deres backend (frontend er RoR).
Windcape (30) skrev:Derudover troede jeg faktisk at det var planen at man gik VÆK fra applikationsservere, siden for en 5-6 år siden, for at designe software det ikke var implemeteringsspecifikt.
Man er ikke på vej væk fra applikations servere i Java EE verdenen.
Man kan argumentere for at det er man heller ikke i andre verdener.
IIS med ASP.NET og Apache med mod_php svarer jo i et vist omfang til web container delen af en Java EE applikations server
(og f.eks. Tomcat er jo kun web container).
I Pythin verdenen bruger man ligefrem også begrebet applikation server (Zope).
Windcape (30) skrev:
Jeg tvivler meget på at du kan benytte en WebSphere application på Tomcat uden at ændre mere end 5 linjers konfiguration.
Der tror du så forkert.
Din JSF apps med web.xml og faces-config.xml bør køre uden nogen som helst ændringer på WebSphere.
[forudsat at det er en WebSphere som understøtter de versioner af standarderne du bruger - jeg vil gætte på at version 6.0, 6.1 og 7.0 vil virke]
Det er ikke sjældent at udviklere udvikler på en anden app server end den som der skal køres produktion på.
[QA bør naturligvis teste på alle de app servere som der skal køres produktion på]
Windcape (26) skrev:Og vi kan vel også nævne Google, jeg tvivler MEGET på at de kunne kører hele deres system i JEE :-)
Søge siden kunne sagtens laves i JSF. Men JSF var nok ikke et oplagt valg.
Deres crawler kunne laves i Java (SE ikke EE), men de har altså tilfældigvis valgt Python.
De øvre lag af deres infrastruktur (map reduce) kunne laves i Java (se Hadoop), men det gør det ikke.
De nedre lag af deres infrastrutur (GFS) kan ikke laves i Kava da det kræver native kode.
En betragtelig del af deres sekundære systemer kunne laves i Java (SE og EE) og mange af dem er lavet i Java.
Google har hyret et antal af de bedste Java folk fra SUN og BEA og de laver meget Java.
De grundlæggende systemmoduler fra 32/70 platformen, er skrevet i PL/1.arne_v (36) skrev:Jeg troede faktisk at Danske Bank havde opgivet at konvertere fra Cobol til PL/I, således at det var Cobol der skulle kommunikeres med.
Og det er ikke helt lige meget. Kommunikationen skal jo ske gennem noget.
Java har bedre support for 2PC, XA, mesage queues etc. end .NET og PHP (PHP er ret dårlig på det område og .NET er langt bedst til at snakke med andre MS produkter).
De skriver stadigvæk batch i COBOL.
Hvilket netop er pointen. Hvis du designer enterprise delen af dit system som SOA, så kan du tilføje et View som XSLT uden at skulle rører det eksisterende system.arne_v (40) skrev:SOA løsninger har ikke nogen præsentation.
Du kan tilføje et custom view direkte oven på en RESTfull service (SOAP er lidt mere advanceret). Hvilket er ideelt hvis du skal supportere flere kilder.
Det betyder at du f.eks. som på newz.dk, har nyheder på forsiden og RSS feed som et dataouput. Og bare 2 forskellige views.
Windcape (29) skrev:Ved at bruge custom tags kræver du at nye udviklerer skal læse dokumentation og lære nye ting.
Ved at bruge HTML, kan du forvente at de er 110% udlærte i det i det sekund de træder ind på kontoret.
110%? Der er godt nok ikke mange, som kan HTML. Jaja, de kan klampe noget sammen som virker i IE, men det kan jeg ikke bruge til noget.
Indse at folk er elendige til HTML. Elendige. Seriøst. Det er IKKE noget man kan forvente at folk er gode til. Og hvorfor pokker skulle de også være det? Det er ikke noget der bliver undervist i nogen steder, og HTML er normalt også noget som bare bliver genereret.
HTML er ikke noget man bare kan. Det er noget man skal lære.
Og det værste er, at det er skide svært at have kontrol over. Hvordan tvinger man folk til at skrive pæn HTML?
Vores custom tags er LANGT lettere at lære folk, end at lære dem at skrive ordentlig HTML. Og så er de også langt lettere at bruge. Og vedligeholde. Og lave statistik på. Og refactor. Og og og...
Windcape (44) skrev:Hvis du designer enterprise delen af dit system som SOA, så kan du tilføje et View som XSLT uden at skulle rører det eksisterende system.
...men det indebærer en ekstremt tynd frontend. Det kan da være OK til nogle ting, men andre steder er det ikke den bedste løsning.
Nej man gør ej?arne_v (31) skrev:Det sparer lidt linier.
Til gengæld exposer man sin applikations struktur.
Det er dårlig encapsulation..
Det er perfekt MVC:
ProductController
- ViewProduct(int id)
- ViewProducts
- CreateProduct(string name)
- EditProduct(int id)
- DeleteProduct(int id)
Product (Model)
ViewProduct.html
ViewProducts.html
CreateProduct.html
EditProduct.html
DeleteProduct.html
Og så ligesom i faces-config binder du det sammen med en route {controller}/{action}/{id}
Forskellen er at det kræver mindre configuration end i Java.
Dvs. argumentet for valg af teknolgi, er fordi at udviklerne ikke kan finde ud af deres arbejde, og/eller ikke vil lære noget nyt.myplacedk (45) skrev:Indse at folk er elendige til HTML. Elendige. Seriøst. Det er IKKE noget man kan forvente at folk er gode til
Frontend skal bare være præsentation. Hvis du ikke kan lave den ligeså tynd så at det kunne være hvilken som helst viewengine, så mener jeg at du ikke følger MVC korrekt.myplacedk (46) skrev:...men det indebærer en ekstremt tynd frontend. Det kan da være OK til nogle ting, men andre steder kan det ikke bruges.
Hele konceptet er jo netop at du skal kunne skifte fra HTML til XML bare ved at ændre dit view. Hvis du benytter custom tags der generere HTML, så kan du ikke lave dit view om, uden at skulle lave nye custom tags!
Gå til top
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Gå til bund