STATUS
4/21/11
Waiting for final release of Wicket 1.5.
Status:
Scala-Wicket at Wicket version 1.5 RC3
About 50% of WicketStuff version 1.5 RC3 ported to Scala
(something to do while waiting for Wicket 1.5)
Scala-Wicket is about 1/2 the number of lines of code (or,
1/2 the number of CRs) - Scala code tends to be denser
or, another way of saying it, Java has a lot of needless
verbosity and boiler plate code.
Replaced Java collections with Scala collections.
Many places the use of null return values has been replace with
the use of Option.
Many places the construct:
if (component instance Form) {
Form form = (Form) component
...
}
has been replace with:
component match {
case form: Form => ...
case _ => // nothing
}
but more need to be converted.
Strong typing has been pushed down to Component. In Java
Wicket, a Component's Model's object is not typed. In the
Scala version it is typed. This makes things more verbose
but the code is strong typed. For example, the signature of
a Component with its parametric type with a Model object of
type String is now "Component[String]"
For the version 2 release of Scala Wicket, this will be
simplified.
Converted Ant build system to use either: Maven, Ivy or one's own
local repository. This is controlled by the value of
an Ant property.
And bunches of other things.
Plans:
After Wicket 1.5 final is merged into existing Scala code
I need to do the following:
Choose a name since there is resistance in the Wicket
community to calling it ScalaWicket (which was only a
working name anyway);
With the name chosen, all of the package paths will have
to be changed (from org.apache.wicket to, for example,
org.thenewdomainname). I do not know if the apache
organization would like the Scala version as a project.
Get a domain and web-site reflecting the name.
Find a site where the source can be located. Currently, I
am using SVN and don't expect to change for the first release.
I would like to do the following:
During porting I had to put lots of println statements into
the code just to figure out what was happening (or not
happening as the case may be). I'd like to convert them
to logging code.
This will lead to a version 1.0.
Future Plans:
It has become clear through some testing that using Scala's
traits as mixins can significantly lower memory usage.
As a not very useful example, consider a Parent Trait:
trait Parent[T] {
private var parent: T
def getParent: T = parent
protected def setParent(parent: T) : Unit = this.parent =
parent
}
Currently, all Components have a parent instance variable. Using
the Parent Trait, Page Components which do not have a parent
will not have to pay the overhead of the parent instance variable.
Yea, not much savings, but, where as, Java at most can have a
single trait-like mixin in the form of an abstract base class,
with Scala one can have any number of such mixin traits ... And
there are many cases where not all of the stuff in Component and
MarkupContainer are need for all components (Component and
MarkupContainer are rather bloated as classes go).
As an example, how may Label Components need a Model? So, having
a Model will be a mixin. Also, some Components will have a model
and never need to change to a different Model. For such Components
the Model instance variable can be eliminated.
I imagine most of the interfaces, traits with no implementation,
will be changed to mixin traits with implementations.
With such mixins, the signature of a Component will once again
be simply "Component".
Plan to understand why the Wicket community says that it is not
reasonable to share the in-memory representations of the HTML
between user sessions. Which is to say, the HTML in the various
HTML files are shared across sessions but the Java Component
hierarchy associate with the HTML is not shared. Clearly, per user
data can not be shared, but have to better understand the limits
of the Component hierarchy that precludes its sharing across users.
Plan to understand better the various Component hierarchy traversals
that take place, such as the render traversal. There is a
bunch of stuff happening and some of it looks like it grew
organically as special cases rather than obeying a uniform
architecture. Also, it appears that during the same traversal the
same code for the same Component is call multiple times.
Scala supports the principle of uniform access. Java Wicket uses
the Java bean approach with getters and setters. Have to see
if this should be changed in the Scala version from bean to
uniform access.
Like to add the ability to monitor and collect statistics concerning
usage patterns with the ability to easily conduct experiments and
modify pages.
This will lead to a version 2.0. I hope this happens quickly. Also,
I hope to get user community support for determining what needs to
be done.
Additional Plans and Issues:
Convert comments from JavaDoc format to ScalaDoc format.
Can/should Scala parallel collections be used.
Should Scala STM be used when committing multiple Model objects.
Review the use of ListBuffer vs ArrayBuffer and should collection
signatures be of type Seq.
Currently, in the Component constructor on-initialization listeners
are triggered. This is very, very bad, the objects are not yet
fully
constructed by they are given out to arbitrary code. Is there
a better Scala approach.
Well, thats the way it is.
Richard
On 04/21/2011 10:38 AM, mb-td wrote:
Is the port still in progress? Please write one or two lines about the
status.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Scala-Wicket-Help-and-Advice-tp3174601p3466499.html
Sent from the Forum for Wicket Core developers mailing list archive at
Nabble.com.
--
Quis custodiet ipsos custodes
