On Tue, Nov 9, 2010 at 11:55 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
um. no. queued components cannot be moved out of their parent. so if
you queued field1 under form1 and the designer moves the tag tied to
field1 outside the tag tied to form1 you will get the same error you
would get
On Tue, Nov 9, 2010 at 11:50 AM, Frank Silbermann
frank.silberm...@fedex.com wrote:
I don't understand your example. You have two forms on one panel. You
wish to move a field (of one of the forms?) to another panel. Doesn't
that imply that you've taken the field out of the form?
Not to
ive outlined a couple of usecases when this is useful in another
email. see there.
-igor
On Tue, Nov 9, 2010 at 8:56 AM, James Carman ja...@carmanconsulting.com wrote:
On Tue, Nov 9, 2010 at 11:55 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
For security reasons in general,
yes, and that would of course be a mistake. if you just queue
everything into the page you can cause serious security problems.
sometimes you have a hard container you want your components to live
under, and other times you dont care. you should always queue into the
hard container, just like you
On Tue, Nov 9, 2010 at 11:55 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
For security reasons in general, you might want to use:
formA.queue(formAstuff);
formB.queue(formBstuff);
But then you're right back where you started. Why not just add and
not queue?
On Tue, Nov 9, 2010 at 12:00 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
yes, and that would of course be a mistake. if you just queue
everything into the page you can cause serious security problems.
sometimes you have a hard container you want your components to live
under, and other
The point is that this new approach can allow the designer to move
things around, potentially changing the semantics of how things work.
For example, a TextField may have validators set up on it that are
applicable within the context of one type of form, but may be
completely inappropriate in
On Tue, Nov 9, 2010 at 12:00 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
http://apache-wicket.1842946.n4.nabble.com/forum/PrintPost.jtp?post=3034640
Did you mean to try to make me print this post?
-
To
martin.maku...@koodaripalvelut.com wrote:
http://apache-wicket.1842946.n4.nabble.com/forum/PrintPost.jtp?post=3034640
Did you mean to try to make me print this post?
Hehe... I did not find antoher way to point to a single post ;]
**
Martin
On Tue, Nov 9, 2010 at 12:06 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
(You) as a coder will be responsible for opening that can ;] For good
and for bad. Not wicket. Nor members of this discussion.
How many times have you done this:
add(new TextField(...))
when you meant
Hi!
First of all, normally I have junit tests that validate the
functionality for me for regression purposes.
Suppose the user does:
queue(new TextField(...))
which will work perfectly fine, but they meant to do (to enforce security):
someSubComponent.queue(new TextField(...))
Now,
On Tue, Nov 9, 2010 at 12:22 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
Yes, if you are unsure, you should use add() to make sure. You get
that extra security with that extra effort, if you want.
Again, the point is (regardless of unit tests) that you can
unknowingly do
Again, the point is (regardless of unit tests) that you can
unknowingly do something that allows stuff to break later quite
easily.
I wouldn't call it unknowingly if you are stating it now before the
feature has been implemented.
**
Martin
On the other hand if you only have to do component nesting
programmatically in case of functional reasons (like security) your code
will probably much cleaner and you'll realize issues like using the
wrong parent faster.
Instead of:
myComponent.add(child1)
child1.add(child2)
On the other hand if you only have to do component nesting programmatically
in case of functional reasons (like security) your code will probably much
cleaner and you'll realize issues like using the wrong parent faster.
+1
Very good point: cleaner code! Finally complex wicket pages will
On Tue, Nov 9, 2010 at 12:29 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
I wouldn't call it unknowingly if you are stating it now before the
feature has been implemented.
The user can queue stuff to the wrong component unknowingly because
they won't get an exception. Then
On Tue, Nov 9, 2010 at 12:33 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
Very good point: cleaner code! Finally complex wicket pages will look
like their hello-world counterparts.
You're becoming a bit irrational here, Martin. Let's try to stay on
point. He brings up a
The user can queue stuff to the wrong component unknowingly because
they won't get an exception.
You will get an exception if you queue explicitly to the wrong
component. If you don't care about the parent component, it 's their
choie (good or bad) ;)
Then later a markup change could
On Tue, Nov 9, 2010 at 12:38 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
You will get an exception if you queue explicitly to the wrong
component. If you don't care about the parent component, it 's their
choie (good or bad) ;)
You're not understanding what I'm saying. I'm
You're not understanding what I'm saying. I'm saying they're not
consciously making a *choice*; they're queueing the component to the
wrong parent on accident, but they aren't getting an exception. This
can lead to problems later on.
So you mean that if a manufacturer manufactures a gun
On Tue, Nov 9, 2010 at 12:43 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
So you mean that if a manufacturer manufactures a gun they are not
conciously making the decision that somebody is getting shot?
Ok, I'm officially done with this conversation. I've voiced my
opinion.
Very good point: cleaner code! Finally complex wicket pages will look
like their hello-world counterparts.
You're becoming a bit irrational here, Martin. Let's try to stay on
point. He brings up a valid point and we should respect his opinion,
much like we're respecting yours. Remember,
, November 09, 2010 9:23 AM
To: users@wicket.apache.org
Subject: Re: Free wicket from component hierarchy hell
So instead of asking, How can we make Wicket different so that my
problem will go away? the proper question to try first is, What is
the
Wicket way of solving my problem?
That's not how
if
you don't yet understand how to use the powers it already has.
-Original Message-
From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com]
Sent: Tuesday, November 09, 2010 9:23 AM
To: users@wicket.apache.org
Subject: Re: Free wicket from component hierarchy hell
So instead
if
you don't yet understand how to use the powers it already has.
-Original Message-
From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com]
Sent: Tuesday, November 09, 2010 9:23 AM
To: users@wicket.apache.org
Subject: Re: Free wicket from component hierarchy hell
So instead
-
From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com]
Sent: Tuesday, November 09, 2010 9:23 AM
To: users@wicket.apache.org
Subject: Re: Free wicket from component hierarchy hell
So instead of asking, How can we make Wicket different so that my
problem will go away? the proper
.
-Original Message-
From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com]
Sent: Tuesday, November 09, 2010 9:23 AM
To: users@wicket.apache.org
Subject: Re: Free wicket from component hierarchy hell
So instead of asking, How can we make Wicket different so that my
problem
the queue() method is there in addition to add(), so you dont have to
use it. yes, it is riskier to use under some circumstances because it
is more forgiving then add() - but thats the point i think.
-igor
On Tue, Nov 9, 2010 at 9:41 AM, James Carman ja...@carmanconsulting.com wrote:
On Tue,
On Tue, Nov 9, 2010 at 9:38 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
The user can queue stuff to the wrong component unknowingly because
they won't get an exception.
You will get an exception if you queue explicitly to the wrong
component. If you don't care about the
[mailto:martin.maku...@koodaripalvelut.com]
Sent: Tuesday, November 09, 2010 9:23 AM
To: users@wicket.apache.org
Subject: Re: Free wicket from component hierarchy hell
So instead of asking, How can we make Wicket different so that my
problem will go away? the proper question to try first is, What
understand how to use the powers it already has.
-Original Message-
From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com]
Sent: Tuesday, November 09, 2010 9:23 AM
To: users@wicket.apache.org
Subject: Re: Free wicket from component hierarchy hell
So instead of asking, How can
[mailto:martin.maku...@koodaripalvelut.com]
Sent: Tuesday, November 09, 2010 9:23 AM
To: users@wicket.apache.org
Subject: Re: Free wicket from component hierarchy hell
So instead of asking, How can we make Wicket different so that my
problem will go away? the proper question to try first is, What
On Tue, Nov 9, 2010 at 12:20 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
I frankly don't see any way to have this auto-hierarchy stuff
without getting lots of unnecessary ambiguity and sources of bugs. I
totally agree with what Eelco wrote below, and what someone else said
...@koodaripalvelut.com]
Sent: Tuesday, November 09, 2010 9:23 AM
To: users@wicket.apache.org
Subject: Re: Free wicket from component hierarchy hell
So instead of asking, How can we make Wicket different so that my
problem will go away? the proper question to try first is, What is
the
Wicket way
suggestions about extending
Wicket if
you don't yet understand how to use the powers it already has.
-Original Message-
From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com]
Sent: Tuesday, November 09, 2010 9:23 AM
To: users@wicket.apache.org
Subject: Re: Free wicket from
Hi,
an easy example is:
tr wicket:id=repeatertdspan wicket:id=first/ span
wicket:id=last//td/tr
now the designer wants tds to have a css class based on some
condition. you now have to add a webmarkupcontainer to represent the
td and renest first and last labels into it. the container is
On Tue, Nov 9, 2010 at 12:03 PM, Sven Meier s...@meiers.net wrote:
Hi,
an easy example is:
tr wicket:id=repeatertdspan wicket:id=first/ span
wicket:id=last//td/tr
now the designer wants tds to have a css class based on some
condition. you now have to add a webmarkupcontainer to represent
Wicket if
you don't yet understand how to use the powers it already has.
-Original Message-
From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com]
Sent: Tuesday, November 09, 2010 9:23 AM
To: users@wicket.apache.org
Subject: Re: Free wicket from component hierarchy hell
So
wtf is with all the stupid and, more importantly, broken analogies? if
you wouldve kept quiet instead of spouting all this garbage i bet a
lot more people wouldve been receptive to the idea. you are digging
your own hole. id like to think we are all practical people, so stick
to practical points.
[mailto:martin.maku...@koodaripalvelut.com]
Sent: Tuesday, November 09, 2010 9:23 AM
To: users@wicket.apache.org
Subject: Re: Free wicket from component hierarchy hell
So instead of asking, How can we make Wicket different so that my
problem will go away? the proper question to try first
wicket from component hierarchy hell
So instead of asking, How can we make Wicket different so that my
problem will go away? the proper question to try first is, What
is
the
Wicket way of solving my problem?
That's not how proggress is made...
**
Martin
[mailto:martin.maku...@koodaripalvelut.com]
Sent: Tuesday, November 09, 2010 9:23 AM
To: users@wicket.apache.org
Subject: Re: Free wicket from component hierarchy hell
So instead of asking, How can we make Wicket different so that my
problem will go away? the proper question to try first is, What
if
you don't yet understand how to use the powers it already has.
-Original Message-
From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com]
Sent: Tuesday, November 09, 2010 9:23 AM
To: users@wicket.apache.org
Subject: Re: Free wicket from component hierarchy hell
So instead
Makundi [mailto:martin.maku...@koodaripalvelut.com]
Sent: Tuesday, November 09, 2010 9:23 AM
To: users@wicket.apache.org
Subject: Re: Free wicket from component hierarchy hell
So instead of asking, How can we make Wicket different so that
my
problem will go away? the proper question to try first
I'm sorry to say, but the whole discussion makes little sense to me and
these attempts to fix something that is not broken actually scares me a bit.
As far as I understand the philosophy of Wicket it is a Java centric and
Java code drive web application framework. This makes it very unique to
I'm sorry to say, but the whole discussion makes little sense to me and
these attempts to fix something that is not broken actually scares me a bit.
+1
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For
it is not about fixing something that isnt broken, its about making it
easier. anyways, i just updated the readme in my experimental branch
that explains the solution a bit more:
https://github.com/ivaynberg/wicket/tree/component-queuing
-igor
On Mon, Nov 8, 2010 at 8:23 AM, Vitaly Tsaplin
I'm sorry to say, but the whole discussion makes little sense to me and
these attempts to fix something that is not broken actually scares me a bit.
+1
It's maybe not broken for you. For me it's like dabbling in a swamp
(http://kuvablogi.com/nayta/prev/img1483294.jpg,
My only hope is that the solution you end up with will not make us
running some sort of script against all the sorces we have.
On Mon, Nov 8, 2010 at 7:30 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
I'm sorry to say, but the whole discussion makes little sense to me and
these
wtf, srsly?
-igor
On Mon, Nov 8, 2010 at 8:30 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
I'm sorry to say, but the whole discussion makes little sense to me and
these attempts to fix something that is not broken actually scares me a bit.
+1
It's maybe not broken for you.
My only hope is that the solution you end up with will not make us
running some sort of script against all the sorces we have.
We ended up with the requirement that it should 100% compatible with
existing code and tests.
**
Martin
Vigor,
as I understand the readme the queue method basically has only a
slightly different behavior compared to the add method in the way that
it either adds a component as a direct child to the parent or as a
sub-child as defined in the markup. So the markup is only used to
determine the
as I understand the readme the queue method basically has only a slightly
different behavior compared to the add method in the way that it either adds
a component as a direct child to the parent or as a sub-child as defined in
the markup. So the markup is only used to determine the child's
On Mon, Nov 8, 2010 at 8:51 AM, Sebastian nospam...@gmx.net wrote:
Vigor,
as I understand the readme the queue method basically has only a slightly
different behavior compared to the add method in the way that it either adds
a component as a direct child to the parent or as a sub-child as
On Mon, Nov 8, 2010 at 8:58 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
as I understand the readme the queue method basically has only a slightly
different behavior compared to the add method in the way that it either adds
a component as a direct child to the parent or as a
...and that makes the queue method a candidate to replace the add method
without breaking anything.
Regards,
Seb
On 08.11.2010 18:03, Igor Vaynberg wrote:
On Mon, Nov 8, 2010 at 8:58 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
as I understand the readme the queue method
...and that makes the queue method a candidate to replace the add method
without breaking anything.
Yes :)
**
Martin
Seb
On 08.11.2010 18:03, Igor Vaynberg wrote:
On Mon, Nov 8, 2010 at 8:58 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
as I understand the readme the
Hi,
I think this approach of changing .add or adding a .queue is too
radical while the purpose can be achieved in a much simpler way. I
think hierarchy of Java code among other things helps considerably
with code-readability and should be kept in pace, but also it's
strictness sometimes makes one
On Mon, Nov 8, 2010 at 9:07 AM, Sebastian nospam...@gmx.net wrote:
...and that makes the queue method a candidate to replace the add method
without breaking anything.
not necessarily. while add() adds right away, queue holds componets in
a buffer until after the oninitialize() cascade. so
It makes more sense to be before.
I think the component hierarchy should be ready for onInitialize()
On Mon, 2010-11-08 at 09:32 -0800, Igor Vaynberg wrote:
On Mon, Nov 8, 2010 at 9:07 AM, Sebastian nospam...@gmx.net wrote:
...and that makes the queue method a candidate to replace the add
But all really depends on your approach. Some people think dabbling in
a swamp gives you a firm grip. I cosinder it the opposite: swamp has a
firm grip on you.
I consider it asking for trouble. Wicket would sacrifice
predictability and conceptual surface for the sake of making a few
things
Chicken.
2010/11/9 Eelco Hillenius eelco.hillen...@gmail.com:
But all really depends on your approach. Some people think dabbling in
a swamp gives you a firm grip. I cosinder it the opposite: swamp has a
firm grip on you.
I consider it asking for trouble. Wicket would sacrifice
Hi!
Or should I say, boldly go where no man has gone before or Do, or
do not. There is no 'try.' .
**
Martin
2010/11/9 Martin Makundi martin.maku...@koodaripalvelut.com:
Chicken.
2010/11/9 Eelco Hillenius eelco.hillen...@gmail.com:
But all really depends on your approach. Some people think
Hi!
Please make sure that it passes all current test cases before submitting the
patch. Also, it would be good to take the examples that have been given to
you in this thread and create tests from them that demonstrate that they all
work. Particularly important will be demonstrating the
On Fri, Nov 5, 2010 at 11:32 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
Hi!
Please make sure that it passes all current test cases before submitting the
patch. Also, it would be good to take the examples that have been given to
you in this thread and create tests from them
The security example is quite extreme and should be implemented in
traditional way if there is no regression test for it.
there is nothing extreme about it, it is a common use of containers
when implementing visibility/security. just the fact that this
forces the traditional approach sounds
On Sat, Nov 6, 2010 at 2:57 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
I'm not scared that easily. Private members have a place and purpose.
Yes, please don't make us have to expose our private parts.
-
To
Hi!
I'm not scared that easily. Private members have a place and purpose.
Yes, please don't make us have to expose our private parts.
;) Here's a first attempt with few TODOs, however:
### Eclipse Workspace Patch 1.0
Index: src/main/java/org/apache/wicket/MarkupContainer.java
On Sat, Nov 6, 2010 at 7:20 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
Hi!
I'm not scared that easily. Private members have a place and purpose.
Yes, please don't make us have to expose our private parts.
;) Here's a first attempt with few TODOs, however:
All right,
Hi!
+ private MapString, Component componentIdMapAidedComponent = new
HashMapString, Component();
So, you just added a new Map to all markup containers that keeps components
in it? Why would you do that?
We need to wait until all components are added so that we can arrange
them into
We need to wait until all components are added so that we can arrange
them into correct hireracy before rendering.
May I suggest that components are added with help of a builder object, for
example:
public MyPanel(String id) {
super(id);
Builder b = new Builder(this); // the Builder gets
here is a proper very rough initial implementation:
https://github.com/ivaynberg/wicket/commit/cbe861f4028120993f5d10d575f12c4ca291fdce
now someone has to mature it to the point where it can be properly evaluated.
-igor
On Sat, Nov 6, 2010 at 6:54 AM, samket sam...@gmx.com wrote:
We need to
Hi!
Can you see how this would fail?
html
form wicket:id=form1
input wicket:id=input .../
/form
form wicket:id=form2
input wicket:id=input .../
/form
/html
That's old-school-wicket ;)
This would not be allowed anymore. An application would have to be
refactored (using an
Hi!
We could also make so that wicket:id is old-school and
wicket:id:protected is new-school.
No need to refactor anything.
Just pros without any cons.
**
Martin
2010/11/5 Martin Makundi martin.maku...@koodaripalvelut.com:
Hi!
Can you see how this would fail?
html
form wicket:id=form1
Hi.
I think its not a solution for problem which Martin described. If you cooperate
with some outer company which provide you styled markup or they are modifing an
existing one they can broke your hierarchy and you must change your code. It
would be nice to not do this, for e.g adding
I know that in this case (Jeremy wrote that) you must provide
uniqueness of components in whole page but it also can be resolved somehow
+1
Also DOM requires id uniqueness according to spec so it is nothing new
to web developers.
**
Martin
I think if you find component hierarchies to be
On Fri, Nov 5, 2010 at 10:07 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
I know that in this case (Jeremy wrote that) you must provide
uniqueness of components in whole page but it also can be resolved
somehow
+1
Also DOM requires id uniqueness according to spec so it
Hi!
If you have to use libraries A and B that provide Wicket components and both
of them use message or feedback as component id in any of their
components then how your application will deal with that ?
You make decision: feedback is either private (traditional) or
protected/panel-scope
On Fri, Nov 5, 2010 at 10:16 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
Hi!
If you have to use libraries A and B that provide Wicket components and
both
of them use message or feedback as component id in any of their
components then how your application will deal with
Let's say both libraries are modern (because private scope is old-fashion,
right) and export message with Page scope.
Then project X (Lombok, Bindgen) finds the problem at compile time and
explain you that both lib A and B export component with the same id.
What would you do now ?
Throw away
To be more precise: namespace would always be per each markupcontainer
which has its own markup.
**
Martin
Please give a concrete example of such situation. If names are panel
or page scope I cannot immagine many worthwile items that can be
imported onto panels and pages that cannot be
LibA provides PanelA which exports ComponentA with id == messages (e.g.
ListView) with Page scope.
LibB provides PanelB which exports ComponentB with id == messages (e.g.
DataGrid) with Page scope.
Then your application has a page MyPage which includes both PanelA and
PanelB and the problem
Hi
In my opinion, when you use lots of inheritance in a page, its really
imposible to control if a component appears just once in the page.
Wicket is great for the ability to reuse components. Actually I've been able
to create a private framework where I'm able to build an entire page with
On Fri, Nov 5, 2010 at 10:31 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
To be more precise: namespace would always be per each markupcontainer
which has its own markup.
So the hell is still here. It is just moved one level up.
It seems you didn't think of all cases.
**
LibA provides PanelA which exports ComponentA with id == messages (e.g.
ListView) with Page scope.
PanelA defines independent namespace.
LibB provides PanelB which exports ComponentB with id == messages (e.g.
DataGrid) with Page scope.
PanelB defines independent namespace.
Then your
If the project gets complicated, I think there is no possible way to control
the uniqueness of the component in the page. The advantages of adding a
component wherever you cant along the hierarchy are true, I don't think that
your proposal gives the best of both worlds.
This is a
Hi!
To be more precise: namespace would always be per each markupcontainer
which has its own markup.
So the hell is still here. It is just moved one level up.
It seems you didn't think of all cases.
I must have miscommunicated myself, this is not at all what I meant.
**
Martin
**
On 2010-11-05 09:37, Martin Makundi wrote:
LibA provides PanelA which exports ComponentA with id == messages (e.g.
ListView) with Page scope.
PanelA defines independent namespace.
LibB provides PanelB which exports ComponentB with id == messages (e.g.
DataGrid) with Page scope.
PanelB
On Fri, Nov 5, 2010 at 8:36 AM, Leszek Gawron lgaw...@apache.org wrote:
add( new PanelA( new Model1() );
add( new PanelA( new Model2() );
add( new PanelA( new Model3() );
to the same page ?
Different ids?
-
To
Yeah, Panel always has id, so what you do is:
add( new PanelA(id1, new Model1() );
add( new PanelA(id2, new Model2() );
add( new PanelA(id3, new Model3() );
All Panels would have their own namespace within themselves.
**
Martin
2010/11/5 James Carman ja...@carmanconsulting.com:
On Fri, Nov
is its consistency. once you learn how to add
components you can use the same method for all usecases and it works.
it seems like this would take away from that.
-igor
On Thu, Nov 4, 2010 at 1:13 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
I propose Free Wicket from component
On Fri, Nov 5, 2010 at 11:55 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote:
in the end we have to figure out if the added simplicity is worth the
headache it brings for more complex usecases.
I don't think it is. Keeping the two hierarchies in sync is not really that
difficult. The funny
. Waste is bad. Intentional waste is even worse.
So let's lean it out ;]
**
Martin
On Thu, Nov 4, 2010 at 1:13 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
I propose Free Wicket from component-hierarchy hell
We have discussd before that Wicket has unnecessary binding
. Intentional waste is even worse.
So let's lean it out ;]
**
Martin
On Thu, Nov 4, 2010 at 1:13 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
I propose Free Wicket from component-hierarchy hell
We have discussd before that Wicket has unnecessary binding to
wicket:id
Hi!
its not about the list *items* its about the components you add to them
onpopuateitem(item item) {
add(new label(name));
add(new label(email));
}
wont work
Why should it? Won't make it any easier than:
item.add(new label(name));
item.add(new label(email));
The developer can
Web pages are 80% trivial. Small friction like doing unnecessary
hierarcy matching is waste of time. 5 min per hour, 40 minutes per
day, 800 minutes per month, 20 people team 16000 wasted minutes per
month is 33 days per month wasted only because of wicket hierarchies.
As time and time again
I don't think it is. Keeping the two hierarchies in sync is not really that
difficult. The funny thing about the proposed approach is that it is in an
effort to make things simpler. But, as you pointed out, the more complex
things won't work with the proposed approach (without probably some
Hi!
As time and time again research shows is that the real cost is not in
the initial development, but in maintaining (which of course starts
often while you're still doing the initial development, as it also
includes refactoring on initial ideas etc).
I believe poorly developed software
I don't think it is. Keeping the two hierarchies in sync is not really that
difficult. The funny thing about the proposed approach is that it is in an
effort to make things simpler. But, as you pointed out, the more complex
things won't work with the proposed approach (without probably some
I think it is a bad idea to enable something that makes developing a
little bit quicker/ easier but that makes problems potentially much
harder to debug.
I don't see any difference in getting hierarchy not matched
exception from either way. Ofcourse the main difference is that you
would get
101 - 200 of 215 matches
Mail list logo
