You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by richard emberson <ri...@gmail.com> on 2011/01/09 02:03:54 UTC
Fragility/Stability of Wicket core
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.
[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
--
Quis custodiet ipsos custodes
Re: Fragility/Stability of Wicket core
Posted by Martin Grigorov <mg...@apache.org>.
Richard,
This is how wrapped models work by design.
They need to know the component they are assigned to to be able to find the
resource bundle.
And the owning component needs to know its parent to be able to look in all
resource locators (component, package, application, ...).
It is the same with components which want to work with their markup - they
need to be either component-with-associated-markup, like Page or Panel, or
they need to know their parent-with-associated-markup to be able to find the
piece in markup which is for this component.
It may look to you that it is wrong/inconsistent/... but actually this is by
design.
I hope it is clearer now.
On Sun, Jan 9, 2011 at 3:01 AM, richard emberson <richard.emberson@gmail.com
> wrote:
>
>
> On 01/08/2011 05:16 PM, Jeremy Thomerson wrote:
>
>> 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).
>>
>
> From the ResourceModelTest.java
>
> IModel model = new ResourceModel("test.label");
>
> Model is constructed.
> Can you call model.getObject() yet? No.
>
> Label l = new Label("testlabel", model);
>
> Component containing Model is constructed.
> Can you call model.getObject() yet? No.
>
> add(l);
>
> Parent Component containing Component which contains
> the Model is constructed.
> Can you call model.getObject() yet? Finally, Yes.
>
> If the advice to a user is to not print any debugging information about
> any state until the application is completely constructed, then, that,
> in generally, really would be amazing.
> I think ResourceModel is a special case that depends upon being is
> a fully constructed Component tree. Just as a Model which communicates
> with a DB can not be interrogated until its connected to the DB.
>
> As an addition, if such pieces that require some level of supporting
> infrastructure prior to interrogation had comments warning the
> user that they needed special care, most users would not remember
> such admonishments while adding general debugging statements
> (especially, if
> the object in question (a Model) was one of a number of such types
> of objects (Models) where most of the types are safe under examination.)
>
>
>
> Richard
> --
> Quis custodiet ipsos custodes
>
Re: Fragility/Stability of Wicket core
Posted by richard emberson <ri...@gmail.com>.
On 01/08/2011 05:16 PM, Jeremy Thomerson wrote:
> 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).
From the ResourceModelTest.java
IModel model = new ResourceModel("test.label");
Model is constructed.
Can you call model.getObject() yet? No.
Label l = new Label("testlabel", model);
Component containing Model is constructed.
Can you call model.getObject() yet? No.
add(l);
Parent Component containing Component which contains
the Model is constructed.
Can you call model.getObject() yet? Finally, Yes.
If the advice to a user is to not print any debugging information about
any state until the application is completely constructed, then, that,
in generally, really would be amazing.
I think ResourceModel is a special case that depends upon being is
a fully constructed Component tree. Just as a Model which communicates
with a DB can not be interrogated until its connected to the DB.
As an addition, if such pieces that require some level of supporting
infrastructure prior to interrogation had comments warning the
user that they needed special care, most users would not remember
such admonishments while adding general debugging statements
(especially, if
the object in question (a Model) was one of a number of such types
of objects (Models) where most of the types are safe under examination.)
Richard
--
Quis custodiet ipsos custodes
Re: Fragility/Stability of Wicket core
Posted by Liam Clarke-Hutchinson <li...@steelsky.co.nz>.
> 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
<je...@wickettraining.com>wrote:
> On Sat, Jan 8, 2011 at 7:03 PM, richard emberson <
> richard.emberson@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*
>
Re: Fragility/Stability of Wicket core
Posted by Jeremy Thomerson <je...@wickettraining.com>.
On Sat, Jan 8, 2011 at 7:03 PM, richard emberson <richard.emberson@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*