Re: Matt Raible's ApacheCon presentation
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matt Raible's ApacheCon presentation
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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
On Nov 15, 2007 9:06 PM, Igor Vaynberg [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matt Raible's ApacheCon presentation
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matt Raible's ApacheCon presentation
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 [EMAIL PROTECTED] wrote: On Nov 15, 2007 12:27 PM, Gwyn Evans [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matt Raible's ApacheCon presentation
On Nov 16, 2007 1:42 AM, Alexis [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matt Raible's ApacheCon presentation
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 [EMAIL PROTECTED] wrote: On Nov 15, 2007 12:27 PM, Gwyn Evans [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matt Raible's ApacheCon presentation
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: On Nov 15, 2007 12:27 PM, Gwyn Evans [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matt Raible's ApacheCon presentation
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matt Raible's ApacheCon presentation
On Nov 16, 2007 8:21 AM, Jonathan Locke [EMAIL PROTECTED] 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
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
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
Re: Matt Raible's ApacheCon presentation
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 [EMAIL PROTECTED] 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
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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matt Raible's ApacheCon presentation
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matt Raible's ApacheCon presentation
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 OyURL: http://www.ri.fi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matt Raible's ApacheCon presentation
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matt Raible's ApacheCon presentation
* 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
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matt Raible's ApacheCon presentation
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matt Raible's ApacheCon presentation
These two are the exact same things I have in mind about wicket: On Nov 15, 2007 10:18 PM, Eelco Hillenius [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matt Raible's ApacheCon presentation
@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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matt Raible's ApacheCon presentation
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: On Nov 15, 2007 12:27 PM, Gwyn Evans [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matt Raible's ApacheCon presentation
* 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matt Raible's ApacheCon presentation
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Nick Heudecker Professional Wicket Training Consulting http://www.systemmobile.com Eventful - Intelligent Event Management http://www.eventfulhq.com
Re: Matt Raible's ApacheCon presentation
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matt Raible's ApacheCon presentation
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matt Raible's ApacheCon presentation
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matt Raible's ApacheCon presentation
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matt Raible's ApacheCon presentation
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Download Wicket 1.3.0-rc1 now! - http://wicketframework.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matt Raible's ApacheCon presentation
On Nov 15, 2007 12:48 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: On Nov 15, 2007 12:27 PM, Gwyn Evans [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matt Raible's ApacheCon presentation
On Nov 15, 2007 12:27 PM, Gwyn Evans [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matt Raible's ApacheCon presentation
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matt Raible's ApacheCon presentation
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matt Raible's ApacheCon presentation
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matt Raible's ApacheCon presentation
On Nov 15, 2007 3:02 PM, Alexis [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Matt Raible's ApacheCon presentation
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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matt Raible's ApacheCon presentation
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matt Raible's ApacheCon presentation
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional
Re: Matt Raible's ApacheCon presentation
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matt Raible's ApacheCon presentation
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matt Raible's ApacheCon presentation
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
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:
Re: Matt Raible's ApacheCon presentation
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Matt Raible's ApacheCon presentation
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
