Re: Fragility/Stability of Wicket core
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.ember...@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
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.comwrote:
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*
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
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*
Re: Fragility/Stability of Wicket core
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
