Two things I disliked about wicket-stuff:
1) Multiple projects providing similar functionality. This is fine if
there is a reason for using one over the other at different times, but
from what I can see there is no such difference. (I believe there are
two overlapping hibernate or data-view modules)
2) ... without meaning to step on anyone's toes here ... I feel that the
quality of the code in wicket-stuff is a level below that in
wicket-core. There are two factors: poor design and poor documentation.
By poor design, I mean it sometimes looks some of the code was created
as a prototype and when it was complete no one went back to refactor it.
By poor documentation I mean that most source code files have absolutely
no comments in them and the variable and method names are so short that
unless you were the original author you'd have no way of knowing what
the heck the code does or why. The point isn't whether or not you could
find this out by sitting down and analysing it for a few days. The point
is that you shouldn't have to.
I'd like to propose that all wicket-stuff code should have extensive
Javadoc for each method. One example that comes to mind (I don't mean to
pick on one author over another here) is "ois" standing for "Optimized
Insert <something>" which was being used by ListView. There were two
problems here:
1) The source-code referred to a variable name "ois" but no
documentation indicated what "ois" actually stood for or what it was
used for. So, either some documentation should have been added to do
this or the variable name should have been longer and more verbose; or both.
2) There was no documentation explaining what this mode does (versus the
normal mode) and when it was approriate to use one mode or the other. As
an example, Javadoc "Indicates if OIS is enabled" is utterly useless if
the user doesn't have a clue what OIS is. A while back wicket-core had a
similar bad Javadoc that read: "Enables autolink mode" but of course
"autolink mode" was never explained so users had no idea what happens
when you enable or disable it. Users shouldn't ever have to look at the
source-code to understand a class's functionality.
Just my 2 cents.
Gili
Martijn Dashorst wrote:
All,
There has been a lot of mixed feelings concerning the current state of
Wicket Stuff. As Wicket 1.1 is getting ready to steam roll out of our
door, we should be starting to address these concerns.
I try to list these concerns as voiced on the various lists:
- too many data(base) oriented packages without structure, documentation
and a definite vision
- too many sandbox projects that didn't finish/made a release
- too little documentation on all projects, no updates made to existing
- unclear who is responsible for which project
- different views on why Wicket Stuff was created
- different views on the lifecycle of the projects created on Wicket Stuff
The projects that have made it to a release are:
contrib-data 1.0 April 5, 2005
contrib-data-hibernate-2.1 1.0 April 5, 2005
contrib-data-hibernate-3.0 1.0 April 5, 2005
contrib-dojo 0.1 September 21, 2005
contrib-fvalidate 1.0 April 5, 2005
contrib-groovy 1.0 April 5, 2005
contrib-spring 1.0 April 5, 2005
contrib-velocity 1.0 April 5, 2005
wicket-kickstart 1.0.1 July 17, 2005
The Wicket kickstart project will be moved into the core project, so we
can forget about that one.
The contrib-data-* projects don't have a presence on the website, so in
my opinion, they haven't been released properly (yet).
Dojo, fvalidate, groovy, spring and velocity *do* have a web presence,
and in some cases the presence may be too small, but at least people can
find the projects.
If we look at the number of projects in the wicket-stuff CVS root
folder, we see a staggering number of efforts:
CVSROOT/
src/
wicket-contrib-ajax-sandbox/
wicket-contrib-beanedit/
wicket-contrib-benchmark/
wicket-contrib-data/
wicket-contrib-data-hibernate-2.1/
wicket-contrib-data-hibernate-3.0/
wicket-contrib-database/
wicket-contrib-dataview/
wicket-contrib-dataview-examples/
wicket-contrib-dojo/
wicket-contrib-easywizard/
wicket-contrib-easywizard-examples/
wicket-contrib-examples/
wicket-contrib-examples-hibernate3/
wicket-contrib-freemarker/
wicket-contrib-fvalidate/
wicket-contrib-gmap/
wicket-contrib-gmap-examples/
wicket-contrib-groovy/
wicket-contrib-jasperreports/
wicket-contrib-navmenu/
wicket-contrib-palette/
wicket-contrib-palette-examples/
wicket-contrib-scriptaculous/
wicket-contrib-scriptaculous-examples/
wicket-contrib-spring/
wicket-contrib-spring-examples/
wicket-contrib-tinymce/
wicket-contrib-tinymce-examples/
wicket-contrib-velocity/
wicket-easywizard/
wicket-library/
wicket-phonebook/
wicket-stuff/
xdocs/
I would like to propose that subgroups will be formed for administering
each project, and that those developers take responsibility for
maintainance, support, and releasing the project. For each release I
suggest we keep a minimum standard to which each project should adhere.
What those standards are, I don't know yet, but I would like the
community to come with suggestions requirements, etc for us developers
to act on.
What do you constitute a minimum requirement for a (sub)project to be
useful, noticable, and ready for a release? How do you percieve Wicket
Stuff, and how would you like to percieve Wicket Stuff in the future? Do
you have suggestions for the website?
Martijn Dashorst
--
http://www.desktopbeautifier.com/
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
