Matt Raible's ApacheCon presentation

[Joshua Partogi]

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 <joetoth@...> 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 <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/
> > >
> > > ---------------------------------------------------------------------
> > > 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@...
>
>

--
What you want today, may not exist tommorrow

Blog: http://joshuajava.wordpress.com/

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

[igor.vaynberg]

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 <joetoth@...> 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 <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/
> > >
> > > ---------------------------------------------------------------------
> > > 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@...

[Eelco Hillenius]

On Nov 15, 2007 8:47 PM, Joshua Jackson <joshua.java@...> wrote:
> It's better to have too much Java than too much XML :)
> I think that's one of the consequences in using Wicket

The end of the day, it comes down to making choices. The Wicket choice
is to not allow template scripting at all. We think we have good
reasons for that, based on our experience (certainly mine!) of what
happens to medium to large sized projects when you do. There are
plenty of threads and discussions about the why. Also, you can avoid a
lot of Java code by just being smarter about things a bit.

Eelco

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

[Eelco Hillenius]

> Example would be a link on a table...
>
>
>                 columns.add(new LinkPropertyColumn(new Model("Delivery"), new Model(
>                                 "change")) {
>                         @Override
>                         public Link createLink(final Item item, String componentId,
>                                         final IModel model) {
>                                 return new Link(componentId) {
>                                         @Override
>                                         public void onClick() {
>                                                 ReportStatistic reportStatistic = (ReportStatistic) model
>                                                                 .getObject();
>                                                 DraftProduct draft = productService
>                                                                 .getDraftProduct(reportStatistic.getReportId());
>                                                 setResponsePage(new ReportDelivery(draft));
>                                         }
>                                 };
>                         }
>                 });
>

For the record, this code fragment doesn't look like 'too much Java'
to me tbh. The decision to load the draft and redirect to another page
could be done in Velocity, but would immediately mean that you pay
with maintainability.

Eelco

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

[Timo Rantalaiho]

On Thu, 15 Nov 2007, mraible wrote:
> FWIW, I'd like to replace the pros and cons (my opinions) with some that are
> more accurate. As users of Wicket, I'd love to hear from you and get your
> opinions on the top 3 pros and cons of Wicket.

Pros:
- excellent markup previewability and separation of concerns
- excellent testability (easy to get high developer testing
  coverage for UI code)
- easy to add AJAX functionality with no or little
  Javascripting
- programming is done in java, not in XML or HTML


Cons:
- steep learning curve
- not a standard (this hinders adoption because of
  bureaucratic and/or political reasons, though is bound to
  give technical advantage. Think JPA annotations vs
  Hibernate annotations)
- newness, which shows in API instability (2.0 branch,
  hopefully getting resolved) and lack of recommended
  practices (AJAX refresh srategies, chaining multiple
  behaviors, editing Hibernate-persisted data, ...)

We need better programming, not ways to make implementing
bad design more easily.

After having used Wicket for a year I don't want to go back.

Best wishes,
Timo


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

[WeaZeLb0y]

Compare the java code to something in velocity/jsp like...

href="/path/to/something.jsp?id=${draft.id}"

...I know, I know...you really can't compare the 2 because wicket's
version can have a lot more functionality easily. But, your ABSOLUTELY
POSITIVELY right about paying with maintainability, except you still
have to maintain the HTML file, yuck.

99.9% of the time I am very very happy with Wicket and wish that
everyone used it. I hate working on JSP/JSF projects because "it's the
standard and blah blah crap crap".

I liked the last "Con" though. "Everything has to be done in Java" - I
know what you meant, but its still funny. I wish everything could be
done in Java, even the design. And I don't mean HTML+CSS, but some
magically awesome design engine that would output HTML+CSS.

With a Wicket application its A LOT easier to figure out where
everything is and how it gets there. OO w00t. Ah, the days of PHP/JSP
hell.



On Thu, 2007-11-15 at 21:20 -0800, Eelco Hillenius wrote:

