> 2 - If you want to use Wicket *in Scala*, work on a transparent layer that
sits on top of "stock Wicket" and adds nice features that would be useful to
the Scala crowd.
I'm already writing all my personal Wicket in Scala. Works well.
On Sun, Jan 9, 2011 at 2:16 PM, Jeremy Thomerson
<jer...@wickettraining.com>wrote:
> On Sat, Jan 8, 2011 at 7:03 PM, richard emberson <
> richard.ember...@gmail.com
> > wrote:
>
> > Ok, you need to debug whats in a Model when it is added to
> > a Component. So, in setModelImpl which is called by the
> > Component constructor you add code to get the object
> > out of the Model (if its not null, of course) by calling
> > model.getObject():
> >
> > void setModelImpl(IModel<?> model)
> > {
> > if (model != null) {
> > System.out.println("Component.setModelImpl: model.object="+
> > model.getObject());
> > }
> > .....
> > }
> >
> > Well, just adding this simple code causes a JUnit test to fail.
> > (And, if you added this debugging a couple of editing cycle prior
> > to running all the tests, you've got the problem of even knowing
> > that this is the offending code.)
> >
> > Why? Give up.
> > Its because in a Component's constructor the Component has not
> > yet been added to its parent Component. Thus, the Component's
> > path only has it as a member. Which means that if the Model
> > was a ResourceModel, which BTW is wrapped!!!, calling getObject
> > gets the wrong path for the resource, the resource lookup
> > fails, and the world ends.
> >
> > For most folk this is never a problem, even for most developers
> > because they are making changes to a working Wicket core.
> > But for me, on the other hand, porting it to Scala where only
> > bits and pieces worked originally, I ran into this kind of
> > hidden side effect .... well, it seemed like all the time, but
> > it was once and a while ... but it take time to figure out the
> > issue.
> >
> > Anyway, amazing that simply asking a model for its inner object
> > can end the world if you do it at the wrong place.
> > Ok, all software is fragile like this - one thing wrong that
> > bang - but it took an hour to find the little innocuous bit of
> > code.
> >
>
> Not all that amazing. This is happening *during construction* which always
> leaves objects in fragile states. It's assumed that you can't start
> monkeying around with an object's state until construction is completed
> (and
> not expect side effects).
>
>
> > [I actually put code, kind of like a constraint, in setModelImpl
> > to make sure that any model added never had, as an object,
> > an Option: Some(value) or None; looking for a totally unrelated bug.]
> >
> > I feel better now, thank you for your time and patience.
> >
> > Richard
> >
>
> I agree with what others on your scala thread said:
>
> 1 - If you want a Scala framework *like* Wicket, start writing Scala code
> from the ground up with ideas taken from Wicket. Some code could perhaps
> be
> ported over in small pieces. But not large sections (or the whole thing
> like you're trying).
>
> 2 - If you want to use Wicket *in Scala*, work on a transparent layer that
> sits on top of "stock Wicket" and adds nice features that would be useful
> to
> the Scala crowd.
>
> You have said that your goal is to "port" java developers to Scala. I'm
> interested in trying Scala at some point. I would try either option one or
> two above.... I would prefer two. With it, I get to keep my Wicket
> expertise and incrementally add *new hotness* from Scala. I am very
> unlikely to try a modified port such as the one you are trying to do. It's
> learning a whole new thing all at once, with annoying similarities to
> something I know, but inconsistencies that I wouldn't expect.
>
> In my book, 2 is your best bet.
>
> (only my $0.02 in a declining economy)
>
> --
> Jeremy Thomerson
> http://wickettraining.com
> *Need a CMS for Wicket? Use Brix! http://brixcms.org*
>
