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
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
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
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:
*
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.
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
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
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
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
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
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
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
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
-
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
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
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
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.
* 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;
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
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
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
@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
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
fyi
http://raibledesigns.com/rd/entry/comparing_jvm_web_frameworks_presentation
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
* 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
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
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.
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)
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
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
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
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
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
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
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
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
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
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
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
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...
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
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
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,
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
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,
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
46 matches
Mail list logo
