langreiter.com plain, simple: comments-2006-07-08

LANGREITER.COM plain, simple

START

INDEX

Samstag, 8. Juli 2006

Wicked: Wicket.

2006-07-08-wicke[d|t]

hns 6715 days AGO
very interesting. die zutaten waren lange bekannt, fast verwunderlich, dass es so lange gebraucht hat, bis sowas für java da ist. wenn ich mir die javadoc anschaue verblüfft mich die innere komplexität etwas, die doch in krassem gegensatz zur äusseren einfachheit steht. ob das nicht abstrahlt, sprich ob nicht ein kleineres, einfaches paket besser wäre?

chris 6713 days AGO
mir ist noch nicht ganz klar, wie sehr sich die chose endeffektiv von durchaus nicht unähnlichen dingen wie tapestry oder gar jsf unterscheidet ...

schaut jedenfalls nett aus. mit javascript sicher noch ein paar ecken netter ;-)

Stephan..Schmidt 6713 days AGO
Wicket gibt es ja schon relativ lange (2004), als dritte Generation von component based frameworks nach WebObjects und Tapestry. Siehe auch Echo2. Wer es sehr viel einfacher mag, ohne viel config und mit einer einfachen API, aber trotzdem Komponenten und Events will, kann mal Click ansehen http://click.sourceforge.org (gibt es seit 2003) (Evaluieren wir unter anderem gerade).

gavin 6713 days AGO
Just an outsider's observation.... It is interesting how the Java folk seem to be moving towards a more monolithic do-everything-in-java model. They keeping extending this model and (as Stephan alludes) simplifying & reducing as they go. (Then again--it is funny how the notion of simplicity in the Java world is to make something Swing-like.)

It is inevitable, in another few years they'll end up with something HOP-like.

Stephan..Schmidt 6713 days AGO
I still think there is no optimal solution for web frameworks. The current discussion seems to be between action (A) and event/ component (C) based frameworks, between dynamic/ guessing (G) and xml config frameworks (X). From my experience action/page based frameworks are better suited for document centric web sites with lots of text, while event/component based frameworks are better suited for web applications with lots of data. After Rails (not first to market but first-to-mind) the overall trend is towards zero config frameworks, either action or component based (Stripes and Click as newer frameworks).

Looking at other solutions like Rails (Ruby), CodeIgniter (PHP), Seaside (Smalltalk) and many others, they solve some problems quite well, but don't solve other problems at all.

Using and evaluating dozens of frameworks in the last 10 years and writing some of my own (Ruby.RO and Bebop for example) there seems to be some progress but no clear identication in what direction the best approach can be found. At least I have no clue.

Funny how from the outside there seems to be "Java folk", from the inside there is no Java folk, just a fragmented, hot, backstabbing and piranha like pool and market of frameworks and developers.

I thought in the end we would end up with Lisp :-)

chris 6712 days AGO
I still think there cannot be an optimal solution for web frameworks. ;-)

Nevertheless, the decomposition in A and C makes a lot of sense. However, I'd rather say that C-style frameworks are most useful for complex interactions (complex workflows), not necessarily "lots of data" - if you aren't doing anything complex with the data, A-style frameworks work just as fine.

Stephan..Schmidt 6711 days AGO
I meant applications with "lots of data" applications which display lots of data items compared to document centric applications. Document centric would be cms, content websites, weblogs, wikis .... Data item applications would be plane seat management software, mail clients, etc.

Yes there might be no optimal solution ;-) But we're also not at several local maximas :-)

Please log in (you may want to register first) to post comments!