Igor Vaynberg wrote:
Jonathan,
Could you please elaborate on why interfaces are "fragile". It doesn't click
for me. How is it more fragile to have an interface and a single
implementation as opposed to a base class with no interface?
an interface is fragile because it is an inflexible, fixed contract. it
really is /set in
stone/ for a large project with a long lifespan (which we all hope
wicket will be).
if you think about it, on a very widely used framework you really can
never ever
change an interface. ever. i don't know about you... but i'm not smart
enough to
get an interface with more than a couple of methods right the first time
and for all
time. i usually discover weeks or months later (or days or hours...
DOH!) that i
forgot something. that's the fragility i'm talking about.
i believe that one shouldn't generally define interfaces for things that
have contracts
that are likely to evolve. especially if they are likely to evolve
significantly and/or
rapidly. if you have more than a few methods, the odds seem to increase
exponentially
with each added method that you'll eventually have that DOH! moment
where you
realize that you didn't really fully understand the contract you long
ago (or not so
long ago) thought was so clever...
an abstract base class has all the abstractness of an interface, but
allows flexible
default implementation that is not fixed for all time. you can think of
it very loosely
as a mixture between a class and an interface if you like. non-abstract
methods
can at least be added even if the existing abstract methods can't be
changed without
breaking the world. interestingly, you can also theoretically /remove/
the abstractness
of abstract methods (loosening the contract) without breaking subclasses by
concretizing methods later. in any case, for things that need the
ability to evolve in
the way that Component has (take a look at the revision history, we're
on version
#164 of that file... and I don't think that includes 100+ versions of
that code
from my original codebase), an interface doesn't make sense unless
there's some
other urgent, overriding need for it.
in general, there can be other arguments that override the disadvantage
of interface
inflexibility, such as a requirement to allow alternate implementations
not based
on the same root functionality, enabling mix-in usage or some other
usage driven
need like making something Remote. none of these seemed or seem like
important
factors in wicket.
As far as mixins go, I only ran into one situation so far. The
IPageableComponent interface has to have getPage() method which really has
nothing to do with the implementation being pageable, but with the fact that
it is a component. Everything that uses IPageableComponent expects a
component with pageable behaviour, not just a pageable something. Im not
screaming interfaces for everything, but in this case it would be nice.
i don't know enough about this case to comment. but i highly suspect
that there is
some answer that doesn't involve making Component or Page an interface.
Thanks,
Igor
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Jonathan Locke
Sent: Tuesday, August 02, 2005 2:29 PM
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] Sigin Example
i think you're awfully, awfully full of yourself (in fact,
you sound like me about 10 years ago... ;-)). have you even
considered the possibility that it might be /you/ that doesn't get it?
from my perspective:
loose coupled interfaces == bell bottom jeans
people think that they're the solution to everything right now.
and just like bell bottom jeans, some people really did look
good in them. they were cool. but what were we thinking!?
does /everyone/ look good in bell bottom jeans? hardly.
just watch "that 70's show" sometime... the neighbor guy
with the curly hair.
he's an example of a guy that definitely doesn't need loose coupling.
when you've been doing this as long as i have, you start to
notice patterns in the fads that sweep through the industry.
and you eventually start to ignore the hype where it doesn't
make any sense.
i could see this whole "bind-everything-with-xml" fad several
years ago coming from a mile away. and now what? people are
attracted to wicket because it didn't follow that fad. i
think you're simply missing the forest for the trees. loose
coupled interfaces are the right design pattern for a whole
host of problems. but the design for a web ui framework is
not one of them. this was one of the things that turned me
off when i looked at tapestry. all these gigantic interfaces?
why? yuck.
don't get me wrong... please, keep thinking. we all have to
learn by experience. i promise i won't stop you from trying
to loose couple every object in /your/ project with gigantic
fragile interfaces that serve no practical purpose. but
please don't try to do it to wicket. interfaces have been
used judiciously in wicket. i'm not saying it's perfect.
i'm not even saying we shouldn't add an interface here or
there. we just have yet to hear an even remotely reasonable
argument that wicket components should be mixins. and that's
why they aren't.
David Liebeherr wrote:
Uh ohh, i started reading the dicussion about interfaces in wicket.
I think Eleco and Jonathan might be wrong in some ways.
One /very/ important reason not to use interfaces in this
case is that:
interfaces are hard to evolve. Interfaces have to be pretty darn
stable before even considering throwing them out in the
public, as
there is no way (not without a tough fight at least) you
can alter
it later on - even adding a new method will break all clients.
He sais that interfaces have to be more stable than an
object without
interface.
But he misses a very important fact:
Assume you have "String str = new String()" String is a concrete
class. but: String in this context is _ALSO_ an interface!
Every reference is an interface no mather if it's a
concrete class or
an interface/abstract class!
And i think it should be not that hard to design proper interfaces!
jonathan: interfaces should always be a set of methods that you
cannot ever imagine extending
"interface B extends A" ? interface inheritance is fun,
isn't it? :-)
[22:43] jonathan: my ideal number of methods in an interface is 1
[22:43] jonathan: ;-) [22:44] jonathan: 2 is okay in some cases
[22:44] jonathan: 3 often should be re-thought
i don't see what's the sens of defining a random number as an limit
for number of methos in an interface.
an interface should be designed by the needs of the context and the
purposal.
i just disagree with him!
I wonder what it is you want
to do with a proxy that you can"t do by simply
subclassing? Or AOP?
He considers to use such a complex thing like AOP but
refuses to use
such a basic thing like Interfaces?
Did you and your colegues read the links i sent in my last mail?
If not i suggest it would be a good idea to do so.
It's worth it, trust me!
Johan Compagner wrote:
But this is not really possible because the internals of page are
pretty
importand for wicket to let it work
This is a serious indication that the design has some flaws
in it. A
design should always be as interchangebale and modular as possible.
Again: I think in the discussion it's missed that you can
even resuse
an implementation in a interfaces based design by delegation...
And it ignores the fact that you can extend interfaces as well
(interface inheritance is a nice thing)...
I can't imagine what's so hard to have a Page just as Interface. If
you can not deal with client objects as interfaced objects
you have a
problem in your design. I do use interfaces every day and i
have never
ever had a big problem with that. It's all about how familiar and
comfortable you with good modular design pratics. Loosly
coupling is
the key word! and loosly coupling is possible. you may have
to think a
bit more about your design, but it safes you so much time later...
Maybe if i have some time i will rewrite a very little part
of wicket
to use interfaces to show that it's definetly not a problem to use
interfaces and that you will get good benefits from it.
Btw: A good design isn't done in a sec, but it's worth to thake the
time to do so...
Another thing i don't understand is, that some ppl
sometimes say that
the refuse to use interfaces on wicket but sometimes there are
interfaces used in wicket. So if you can use an interface for a
sessionFactory then why can't you use an interface for the session
itself?
Well, however, i think when wicket reaches 2.0 and it's
clear enough
which functionalities are implemented i may be a good idea
to review
the source and move over to use interfaces where they make sense...
And one thing not to forget: Wicket uses "wicket:id" tags to loosly
couple html with the logic-code. That is the most valuable
thing about
wicket!
But it's a bad thing to not continue the loosly coupling aproach in
the api. Think about it! Loosly compling on the html/code
side is the
key thing that makes wicket better than other frameworks.
So continue
to use that in the api and you have done the best way that
is possible
with java!
And please remeber: It's cunstructive critism which i try
to provide.
I just want to get wicket as the best what's possible bc the basic
ideas of wicket are great!
Thanx for your attention,
Dave
PS: I don't say i know the overall truth i just provided my toughts
:-)
Juergen Donnerstag wrote:
David,
we did have a very hot discussion about that topic just a
week or two
ago. Please check the mail archiv (gmane) for details. But
I can tell
you it was a very deliberate decison to implement it the way it is.
Juergen
On 8/2/05, David Liebeherr <[EMAIL PROTECTED]> wrote:
Hi Juergen,
Juergen Donnerstag wrote:
David,
yes you're right we have to work on the docs, has been
on our list
and is under construction. Did you check out our wiki and (the
outdated) user guide. it should provide at a beginner
some inside into Wicket.
You mentioned you would simplifiy the API even further. You
mentioned IModel. Anything else that comes into your mind?
I my gosh, do you realy want to get me started on that?
:-) No, for
real:
There are lot's of things that need very much simplification.
When i have some time, we may discuss that in detail (if you are
interested) in a chat or something like that (Log of chat goes to
maillinglist/wiki of course).
One of the much important things is to realize the
"programm to an
interface, not to an implementation" principle.
For exmaple:
Session should be an Interface and SessionImpl should be (one!)
implementation of it.
Btw: Don't name interfaces with a I prefix, that is not so good.
It should be always like that:
Car exmaple:
interface Car {};
class CarImpl impements Car {};
or
class BmwImpl implements Car{};
I know ppl have different opinions about such things, but the i
discussed those things for a rather long time with a lot of
developers and some very very good (actually one of the best
programmers out there). I have lot's of serious reasons
why i think
you should follow this naming convention. And the most important
thing is: Use interfaces rather then concrete implementation!
And another very very thing is: Use delegation rather
than concrete
inheritance!
Again, i have very serious reasons why i think that way.
And it does not mean much more work to do with proper
coding tools
(Like IntelliJ IDEA).
I think the Idea of Wicket is geniusly!
Especialy the part that code is attached to free
placeable tags with
a proper wicket:id!
But i think at this point the API needs a revision to simplify it
and to realy follow some very important rules (like avoiding
concrete inheritance).
Btw: have a look on that:
http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html
AND AFTER THAT ALSO READ THAT! -->
http://jtiger.org/articles/why-extends-is-not-evil.html
It explains very very well what's the problem with concrete
inheritance.
And last but not least:
I think you core developers have done a very good job and
i'm very
happy to use wicket!
Everything i said (and will say) is not meant as a
complain i realy
want to participate in wicket and to make it the best WebApp
framework that exists (And i think wicket can reach that
target! If
i think about all that XMl-Config files crap like with Struts and
JSF :-))
So please always thake what i say at what is it meant to be:
Constructive critism.
Thanx again for your Work,
Dave
Juergen
On 8/2/05, David Liebeherr <[EMAIL PROTECTED]> wrote:
Juergen Donnerstag wrote:
Sorry, I guess except the javadoc there is no extra doc on it.
What is
your question? Signin and Signin2 and not very complex.
I think this is precisely the Problem.
I found it already out by myself, but it took me some
time to find
and understand that the key thing is the checkAccess-method.
You think it is very simple code. But you are one of the
Developers that wrote the Libs, so you know what checkAccess do
and you know that you do not have to search in the
WebApplication-Class code to search where it is
redirected to the
Login-Page.
So i think the problem is for outsiders and newbees of
the project
many many things are not so clear as you might think.
I think the lack of good Documentation - and by documentation i
don't mean a simple doc of the API methods, rather a
documentation
describes the realtionships between components and how
to use them
- is one of the biggest problems (or todos) for wicket.
Another Problem is, that's at least my personal opinion (and
please thake it as constructive critic and not just as
a complain)
is that the api is yet to complex. I thought one of the
main goals
of wicket was to keep the learning curve as low as
possible. But
the api is to complex for that i think. Especialy the
IModel API
is very complex and i think it would be a very good idea to
simplify it much more.
I mean at this time i am a newbee to wicket for my
self. But that
is good bc that way i can provide the "sight of a newbee".
Developers of the proect may thing that something is
"quite easy",
but if i'm a developer of the project i know too much
already to
tell if a thing can be easy understood.
But however thanks for your help,
Dave
Juergen
On 8/1/05, David Liebeherr <[EMAIL PROTECTED]> wrote:
Is there any documentation/tutorial available for the Signin
Exmaple?
I realy have some problems understanding how it works.
Thanx,
Dave
PS: Wicket ROCKS!
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration
Strategies
from IBM. Find simple to follow Roadmaps, straightforward
articles,
informative Webcasts and more! Get everything you
need to get up
to speed, fast.
http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration
Strategies
from IBM. Find simple to follow Roadmaps, straightforward
articles,
informative Webcasts and more! Get everything you need
to get up
to speed, fast.
http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration
Strategies
from IBM. Find simple to follow Roadmaps, straightforward
articles,
informative Webcasts and more! Get everything you need
to get up
to speed, fast.
http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration
Strategies from IBM. Find simple to follow Roadmaps,
straightforward articles, informative Webcasts and more! Get
everything you need to get up to speed, fast.
http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration
Strategies from IBM. Find simple to follow Roadmaps,
straightforward
articles, informative Webcasts and more! Get everything
you need to
get up to speed, fast.
http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration
Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration
Strategies from IBM. Find simple to follow Roadmaps,
straightforward articles, informative Webcasts and more! Get
everything you need to get up to speed, fast.
http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&opÌk
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
