tinokissig.de

Kommentare (5)

1. 

   Jürgen sagt am 31. August 2006 um 18:57

   Wicket, schon wieder ein Framework, bei dem kein Compiler irgendwas prüfen kann. getHomePage() gibt eine Klasse zurück, die kann zur Compile-Zeit auch Object.class sein, stört den Compiler gar nicht. Ganz zu schweigen von der mystischen Zuordnung zwischen IDs im HTML und Dingen, die man zur Laufzeit per add() zur Seite hinzufügt. Und dass Wicket zur Laufzeit die html-Dateien parst und darin Dinge ersetzt, wird sicherlich auch nicht gerade die Geschwindigkeit erhöhen. Krass, wie viel Zeit in sowas investiert wird.

   Antworten

2. Pingback: Wissenswertes über die Fettverbrennung! « Hitzi’s Blog

3. 

   Eelco Hillenius sagt am 1. September 2006 um 18:14

   [Comment ID #3694 Will Be Quoted Here]

   Wicket 2.0 utilizes generics, so you have to return a subclass of page in getHomePage (and similar methods). We don’t use add in 2.0, but instead create the hierarchy by passing the parent in the constructor (like e.g. SWT), so that we match with the markup at construction time. Btw, markup is parsed only once, your presumption that it is parsed every time is false. This area is typically not a concern anyway with web frameworks, but if it were, you would find that Wicket is in fact one of the most efficient frameworks if it comes to rendering.

   The fact that you have to synchronize your markup with your Java code is something that might bother you or not. With most other frameworks you have to do this declaratively (e.g. in the markup or in a third file). This usually saves some code, but otoh leads to quite some inflexibility. You are bound by what kind of interactions and creation patterns the framework builders thought up for you much more in that way. For the ‘price’ of having to sync Java with markup, you’ll get a lot of developer freedom as to how to create your components (like which dependencies they have and how you resolve them) and how they interact.

   Antworten
4. 

   Jürgen sagt am 3. September 2006 um 20:30

   Thanks for answering. The problem of missing compiler checks will persist though, even if Wicket 2.0 allowes the compiler to check the java object structure. The html pages do not get compiled. I understand you are doing it this way to allow for wysiwyg html editing. This however is completely irrelevant to us. We are software developers and not web designers. We usually get the html first and then need to make it work. We build huge “enterprise” systems and strive for 100% completeness in automatic building and testing. We do have problems with frameworks such as Struts since the xml configuration cannot be checked. But with Struts at least the classes AND the JSPs can be compiled (not that this again will mean much if one uses those struts runtime-resolving tag libraries). I believe the web framework development is headed into the wrong direction and Wicket seems to be no exception.

   Antworten
5. 

   tino sagt am 4. September 2006 um 08:50

   Evaluation-Jürgen was (again) faster than me… But after studying the features of “Wicket” I have to agree with him… Also Wicket is not the web framework that we are looking for…

   Antworten