A sympathetic voice on the Wicket mailing list, greetings.
I don't know if you have followed it all but I have ported
Wicket to Scala, replaced the Java collections with Scala
collections, pushed the IModel[T] strong typing down to the
Component object and have plans for more changes. But,
I wanted to get some advice and help. With regards to Scala,
where should the Scala-Wicket be heading?
I also believe that emphasising the non-object oriented features
of Scala will make it harder to attract Java programmers.
So, I want to use Scala's functional, advanced type classes,
implicits, and other such features very carefully if at all.
One idea that I've thought about was to factor out IModel 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.
Richard
On 01/06/2011 03:43 PM, Gustavo Hexsel wrote:
I'll have to say I looked at Lift, and although it was greatly improved
since 1.0, it doesn't have the awesome separation of concerns that wicket
does. Even in the tutorial, the markup and the templates leak into each
other. Wicket's greatest asset was always IMO the fact that the HTML itself
can be almost unmodified between designer and programmer (of course, usually
it pays to create components).
I've made a couple of toy projects in Scala/Wicket, and the biggest pain
was to get the collections and generics right. I don't much like the
implicit conversions (anywhere, even boxing and unboxing end up doing weird
stuff once in a while), so I always ended up having to do it by hand. It
made life easier to keep using the Scala collections, and just convert it to
Java collections in the Wicket Models, but once in a while it still messed
me up...
I would love to see a wicket api that used the Scala collections and made
models use SModels or something like that.
PS.: that's my opinion as a lurker... not a Wicket dev
On Thu, Jan 6, 2011 at 12:19 PM, Jonathan Locke<jonathan.lo...@gmail.com>wrote:
Not so sure that doing a simple fork of Wicket into Scala is such a great
idea. And at the end of the day you probably couldn't call it Wicket
without
Apache permission, which seems unlikely. But creating a Wicket-inspired
framework in Scala sounds like a good idea to me. Have you taken a look at
David Pollak's Lift project?
Regarding Scala, I think it's a good sign that people are interested in
advancing the state of the art. And I think Martin and company have found
some of the problems that need solving and to their great credit done
something about them, even if only 0.4% of programmers are using Scala so
far. Unfortunately, I don't think a large or powerful or killer set of
features is what makes or breaks a language in terms of widespread
adoption.
And I *especially* don't think that economy of expression makes a language
"better", particularly where large teams are concerned. Clarity, precision
and simplicity are far more important than brevity and power.
Jon
"Less is more."
http://www.amazon.com/Coding-Software-Design-Process-ebook/dp/B0042X99SA/
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Scala-Wicket-Help-and-Advice-tp3174601p3178126.html
Sent from the Forum for Wicket Core developers mailing list archive at
Nabble.com.
--
Quis custodiet ipsos custodes
