You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Sean Sullivan <se...@seansullivan.com> on 2007/11/15 17:55:10 UTC
Matt Raible's ApacheCon presentation
fyi
http://raibledesigns.com/rd/entry/comparing_jvm_web_frameworks_presentation
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by Matej Knopp <ma...@gmail.com>.
On Nov 15, 2007 9:06 PM, Igor Vaynberg <ig...@gmail.com> wrote:
> for me, pros would be:
>
> trully object oriented: allows great encapsulation/extension/reuse
> code centric: easier refactoring, maintenance
> trivial component creation: awesome reuse of high level functionality
> inter/intra projects
>
> but then again i am one of those "hardcore" java developers who
> understands OO... saying a java webframework is hard to use because
> its built with java seems silly to me...
>
> cons:
>
> no default native (httpsessionbased) failover cluster strategy yet -
> coming in 1.4 right matej? by default failover only works if the user
> does not press the backbutton right after failover event
More like 1.3.1 hopefully :)
-Matej
>
> stateful/stateless support right now is not as nice as it could be -
> stateless component tree is pretty much a limited/parallel hierarchy
> of the stateful tree - that means you cannot have bookmarkable/pretty
> urls for complex pages
>
> cant think of any more right now - will think about it some more
> through the rest of the day
>
> -igor
>
>
>
>
>
>
> -igor
>
>
>
> On Nov 15, 2007 11:46 AM, Scott Swank <sc...@gmail.com> wrote:
> > You're complaining that 2 out of 3 "Cons" aren't necessarily negative? :)
> >
> > I would re-state the first of them to read that "By default HTML
> > templates live next to Java code". Is there a better way to state the
> > 2nd Pro?
> >
> >
> > On Nov 15, 2007 11:43 AM, Igor Vaynberg <ig...@gmail.com> wrote:
> > > > * HTML templates live next to Java code
> > > this is easily changed - just a default
> > >
> > > > * Need to have a good grasp of OO
> > > why is this a con? you are saying not knowing oo is a good thing? you
> > > can say this is a pro - learning wicket will make you a better
> > > developer :)
> > >
> > > > * The Wicket Way - everything done in Java
> > > as opposed to embedding logic in views which has been something
> > > plaguing other frameworks for ages?
> > >
> > > -igor
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
> >
> >
> > --
> > Scott Swank
> > reformed mathematician
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by Eelco Hillenius <ee...@gmail.com>.
> no default native (httpsessionbased) failover cluster strategy yet -
> coming in 1.4 right matej? by default failover only works if the user
> does not press the backbutton right after failover event
We have to decide how to best wrap this in projects etc, but the
cluster code worked well when I tested it with Teachscape.
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by Igor Vaynberg <ig...@gmail.com>.
for me, pros would be:
trully object oriented: allows great encapsulation/extension/reuse
code centric: easier refactoring, maintenance
trivial component creation: awesome reuse of high level functionality
inter/intra projects
but then again i am one of those "hardcore" java developers who
understands OO... saying a java webframework is hard to use because
its built with java seems silly to me...
cons:
no default native (httpsessionbased) failover cluster strategy yet -
coming in 1.4 right matej? by default failover only works if the user
does not press the backbutton right after failover event
stateful/stateless support right now is not as nice as it could be -
stateless component tree is pretty much a limited/parallel hierarchy
of the stateful tree - that means you cannot have bookmarkable/pretty
urls for complex pages
cant think of any more right now - will think about it some more
through the rest of the day
-igor
-igor
On Nov 15, 2007 11:46 AM, Scott Swank <sc...@gmail.com> wrote:
> You're complaining that 2 out of 3 "Cons" aren't necessarily negative? :)
>
> I would re-state the first of them to read that "By default HTML
> templates live next to Java code". Is there a better way to state the
> 2nd Pro?
>
>
> On Nov 15, 2007 11:43 AM, Igor Vaynberg <ig...@gmail.com> wrote:
> > > * HTML templates live next to Java code
> > this is easily changed - just a default
> >
> > > * Need to have a good grasp of OO
> > why is this a con? you are saying not knowing oo is a good thing? you
> > can say this is a pro - learning wicket will make you a better
> > developer :)
> >
> > > * The Wicket Way - everything done in Java
> > as opposed to embedding logic in views which has been something
> > plaguing other frameworks for ages?
> >
> > -igor
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
>
>
> --
> Scott Swank
> reformed mathematician
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by Scott Swank <sc...@gmail.com>.
You're complaining that 2 out of 3 "Cons" aren't necessarily negative? :)
I would re-state the first of them to read that "By default HTML
templates live next to Java code". Is there a better way to state the
2nd Pro?
On Nov 15, 2007 11:43 AM, Igor Vaynberg <ig...@gmail.com> wrote:
> > * HTML templates live next to Java code
> this is easily changed - just a default
>
> > * Need to have a good grasp of OO
> why is this a con? you are saying not knowing oo is a good thing? you
> can say this is a pro - learning wicket will make you a better
> developer :)
>
> > * The Wicket Way - everything done in Java
> as opposed to embedding logic in views which has been something
> plaguing other frameworks for ages?
>
> -igor
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Scott Swank
reformed mathematician
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by Eelco Hillenius <ee...@gmail.com>.
> Back button in ajax (so an ajax request triggers a change that then should
> be a backbutton change?)
> "Everything" on the serverside is ready for that.. Somebody just need to
> write the javascript/behavior..
> But nobody seems to really want to have that...
This is one of the things I meant that are probably open for
improvement, but are not easy to implement/ will make our internals
even more complex.
> bookmarkability in full ajax frameworks? I guess the have support for that
> but then you have
> to code that in. And we also have that thats called BookmarkableLinks..
Yeah, I guess that will always take hand work. And bookmarkability is
probably easier to achieve with Wicket in general. So that might
balance out.
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by Johan Compagner <jc...@gmail.com>.
I dont think ajax is a compromise .. Not for the kind of webframe work we
are..
We are a serverside framework. just like struts/jsf/tapestry.
I guess you compare it with full client side frameworks (gwt or echo2)
yes those are ajax through and through (they have to) But that doesn't mean
that
i call ours a compromise, we just do or use it differently.
Back button in ajax (so an ajax request triggers a change that then should
be a backbutton change?)
"Everything" on the serverside is ready for that.. Somebody just need to
write the javascript/behavior..
But nobody seems to really want to have that...
bookmarkability in full ajax frameworks? I guess the have support for that
but then you have
to code that in. And we also have that thats called BookmarkableLinks..
asynchronous server handling we also have ofcourse, what we dont have is
multply request
at the same time.. thats just our single threaded model...(can by bypassed
with resources but...)
Maybe we can relax that a bit in a next version where we can say "this ajax
request/behavior doesnt lock"
Some kind of tagging interface for an ajax behavior.. But then it is really
up to the user to be very carefull
and we as a framework also have to really look into our own page handling
code :(
Hybrid approach?
Make a (statefull) page with stateless links that have parameters...
I call that hybrid.. The page can live and will be reused, if not and you
click on that stateless link
a new page is created and the link has its state. So thats already doable.
Only the encoding of the
params is maybe a bit cumbersome.
johan
On Nov 15, 2007 10:18 PM, Eelco Hillenius <ee...@gmail.com> wrote:
> * Ajax support is a compromise. We can't really help this, and I feel
> we did/ are doing the best we can, but our Ajax support suffers from
> the fact that we're trying to support both a traditional (page based)
> and ajax approach. Particularly, back button support, bookmarkability
> and asynchronous server handling suffers. Some of this might still be
> improved in future versions, but I think we're already easily one of
> the most complex web frameworks out there when it comes to the
> internals, and these fixes are only gonna make things more difficult.
>
> * No Hybrid approach to state handling. I know many team members
> disagree here, but I've always had in my mind that the perfect
> approach to state handling would be to give users the choice between
> server managed and client managed (i.e. by passing parameters/ rest)
> on a component level. To our defense, none of our competitors support
> this either, at least not on the component level I am envisioning.
>
>
Re: Matt Raible's ApacheCon presentation
Posted by Eelco Hillenius <ee...@gmail.com>.
> Oh, and type-safe models are a must, I was surprised to read in this
> thread not everybody agrees with that. Especially since type erasure
> ensures backwards compatibility, and lets the cast-fans stick to their
> habits :-)
The problem that I have with type safe models is that in order to fit
them into Wicket, we have to make components make typed as well. And
that's not always a good fit, and makes the code a lot more verbose,
not just a little bit (at least with Java's current state of
inference). Anyway, I'm not against it really... some aspects of it
just annoy me :-)
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by Gabor Szokoli <sz...@gmail.com>.
These two are the exact same things I have in mind about wicket:
On Nov 15, 2007 10:18 PM, Eelco Hillenius <ee...@gmail.com> wrote:
> I've always had in my mind that the perfect
> approach to state handling would be to give users the choice between
> server managed and client managed (i.e. by passing parameters/ rest)
> on a component level.
Yes! Taking after the database-backed DetatchableModel, there could be
a PageParameterModel. We could use it to store the search form values
and the DefaultDataTable sort parameters and such to make application
state bookmarkable (and preferably human readable).
> * Java. I'm getting tired of Java's limitations and plain inelegance
Same here, too much academic language programming on my mind :-)
I hope I can get around to replicate and your scala-wicket experiments
in the holiday season.
Oh, and type-safe models are a must, I was surprised to read in this
thread not everybody agrees with that. Especially since type erasure
ensures backwards compatibility, and lets the cast-fans stick to their
habits :-)
Szocske
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by Eelco Hillenius <ee...@gmail.com>.
> I didn't say my cons were valid - but I do believe there *are* cons to
> Wicket. What are they - in your opinion?
You know what I think the pros are by now. I don't always feel the
same about the cons we currently have, but currently they would be:
* Ajax support is a compromise. We can't really help this, and I feel
we did/ are doing the best we can, but our Ajax support suffers from
the fact that we're trying to support both a traditional (page based)
and ajax approach. Particularly, back button support, bookmarkability
and asynchronous server handling suffers. Some of this might still be
improved in future versions, but I think we're already easily one of
the most complex web frameworks out there when it comes to the
internals, and these fixes are only gonna make things more difficult.
* No Hybrid approach to state handling. I know many team members
disagree here, but I've always had in my mind that the perfect
approach to state handling would be to give users the choice between
server managed and client managed (i.e. by passing parameters/ rest)
on a component level. To our defense, none of our competitors support
this either, at least not on the component level I am envisioning.
* Java. I'm getting tired of Java's limitations and plain inelegance
in some areas and how this sometimes makes Wicket verbose and even
inflexible. I'm starting to get very interested in languages like
Haskell, Erlang and Scala. Maybe it's just a phase I'm going through,
and I'm sure that people who hate anonymous classes would hate FP even
more ;-)
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by jweekend <jw...@cabouge.com>.
Matt,
This looks like it will be an interesting presentation.
For me, Wicket is the main reason I decided I'm happy to do a bit of Web
development. You can build applications that give you the satisfaction of
being well designed and engineered, especially if you believe that OO is
good.
A big plus for many people is the total lack of xml (apart from the
obligatory web.xml, of course). You get all the benefits of an OO, strongly
typed language and the fantastic power of the IDEs available today when you
use java to define how your application behaves.
Wicket let's you design and build good web applications the way you want to.
In essence, you are building just another plain old java application (POJA
?) and you can use all the tools and techniques that you already know make
sense for the class of software you are building.
The integration with mainstream middle-tier frameworks like Spring, Guice,
Hibernate, Acegi etc make it a breeze to develop using what you have already
decided makes good system development a better experience.
Everything I have tried just works. I would never have thought that adding
Ajax to a web app could be made to be so easy. And, on top of that, there
are excellent contributions that allow very easy and robust integration with
the likes of Google Maps, Prototype, Dojo and other useful client-side
libraries.
Custom components are an essential fact of life in real world systems. I
cannot imagine how Wicket could be bettered on this front.
The total separation of the view (html, css) from the display logic/mode
makes perfect sense to me too. If you fancy yourself as an html/css artist,
go ahead and make a good-looking/feeling app. If not, give the html/css work
to someone who knows what to do with html/css and they won't need to learn
anything else.
Everyone I know that has used Wicket seems to think it's incredibly clever,
useful and a joy to work with.
I must admit that I am a big believer in the benefits of OO, so the Wicket
development effort seemed much more natural to me than the few other
frameworks that I spent a very limited time with.
I have no doubt that some of these other frameworks have very good features,
but having started using Wicket, everything else seems like a step in the
wrong direction or at the very least, a lot harder to do what you feel is
right with. On the other hand, I don't feel I have quite enough experience
with them to make any strong statements.
I am lucky to work with Java 5. This goes well with Wicket, even though it
is still 1.4 compliant. I am looking forward to the next version, ported to
1.5, with genericised Wicket Models adding to the quality of the development
experience.
The documentation is not the best, but it seems to be improving all the time
and I know for a fact that this will get more attention soon. There are
already excellent examples to help you get going and that cover/illustrate
pretty much all of Wicket's features.
Finally, don't under-estimate the value of this mailing-list. It is full of
very bright and helpful people who will assist with any problem you post
about. And, you will usually get this help, and sometimes an interesting,
thought provoking and instructional discussion brewing, within minutes.
I hope your presentation goes well.
Regards - Cemal
http://jWeekend.co.uk http://jWeekend.co.uk
mraible wrote:
>
> I didn't say my cons were valid - but I do believe there *are* cons to
> Wicket. What are they - in your opinion?
>
> matt
>
>
> igor.vaynberg wrote:
>>
>>> * HTML templates live next to Java code
>> this is easily changed - just a default
>>
>>> * Need to have a good grasp of OO
>> why is this a con? you are saying not knowing oo is a good thing? you
>> can say this is a pro - learning wicket will make you a better
>> developer :)
>>
>>> * The Wicket Way - everything done in Java
>> as opposed to embedding logic in views which has been something
>> plaguing other frameworks for ages?
>>
>> -igor
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Matt-Raible%27s-ApacheCon-presentation-tf4815955.html#a13781901
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by Nino Saturnino Martinez Vazquez Wael <ni...@jayway.dk>.
I'll do that if what I want todo makes any sense..
regards Nino
Johan Compagner wrote:
> If you have patches that made our WicketTester better please add them to
> jira.
>
> johan
>
>
>
> On Nov 16, 2007 10:24 AM, Nino Saturnino Martinez Vazquez Wael <
> nino.martinez@jayway.dk> wrote:
>
>
>> I totally agree.
>>
>> Wicket has made me a better developer. It actually makes you think in a
>> more OO way, comming from .net and jsp back in the day.
>>
>> Comming from jsp and somewhat .net I had somewhat a hard time to grasp
>> the concept of models and the fact that wicket maintains whats selected
>> in the ui for you. However this has todo with changing mindsets(years
>> of bad practice with JSP) and not so much wicket itself. After passing
>> that boundary, learning curve decreased.
>>
>> A great pro for me are that wicket are opensource, this means that I can
>> see how developers do their programming. If im in doubt about something
>> i just look in the source.
>>
>> A possible con are that the testing part of wicket could be improved by
>> having more convenince methods. Also there seems to be some trouble
>> testing if you use spring injection for your beans.
>>
>> It's "pretty" hard doing stuff with the tester if you go beyond just
>> selecting things, if you want to verify what the model contains. I could
>> look into this, in fact I've been thinking about creating a wicket stuff
>> project for this.
>>
>> Thats what I could think of right now.
>>
>>
>> No matter what, I think wicket are great. And the devs are doing a GREAT
>> job.
>>
>>
>> regards Nino
>>
>> Eelco Hillenius wrote:
>>
>>> On Nov 15, 2007 12:48 PM, Eelco Hillenius <ee...@gmail.com>
>>>
>> wrote:
>>
>>>> On Nov 15, 2007 12:27 PM, Gwyn Evans <gw...@gmail.com> wrote:
>>>>
>>>>
>>>>> I think that I'd have to say that the main cons are:-
>>>>>
>>>>> (a) It does demand a certain level of OO coding, in terms of being
>>>>> happy to override classes & typically to be able to create anonymous
>>>>> classes - not a huge amount, but coders grounded in procedural code
>>>>> will feel lost.
>>>>>
>>>>>
>>>> I'm in the camp who doesn't think that is an example.
>>>>
>>>>
>>> Ugh. I meant disadvantage, not 'example'.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>>
>> --
>> Nino Martinez Wael
>> Java Specialist @ Jayway DK
>> http://www.jayway.dk
>> +45 2936 7684
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
>
--
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by Johan Compagner <jc...@gmail.com>.
If you have patches that made our WicketTester better please add them to
jira.
johan
On Nov 16, 2007 10:24 AM, Nino Saturnino Martinez Vazquez Wael <
nino.martinez@jayway.dk> wrote:
> I totally agree.
>
> Wicket has made me a better developer. It actually makes you think in a
> more OO way, comming from .net and jsp back in the day.
>
> Comming from jsp and somewhat .net I had somewhat a hard time to grasp
> the concept of models and the fact that wicket maintains whats selected
> in the ui for you. However this has todo with changing mindsets(years
> of bad practice with JSP) and not so much wicket itself. After passing
> that boundary, learning curve decreased.
>
> A great pro for me are that wicket are opensource, this means that I can
> see how developers do their programming. If im in doubt about something
> i just look in the source.
>
> A possible con are that the testing part of wicket could be improved by
> having more convenince methods. Also there seems to be some trouble
> testing if you use spring injection for your beans.
>
> It's "pretty" hard doing stuff with the tester if you go beyond just
> selecting things, if you want to verify what the model contains. I could
> look into this, in fact I've been thinking about creating a wicket stuff
> project for this.
>
> Thats what I could think of right now.
>
>
> No matter what, I think wicket are great. And the devs are doing a GREAT
> job.
>
>
> regards Nino
>
> Eelco Hillenius wrote:
> > On Nov 15, 2007 12:48 PM, Eelco Hillenius <ee...@gmail.com>
> wrote:
> >
> >> On Nov 15, 2007 12:27 PM, Gwyn Evans <gw...@gmail.com> wrote:
> >>
> >>> I think that I'd have to say that the main cons are:-
> >>>
> >>> (a) It does demand a certain level of OO coding, in terms of being
> >>> happy to override classes & typically to be able to create anonymous
> >>> classes - not a huge amount, but coders grounded in procedural code
> >>> will feel lost.
> >>>
> >> I'm in the camp who doesn't think that is an example.
> >>
> >
> > Ugh. I meant disadvantage, not 'example'.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> --
> Nino Martinez Wael
> Java Specialist @ Jayway DK
> http://www.jayway.dk
> +45 2936 7684
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Matt Raible's ApacheCon presentation
Posted by Nino Saturnino Martinez Vazquez Wael <ni...@jayway.dk>.
Reading through all the responses on this thread, I can already see that
all the fundemental things in wicket I now take for granted forexample
as debugging. I guess I would have a hard time doing anything else by now.
regards Nino
Nino Saturnino Martinez Vazquez Wael wrote:
> I totally agree.
>
> Wicket has made me a better developer. It actually makes you think in
> a more OO way, comming from .net and jsp back in the day.
>
> Comming from jsp and somewhat .net I had somewhat a hard time to grasp
> the concept of models and the fact that wicket maintains whats
> selected in the ui for you. However this has todo with changing
> mindsets(years of bad practice with JSP) and not so much wicket
> itself. After passing that boundary, learning curve decreased.
>
> A great pro for me are that wicket are opensource, this means that I
> can see how developers do their programming. If im in doubt about
> something i just look in the source.
>
> A possible con are that the testing part of wicket could be improved
> by having more convenince methods. Also there seems to be some trouble
> testing if you use spring injection for your beans.
>
> It's "pretty" hard doing stuff with the tester if you go beyond just
> selecting things, if you want to verify what the model contains. I
> could look into this, in fact I've been thinking about creating a
> wicket stuff project for this.
>
> Thats what I could think of right now.
>
>
> No matter what, I think wicket are great. And the devs are doing a
> GREAT job.
>
>
> regards Nino
>
> Eelco Hillenius wrote:
>> On Nov 15, 2007 12:48 PM, Eelco Hillenius <ee...@gmail.com>
>> wrote:
>>
>>> On Nov 15, 2007 12:27 PM, Gwyn Evans <gw...@gmail.com> wrote:
>>>
>>>> I think that I'd have to say that the main cons are:-
>>>>
>>>> (a) It does demand a certain level of OO coding, in terms of being
>>>> happy to override classes & typically to be able to create anonymous
>>>> classes - not a huge amount, but coders grounded in procedural code
>>>> will feel lost.
>>>>
>>> I'm in the camp who doesn't think that is an example.
>>>
>>
>> Ugh. I meant disadvantage, not 'example'.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
--
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by Nino Saturnino Martinez Vazquez Wael <ni...@jayway.dk>.
Nino Saturnino Martinez Vazquez Wael wrote:
> @jdave I think it would be an option(I dont think I can go back to 1.4
> ever and hope I dont have to), however I'd like to see more
> convenience methods.. Why arent it mentioned on the wiki page or
> somewhere else?
>
> @Spring problems
> Did not know that.. Thanks :)
>
> @Pretty hard doing stuff with the tester
> if I have to compare lists for example, I might have a component that
> should show something based on a filter. So to test it I need to get a
> list based on the filter in the tester, and compare that to the list.
> I think it would be nice to be able to do this directly..
>
> Example :
> wicketTester.assertEqualsListViewCompareToListFromLastPage(String id,
> List list)
>
> Stuff like that. Might just be me who's stuck, has been known to
> happen before..
>
> Also I have not found a method to unselect from checkboxes or
> dropdowns, I've tried setting models to null etc but its ugly compared
> to the convenice methods for selecting and does not seem to work?
Of course I meant modelObjects above...
>
>
> Timo Rantalaiho wrote:
>> On Fri, 16 Nov 2007, Nino Saturnino Martinez Vazquez Wael wrote:
>>
>>> A possible con are that the testing part of wicket could be improved
>>> by having more convenince methods. Also there seems to be some
>>> trouble testing if you use spring injection for your beans.
>>>
>>
>> jdave-wicket has more convenience methods if that's an
>> option for you.
>>
>> But what trouble have you run into with Spring beans? We instantiate
>> a MockApplicationContext and feed it to the
>> SpringComponentInstantiationListener of the Application
>> that WicketTester uses, and @SpringBeans just work.
>>
>>
>>> It's "pretty" hard doing stuff with the tester if you go beyond just
>>> selecting things, if you want to verify what the model contains. I
>>> could
>>
>> Again this sounds strange to me.
>>
>> You can just get the component you want and ask it, e.g.
>>
>>
>> wicketTester.getComponentFromLastRenderedPage("name").getModelObject().equals("Frank")
>>
>>
>> Best wishes,
>> Timo
>>
>>
>
--
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by Nino Saturnino Martinez Vazquez Wael <ni...@jayway.dk>.
@jdave I think it would be an option(I dont think I can go back to 1.4
ever and hope I dont have to), however I'd like to see more convenience
methods.. Why arent it mentioned on the wiki page or somewhere else?
@Spring problems
Did not know that.. Thanks :)
@Pretty hard doing stuff with the tester
if I have to compare lists for example, I might have a component that
should show something based on a filter. So to test it I need to get a
list based on the filter in the tester, and compare that to the list. I
think it would be nice to be able to do this directly..
Example :
wicketTester.assertEqualsListViewCompareToListFromLastPage(String id,
List list)
Stuff like that. Might just be me who's stuck, has been known to happen
before..
Also I have not found a method to unselect from checkboxes or dropdowns,
I've tried setting models to null etc but its ugly compared to the
convenice methods for selecting and does not seem to work?
Timo Rantalaiho wrote:
> On Fri, 16 Nov 2007, Nino Saturnino Martinez Vazquez Wael wrote:
>
>> A possible con are that the testing part of wicket could be improved by
>> having more convenince methods. Also there seems to be some trouble
>> testing if you use spring injection for your beans.
>>
>
> jdave-wicket has more convenience methods if that's an
> option for you.
>
> But what trouble have you run into with Spring beans? We
> instantiate a MockApplicationContext and feed it to the
> SpringComponentInstantiationListener of the Application
> that WicketTester uses, and @SpringBeans just work.
>
>
>> It's "pretty" hard doing stuff with the tester if you go beyond just
>> selecting things, if you want to verify what the model contains. I could
>>
>
> Again this sounds strange to me.
>
> You can just get the component you want and ask it, e.g.
>
> wicketTester.getComponentFromLastRenderedPage("name").getModelObject().equals("Frank")
>
> Best wishes,
> Timo
>
>
--
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by Timo Rantalaiho <Ti...@ri.fi>.
On Fri, 16 Nov 2007, Nino Saturnino Martinez Vazquez Wael wrote:
> A possible con are that the testing part of wicket could be improved by
> having more convenince methods. Also there seems to be some trouble
> testing if you use spring injection for your beans.
jdave-wicket has more convenience methods if that's an
option for you.
But what trouble have you run into with Spring beans? We
instantiate a MockApplicationContext and feed it to the
SpringComponentInstantiationListener of the Application
that WicketTester uses, and @SpringBeans just work.
> It's "pretty" hard doing stuff with the tester if you go beyond just
> selecting things, if you want to verify what the model contains. I could
Again this sounds strange to me.
You can just get the component you want and ask it, e.g.
wicketTester.getComponentFromLastRenderedPage("name").getModelObject().equals("Frank")
Best wishes,
Timo
--
Timo Rantalaiho
Reaktor Innovations Oy <URL: http://www.ri.fi/ >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by Nino Saturnino Martinez Vazquez Wael <ni...@jayway.dk>.
I totally agree.
Wicket has made me a better developer. It actually makes you think in a
more OO way, comming from .net and jsp back in the day.
Comming from jsp and somewhat .net I had somewhat a hard time to grasp
the concept of models and the fact that wicket maintains whats selected
in the ui for you. However this has todo with changing mindsets(years
of bad practice with JSP) and not so much wicket itself. After passing
that boundary, learning curve decreased.
A great pro for me are that wicket are opensource, this means that I can
see how developers do their programming. If im in doubt about something
i just look in the source.
A possible con are that the testing part of wicket could be improved by
having more convenince methods. Also there seems to be some trouble
testing if you use spring injection for your beans.
It's "pretty" hard doing stuff with the tester if you go beyond just
selecting things, if you want to verify what the model contains. I could
look into this, in fact I've been thinking about creating a wicket stuff
project for this.
Thats what I could think of right now.
No matter what, I think wicket are great. And the devs are doing a GREAT
job.
regards Nino
Eelco Hillenius wrote:
> On Nov 15, 2007 12:48 PM, Eelco Hillenius <ee...@gmail.com> wrote:
>
>> On Nov 15, 2007 12:27 PM, Gwyn Evans <gw...@gmail.com> wrote:
>>
>>> I think that I'd have to say that the main cons are:-
>>>
>>> (a) It does demand a certain level of OO coding, in terms of being
>>> happy to override classes & typically to be able to create anonymous
>>> classes - not a huge amount, but coders grounded in procedural code
>>> will feel lost.
>>>
>> I'm in the camp who doesn't think that is an example.
>>
>
> Ugh. I meant disadvantage, not 'example'.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by Eelco Hillenius <ee...@gmail.com>.
On Nov 15, 2007 12:48 PM, Eelco Hillenius <ee...@gmail.com> wrote:
> On Nov 15, 2007 12:27 PM, Gwyn Evans <gw...@gmail.com> wrote:
> > I think that I'd have to say that the main cons are:-
> >
> > (a) It does demand a certain level of OO coding, in terms of being
> > happy to override classes & typically to be able to create anonymous
> > classes - not a huge amount, but coders grounded in procedural code
> > will feel lost.
>
> I'm in the camp who doesn't think that is an example.
Ugh. I meant disadvantage, not 'example'.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by Eelco Hillenius <ee...@gmail.com>.
On Nov 15, 2007 12:27 PM, Gwyn Evans <gw...@gmail.com> wrote:
> I think that I'd have to say that the main cons are:-
>
> (a) It does demand a certain level of OO coding, in terms of being
> happy to override classes & typically to be able to create anonymous
> classes - not a huge amount, but coders grounded in procedural code
> will feel lost.
I'm in the camp who doesn't think that is an example. In fact, the big
pro of this is that you'll have your developers practice more with OO
so Wicket might even make them better coders.
It seems to be very specific for the Java (and possibly .NET) crowd as
well. I don't think ErlyWeb to name one gets criticized for requiring
it's users to know Erlang.
> (b) The documention is scattered - partly because there are so many
> ways that it can go beyond the basic web-page (i.e. page inheritance,
> panels/fragments, embeded forms, built-in AJAX, security, etc,) that
> not much short of an encylopedia could do it justice!
Documentation will always be something that can be improved. What's
new? Even with projects like Hibernate it is sometimes hard to find
exactly what you want, and about 90% of open source projects hardly
have any documentation.
Anyway, it would be great to have a single tutorial that stands out
from the rest of the web site to get people going. Someone just has to
pick this up again and feel responsible for it. Also, the fact that
Martijn and I are writing Wicket In Action is to provide more
documentation. So we are working on improving it.
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by Gwyn Evans <gw...@gmail.com>.
I think that I'd have to say that the main cons are:-
(a) It does demand a certain level of OO coding, in terms of being
happy to override classes & typically to be able to create anonymous
classes - not a huge amount, but coders grounded in procedural code
will feel lost.
(b) The documention is scattered - partly because there are so many
ways that it can go beyond the basic web-page (i.e. page inheritance,
panels/fragments, embeded forms, built-in AJAX, security, etc,) that
not much short of an encylopedia could do it justice!
/Gwyn
On 15/11/2007, mraible <ma...@raibledesigns.com> wrote:
>
> I didn't say my cons were valid - but I do believe there *are* cons to
> Wicket. What are they - in your opinion?
>
> matt
>
>
> igor.vaynberg wrote:
> >
> >> * HTML templates live next to Java code
> > this is easily changed - just a default
> >
> >> * Need to have a good grasp of OO
> > why is this a con? you are saying not knowing oo is a good thing? you
> > can say this is a pro - learning wicket will make you a better
> > developer :)
> >
> >> * The Wicket Way - everything done in Java
> > as opposed to embedding logic in views which has been something
> > plaguing other frameworks for ages?
> >
> > -igor
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Matt-Raible%27s-ApacheCon-presentation-tf4815955.html#a13780519
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Download Wicket 1.3.0-rc1 now! - http://wicketframework.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by Jonathan Locke <jo...@gmail.com>.
yeah, i'm afraid i agree with you now. ;-)
oh well. hindsight is 20/20. otoh, if this is some of the biggest stuff
we can find to complain about, i think we did pretty damn well.
Johan Compagner wrote:
>
> On Nov 16, 2007 8:21 AM, Jonathan Locke <jo...@gmail.com> wrote:
>
>>
>>
>> - the api surface area /is/ a little bigger than it would ideally be. i
>> wish i had stayed
>> more on top of this. fighting to remove stuff and shrink the api is
>> half
>> the
>> battle of making a framework. there are even a number of things i put
>> in
>> there myself that i now regret. you want expressive completeness, but
>> you
>
>
> HA :)
> i just wanted to yell out.. what is jonathan telling me now.....
> Why for example all those ugly helper method on component?
> (like some urlFor, setRedirect, setResponsePage)
> I never liked them.. But i know somebody did (wink, wink) ;)
>
> Ok they are handy, but they really bloated up component..
> Those methods are pretty much the same thing a static imports.. (also a
> horrible thing if you ask me)
>
> johan
>
>
--
View this message in context: http://www.nabble.com/Matt-Raible%27s-ApacheCon-presentation-tf4815955.html#a13798299
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by Johan Compagner <jc...@gmail.com>.
On Nov 16, 2007 8:21 AM, Jonathan Locke <jo...@gmail.com> wrote:
>
>
> - the api surface area /is/ a little bigger than it would ideally be. i
> wish i had stayed
> more on top of this. fighting to remove stuff and shrink the api is
> half
> the
> battle of making a framework. there are even a number of things i put
> in
> there myself that i now regret. you want expressive completeness, but
> you
HA :)
i just wanted to yell out.. what is jonathan telling me now.....
Why for example all those ugly helper method on component?
(like some urlFor, setRedirect, setResponsePage)
I never liked them.. But i know somebody did (wink, wink) ;)
Ok they are handy, but they really bloated up component..
Those methods are pretty much the same thing a static imports.. (also a
horrible thing if you ask me)
johan
Re: Matt Raible's ApacheCon presentation
Posted by Jonathan Locke <jo...@gmail.com>.
it might almost go without saying that i don't agree with these particular
cons.
html templates live next to java code because they are conceptually related
and so it makes sense to encapsulate them in the same package. what never
made sense to me was the other way of doing it. requiring a good grasp of
OO
means wicket is actually a pretty good litmus test for determining who not
to
hire. separation of markup from code is important to designers and coders.
i have been able to work alongside with a designer for months and the work
is so seamless that we often go for days or even weeks without
communicating.
because of the split it's just not necessary. this saves a lot of time and
hassle.
i do agree there are cons to wicket for certain specific kinds of jobs.
there are
also imperfections that come to mind. but for anything that falls fairly
strongly
into the category of "web application" and is not something closer to
"static site",
i find few if any mentionable cons in using wicket day-to-day. of course, i
/could/
be biased since wicket was originally designed to serve my own needs.
cons
- if you are not really building a web /application/, but are either doing
a quickie
prototype of something or you are writing something that is more like a
static
web site with a few dynamic bits, wicket may be overkill. you might
prefer
something like freemarker or ROR. if you plan to scale and maintain a
web
application with any real complexity, however, wicket wins in my book.
flaws
- the api surface area /is/ a little bigger than it would ideally be. i
wish i had stayed
more on top of this. fighting to remove stuff and shrink the api is half
the
battle of making a framework. there are even a number of things i put in
there myself that i now regret. you want expressive completeness, but
you
also want minimality because you ideally want an api to guide people to a
single
right answer rather than leaving them feeling like they are swimming in
options.
one way of minimizing the api surface area is to hide things in objects.
this makes
it implicitly clear how to find them based on their location. the
competing need is
to make things expressive. there are a number of methods in Component in
particular which are in the gray zone between the need to be expressive
and the
need to minimize the surface area. quite a few of these methods were
guesses
as to what people would do a lot. i regret making some of those guesses.
in the
future, i would err on the side of minimality and add convenience methods
based
on actual use cases and consistency instead of trying to predict usage.
- wicket currently lacks support for generics. i know there are people on
our core
team who don't like generics because they are verbose, but i disagree
with this
view. this is a con i would like to see corrected in the next version.
people who
don't want more type safety can turn off the compiler warnings. of
course,
compared with most other frameworks, the fact that wicket has any type
safety
at all is a major pro.
- the documentation and examples are scattered and sometimes out of date.
we
simply have not had the resources to deal with these problems. there
have always
been far more important things to deal with - things that affect shipping
applications -
to really focus on this. it's an unfortunate situation, but not
something i'd personally
list as a con because the ##wicket irc channel and the wicket-user list
more than
make up for this lacking. given the choice, i'd rather have wicket-user
and no docs
at all than great docs and no personal help from experts.
- you can get bitten by serialization if you are not careful with anonymous
classes.
this is more of a java flaw though and i have submitted a request for
static anonymous
classes to sun.
- eelco's right. java is getting annoying in its limitations. there are a
lot of things
we could do in wicket to improve the api that we simply can't do because
of java.
- i would still like to see a wicket container that eliminates the servlet
API entirely and
creates a zero-config environment with high performance clustering. this
is, of course,
a fairly major project with no financial payoff.
mraible wrote:
>
> I didn't say my cons were valid - but I do believe there *are* cons to
> Wicket. What are they - in your opinion?
>
> matt
>
>
> igor.vaynberg wrote:
>>
>>> * HTML templates live next to Java code
>> this is easily changed - just a default
>>
>>> * Need to have a good grasp of OO
>> why is this a con? you are saying not knowing oo is a good thing? you
>> can say this is a pro - learning wicket will make you a better
>> developer :)
>>
>>> * The Wicket Way - everything done in Java
>> as opposed to embedding logic in views which has been something
>> plaguing other frameworks for ages?
>>
>> -igor
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Matt-Raible%27s-ApacheCon-presentation-tf4815955.html#a13788209
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by Nick Heudecker <nh...@gmail.com>.
In my opinion, Wicket's cons evolve over time, as your experience with the
framework increases. An early con I ran into was simply the size of the
framework - Wicket has a large API. Once I understood where things were and
how they were structured, the size of the framework wasn't a problem.
Coming from a heavy Struts background, I was a little surprised to find
myself so insulated from the servlet APIs. You still have access if you
need it, but you rarely do. Not really a con, more of a function of how
Wicket works. (One side effect of not needing access to the servlet API is
applications feel less like a collection of hacks and more like
engineering.)
Understanding models and state within Wicket also took some time, but I
think that's mostly because of how much Struts development I suffered
through. Had I done any Swing development, I'm sure getting my head around
models would've been easier.
Now that I've used Wicket for a while, one problem I run into is not quite
being able to customize things like I'd wish without duplicating existing
framework code. However, the developers are pretty good about entertaining
my (often inane) requests.
Your comment about needing a good grasp of OOP makes sense in only one
regard - it's harder to find great talent. Being able to flex some
development muscle results in tighter code, more reuse and it's much more
fun.
Honestly, I don't find many cons when developing with Wicket. What you
might call cons I call framework inexperience.
On Nov 15, 2007 1:56 PM, mraible <ma...@raibledesigns.com> wrote:
>
> I didn't say my cons were valid - but I do believe there *are* cons to
> Wicket. What are they - in your opinion?
>
> matt
>
>
> igor.vaynberg wrote:
> >
> >> * HTML templates live next to Java code
> > this is easily changed - just a default
> >
> >> * Need to have a good grasp of OO
> > why is this a con? you are saying not knowing oo is a good thing? you
> > can say this is a pro - learning wicket will make you a better
> > developer :)
> >
> >> * The Wicket Way - everything done in Java
> > as opposed to embedding logic in views which has been something
> > plaguing other frameworks for ages?
> >
> > -igor
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Matt-Raible%27s-ApacheCon-presentation-tf4815955.html#a13780519
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Nick Heudecker
Professional Wicket Training & Consulting
http://www.systemmobile.com
Eventful - Intelligent Event Management
http://www.eventfulhq.com
RE: Matt Raible's ApacheCon presentation
Posted by Maeder Thomas <th...@ecofin.ch>.
One BIG plus that I haven't seen mentioned is debuggability. A wicket
application is almost as easy to debug as a regular application. For one
thing the error messages are really great. 90% of the time the nail the
problem. But the biggest plus is that the whole control flow is just in
regular Java classes. No excursions into the templating engine, no
reflection magic, just good ole Java code you actually have half a
chance of debugging.
Jonathan has mentioned that the API footprint is bigger than he would
like (you started to sound a bit like Steve Northover, there, by the
way; scary! ;-). But I find that wicket actually has a very small
footprint compared to other frameworks, because wicket is all there is.
No templating engine, no bytcode manipulation framework, no expression
language you have to know. I can understand wicket top to bottom. Sweet!
Thomas
> -----Original Message-----
> From: mraible [mailto:matt@raibledesigns.com]
> Sent: Donnerstag, 15. November 2007 20:57
> To: users@wicket.apache.org
> Subject: Re: Matt Raible's ApacheCon presentation
>
>
> I didn't say my cons were valid - but I do believe there
> *are* cons to Wicket. What are they - in your opinion?
>
> matt
>
>
> igor.vaynberg wrote:
> >
> >> * HTML templates live next to Java code
> > this is easily changed - just a default
> >
> >> * Need to have a good grasp of OO
> > why is this a con? you are saying not knowing oo is a good
> thing? you
> > can say this is a pro - learning wicket will make you a better
> > developer :)
> >
> >> * The Wicket Way - everything done in Java
> > as opposed to embedding logic in views which has been something
> > plaguing other frameworks for ages?
> >
> > -igor
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Matt-Raible%27s-ApacheCon-presentation-t
f4815955.html#a13780519
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by mraible <ma...@raibledesigns.com>.
I didn't say my cons were valid - but I do believe there *are* cons to
Wicket. What are they - in your opinion?
matt
igor.vaynberg wrote:
>
>> * HTML templates live next to Java code
> this is easily changed - just a default
>
>> * Need to have a good grasp of OO
> why is this a con? you are saying not knowing oo is a good thing? you
> can say this is a pro - learning wicket will make you a better
> developer :)
>
>> * The Wicket Way - everything done in Java
> as opposed to embedding logic in views which has been something
> plaguing other frameworks for ages?
>
> -igor
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Matt-Raible%27s-ApacheCon-presentation-tf4815955.html#a13780519
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by Igor Vaynberg <ig...@gmail.com>.
> * HTML templates live next to Java code
this is easily changed - just a default
> * Need to have a good grasp of OO
why is this a con? you are saying not knowing oo is a good thing? you
can say this is a pro - learning wicket will make you a better
developer :)
> * The Wicket Way - everything done in Java
as opposed to embedding logic in views which has been something
plaguing other frameworks for ages?
-igor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by Johan Compagner <jc...@gmail.com>.
>
> Cons:
> - steep learning curve
this really depends where you coming from.
For me wicket is simple, it feels natural.
Struts for example never did that for me.
Also tapestry that came close for me. But it still did itches.. still though
yeah close but not quite there.
Of course you need to learn API. And our api is not 10 classes thats true.
But in the end it is not that many: Page/Component, IModel, IBehavior ,
IValidatior, IConverter..
We only have many implementations of them :)
>
> - not a standard (this hinders adoption because of
> bureaucratic and/or political reasons, though is bound to
> give technical advantage. Think JPA annotations vs
> Hibernate annotations)
But a standard has again other drawbacks.. Can you move fast forward?
>
> - newness, which shows in API instability (2.0 branch,
My guess is that with 1.3 we have settles large parts of the api.
For example the IModel/IBehavior/IValidator/IConverter are pretty stable at
least for the next version
>
> hopefully getting resolved) and lack of recommended
> practices (AJAX refresh srategies, chaining multiple
> behaviors, editing Hibernate-persisted data, ...)
Chaining multiply behaviors is on my todo for the next version.
And what does have Hibernate-persisted data to do with wicket? Wicket (the
core) is a WebFramework
that only gives you options (like LoadableDetachableModel) for using
persisted data.
johan
Re: Matt Raible's ApacheCon presentation
Posted by Timo Rantalaiho <Ti...@ri.fi>.
On Thu, 15 Nov 2007, mraible wrote:
> FWIW, I'd like to replace the pros and cons (my opinions) with some that are
> more accurate. As users of Wicket, I'd love to hear from you and get your
> opinions on the top 3 pros and cons of Wicket.
Pros:
- excellent markup previewability and separation of concerns
- excellent testability (easy to get high developer testing
coverage for UI code)
- easy to add AJAX functionality with no or little
Javascripting
- programming is done in java, not in XML or HTML
Cons:
- steep learning curve
- not a standard (this hinders adoption because of
bureaucratic and/or political reasons, though is bound to
give technical advantage. Think JPA annotations vs
Hibernate annotations)
- newness, which shows in API instability (2.0 branch,
hopefully getting resolved) and lack of recommended
practices (AJAX refresh srategies, chaining multiple
behaviors, editing Hibernate-persisted data, ...)
We need better programming, not ways to make implementing
bad design more easily.
After having used Wicket for a year I don't want to go back.
Best wishes,
Timo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by Martijn Dashorst <ma...@gmail.com>.
Now that you have gotten a ton of feedback, I'm interested in if and how you
adjusted your pros and cons. And of course how the presentation went.
Martijn
On Nov 15, 2007 8:35 PM, mraible <ma...@raibledesigns.com> wrote:
>
> FWIW, I'd like to replace the pros and cons (my opinions) with some that
> are
> more accurate. As users of Wicket, I'd love to hear from you and get your
> opinions on the top 3 pros and cons of Wicket.
>
> Here's the ones I currently have:
>
> Pros:
>
> * Great for Java developers, not web developers
> * Tight binding between pages and views
> * Active community - support from the creators
>
> Cons:
>
> * HTML templates live next to Java code
> * Need to have a good grasp of OO
> * The Wicket Way - everything done in Java
>
> IMO, there's no need to debate whether these are valid or not. If they're
> not - please suggest new ones. James Ward of Flex had a nice and honest
> comment this morning pointing out Flex's cons:
>
> http://tinyurl.com/yvybnm
>
> Thanks,
>
> Matt
>
>
> Sean Sullivan-3 wrote:
> >
> > fyi
> >
> >
> http://raibledesigns.com/rd/entry/comparing_jvm_web_frameworks_presentation
> >
>
> --
> View this message in context:
> http://www.nabble.com/Matt-Raible%27s-ApacheCon-presentation-tf4815955.html#a13780071
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0-rc1 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-rc1/
Re: Matt Raible's ApacheCon presentation
Posted by John Krasnay <jo...@krasnay.ca>.
On Fri, Nov 16, 2007 at 09:54:39AM -0800, Curtis Cooley wrote:
> Michael Laccetti wrote:
> > John Krasnay wrote:
> >> To me this is the biggest con. I've worked with a number of Java devs
> >> who have trouble grokking anonymous inner classes, which you must know
> >> cold to be effective with Wicket.
> >
> > Quite a con indeed. Wicket is not a framework that most people new to
> > Java/OO can easily jump into and start churning out apps with. This
> > ties together with the concept of models, and figuring out which is
> > the right for the situation. There is no easy answer, it is more of
> > an instinctive "feel" that you get over time.
> >
> > It is inherently worse for people that were Struts devs. It took me a
> > while to unlearn my view of the world.
> >
> You have to know OO and grok anonymous inner classes to program in Swing
> and you have to know OO to program in SWT, so why wouldn't you need to
> know OO to program a web framework. If you're going to be a Java
> programmer, then learn OO. If you don't want to learn OO, then write
> .NET and get used to maintenance hell.
>
On second thought, you're right. Listing this as a Wicket con is a bit
like saying "Your team may not be smart enough to use Wicket," which I
don't think would go over very well at Matt's presentation.
jk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by Curtis Cooley <cu...@venture.com.sg>.
Michael Laccetti wrote:
> John Krasnay wrote:
>> To me this is the biggest con. I've worked with a number of Java devs
>> who have trouble grokking anonymous inner classes, which you must know
>> cold to be effective with Wicket.
>
> Quite a con indeed. Wicket is not a framework that most people new to
> Java/OO can easily jump into and start churning out apps with. This
> ties together with the concept of models, and figuring out which is
> the right for the situation. There is no easy answer, it is more of
> an instinctive "feel" that you get over time.
>
> It is inherently worse for people that were Struts devs. It took me a
> while to unlearn my view of the world.
>
You have to know OO and grok anonymous inner classes to program in Swing
and you have to know OO to program in SWT, so why wouldn't you need to
know OO to program a web framework. If you're going to be a Java
programmer, then learn OO. If you don't want to learn OO, then write
.NET and get used to maintenance hell.
Re: Matt Raible's ApacheCon presentation
Posted by Michael Laccetti <mi...@s2g.ca>.
John Krasnay wrote:
> To me this is the biggest con. I've worked with a number of Java devs
> who have trouble grokking anonymous inner classes, which you must know
> cold to be effective with Wicket.
Quite a con indeed. Wicket is not a framework that most people new to Java/OO can easily jump into and start churning out apps with. This ties together with the concept of models, and figuring out which is the right for the situation. There is no easy answer, it is more of an instinctive "feel" that you get over time.
It is inherently worse for people that were Struts devs. It took me a while to unlearn my view of the world.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by John Krasnay <jo...@krasnay.ca>.
On Thu, Nov 15, 2007 at 11:35:02AM -0800, mraible wrote:
>
> Pros:
>
> * Great for Java developers, not web developers
Not sure here who you mean by "web developers". If you mean HTML
slingers I would think the absence of taglibs and logic in the templates
would be an advantage.
> * Tight binding between pages and views
Not sure what this means either, but it sounds bad!
The biggest pros for me are as follows:
* Easy to build re-usable components
* Components can be packaged as simple JARs
> Cons:
>
> * HTML templates live next to Java code
I think this is a pro. Not only does it encourage logical organization
(just like Java source in directories and files named after the class
names), but it is key to being able to package components into JARs.
> * Need to have a good grasp of OO
To me this is the biggest con. I've worked with a number of Java devs
who have trouble grokking anonymous inner classes, which you must know
cold to be effective with Wicket.
> * The Wicket Way - everything done in Java
...as opposed to some things in Java, some things with taglibs,
some things with Velocity/FreeMarker control structures, and the rest in
XML? Sure sounds like a pro to me.
jk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by Johan Compagner <jc...@gmail.com>.
>
> * Not stateless (i'm talking about the stable 1.2 here)
thats not a con anymore because 1.3 is pretty good now in that area.
>
> * Too much alternatives to do quite the same things (markup inheritance vs
> borders; passing component's constructors models, full objects or even
> components; ListView vs DataView vs GridView ...)
thats just evolution.. But i guess we should document exactly what to use
when (or best to use for..)
But i agree to much choice ís bad.. (this is pretty much valid for anything)
>
> * TOO MUCH JAVA and too component oriented: in fact on some pages you need
> to create some components (panels, fragment, or inner classes) to write
> maintenable code whereas these components will never be reused elsewhere.
> In
> general you need some effort and focus to produce maintenable code on not
> so
> complex pages / components, this is my biggest con.
Dont believe in to much java, i believe in to much xml or to much code
inside places where it doesnt belonge.
Java code is easy to read and type and compile save. Maybe a bit to verbose
at some time
But sun is fixing that i think (java 7)
johan
Re: Matt Raible's ApacheCon presentation
Posted by Igor Vaynberg <ig...@gmail.com>.
public class QuickLinkPropertyColumn {
protected abstract void onClick();
public Link createLink(final Item item, String componentId, final
IModel model) {
return new Link(componentId) { public void onClick() {
QuickLinkPropertyColumn.this.onClick()}}
then all you have is
columns.add(new QuickLinkPropertyColumn("foo","bar") { void onClick()
{ dowhatever(); }});
is that too much code?
-igor
On Nov 15, 2007 8:40 PM, Joe Toth <jo...@gmail.com> wrote:
> I agree with the "Too much java" statement. Sometimes you have to
> create a bunch of stuff that would be a lot easier to do in a velocity
> template. It only takes a couple of seconds more to do it, but it just
> makes everything 'seem' bigger.
>
>
> Example would be a link on a table...
>
>
> columns.add(new LinkPropertyColumn(new Model("Delivery"), new Model(
> "change")) {
> @Override
> public Link createLink(final Item item, String componentId,
> final IModel model) {
> return new Link(componentId) {
> @Override
> public void onClick() {
> ReportStatistic reportStatistic = (ReportStatistic) model
> .getObject();
> DraftProduct draft = productService
> .getDraftProduct(reportStatistic.getReportId());
> setResponsePage(new ReportDelivery(draft));
> }
> };
> }
> });
>
>
>
> On Thu, 2007-11-15 at 15:02 -0800, Alexis wrote:
> > Pros :
> > * Statefull
> > * Steady features (simple Ajax built-in, validation, ...)
> > * Can do simple stuff quickly without knowing the internals (good for java
> > developpers without web experiences)
> >
> > Cons :
> > * Not stateless (i'm talking about the stable 1.2 here)
> > * Too much alternatives to do quite the same things (markup inheritance vs
> > borders; passing component's constructors models, full objects or even
> > components; ListView vs DataView vs GridView ...)
> > * TOO MUCH JAVA and too component oriented: in fact on some pages you need
> > to create some components (panels, fragment, or inner classes) to write
> > maintenable code whereas these components will never be reused elsewhere. In
> > general you need some effort and focus to produce maintenable code on not so
> > complex pages / components, this is my biggest con.
> >
> >
> > Martijn Dashorst wrote:
> > >
> > > Pros:
> > > * elegant solutions to problems using object oriented programming are
> > > possible again
> > > * unspoiled (by model2 framework) graduates can create complex UI's
> > > almost instantly
> > > * you actually need to engage your brain at times
> > > * custom component creation is *really* easy: just use extends (tm)
> > >
> > > Cons:
> > > * single threaded model for responding to client actions: a lot is
> > > sync'd on the pagemap
> > > * you actually need to engage your brain at times
> > > * getting to know the internals can be quite challenging as it is a
> > > complex beast
> > > * too easy to create complex UI's that show the world and then some
> > > * sometimes the limitations of HTML/the web leak into the wicket
> > > world, making it tougher for new web developers as they are presented
> > > with quite an abstraction (keeping state in forms across requests in
> > > tabbed panels)
> > >
> > > Martijn
> > >
> > > On 11/15/07, mraible <ma...@raibledesigns.com> wrote:
> > >>
> > >> FWIW, I'd like to replace the pros and cons (my opinions) with some that
> > >> are
> > >> more accurate. As users of Wicket, I'd love to hear from you and get your
> > >> opinions on the top 3 pros and cons of Wicket.
> > >>
> > >> Here's the ones I currently have:
> > >>
> > >> Pros:
> > >>
> > >> * Great for Java developers, not web developers
> > >> * Tight binding between pages and views
> > >> * Active community - support from the creators
> > >>
> > >> Cons:
> > >>
> > >> * HTML templates live next to Java code
> > >> * Need to have a good grasp of OO
> > >> * The Wicket Way - everything done in Java
> > >>
> > >> IMO, there's no need to debate whether these are valid or not. If they're
> > >> not - please suggest new ones. James Ward of Flex had a nice and honest
> > >> comment this morning pointing out Flex's cons:
> > >>
> > >> http://tinyurl.com/yvybnm
> > >>
> > >> Thanks,
> > >>
> > >> Matt
> > >>
> > >>
> > >> Sean Sullivan-3 wrote:
> > >> >
> > >> > fyi
> > >> >
> > >> >
> > >> http://raibledesigns.com/rd/entry/comparing_jvm_web_frameworks_presentation
> > >> >
> > >>
> > >> --
> > >> View this message in context:
> > >> http://www.nabble.com/Matt-Raible%27s-ApacheCon-presentation-tf4815955.html#a13780071
> > >> Sent from the Wicket - User mailing list archive at Nabble.com.
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > >> For additional commands, e-mail: users-help@wicket.apache.org
> > >>
> > >>
> > >
> > >
> > > --
> > > Buy Wicket in Action: http://manning.com/dashorst
> > > Apache Wicket 1.3.0-rc1 is released
> > > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-rc1/
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> > >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by Jonathan Locke <jo...@gmail.com>.
yeah, strong coding is about making strong choices. when you
/know/ a design decision (such as this one -- separating markup
from code) is the right decision, you need to stick to your guns
and not lose the whole war because you want to win some little
battle. the fact that it takes a little more effort to do a label in
wicket than to use some special syntax to substitute a run-time
expression is only a lost battle to someone who does not look very
deeply at the problem domain. by not trying to please everyone,
wicket is able to make a strong design choice here (and in other
places). these strong choices are, for many people, winning the
war of web app development (if i do say so myself).
Eelco Hillenius wrote:
>
> On Nov 15, 2007 8:47 PM, Joshua Jackson <jo...@gmail.com> wrote:
>> It's better to have too much Java than too much XML :)
>> I think that's one of the consequences in using Wicket
>
> The end of the day, it comes down to making choices. The Wicket choice
> is to not allow template scripting at all. We think we have good
> reasons for that, based on our experience (certainly mine!) of what
> happens to medium to large sized projects when you do. There are
> plenty of threads and discussions about the why. Also, you can avoid a
> lot of Java code by just being smarter about things a bit.
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Matt-Raible%27s-ApacheCon-presentation-tf4815955.html#a13788321
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by Eelco Hillenius <ee...@gmail.com>.
On Nov 15, 2007 8:47 PM, Joshua Jackson <jo...@gmail.com> wrote:
> It's better to have too much Java than too much XML :)
> I think that's one of the consequences in using Wicket
The end of the day, it comes down to making choices. The Wicket choice
is to not allow template scripting at all. We think we have good
reasons for that, based on our experience (certainly mine!) of what
happens to medium to large sized projects when you do. There are
plenty of threads and discussions about the why. Also, you can avoid a
lot of Java code by just being smarter about things a bit.
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by Joshua Jackson <jo...@gmail.com>.
It's better to have too much Java than too much XML :)
I think that's one of the consequences in using Wicket
On 11/16/07, Joe Toth <jo...@gmail.com> wrote:
> I agree with the "Too much java" statement. Sometimes you have to
> create a bunch of stuff that would be a lot easier to do in a velocity
> template. It only takes a couple of seconds more to do it, but it just
> makes everything 'seem' bigger.
>
>
> Example would be a link on a table...
>
>
> columns.add(new LinkPropertyColumn(new Model("Delivery"), new Model(
> "change")) {
> @Override
> public Link createLink(final Item item, String componentId,
> final IModel model) {
> return new Link(componentId) {
> @Override
> public void onClick() {
> ReportStatistic reportStatistic = (ReportStatistic) model
> .getObject();
> DraftProduct draft = productService
> .getDraftProduct(reportStatistic.getReportId());
> setResponsePage(new ReportDelivery(draft));
> }
> };
> }
> });
>
>
> On Thu, 2007-11-15 at 15:02 -0800, Alexis wrote:
> > Pros :
> > * Statefull
> > * Steady features (simple Ajax built-in, validation, ...)
> > * Can do simple stuff quickly without knowing the internals (good for java
> > developpers without web experiences)
> >
> > Cons :
> > * Not stateless (i'm talking about the stable 1.2 here)
> > * Too much alternatives to do quite the same things (markup inheritance vs
> > borders; passing component's constructors models, full objects or even
> > components; ListView vs DataView vs GridView ...)
> > * TOO MUCH JAVA and too component oriented: in fact on some pages you need
> > to create some components (panels, fragment, or inner classes) to write
> > maintenable code whereas these components will never be reused elsewhere. In
> > general you need some effort and focus to produce maintenable code on not so
> > complex pages / components, this is my biggest con.
> >
> >
> > Martijn Dashorst wrote:
> > >
> > > Pros:
> > > * elegant solutions to problems using object oriented programming are
> > > possible again
> > > * unspoiled (by model2 framework) graduates can create complex UI's
> > > almost instantly
> > > * you actually need to engage your brain at times
> > > * custom component creation is *really* easy: just use extends (tm)
> > >
> > > Cons:
> > > * single threaded model for responding to client actions: a lot is
> > > sync'd on the pagemap
> > > * you actually need to engage your brain at times
> > > * getting to know the internals can be quite challenging as it is a
> > > complex beast
> > > * too easy to create complex UI's that show the world and then some
> > > * sometimes the limitations of HTML/the web leak into the wicket
> > > world, making it tougher for new web developers as they are presented
> > > with quite an abstraction (keeping state in forms across requests in
> > > tabbed panels)
> > >
> > > Martijn
> > >
> > > On 11/15/07, mraible <ma...@raibledesigns.com> wrote:
> > >>
> > >> FWIW, I'd like to replace the pros and cons (my opinions) with some that
> > >> are
> > >> more accurate. As users of Wicket, I'd love to hear from you and get your
> > >> opinions on the top 3 pros and cons of Wicket.
> > >>
> > >> Here's the ones I currently have:
> > >>
> > >> Pros:
> > >>
> > >> * Great for Java developers, not web developers
> > >> * Tight binding between pages and views
> > >> * Active community - support from the creators
> > >>
> > >> Cons:
> > >>
> > >> * HTML templates live next to Java code
> > >> * Need to have a good grasp of OO
> > >> * The Wicket Way - everything done in Java
> > >>
> > >> IMO, there's no need to debate whether these are valid or not. If they're
> > >> not - please suggest new ones. James Ward of Flex had a nice and honest
> > >> comment this morning pointing out Flex's cons:
> > >>
> > >> http://tinyurl.com/yvybnm
> > >>
> > >> Thanks,
> > >>
> > >> Matt
> > >>
> > >>
> > >> Sean Sullivan-3 wrote:
> > >> >
> > >> > fyi
> > >> >
> > >> >
> > >> http://raibledesigns.com/rd/entry/comparing_jvm_web_frameworks_presentation
> > >> >
> > >>
> > >> --
> > >> View this message in context:
> > >> http://www.nabble.com/Matt-Raible%27s-ApacheCon-presentation-tf4815955.html#a13780071
> > >> Sent from the Wicket - User mailing list archive at Nabble.com.
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > >> For additional commands, e-mail: users-help@wicket.apache.org
> > >>
> > >>
> > >
> > >
> > > --
> > > Buy Wicket in Action: http://manning.com/dashorst
> > > Apache Wicket 1.3.0-rc1 is released
> > > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-rc1/
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> > >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
What you want today, may not exist tommorrow
Blog: http://joshuajava.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by Igor Vaynberg <ig...@gmail.com>.
dont forget the code you have to write to convert draftid into
int/long from a string, deal with type conversion error, and make sure
someone didnt pass in a -1 or attempt sql injection...
-igor
On Nov 15, 2007 10:21 PM, Joe Toth <jo...@gmail.com> wrote:
> Compare the java code to something in velocity/jsp like...
>
> href="/path/to/something.jsp?id=${draft.id}"
>
> ...I know, I know...you really can't compare the 2 because wicket's
> version can have a lot more functionality easily. But, your ABSOLUTELY
> POSITIVELY right about paying with maintainability, except you still
> have to maintain the HTML file, yuck.
>
> 99.9% of the time I am very very happy with Wicket and wish that
> everyone used it. I hate working on JSP/JSF projects because "it's the
> standard and blah blah crap crap".
>
> I liked the last "Con" though. "Everything has to be done in Java" - I
> know what you meant, but its still funny. I wish everything could be
> done in Java, even the design. And I don't mean HTML+CSS, but some
> magically awesome design engine that would output HTML+CSS.
>
> With a Wicket application its A LOT easier to figure out where
> everything is and how it gets there. OO w00t. Ah, the days of PHP/JSP
> hell.
>
>
>
>
> On Thu, 2007-11-15 at 21:20 -0800, Eelco Hillenius wrote:
> > > Example would be a link on a table...
> > >
> > >
> > > columns.add(new LinkPropertyColumn(new Model("Delivery"), new Model(
> > > "change")) {
> > > @Override
> > > public Link createLink(final Item item, String componentId,
> > > final IModel model) {
> > > return new Link(componentId) {
> > > @Override
> > > public void onClick() {
> > > ReportStatistic reportStatistic = (ReportStatistic) model
> > > .getObject();
> > > DraftProduct draft = productService
> > > .getDraftProduct(reportStatistic.getReportId());
> > > setResponsePage(new ReportDelivery(draft));
> > > }
> > > };
> > > }
> > > });
> > >
> >
> > For the record, this code fragment doesn't look like 'too much Java'
> > to me tbh. The decision to load the draft and redirect to another page
> > could be done in Velocity, but would immediately mean that you pay
> > with maintainability.
> >
> > Eelco
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by Johan Compagner <jc...@gmail.com>.
If you don't want to maintain HTML/CSS and also have that generated
look at the layout manager frameworks like Echo2
johan
On Nov 16, 2007 7:21 AM, Joe Toth <jo...@gmail.com> wrote:
> Compare the java code to something in velocity/jsp like...
>
> href="/path/to/something.jsp?id=${draft.id}"
>
> ...I know, I know...you really can't compare the 2 because wicket's
> version can have a lot more functionality easily. But, your ABSOLUTELY
> POSITIVELY right about paying with maintainability, except you still
> have to maintain the HTML file, yuck.
>
> 99.9% of the time I am very very happy with Wicket and wish that
> everyone used it. I hate working on JSP/JSF projects because "it's the
> standard and blah blah crap crap".
>
> I liked the last "Con" though. "Everything has to be done in Java" - I
> know what you meant, but its still funny. I wish everything could be
> done in Java, even the design. And I don't mean HTML+CSS, but some
> magically awesome design engine that would output HTML+CSS.
>
> With a Wicket application its A LOT easier to figure out where
> everything is and how it gets there. OO w00t. Ah, the days of PHP/JSP
> hell.
>
>
>
> On Thu, 2007-11-15 at 21:20 -0800, Eelco Hillenius wrote:
> > > Example would be a link on a table...
> > >
> > >
> > > columns.add(new LinkPropertyColumn(new
> Model("Delivery"), new Model(
> > > "change")) {
> > > @Override
> > > public Link createLink(final Item item, String
> componentId,
> > > final IModel model) {
> > > return new Link(componentId) {
> > > @Override
> > > public void onClick() {
> > > ReportStatistic
> reportStatistic = (ReportStatistic) model
> > >
> .getObject();
> > > DraftProduct draft =
> productService
> > >
> .getDraftProduct(reportStatistic.getReportId());
> > > setResponsePage(new
> ReportDelivery(draft));
> > > }
> > > };
> > > }
> > > });
> > >
> >
> > For the record, this code fragment doesn't look like 'too much Java'
> > to me tbh. The decision to load the draft and redirect to another page
> > could be done in Velocity, but would immediately mean that you pay
> > with maintainability.
> >
> > Eelco
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Matt Raible's ApacheCon presentation
Posted by Joe Toth <jo...@gmail.com>.
Compare the java code to something in velocity/jsp like...
href="/path/to/something.jsp?id=${draft.id}"
...I know, I know...you really can't compare the 2 because wicket's
version can have a lot more functionality easily. But, your ABSOLUTELY
POSITIVELY right about paying with maintainability, except you still
have to maintain the HTML file, yuck.
99.9% of the time I am very very happy with Wicket and wish that
everyone used it. I hate working on JSP/JSF projects because "it's the
standard and blah blah crap crap".
I liked the last "Con" though. "Everything has to be done in Java" - I
know what you meant, but its still funny. I wish everything could be
done in Java, even the design. And I don't mean HTML+CSS, but some
magically awesome design engine that would output HTML+CSS.
With a Wicket application its A LOT easier to figure out where
everything is and how it gets there. OO w00t. Ah, the days of PHP/JSP
hell.
On Thu, 2007-11-15 at 21:20 -0800, Eelco Hillenius wrote:
> > Example would be a link on a table...
> >
> >
> > columns.add(new LinkPropertyColumn(new Model("Delivery"), new Model(
> > "change")) {
> > @Override
> > public Link createLink(final Item item, String componentId,
> > final IModel model) {
> > return new Link(componentId) {
> > @Override
> > public void onClick() {
> > ReportStatistic reportStatistic = (ReportStatistic) model
> > .getObject();
> > DraftProduct draft = productService
> > .getDraftProduct(reportStatistic.getReportId());
> > setResponsePage(new ReportDelivery(draft));
> > }
> > };
> > }
> > });
> >
>
> For the record, this code fragment doesn't look like 'too much Java'
> to me tbh. The decision to load the draft and redirect to another page
> could be done in Velocity, but would immediately mean that you pay
> with maintainability.
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by Eelco Hillenius <ee...@gmail.com>.
> Example would be a link on a table...
>
>
> columns.add(new LinkPropertyColumn(new Model("Delivery"), new Model(
> "change")) {
> @Override
> public Link createLink(final Item item, String componentId,
> final IModel model) {
> return new Link(componentId) {
> @Override
> public void onClick() {
> ReportStatistic reportStatistic = (ReportStatistic) model
> .getObject();
> DraftProduct draft = productService
> .getDraftProduct(reportStatistic.getReportId());
> setResponsePage(new ReportDelivery(draft));
> }
> };
> }
> });
>
For the record, this code fragment doesn't look like 'too much Java'
to me tbh. The decision to load the draft and redirect to another page
could be done in Velocity, but would immediately mean that you pay
with maintainability.
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by Joe Toth <jo...@gmail.com>.
I agree with the "Too much java" statement. Sometimes you have to
create a bunch of stuff that would be a lot easier to do in a velocity
template. It only takes a couple of seconds more to do it, but it just
makes everything 'seem' bigger.
Example would be a link on a table...
columns.add(new LinkPropertyColumn(new Model("Delivery"), new Model(
"change")) {
@Override
public Link createLink(final Item item, String componentId,
final IModel model) {
return new Link(componentId) {
@Override
public void onClick() {
ReportStatistic reportStatistic = (ReportStatistic) model
.getObject();
DraftProduct draft = productService
.getDraftProduct(reportStatistic.getReportId());
setResponsePage(new ReportDelivery(draft));
}
};
}
});
On Thu, 2007-11-15 at 15:02 -0800, Alexis wrote:
> Pros :
> * Statefull
> * Steady features (simple Ajax built-in, validation, ...)
> * Can do simple stuff quickly without knowing the internals (good for java
> developpers without web experiences)
>
> Cons :
> * Not stateless (i'm talking about the stable 1.2 here)
> * Too much alternatives to do quite the same things (markup inheritance vs
> borders; passing component's constructors models, full objects or even
> components; ListView vs DataView vs GridView ...)
> * TOO MUCH JAVA and too component oriented: in fact on some pages you need
> to create some components (panels, fragment, or inner classes) to write
> maintenable code whereas these components will never be reused elsewhere. In
> general you need some effort and focus to produce maintenable code on not so
> complex pages / components, this is my biggest con.
>
>
> Martijn Dashorst wrote:
> >
> > Pros:
> > * elegant solutions to problems using object oriented programming are
> > possible again
> > * unspoiled (by model2 framework) graduates can create complex UI's
> > almost instantly
> > * you actually need to engage your brain at times
> > * custom component creation is *really* easy: just use extends (tm)
> >
> > Cons:
> > * single threaded model for responding to client actions: a lot is
> > sync'd on the pagemap
> > * you actually need to engage your brain at times
> > * getting to know the internals can be quite challenging as it is a
> > complex beast
> > * too easy to create complex UI's that show the world and then some
> > * sometimes the limitations of HTML/the web leak into the wicket
> > world, making it tougher for new web developers as they are presented
> > with quite an abstraction (keeping state in forms across requests in
> > tabbed panels)
> >
> > Martijn
> >
> > On 11/15/07, mraible <ma...@raibledesigns.com> wrote:
> >>
> >> FWIW, I'd like to replace the pros and cons (my opinions) with some that
> >> are
> >> more accurate. As users of Wicket, I'd love to hear from you and get your
> >> opinions on the top 3 pros and cons of Wicket.
> >>
> >> Here's the ones I currently have:
> >>
> >> Pros:
> >>
> >> * Great for Java developers, not web developers
> >> * Tight binding between pages and views
> >> * Active community - support from the creators
> >>
> >> Cons:
> >>
> >> * HTML templates live next to Java code
> >> * Need to have a good grasp of OO
> >> * The Wicket Way - everything done in Java
> >>
> >> IMO, there's no need to debate whether these are valid or not. If they're
> >> not - please suggest new ones. James Ward of Flex had a nice and honest
> >> comment this morning pointing out Flex's cons:
> >>
> >> http://tinyurl.com/yvybnm
> >>
> >> Thanks,
> >>
> >> Matt
> >>
> >>
> >> Sean Sullivan-3 wrote:
> >> >
> >> > fyi
> >> >
> >> >
> >> http://raibledesigns.com/rd/entry/comparing_jvm_web_frameworks_presentation
> >> >
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/Matt-Raible%27s-ApacheCon-presentation-tf4815955.html#a13780071
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
> > --
> > Buy Wicket in Action: http://manning.com/dashorst
> > Apache Wicket 1.3.0-rc1 is released
> > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-rc1/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by Eelco Hillenius <ee...@gmail.com>.
On Nov 16, 2007 1:42 AM, Alexis <al...@gmail.com> wrote:
>
> Yep that would be more maintenable ;)
> As an alternative, you could provide instanciation of components in markup.
> I think i've seen some code doing just that in the hypothetical v2.0, is
> this planned for 1.3 ?
We've had this hidden feature that would let you do things like:
<wicket:component name="myTable"
class="org.apache.wicket.markup.MyTable" rowsPerPage="10">
I think we removed it permanently by now, but you could implement
something like that if you really would like to do that. We won't be
supporting it though :-)
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by Alexis <al...@gmail.com>.
Yep that would be more maintenable ;)
As an alternative, you could provide instanciation of components in markup.
I think i've seen some code doing just that in the hypothetical v2.0, is
this planned for 1.3 ?
igor.vaynberg wrote:
>
> On Nov 15, 2007 3:02 PM, Alexis <al...@gmail.com> wrote:
>> * TOO MUCH JAVA and too component oriented: in fact on some pages you
>> need
>> to create some components (panels, fragment, or inner classes) to write
>> maintenable code whereas these components will never be reused elsewhere.
>> In
>> general you need some effort and focus to produce maintenable code on not
>> so
>> complex pages / components, this is my biggest con.
>
> you can always override render() and spit html directly into
> servletresponse as a string... :)
>
> -igor
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Matt-Raible%27s-ApacheCon-presentation-tf4815955.html#a13790063
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by Igor Vaynberg <ig...@gmail.com>.
On Nov 15, 2007 3:02 PM, Alexis <al...@gmail.com> wrote:
> * TOO MUCH JAVA and too component oriented: in fact on some pages you need
> to create some components (panels, fragment, or inner classes) to write
> maintenable code whereas these components will never be reused elsewhere. In
> general you need some effort and focus to produce maintenable code on not so
> complex pages / components, this is my biggest con.
you can always override render() and spit html directly into
servletresponse as a string... :)
-igor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by Alexis <al...@gmail.com>.
Pros :
* Statefull
* Steady features (simple Ajax built-in, validation, ...)
* Can do simple stuff quickly without knowing the internals (good for java
developpers without web experiences)
Cons :
* Not stateless (i'm talking about the stable 1.2 here)
* Too much alternatives to do quite the same things (markup inheritance vs
borders; passing component's constructors models, full objects or even
components; ListView vs DataView vs GridView ...)
* TOO MUCH JAVA and too component oriented: in fact on some pages you need
to create some components (panels, fragment, or inner classes) to write
maintenable code whereas these components will never be reused elsewhere. In
general you need some effort and focus to produce maintenable code on not so
complex pages / components, this is my biggest con.
Martijn Dashorst wrote:
>
> Pros:
> * elegant solutions to problems using object oriented programming are
> possible again
> * unspoiled (by model2 framework) graduates can create complex UI's
> almost instantly
> * you actually need to engage your brain at times
> * custom component creation is *really* easy: just use extends (tm)
>
> Cons:
> * single threaded model for responding to client actions: a lot is
> sync'd on the pagemap
> * you actually need to engage your brain at times
> * getting to know the internals can be quite challenging as it is a
> complex beast
> * too easy to create complex UI's that show the world and then some
> * sometimes the limitations of HTML/the web leak into the wicket
> world, making it tougher for new web developers as they are presented
> with quite an abstraction (keeping state in forms across requests in
> tabbed panels)
>
> Martijn
>
> On 11/15/07, mraible <ma...@raibledesigns.com> wrote:
>>
>> FWIW, I'd like to replace the pros and cons (my opinions) with some that
>> are
>> more accurate. As users of Wicket, I'd love to hear from you and get your
>> opinions on the top 3 pros and cons of Wicket.
>>
>> Here's the ones I currently have:
>>
>> Pros:
>>
>> * Great for Java developers, not web developers
>> * Tight binding between pages and views
>> * Active community - support from the creators
>>
>> Cons:
>>
>> * HTML templates live next to Java code
>> * Need to have a good grasp of OO
>> * The Wicket Way - everything done in Java
>>
>> IMO, there's no need to debate whether these are valid or not. If they're
>> not - please suggest new ones. James Ward of Flex had a nice and honest
>> comment this morning pointing out Flex's cons:
>>
>> http://tinyurl.com/yvybnm
>>
>> Thanks,
>>
>> Matt
>>
>>
>> Sean Sullivan-3 wrote:
>> >
>> > fyi
>> >
>> >
>> http://raibledesigns.com/rd/entry/comparing_jvm_web_frameworks_presentation
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Matt-Raible%27s-ApacheCon-presentation-tf4815955.html#a13780071
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
> --
> Buy Wicket in Action: http://manning.com/dashorst
> Apache Wicket 1.3.0-rc1 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-rc1/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Matt-Raible%27s-ApacheCon-presentation-tf4815955.html#a13783821
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by Martijn Dashorst <ma...@gmail.com>.
Pros:
* elegant solutions to problems using object oriented programming are
possible again
* unspoiled (by model2 framework) graduates can create complex UI's
almost instantly
* you actually need to engage your brain at times
* custom component creation is *really* easy: just use extends (tm)
Cons:
* single threaded model for responding to client actions: a lot is
sync'd on the pagemap
* you actually need to engage your brain at times
* getting to know the internals can be quite challenging as it is a
complex beast
* too easy to create complex UI's that show the world and then some
* sometimes the limitations of HTML/the web leak into the wicket
world, making it tougher for new web developers as they are presented
with quite an abstraction (keeping state in forms across requests in
tabbed panels)
Martijn
On 11/15/07, mraible <ma...@raibledesigns.com> wrote:
>
> FWIW, I'd like to replace the pros and cons (my opinions) with some that are
> more accurate. As users of Wicket, I'd love to hear from you and get your
> opinions on the top 3 pros and cons of Wicket.
>
> Here's the ones I currently have:
>
> Pros:
>
> * Great for Java developers, not web developers
> * Tight binding between pages and views
> * Active community - support from the creators
>
> Cons:
>
> * HTML templates live next to Java code
> * Need to have a good grasp of OO
> * The Wicket Way - everything done in Java
>
> IMO, there's no need to debate whether these are valid or not. If they're
> not - please suggest new ones. James Ward of Flex had a nice and honest
> comment this morning pointing out Flex's cons:
>
> http://tinyurl.com/yvybnm
>
> Thanks,
>
> Matt
>
>
> Sean Sullivan-3 wrote:
> >
> > fyi
> >
> > http://raibledesigns.com/rd/entry/comparing_jvm_web_frameworks_presentation
> >
>
> --
> View this message in context: http://www.nabble.com/Matt-Raible%27s-ApacheCon-presentation-tf4815955.html#a13780071
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0-rc1 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-rc1/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Matt Raible's ApacheCon presentation
Posted by William Hoover <wh...@nemours.org>.
I think that the html code residing next to the java code is a lot more natural than the traditional schema and would be a pro. We are always resistant to change, but in some cases change is good thing. If they go hand-in-hand why would you not want to keep them together?
I hope you have a good grasp on OO if your programming in this day and age and that would also be a pro!
The last con is also a pro! Java is intended to handle logic- html is not! Placing the logic within the view (as the case with JSP/JSF) isn't very MVC like as they claim to be (more like MC ;)
-----Original Message-----
From: mraible [mailto:matt@raibledesigns.com]
Sent: Thursday, November 15, 2007 2:35 PM
To: users@wicket.apache.org
Subject: Re: Matt Raible's ApacheCon presentation
FWIW, I'd like to replace the pros and cons (my opinions) with some that are
more accurate. As users of Wicket, I'd love to hear from you and get your
opinions on the top 3 pros and cons of Wicket.
Here's the ones I currently have:
Pros:
* Great for Java developers, not web developers
* Tight binding between pages and views
* Active community - support from the creators
Cons:
* HTML templates live next to Java code
* Need to have a good grasp of OO
* The Wicket Way - everything done in Java
IMO, there's no need to debate whether these are valid or not. If they're
not - please suggest new ones. James Ward of Flex had a nice and honest
comment this morning pointing out Flex's cons:
http://tinyurl.com/yvybnm
Thanks,
Matt
Sean Sullivan-3 wrote:
>
> fyi
>
> http://raibledesigns.com/rd/entry/comparing_jvm_web_frameworks_presentation
>
--
View this message in context: http://www.nabble.com/Matt-Raible%27s-ApacheCon-presentation-tf4815955.html#a13780071
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Matt Raible's ApacheCon presentation
Posted by mraible <ma...@raibledesigns.com>.
FWIW, I'd like to replace the pros and cons (my opinions) with some that are
more accurate. As users of Wicket, I'd love to hear from you and get your
opinions on the top 3 pros and cons of Wicket.
Here's the ones I currently have:
Pros:
* Great for Java developers, not web developers
* Tight binding between pages and views
* Active community - support from the creators
Cons:
* HTML templates live next to Java code
* Need to have a good grasp of OO
* The Wicket Way - everything done in Java
IMO, there's no need to debate whether these are valid or not. If they're
not - please suggest new ones. James Ward of Flex had a nice and honest
comment this morning pointing out Flex's cons:
http://tinyurl.com/yvybnm
Thanks,
Matt
Sean Sullivan-3 wrote:
>
> fyi
>
> http://raibledesigns.com/rd/entry/comparing_jvm_web_frameworks_presentation
>
--
View this message in context: http://www.nabble.com/Matt-Raible%27s-ApacheCon-presentation-tf4815955.html#a13780071
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org