Re: Scala-Wicket Help and Advice

[mb-td <mb...@thomas-daily.de>]

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.

Re: Scala-Wicket Help and Advice

[mb-td <mb...@thomas-daily.de>]

Thank you for the extensive overview! I wish you the best of luck and success
for this endeavour. Don't forget to let us know when a project website is up
and running :)

--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Scala-Wicket-Help-and-Advice-tp3174601p3475536.html
Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.

Re: Scala-Wicket Help and Advice

[richard emberson <ri...@gmail.com>]

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