I haven't had time to read all of this (hard to get through it all on my phone), but I don't think that mere "port" of Wicket to Scala is what is needed. I'd rather see a project built for Scala from the ground up based on some of the concepts from Wicket. Wicket wasn't designed with a functional programming language in mind and I think there are a lot of places where the functional style could simplify things quite a bit. I am very interested in seeing what you have put together. Are you planning on putting the code up on Github or something?
On Tue, Jan 4, 2011 at 6:15 PM, richard emberson <richard.ember...@gmail.com> wrote: > Dev Wicketers, > > What: I have ported Wicket to Scala > A couple of months ago I took a 1.5 snapshot and ported to Scala. > This encompasses all of the source and test code. As successive 1.5 > snapshots were released, I ported those differences to my Scala > version. I am current with 1.5 M3. > > The Java 137,791 loc in 1.5 M3 are now 100,077 loc Scala (not > counting all the println statements I put into the Scala code > for debugging). I used cloc (http://cloc.sourceforge.net/) to > count lines of code. > > I have also replaced all of the Java collection classes with > Scala collection classes (though a small number of Java collection > classes remain that did not have comparable Scala implementations). > > I have changed many method return types from the Java returning > some "object" or "null" to Scala returning "Some(object)" or "None" > (using the Scala Option[return-type] construct) - trying to > eliminate nulls. > > Lastly, I pushed the IModel[T] typing down to the Component class > making get/set DefaultModel and get/set DefaultModelObject strong > typed. This included using Scala companion object apply methods > which eliminated having to explicitly declare type parameters in > most end-user code (I had read that one of the objections to > pushing strong typing down to the Component class in Wicket was > that there were "too many notes", end-user code was too verbose). > > It can not interoperate with Java Wicket because Scala compiles to > JVM class files and so all of the classes in Java Wicket also > appear in Scala-Wicket. > > I have an "internal" name for my Scala port of Wicket which > acknowledges its Wicket heritage as well as advertises its > enterprise level capabilities. For external communications, > I am currently simply call it Scala-Wicket. > > Why: Scala is a better Java > I was introduced to Scala 9 months ago and quickly determined that > it was a better Java (at least IMO). For Scala to succeed it > requires more programmers to use it. Many on the Scala mailing > lists were from a functional background and seemed not to recognize > that Haskell and Lisp are not blindingly successful but, rather, > niche languages and that the heavy selling of Scala's function and > typing capabilities might turn off Java programmers. > > Scala struck me in many ways as a strong-typed JavaScript, at > least, much of the code did not have to have type declarations > because the compiler could infer types in many cases. In addition, > a whole lot of the Java boil-plate code was not needed. As such, > it could be sold as simply a better Java; a more-to-the-point > object oriented language with functional programming in-the-small. > > To get more Java programmers to try Scala I looked for a > significant Java application with a strong support and user > community that I could port to Scala. I ended up with Wicket. > Wicket is an enterprise level web framework (unlike existing > Scale web frameworks which place restrictions on enterprise IT > organizations, e.g., by requiring sticky sessions). It is well > documented. And, as it turned out, very, very importantly it had > a large number of unit tests (the unit tests saved my butt, > without them I would never had succeeded in getting a port that > worked). > > No, Really, Why: > I like Scala and I took the time to learn it. Right now about > 20% of programmers use Java while only some 0.4% use Scala. > I did not want my effort of learning Scala to be wasted so my > solution is to increase the number of Scala programmers. Where > to get them? Again, my solution is from the existing horde of > Java programmers. > > Plans: Release, Evolve and Proselytize > I would like to release Scala-Wicket. > I do not know if Apache hosts anything other than Java code. > Growing a community is important. > > Still Todo: > Comments: All of the existing class and inline comments are > still Java related. This would have to be a long, on-going > task to edit the comments so they reflect the code's > Scala usage. > Package path: The code still uses the "org.apache.wicket" > package path and this must be changed - unless this became > an Apache project. > Author: I have quite literally looked at and touched every line > of code but I have not yet felt comfortable with adding > myself as an author since, well, many changes were > syntactic and not semantic. > Refactor with Traits: Currently the port uses Scala traits like > Java interfaces but it should be possible to factor the > common code out into the traits. This would result in many > of the interfaces, the "I" files, such as IModel.scala, > going away. > Some general refactoring: > As an example, consider factoring out the IModel[T] from > Component. Half the time a user wants a Component with > no model, so, if there was a HasModel trait: > class Model[T](var value: T) { > def getObject: T = value > def setObject(value: T): Unit = this.value = value > } > trait HasModel[T] { > var model: Model[T] > def getDefaultModel: IModel[T] = model > def setDefaultModel(model: IModel[T]): this.type = { > .... > this > } > def getDefaultModelObject: Option[T] = { > .... > } > def setDefaultModelObject(obj: T): this.type = { > .... > this > } > } > The Component hierarchy would have no model support. > The user could add model support when needed: > val form = new Form("hi") > with HasModel[Int] { var model = new Model(42) } > Just an Idea. > STM: There are a number of Scala STM projects and I do not know > if it is useful to add STM capabilities to Scala-Wicket. > RBAC: I've written a Scala implementation of the NIST RBAC > recommended standard and might consider adding it. > Logging: Adding a Scala-based logging framework to aid user > debugging. > Monitoring and stats: In the last couple of years many web > sites have added monitoring and statistics gathering > capabilities (e.g., who clicks what, where, how long, on > what page does the visitor exit the web site, etc.) in > order to know how the web site is being used and then > improve the web site. > Significant Memory Usage Reduction: I've an idea that would > significantly decrease the memory usage of Scala-Wicket and > I plan to do a test implementation. > Replace Java features: There are still some Java-isms that can > be replaced with Scala equivalents. > Port additional Java Wicket libraries to Scala. > Enable multiple instances of a unit tests to be run at once. > More: ???????????? > > I want to avoid using some of the WTF features of Scala (when a > Java programmer looks at the code and says "WTF") in order to > ease and accelerate acceptance by Java programmers; as > examples, implicits can make code hard to understand and > advanced Scala type usages, as James Gosling said, "makes one's > head spin". > > > Help and Advice: How should Scala-Wicket be extended and released > > Scala-Wicket is a port and evolution of Wicket, not a ground-up > re-write. Given that, what would you do differently in Wicket > now that there are years of experience using it? > > How best to get a hosting site, release the code and build a > community? > > Are there any mechanism to help fund such an open-source project? > > This is not meant to be a general announcement but rather a means > for me to get some initial advice as to how to proceed. > > Any help is appreciated. > > Richard Emberson > > > -- > Quis custodiet ipsos custodes >
