1.5 port https://github.com/koutsoub/wicket/tree/component_queuing_1.5
https://github.com/koutsoub/wicket/tree/component_queuing_1.5
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Free-wicket-from-component-hierarchy-hell-tp3027705p3226581.html
Sent from the Users
On Wed, Jan 19, 2011 at 3:55 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
Can we bargain about this? Say, also wicket auto ajax enclosure and
both into 1.4-x
This made me laugh. What is the other side of the bargain? What does the
giving party get in return? :)
Apache is
http://farm5.static.flickr.com/4089/4968160827_b742a7448a_z.jpg
..hrm.. putting that aside, did you give it a test drive?
**
Martin
2011/1/20 Jeremy Thomerson jer...@wickettraining.com:
On Wed, Jan 19, 2011 at 3:55 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
Can we bargain
On Thu, Jan 20, 2011 at 11:24 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
..hrm.. putting that aside, did you give it a test drive?
No, I haven't. Because keeping the two hierarchies in sync has never been a
problem on any project that I worked on. Typically, the
I'm not a committer, just a normal 1.5 user concerned about bloat.
For what it's worth, I took a few minutes to actually look at the change
(MarkupContainer as you'd expect) and I can see that if you don't use the
new queue methods, the only a memory overhead is the *static* QUEUE (nothing
extra
On Thu, Jan 20, 2011 at 11:50 AM, Jim Pinkham pinkh...@gmail.com wrote:
I still don't think it's necessary, and wonder if it might actually be
counter-productive to have more than one way to learn for new adopters. If
it goes forward, I don't suppose there's much precedent for taking
On Thu, Jan 20, 2011 at 4:41 PM, Giannis Koutsoubos kouts...@gmail.comwrote:
1.5 port https://github.com/koutsoub/wicket/tree/component_queuing_1.5
https://github.com/koutsoub/wicket/tree/component_queuing_1.5
Thanks, Giannis!
--
View this message in context:
On Thu, Jan 20, 2011 at 6:24 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
http://farm5.static.flickr.com/4089/4968160827_b742a7448a_z.jpg
..hrm.. putting that aside, did you give it a test drive?
Martin, I know you started the thread about this idea last time.
I'm wondering
Quote from Igor
http://apache-wicket.1842946.n4.nabble.com/Free-wicket-from-component-hierarchy-hell-td3027705i160.html
If in doubt, there is always
getMarkupSettings().setAllowComponentAutoHierarchy(false);
there will be no such method.
+1 for not making this part of core.
..hrm..
On Thu, Jan 20, 2011 at 9:14 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
Quote from Igor
http://apache-wicket.1842946.n4.nabble.com/Free-wicket-from-component-hierarchy-hell-td3027705i160.html
If in doubt, there is always
http://apache-wicket.1842946.n4.nabble.com/Free-wicket-from-component-hierarchy-hell-td3027705i160.html
If in doubt, there is always
getMarkupSettings().setAllowComponentAutoHierarchy(false);
there will be no such method.
+1 for not making this part of core.
I mean for yes making part
On Thu, Jan 20, 2011 at 3:34 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
The largest production I am responsible for is stuck with
wicket.version1.4.9/wicket.version because some of the later
releases have not been monotonically improving. So we are stuck with
some patches
so you only have one place to fix it in
-igor
On Thu, Jan 20, 2011 at 1:43 PM, James Carman
ja...@carmanconsulting.com wrote:
On Thu, Jan 20, 2011 at 3:34 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
The largest production I am responsible for is stuck with
I'm actually looking at it now. The markup changed between 1.4.5 and
1.4.6, so there must be some other reason that I stayed with 1.4.9
(assuming laziness wasn't it). :)
On Thu, Jan 20, 2011 at 5:12 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
so you only have one place to fix it in
(assuming laziness wasn't it). :)
We are not lazy, we are just very busy ;)
**
Martin
On Thu, Jan 20, 2011 at 5:12 PM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
so you only have one place to fix it in
-igor
On Thu, Jan 20, 2011 at 1:43 PM, James Carman
Can we bargain about this? Say, also wicket auto ajax enclosure and
both into 1.4-x?
**
Martin
2011/1/18 Jeremy Thomerson jer...@wickettraining.com:
I agree. I'm -0 in general, and definitely -1 for 1.4 and -0.9 for 1.5.
On Tue, Jan 18, 2011 at 3:54 AM, Martijn Dashorst
Jira issue https://issues.apache.org/jira/browse/WICKET-3335
https://issues.apache.org/jira/browse/WICKET-3335
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Free-wicket-from-component-hierarchy-hell-tp3027705p3221292.html
Sent from the Users forum mailing list
This wont go in Wicket 1.5.
If there are no issues then most probably it will be included in 1.6
Thanks !
On Tue, Jan 18, 2011 at 10:04 AM, Giannis Koutsoubos kouts...@gmail.comwrote:
Jira issue https://issues.apache.org/jira/browse/WICKET-3335
Hi!
We would like to see it in 1.4, if possible.
**
Martin
2011/1/18 Martin Grigorov mgrigo...@apache.org:
This wont go in Wicket 1.5.
If there are no issues then most probably it will be included in 1.6
Thanks !
On Tue, Jan 18, 2011 at 10:04 AM, Giannis Koutsoubos
I don't take decisions alone but I'd vote -1 for 1.4.x.
1.4.x is the stable version and I don't want to compromise it with feature
that is neither a regression nor a security hole.
Please port the patch to 1.5/trunk and then we can talk about adding it in
early 1.5.x versions.
1.5-RC1 will be
I vote
+1 for also 1.4.x
because this feature does not compromise anything, it is just an
alternate way of adding components.
**
Martin
2011/1/18 Martin Grigorov mgrigo...@apache.org:
I don't take decisions alone but I'd vote -1 for 1.4.x.
1.4.x is the stable version and I don't want to
-1 for 1.4.x as well. No need to add this to current wicket. If it is
so important, wicket is open source, and you can readily port it
yourself.
Martijn
On Tue, Jan 18, 2011 at 10:43 AM, Martin Grigorov mgrigo...@apache.org wrote:
I don't take decisions alone but I'd vote -1 for 1.4.x.
1.4.x
On Tue, Jan 18, 2011 at 10:43 AM, Martin Grigorov mgrigo...@apache.org wrote:
Please port the patch to 1.5/trunk and then we can talk about adding it in
early 1.5.x versions.
I would be wary about adding this to 1.5 as well (that is -1 for 1.5).
1.6 will be a fine place for this to get ironed
I agree. I'm -0 in general, and definitely -1 for 1.4 and -0.9 for 1.5.
On Tue, Jan 18, 2011 at 3:54 AM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
On Tue, Jan 18, 2011 at 10:43 AM, Martin Grigorov mgrigo...@apache.org
wrote:
Please port the patch to 1.5/trunk and then we can talk
I've done some work based on Igor's implementation of component queuing.
It can be found here :
https://github.com/koutsoub/wicket/tree/component-queuing
https://github.com/koutsoub/wicket/tree/component-queuing
The code is written against the 1.4.x branch, i'm also working on making it
On Tue, 9 Nov 2010 11:49:32 -0500
James Carman ja...@carmanconsulting.com wrote:
Are you moving a field from one form to another? But that does
change the semantics, doesn't it? If it doesn't, why are there two
forms?
Both forms edit one particular object (say a Person). They just
On Wed, Nov 10, 2010 at 3:49 AM, Carl-Eric Menzel cmen...@wicketbuch.de wrote:
So either there is a difference between the forms (different submit
method maybe?), then this move would make a semantic/behavioral
difference and needs to be done in code.
As I said, the two forms edit different
On Tue, 9 Nov 2010 12:17:38 -0800
Igor Vaynberg igor.vaynb...@gmail.com wrote:
i wonder if queuing can actually replace icomponentresolver and
auto-adding. i wonder if after onbeforerender we can do what unqueing
does now, parse the markup, find any missing components, and insert
them.
On Tue, 9 Nov 2010 12:16:00 -0800
Igor Vaynberg igor.vaynb...@gmail.com wrote:
the difficult part is that doing this to complex pages is...difficult.
in the example above it is easy to see the two components that need to
be renested. but, in complex pages there can be 20 components that
need
On Wed, 10 Nov 2010 07:31:28 -0500
James Carman ja...@carmanconsulting.com wrote:
On Wed, Nov 10, 2010 at 3:49 AM, Carl-Eric Menzel
cmen...@wicketbuch.de wrote:
So either there is a difference between the forms (different submit
method maybe?), then this move would make a
What were the reasons for requiring the hierarchies to match in the
original design of Wicket?
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
On Wed, Nov 10, 2010 at 8:08 AM, Carl-Eric Menzel cmen...@wicketbuch.de wrote:
That's exactly my point :-)
This is not a good example to allow queuing, because there's no gain.
Either there is an important difference between the two forms, then it
doesn't make sense to queue *above* the
i can only hazard a guess, but if i did it would be that it was the
simplest and cleanest solution that made sense. that is always a good
starting point.
-igor
On Wed, Nov 10, 2010 at 6:19 AM, Frank Silbermann
frank.silberm...@fedex.com wrote:
What were the reasons for requiring the hierarchies
On Wed, Nov 10, 2010 at 1:05 AM, Carl-Eric Menzel cmen...@wicketbuch.de wrote:
On Tue, 9 Nov 2010 12:16:00 -0800
Igor Vaynberg igor.vaynb...@gmail.com wrote:
the difficult part is that doing this to complex pages is...difficult.
in the example above it is easy to see the two components that
you guys are both making an argument against queuing, and against
each-other. paradox.
-igor
On Wed, Nov 10, 2010 at 5:08 AM, Carl-Eric Menzel cmen...@wicketbuch.de wrote:
On Wed, 10 Nov 2010 07:31:28 -0500
James Carman ja...@carmanconsulting.com wrote:
On Wed, Nov 10, 2010 at 3:49 AM,
Hi,
no offense meant, but the rhetoric in this thread is getting more and
more ridiculous. Chicken? Component hierarchy hell? Seriously? At
most maybe component hierarchy slight annoyance.
I am not at all convinced that this is a good idea. In my opinion, one
of the strongest and best points
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
about the Python way of having only *one* way to do *one* thing.
Would you be happy if there
Hi!
So far, I have often heard about people not liking the requirement to
match the code hierarchy in the markup. Most (not all!) of them have
never actually used Wicket (I know this doesn't apply to Martin). Not
once have I seen a convincing productive(!) example of where it was an
actual
On Tue, 9 Nov 2010 10:20:12 +0200
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
On Tue, 9 Nov 2010 10:23:27 +0200
Martin Makundi martin.maku...@koodaripalvelut.com wrote:
Hi!
So far, I have often heard about people not liking the requirement
to match the code hierarchy in the markup. Most (not all!) of them
have never actually used Wicket (I know this doesn't apply
Hi!
Coding friction? Yes. Every time I need to look at somebody else's code
and try to figure out what exactly they did.
Ah.. so you are trying to solve your problem probably from the wrong
end? If you have bad warriors give them plastic swords so they can
hurt nobody? Training, Coding dojos,
...@koodaripalvelut.com]
Sent: Tuesday, November 09, 2010 6:55 AM
To: users@wicket.apache.org
Subject: Re: Free wicket from component hierarchy hell
Hi!
Isn't this exactly the reason we've got CSS?
It's just the buzz, not the reality. Unfortunately often CSS doesn't
quite cut it:
* http
On Tue, 9 Nov 2010 14:21:46 +0200
Martin Makundi martin.maku...@koodaripalvelut.com wrote:
Here we finally come to an actual argument about this:
Panel is not reusable enough because it has its own markup. If I
override its markup, it stops working.
Frank wrote in another message how to deal
On Tue, 9 Nov 2010 11:01:28 +0200
Martin Makundi martin.maku...@koodaripalvelut.com wrote:
Hi!
Coding friction? Yes. Every time I need to look at somebody else's
code and try to figure out what exactly they did.
Ah.. so you are trying to solve your problem probably from the wrong
end?
In simple cases it makes no difference. It makes real difference with
some complex widgets (for example search components) that must be
reused on many pages and they should render differently on each page
depending on how much space and what context they are in. I don't like
duplicating code
Also making skins for different devices / screen sizes becomes easier.
**
Martin
2010/11/9 Vitaly Tsaplin vitaly.tsap...@gmail.com:
In simple cases it makes no difference. It makes real difference with
some complex widgets (for example search components) that must be
reused on many pages and
Hi!
Isn't this exactly the reason we've got CSS?
It's just the buzz, not the reality. Unfortunately often CSS doesn't
quite cut it:
* http://blog.iconara.net/2007/09/21/the-failure-of-css/
HTML shouldn't really be used for lookfeel and the size and placement of
components can perfectly be
your proposal is to wicket, what auto-generating-java-servlet-code is to a
JSP (~ what a tied-and-deciding-designer-code was to a programmer-code
in the past)
that is, simply going back to hell :)
why don't you stay on JSP domain, instead, sir?
Please have some patience, just watch and see
constructor-constructor.
/Frank
-Original Message-
From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com]
Sent: Tuesday, November 09, 2010 6:55 AM
To: users@wicket.apache.org
Subject: Re: Free wicket from component hierarchy hell
Hi!
Isn't this exactly the reason we've got CSS
Hi!
I don't think there is a substitute for coding skills/talent ;)))
There isn't. That's not the point. So far your argument seems to be #1
I don't like this and #2 those who don't agree with you aren't good
coders.
Bad coding was your argument, not mine ;)
I simply don't allow bad coders
On Tue, 9 Nov 2010 10:05:39 -0500
James Carman ja...@carmanconsulting.com wrote:
I think we need to try to put our heads together on this one. I don't
necessarily think this approach is the best, but I haven't really had
a chance to wrap my head around it yet, frankly. Do we really think
your proposal is to wicket, what auto-generating-java-servlet-code is to a
JSP (~ what a tied-and-deciding-designer-code was to a programmer-code
in the past)
that is, simply going back to hell :)
why don't you stay on JSP domain, instead, sir?
On Tue, Nov 9, 2010 at 1:47 PM, Matthias Keller
Hi Martin
Isn't this exactly the reason we've got CSS?
HTML shouldn't really be used for lookfeel and the size and placement
of components can perfectly be defined using CSS classes.
Matt
On 2010-11-09 13:34, Martin Makundi wrote:
Also making skins for different devices / screen sizes
For what it's worth, I agree with these sentiments. I am not jazzed
about this whole auto hierarchy idea. I too like the predictability
of Wicket and I don't mind staying within the confines of a strict
hierarchy. I've kept quiet until now because I really don't have the
time to jump into this
On Tue, Nov 9, 2010 at 7:49 AM, manuelbarzi manuelba...@gmail.com wrote:
why don't you stay on JSP domain, instead, sir?
Let's keep it civil here folks. Can we agree to disagree without
being disagreeable?
-
To unsubscribe,
may it be enough just create an independent simple
html-code-processor-to-wicket-java-code-tool, that would auto-generate that
tedious code you would like to avoid? a simple java-class-processor-tool may
help for that... possible an eclipse-wicket-plugin-tool, if it doesn't
already exists...
On
away? the proper question to try first is, What is the
Wicket way of solving my problem?
-Original Message-
From: Carl-Eric Menzel [mailto:cmen...@wicketbuch.de]
Sent: Tuesday, November 09, 2010 9:12 AM
To: users@wicket.apache.org
Subject: Re: Free wicket from component hierarchy hell
@wicket.apache.org
Subject: Re: Free wicket from component hierarchy hell
Hi!
Isn't this exactly the reason we've got CSS?
It's just the buzz, not the reality. Unfortunately often CSS doesn't
quite cut it:
* http://blog.iconara.net/2007/09/21/the-failure-of-css/
HTML shouldn't really be used
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
-Original Message-
Fro
-constructor.
/Frank
-Original Message-
From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com]
Sent: Tuesday, November 09, 2010 6:55 AM
To: users@wicket.apache.org
Subject: Re: Free wicket from component hierarchy hell
Hi!
Isn't this exactly the reason we've got CSS?
It's
On Tue, Nov 9, 2010 at 10:23 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
That's not how proggress is made...
Well, it's at least a sane place to start. Figuring out how Wicket
can be used as-is to solve your problem lets you know if it's really a
problem or not. If this can
]
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 of solving my problem
That's not how proggress is made...
Well, it's at least a sane place to start. Figuring out how Wicket
can be used as-is to solve your problem lets you know if it's really a
problem or not.
I've been dabbling with Wicket for 2,5 years now, and I have now
finally come up with this request
to be a problem, but its limitations need some alleviation ;)
**
Martin
-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
On Tue, 9 Nov 2010 17:23:18 +0200
Martin Makundi martin.maku...@koodaripalvelut.com wrote:
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
Well.. that's what we are doing, at runtime.
**
Martin
2010/11/9 manuelbarzi manuelba...@gmail.com:
may it be enough just create an independent simple
html-code-processor-to-wicket-java-code-tool, that would auto-generate that
tedious code you would like to avoid? a simple
[mailto:martin.maku...@koodaripalvelut.com]
Sent: Tuesday, November 09, 2010 6:55 AM
To: users@wicket.apache.org
Subject: Re: Free wicket from component hierarchy hell
Hi!
Isn't this exactly the reason we've got CSS?
It's just the buzz, not the reality. Unfortunately often CSS doesn't
quite cut
:06 AM
To: users@wicket.apache.org
Subject: Re: Free wicket from component hierarchy hell
I think we need to try to put our heads together on this one. I don't
necessarily think this approach is the best, but I haven't really had
a chance to wrap my head around it yet, frankly. Do we really think
On Tue, Nov 9, 2010 at 10:32 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
I've been dabbling with Wicket for 2,5 years now, and I have now
finally come up with this request for the core wicketeers to show us
the correct way to patch this particular issue.
I'm not necessarily
At the same time, you have not responded to valid criticisms like the
problems with enabledInHierarchy (at least I haven't seen any such
response).
@Carl-Erik
Reason why I haven't commented your enabledInHierarchy comment is
because it would not afect it in any way.
I hope the proposition
On Tue, Nov 9, 2010 at 10:48 AM, Frank Silbermann
frank.silberm...@fedex.com wrote:
If the component hierarchy can be changed without changing behavior or
semantics, then why are the components in a hierarchy to begin with?
Why aren't all the components being moved around already siblings at
You could do that, but I think Martin is trying to take it a step
further allowing you to have an arbitrary hierarchy in your markup and
just figure it out at runtime. Wicket doesn't care what order you add
stuff to the page/component as long as they're all on the same level
within the
On Tue, Nov 9, 2010 at 10:58 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
Yes, and if they are at different levels in the hierarchy, Wicket can
figure that out also, at runtime.
What happens if a sub-component changes one of the ids of one of its
components that it contains?
Hi!
What happens if a sub-component changes one of the ids of one of its
components that it contains? Is that then going to break your page
because it's going to grab that id from you?
Igor explained that # Components can be queued to any container, and
can only be added to the hierarchy
On Tue, 9 Nov 2010 17:46:13 +0200
Martin Makundi martin.maku...@koodaripalvelut.com wrote:
@Carl-Erik
Reason why I haven't commented your enabledInHierarchy comment is
because it would not afect it in any way.
I hope the proposition will be clear when we have it ready. We are
working on
On Tue, 9 Nov 2010 10:51:49 -0500
James Carman ja...@carmanconsulting.com wrote:
On Tue, Nov 9, 2010 at 10:48 AM, Frank Silbermann
frank.silberm...@fedex.com wrote:
If the component hierarchy can be changed without changing behavior
or semantics, then why are the components in a hierarchy
one of the nice things of wicket is that java-code (programmer) and
html-code (designer) are quite independent. only watching a wicket-java-file
does a programmer deduce the structure and behaviour of the corresponding
view, both things, without fully depending on inspecting html for
On Tue, 9 Nov 2010 18:04:44 +0200
Martin Makundi martin.maku...@koodaripalvelut.com wrote:
Igor explained that # Components can be queued to any container, and
can only be added to the hierarchy that stems from that container,
thereby solving the security requirement
Say you have two forms on one panel (don't know if this is the best
example or not, but here goes). You want to move a field from one
panel to another. You'd have to do that in code with the traditional
approach. With the queued approach, you'd just queue all your
components to the parent
On Tue, Nov 9, 2010 at 11:04 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
Igor explained that # Components can be queued to any container, and
can only be added to the hierarchy that stems from that container,
thereby solving the security requirement
What happens if a sub-component changes one of the ids of one of its
components that it contains? Is that then going to break your page
because it's going to grab that id from you?
Also depends what you mean by a component. A panel sitting on a
panel has its own markup so it won't grab
On Tue, Nov 9, 2010 at 11:34 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
When fragments are added they materialize as natural markup at the
junction point?
I don't know the answer to that. I'm asking, myself. :) Just trying
to make sure the queue approach doesn't break with
On Tue, Nov 9, 2010 at 11:10 AM, Carl-Eric Menzel cmen...@wicketbuch.de wrote:
I think you misunderstood Frank's point. Why are the components in a
hierarchy in the first place, if the hierarchy can be changed without
changing behavior or semantics? They can simply be flat in the parent
then.
https://github.com/ivaynberg/wicket/tree/component-queuing
Sorry, I was thinking for some reason that the depth-first search
through the current component's hierarchy would actually traverse into
subcomponent's markup, but I don't think it will. It will stay within
the current component's
Martin, isn't it all a matter of principles towards keeping a correct
separation of concerns?
one of the nice things of wicket is that java-code (programmer) and
html-code (designer) are quite independent. only watching a wicket-java-file
does a programmer deduce the structure and behaviour of
@Carl-Erik
Reason why I haven't commented your enabledInHierarchy comment is
because it would not afect it in any way.
I hope the proposition will be clear when we have it ready. We are
working on Igor's proposal.
It will be interesting to see how you propose not affecting something
that
From my understanding the proposal works like this that you have a
partially code controlled hierarchy of components when you need it for
functional reasons (security, AJAX refresh, visibility, etc). You can
define the parent of a component but technical you allow child
components being nested
On Tue, Nov 9, 2010 at 11:40 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
Yeah ids must be unique per each level and ofcourse if you have markup like:
div wicket:id=adiv wicket:id=a/div/div
If you have code like:
panel {
queue(a(a));
a.queue(a(a));
}
This could be a
On Tue, 9 Nov 2010 11:33:31 -0500
James Carman ja...@carmanconsulting.com wrote:
Say you have two forms on one panel (don't know if this is the best
example or not, but here goes). You want to move a field from one
panel to another. You'd have to do that in code with the traditional
so queue each formcomponet under the form they belong to. that way
they cannot be moved outside the form.
-igor
On Tue, Nov 9, 2010 at 8:46 AM, James Carman ja...@carmanconsulting.com wrote:
On Tue, Nov 9, 2010 at 11:40 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
Yeah ids
PS: I think much of this controversy could have been streamlined by
pointing to a concept-complete implementation or at least making a
properly thought-out suggestion, instead of all the name-calling that
went on. (Almost) No offense taken, just a suggestion for the future.
My apologies. I am
On Tue, Nov 9, 2010 at 11:47 AM, Carl-Eric Menzel cmen...@wicketbuch.de wrote:
Are you moving a field from one form to another? But that does change
the semantics, doesn't it? If it doesn't, why are there two forms?
Both forms edit one particular object (say a Person). They just
edit
Makundi [mailto:martin.maku...@koodaripalvelut.com]
Sent: Tuesday, November 09, 2010 6:55 AM
To: users@wicket.apache.org
Subject: Re: Free wicket from component hierarchy hell
Hi!
Isn't this exactly the reason we've got CSS?
It's just the buzz, not the reality. Unfortunately often CSS
]
On Behalf Of James Carman
Sent: Tuesday, November 09, 2010 10:34 AM
To: users@wicket.apache.org
Subject: Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 11:10 AM, Carl-Eric Menzel
cmen...@wicketbuch.de wrote:
I think you misunderstood Frank's point. Why are the components
On Tue, Nov 9, 2010 at 11:48 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
so queue each formcomponet under the form they belong to. that way
they cannot be moved outside the form.
That's what happens in code not markup. You could potentially
change what gets edited by the form merely by
On Tue, Nov 9, 2010 at 8:10 AM, Carl-Eric Menzel cmen...@wicketbuch.de wrote:
On Tue, 9 Nov 2010 10:51:49 -0500
James Carman ja...@carmanconsulting.com wrote:
On Tue, Nov 9, 2010 at 10:48 AM, Frank Silbermann
frank.silberm...@fedex.com wrote:
If the component hierarchy can be changed
That's what happens in code not markup. You could potentially
change what gets edited by the form merely by moving fields around in
the markup.
With compoundpropertymodels yes if you don't restrict components
inside a form this can happen. For good or for bad.
For security reasons in
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 now.
-igor
On Tue, Nov 9, 2010 at 8:50 AM, James Carman
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 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
1 - 100 of 213 matches
Mail list logo