> > Example would be a link on a table...
> >
> >
> >                 columns.add(new LinkPropertyColumn(new Model("Delivery"), new Model(
> >                                 "change")) {
> >                         @Override
> >                         public Link createLink(final Item item, String componentId,
> >                                         final IModel model) {
> >                                 return new Link(componentId) {
> >                                         @Override
> >                                         public void onClick() {
> >                                                 ReportStatistic reportStatistic = (ReportStatistic) model
> >                                                                 .getObject();
> >                                                 DraftProduct draft = productService
> >                                                                 .getDraftProduct(reportStatistic.getReportId());
> >                                                 setResponsePage(new ReportDelivery(draft));
> >                                         }
> >                                 };
> >                         }
> >                 });
> >
>
> For the record, this code fragment doesn't look like 'too much Java'
> to me tbh. The decision to load the draft and redirect to another page
> could be done in Velocity, but would immediately mean that you pay
> with maintainability.
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

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

[igor.vaynberg]

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 <joetoth@...> wrote:

> Compare the java code to something in velocity/jsp like...
>
> href="/path/to/something.jsp?id=${draft.id}"
>
> ...I know, I know...you really can't compare the 2 because wicket's
> version can have a lot more functionality easily. But, your ABSOLUTELY
> POSITIVELY right about paying with maintainability, except you still
> have to maintain the HTML file, yuck.
>
> 99.9% of the time I am very very happy with Wicket and wish that
> everyone used it. I hate working on JSP/JSF projects because "it's the
> standard and blah blah crap crap".
>
> I liked the last "Con" though. "Everything has to be done in Java" - I
> know what you meant, but its still funny. I wish everything could be
> done in Java, even the design. And I don't mean HTML+CSS, but some
> magically awesome design engine that would output HTML+CSS.
>
> With a Wicket application its A LOT easier to figure out where
> everything is and how it gets there. OO w00t. Ah, the days of PHP/JSP
> hell.
>
>
>
>
> On Thu, 2007-11-15 at 21:20 -0800, Eelco Hillenius wrote:
> > > Example would be a link on a table...
> > >
> > >
> > >                 columns.add(new LinkPropertyColumn(new Model("Delivery"), new Model(
> > >                                 "change")) {
> > >                         @Override
> > >                         public Link createLink(final Item item, String componentId,
> > >                                         final IModel model) {
> > >                                 return new Link(componentId) {
> > >                                         @Override
> > >                                         public void onClick() {
> > >                                                 ReportStatistic reportStatistic = (ReportStatistic) model
> > >                                                                 .getObject();
> > >                                                 DraftProduct draft = productService
> > >                                                                 .getDraftProduct(reportStatistic.getReportId());
> > >                                                 setResponsePage(new ReportDelivery(draft));
> > >                                         }
> > >                                 };
> > >                         }
> > >                 });
> > >
> >
> > For the record, this code fragment doesn't look like 'too much Java'
> > to me tbh. The decision to load the draft and redirect to another page
> > could be done in Velocity, but would immediately mean that you pay
> > with maintainability.
> >
> > Eelco
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@...
> > 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@...

[Jonathan Locke]

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.


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: [e-mail]
For additional commands, e-mail: [e-mail]

[Jonathan Locke]

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 <[e-mail]> 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: [e-mail]
For additional commands, e-mail: [e-mail]

[Thomas Maeder]

One BIG plus that I haven't seen mentioned is debuggability. A wicket
application is almost as easy to debug as a regular application. For one
thing the error messages are really great. 90% of the time the nail the
problem. But the biggest plus is that the whole control flow is just in
regular Java classes. No excursions into the templating engine, no
reflection magic, just good ole Java code you actually have half a
chance of debugging.
Jonathan has mentioned that the API footprint is bigger than he would
like (you started to sound a bit like Steve Northover, there, by the
way; scary! ;-). But I find that wicket actually has a very small
footprint compared to other frameworks, because wicket is all there is.
No templating engine, no bytcode manipulation framework, no expression
language you have to know. I can understand wicket top to bottom. Sweet!

Thomas

 

> -----Original Message-----
> From: mraible [mailto:matt@...]
> Sent: Donnerstag, 15. November 2007 20:57
> To: users@...
> Subject: Re: Matt Raible's ApacheCon presentation
>
>
> I didn't say my cons were valid - but I do believe there
> *are* cons to Wicket. What are they - in your opinion?
>
> matt
>
>
> igor.vaynberg wrote:
> >
> >> * HTML templates live next to Java code
> > this is easily changed - just a default
> >
> >> * Need to have a good grasp of OO
> > why is this a con? you are saying not knowing oo is a good
> thing? you
> > can say this is a pro - learning wicket will make you a better
> > developer :)
> >
> >> * The Wicket Way - everything done in Java
> > as opposed to embedding logic in views which has been something
> > plaguing other frameworks for ages?
> >
> > -igor
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Matt-Raible%27s-ApacheCon-presentation-t

