On Tue, 9 Nov 2010 11:01:28 +0200
Martin Makundi <martin.maku...@koodaripalvelut.com> wrote:

> Hi!
> > Coding friction? Yes. Every time I need to look at somebody else's
> > code and try to figure out what exactly they did.
> Ah.. so you are trying to solve your problem probably from the wrong
> end? If you have bad warriors give them plastic swords so they can
> hurt nobody? Training, Coding dojos, Code Reviews, Coding Policies,
> Dream teams, ...

So a clear architecture is a plastic sword? And "do whatever you want"
is better?

> > Please consider the needy ones that would have to deal with this and
> > would have to support people who made the mistake of using it :-)
> I don't think there is a substitute for coding skills/talent ;)))

There isn't. That's not the point. So far your argument seems to be #1
"I don't like this" and #2 those who don't agree with you aren't good

> >> It's just the itchy feeling you get all day long when coding "in
> >> the zone". "This unneccessary fuzz is in my way".
> >
> > If you only write code and never read or need to fix it.
> I understand if you are a consultant it gives you plenty of billable
> to code again and again.

WTF? Your argument #3 is that *I* want to screw my customers over?

> But my sweetspot is product development and I
> need to make flexibly reusable components and unfortunately requiring
> html hierarchy to match on different pages makes really messy code on
> java side if I try to implement free-from-iherarchy in a manual way (I
> must provide various different parent containers to a generic
> component so that it can land in the right place).

This just doesn't make sense. Put your stuff in a panel, then it's a
self-contained component and insulated from the hierarchy of the page
and other components. Then you can put that component wherever you want.

> > Well that certainly applies the other way around too. It's not for
> > everybody, so please don't introduce a new source of bugs into
> > *this* toolkit. Also, unless I missed a message (which is
> > possible), so far we seem to have a needy *one*, not *ones*.
> Still, I don't think there is a substitute for coding
> skills/talent ;)))

And I still haven't yet seen a convincing example of this being a
problem worth adding the complexity.

Then again, in the end the Wicket devs need to decide on whether they
want to support this or not. So far *my* definitely non-binding vote is
-1 :)


To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to