it looks to me like one detail of the existing IPageableComponent
that's probably flat
wrong is the existence of getItemCount(), which is being used to
adjust the list index
in a listview. that's no business of a general paging component
that's designed to be
replacable and modular and i suspect it shouldn't be part of the
interface. how the paged
thing adjusts its internal index variable to locate page N is an
implemenation detail that
should not be part of the contract.
the business of a paging component should be to do paging. not a
bunch of other stuff,
don't you think? once we've built a basic paging component that can
be used anywhere
for anything, we can make a specialized one that pages a list view or
whatever. how
uh, i didn't mean this... ;-) i meant that we should have the pageable
list view implement
IPageable the paging component used to page the list view should be
fully independent
of the list view. it's just an IPageable thing, like any other. one
can imagine something like a
DVD chapter list or the pages of a short e-book or a million other uses
for a paging component...
let's fix this right.
the item index is maintained or whether the thing is a component is an
implementation detail
of a particular kind of IPageable.
okay, i'm done rambling.
does this make more sense?
-Igor
Igor Vaynberg wrote:
Just thought of adding getComponent() to
IPageableComponent, still a
hack in my opinion.
-Igor
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Igor
Vaynberg
Sent: Tuesday, August 02, 2005 5:04 PM
To: wicket-user@lists.sourceforge.net
Subject: RE: [Wicket-user] Sigin Example
I can see your point. My thinking has always been that
any abstract
class has an implicit interface which is the sum of its public
methods, and that there really is no difference between evolving
public methods in an abstract class and evolving an interface and
its single implementation. This is of course different when an
interface is intended as a joint point between two
systems or when
alternate implementations are expected.
I am far more interested in finding a good solution for the
IPageableComponent than discussing philosophies.
The need for this arose when I was writing DataView. I wanted to
reuse navigation components that worked with listview, such as
PageableListViewNavigation,
PageableListViewNavigationLink, etc. In
their current state they were tightly coupled to
listview, so I had
to decouple them, thus the IPageableComponent interface.
Inside it
it has all the methods that those navigation components need to
manipulate the listview, so now instead of getting the listview
directly they get an instance of IPageableComponent and do the
manipulation through that.
Now all my dataview had to do is implement
IPageableComponent and it
could magically be navigated by the navigation components.
Pretty clean and simple, however, the navigation
components expect
IPageableComponent to also be a component. For example,
PageableListViewNavigationLink needs access to the page that the
pageable component is on. Because of this I had to add a Page
getPage() implemented by Component to the interface. This is the
part that I am trying to find a cleaner solution for, and this is
why I suggested Icomponent. If we had Icomponent
IPageableComponent
could extend that and also be used as a regular component.
An alternate solution I can see is to get rid of
IPageableComponent
and use a PageableAdapter class with a getComponent()
method inside.
So instead of PageableListViewLink(...., dataview) it would be
PageableListViewLink(...., new PageableAdapter(dataview)). This
solution seems a bit unnatural to me because it goes around the
inheritance hirarchy.
What are your thoughts?
Thanks,
Igor
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Jonathan
Locke
Sent: Tuesday, August 02, 2005 3:41 PM
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] Sigin Example
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-too
lbox.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
-------------------------------------------------------
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=ick
_______________________________________________
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
-------------------------------------------------------
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
-------------------------------------------------------
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