f4815955.html#a13780519
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

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

[Nino.Martinez]

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@...

[Alexis]

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 <[e-mail]> 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: [e-mail]
For additional commands, e-mail: [e-mail]

[Nino.Martinez]

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

On Nov 16, 2007 1:42 AM, Alexis <alexis.tual@...> wrote:
>
> Yep that would be more maintenable ;)
> As an alternative, you could provide instanciation of components in markup.
> I think i've seen some code doing just that in the hypothetical v2.0, is
> this planned for 1.3 ?

We've had this hidden feature that would let you do things like:

<wicket:component name="myTable"
class="org.apache.wicket.markup.MyTable" rowsPerPage="10">

I think we removed it permanently by now, but you could implement
something like that if you really would like to do that. We won't be
supporting it though :-)

Eelco

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

[Timo Rantalaiho]

On Fri, 16 Nov 2007, Nino Saturnino Martinez Vazquez Wael wrote:
> A possible con are that the testing part of wicket could be improved by
> having more convenince methods. Also there seems to be some trouble
> testing if you use spring injection for your beans.

jdave-wicket has more convenience methods if that's an
option for you.

But what trouble have you run into with Spring beans? We
instantiate a MockApplicationContext and feed it to the
SpringComponentInstantiationListener of the Application
that WicketTester uses, and @SpringBeans just work.

> It's "pretty" hard doing stuff with the tester if you go beyond just
> selecting things, if you want to verify what the model contains. I could

Again this sounds strange to me.

You can just get the component you want and ask it, e.g.

  wicketTester.getComponentFromLastRenderedPage("name").getModelObject().equals("Frank")

Best wishes,
Timo

--
Timo Rantalaiho          
Reaktor Innovations Oy    <URL: http://www.ri.fi/ >

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

[Johan Compagner]

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 <eelco.hillenius@...> 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.
>
>

[Johan Compagner]

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

[Johan Compagner]

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

[Johan Compagner]

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 <joetoth@...> wrote:

> Compare the java code to something in velocity/jsp like...
>
> href="/path/to/something.jsp?id=${draft.id}"
>
> ...I know, I know...you really can't compare the 2 because wicket's
> version can have a lot more functionality easily. But, your ABSOLUTELY
> POSITIVELY right about paying with maintainability, except you still
> have to maintain the HTML file, yuck.
>
> 99.9% of the time I am very very happy with Wicket and wish that
> everyone used it. I hate working on JSP/JSF projects because "it's the
> standard and blah blah crap crap".
>
> I liked the last "Con" though. "Everything has to be done in Java" - I
> know what you meant, but its still funny. I wish everything could be
> done in Java, even the design. And I don't mean HTML+CSS, but some
> magically awesome design engine that would output HTML+CSS.
>
> With a Wicket application its A LOT easier to figure out where
> everything is and how it gets there. OO w00t. Ah, the days of PHP/JSP
> hell.
>
>
>
> On Thu, 2007-11-15 at 21:20 -0800, Eelco Hillenius wrote:
> > > Example would be a link on a table...
> > >
> > >
> > >                 columns.add(new LinkPropertyColumn(new
> Model("Delivery"), new Model(
> > >                                 "change")) {
> > >                         @Override
> > >                         public Link createLink(final Item item, String
> componentId,
> > >                                         final IModel model) {
> > >                                 return new Link(componentId) {
> > >                                         @Override
> > >                                         public void onClick() {
> > >                                                 ReportStatistic
> reportStatistic = (ReportStatistic) model
> > >
> .getObject();
> > >                                                 DraftProduct draft =
> productService
> > >
> .getDraftProduct(reportStatistic.getReportId());
> > >                                                 setResponsePage(new
> ReportDelivery(draft));
> > >                                         }
> > >                                 };
> > >                         }
> > >                 });
> > >
> >
> > For the record, this code fragment doesn't look like 'too much Java'
> > to me tbh. The decision to load the draft and redirect to another page
> > could be done in Velocity, but would immediately mean that you pay
> > with maintainability.
> >
> > Eelco
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[Johan Compagner]

On Nov 16, 2007 8:21 AM, Jonathan Locke <jonathan.locke@...> 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