Matt Raible's ApacheCon presentation

[Johan Compagner]

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@...> 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 <eelco.hillenius@...>
> wrote:
> >
> >> On Nov 15, 2007 12:27 PM, Gwyn Evans <gwyn.evans@...> 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@...
> > For additional commands, e-mail: users-help@...
> >
> >
> >
>
> --
> Nino Martinez Wael
> Java Specialist @ Jayway DK
> http://www.jayway.dk
> [phone]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[Eelco Hillenius]

> 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@...
For additional commands, e-mail: users-help@...

[Curtis Cooley-2]

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.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[John Krasnay]

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@...
For additional commands, e-mail: users-help@...

[Jonathan Locke]

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 <[e-mail]> 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

[Gabor Szokoli]

These two are the exact same things I have in mind about wicket:

On Nov 15, 2007 10:18 PM, Eelco Hillenius <eelco.hillenius@...> 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@...
For additional commands, e-mail: users-help@...

[Eelco Hillenius]

> 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@...
For additional commands, e-mail: users-help@...

[Nino.Martinez]

@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
[phone]


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Nino.Martinez]

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@...> 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 <eelco.hillenius@...>
>>>      
>> wrote:
>>    
>>>> On Nov 15, 2007 12:27 PM, Gwyn Evans <gwyn.evans@...> 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@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>>
>>>      
>> --
>> Nino Martinez Wael
>> Java Specialist @ Jayway DK
>> http://www.jayway.dk
>> [phone]
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>>    
>
>  

--
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
[phone]


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Martijn Dashorst]

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 <matt@...> 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@...
> For additional commands, e-mail: users-help@...
>
>

--
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/

[Matej Knopp]

On Nov 15, 2007 9:06 PM, Igor Vaynberg <igor.vaynberg@...> 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 <scott.swank@...> 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 <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@...
> > > For additional commands, e-mail: users-help@...
> > >
> > >
> >
> >
> >
> > --
> > Scott Swank
> > reformed mathematician
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Nino.Martinez]

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
[phone]


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...