I would like to completely clean out wicket-data and wicket-data-hibernate3. Basically, leave it all up to the dataview package except for some of the Hibernate3 helpers. We may want to keep Eelco's ListView helpers, but I'd like to get rid of all the stuff I wrote if that's cool with people. It's just duplicating functionality and confusing people.
On 10/16/05, Gili <[EMAIL PROTECTED]> wrote: > > 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 > > ------------------------------------------------------- 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
