On Wed, Jan 5, 2011 at 9:38 AM, Juergen Donnerstag < juergen.donners...@gmail.com> wrote:
> Cool. May I ask which tools (IDE) you've been using and what your > experience with these tools has been. > #scala suggests IDEA 10 + SBT plugin as the most mature one. > > -Juergen > > On Wed, Jan 5, 2011 at 2:34 AM, Jeremy Thomerson > <jer...@wickettraining.com> wrote: > > On Tue, Jan 4, 2011 at 5: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 haven't used CLOC before. I've used Ohcount ( > > http://www.ohloh.net/p/ohcount) and like it. I'll have to give this a > try. > > > > > > 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? > >> > > > > If you're looking for a place to host it, I'd recommend starting with > > Github. Git is where the crowd is headed, and Github is the easiest > place > > to get up and running with it these days. > > > > You mentioned earlier the idea of it being an Apache project. If you > wanted > > it to be an Apache project, you would start at the Incubator ( > > http://incubator.apache.org/). The one barrier you'll have initially is > > that Apache favors "community over code"... so it's not a great place to > > start a one-man project. Since this is a port of an existing Apache > > project, you might have more leniency, but you'd have to build a > community > > around the project before you could ever "graduate" from the incubator. > > > > Probably Github is your best bet for now. Build a community. Then, if > your > > community is in favor, move to Apache. By that time, ASF might have full > > git support. > > > > > >> Are there any mechanism to help fund such an open-source project? > >> > > > > Best bet is to build a community. Of course, if you can find some > company > > that wants such a project, you can get monetary support to develop / > > maintain. But that seems unlikely in this case with the limited number > of > > companies looking for Scala out there, and especially since this is an > > unproven port of a large Java project. So, start by getting folks like > > jWeekend involved - great coders who are already salivating for Scala. > Find > > other individuals such as yourself who are interested, and build a group > of > > core committers. > > > > > >> 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 > > > > > > I'm impressed. Quite an undertaking. > > > > -- > > Jeremy Thomerson > > http://wickettraining.com > > *Need a CMS for Wicket? Use Brix! http://brixcms.org* > > >
