> (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
> wrote:
>> so you only have one place to fix it in
>>
>> -igor
>>
>> On Thu, Jan 20, 2011 at 1:43 PM, James Carman
>> wrote:
>>> On Thu, Jan 20, 20
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 wrote:
> so you only have one place to fix it in
>
> -igor
>
> On Thu, Jan
so you only have one place to fix it in
-igor
On Thu, Jan 20, 2011 at 1:43 PM, James Carman
wrote:
> On Thu, Jan 20, 2011 at 3:34 PM, Martin Makundi
> wrote:
>>
>> The largest production I am responsible for is stuck with
>> 1.4.9 because some of the later
>> releases have not been monoton
On Thu, Jan 20, 2011 at 3:34 PM, Martin Makundi
wrote:
>
> The largest production I am responsible for is stuck with
> 1.4.9 because some of the later
> releases have not been monotonically improving. So we are stuck with
> some patches etc. and we haven't had time to refactor to 1.4.x
>
We're s
>> 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 y
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
> getMarkupSettings().setAllowComponentAut
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 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 wonde
On Thu, Jan 20, 2011 at 4:41 PM, Giannis Koutsoubos wrote:
>
> 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:
> http://apache-wicket.1842946.n4.nabble
On Thu, Jan 20, 2011 at 11:50 AM, Jim Pinkham 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
> something
> back out,
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 p
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 hierarc
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 :
> On Wed, Jan 19, 2011 at 3:55 AM, Martin Makundi <
> martin.maku...@koodaripalvelut.com> wrote:
>
>> Can we bargain about this? Say, a
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? :)
Apac
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
Can we bargain about this? Say, also wicket auto ajax enclosure and
both into 1.4-x?
**
Martin
2011/1/18 Jeremy Thomerson :
> 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:
>
>>
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
> wrote:
> > Please port the patch to 1.5/trunk and then we can talk about adding it
On Tue, Jan 18, 2011 at 10:43 AM, Martin Grigorov 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 out.
Martijn
-
-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 wrote:
> I don't take decisions alone but I'd vote -1 for 1.4.x.
>
> 1.4.x is the stable vers
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 :
> 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 fea
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 re-
Hi!
We would like to see it in 1.4, if possible.
**
Martin
2011/1/18 Martin Grigorov :
> 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
> wrote:
>
>>
>> Jira issue https://is
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 wrote:
>
> Jira issue https://issues.apache.org/jira/browse/WICKET-3335
> https://issues.apache.org/jira/browse/WICKET-3335
>
> --
> View
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
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
compatibl
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 wrote:
> On Wed, 10 Nov 2010 07:31:28 -0500
> James Carman wrote:
>
>> On Wed, Nov 10, 2010 at 3:49 AM, Carl-Eric Menzel
>> wrote:
>> >
>> > So either
On Wed, Nov 10, 2010 at 1:05 AM, Carl-Eric Menzel wrote:
> On Tue, 9 Nov 2010 12:16:00 -0800
> Igor Vaynberg 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
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
wrote:
> What were the reasons for requiring the hierarchies to match in the
> origi
On Wed, Nov 10, 2010 at 8:08 AM, Carl-Eric Menzel 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 forms, or there is n
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, 10 Nov 2010 07:31:28 -0500
James Carman wrote:
> On Wed, Nov 10, 2010 at 3:49 AM, Carl-Eric Menzel
> 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
On Tue, 9 Nov 2010 12:16:00 -0800
Igor Vaynberg 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 to be renested, and
On Tue, 9 Nov 2010 12:17:38 -0800
Igor Vaynberg 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. autocomponents and autoadd
On Wed, Nov 10, 2010 at 3:49 AM, Carl-Eric Menzel 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 values on the sam
On Tue, 9 Nov 2010 11:49:32 -0500
James Carman 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 different v
;>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> this solution you just can throw everything in the panel or webpage
>>>>>>>>>>> that is the IComponentResolver for
t;>>>>>>>
>>>>>>>>>> this solution you just can throw everything in the panel or webpage
>>>>>>>>>> that is the IComponentResolver for all its childs...
>>>>>>>>>> Just look at how the code
the code works..
>>>>>>>>> IF a component can't be found on its own parent the ComponentResolver
>>>>>>>>> will ask all the parents which can be IComponentResolver to render the
>>>>>>>>> child..
>>>>
;>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Nov 9, 2010 at 19:04, Martin Makundi
>>>>>>>> wrote:
>>>>>>>>> This does not really nest the components logically, d
;
>>>>>>>> If you set get("body").setVisible(false) will the label remain visible?
>>>>>>>>
>>>>>>>> **
>>>>>>>> Martin
>>>>>>>>
>>>>>>>> 2010/11/9 Johan Compagner :
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. y
hy are we discussing here already that works in wicket 1.4 if you
>>>>>>>> really need it?
>>>>>>>>
>>>>>>>>
>>>>>>>> public class HelloWorld extends WebPage implements IComponentResolver {
>>
On Tue, Nov 9, 2010 at 12:03 PM, Sven Meier wrote:
> Hi,
>
>> an easy example is:
>>
>> > wicket:id="last"/>
>>
>> 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. t
Hi,
> an easy example is:
>
> wicket:id="last"/>
>
> 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 there
> purely for the design aspect.
I have
> >>>>>>> Why are we discussing here already that works in wicket 1.4 if you
> >>>>>>> really need it?
> >>>>>>>
> >>>>>>>
> >>>>>>> public class HelloWorld extends WebPage implements
>
gt;>>>>>>
>>>>>>> public HelloWorld()
>>>>>>> {
>>>>>>> add(new WebMarkupContainer("body"));
>>>>>>> add(new Label("label","my
On Tue, Nov 9, 2010 at 12:20 AM, Martin Makundi
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
>> about the Python way of havi
;>
>>>>>> public boolean resolve(MarkupContainer container,
>>>>>> MarkupStream markupStream, ComponentTag tag) {
>>>>>>
>>>>>> Component component = get(tag.getId());
>>>
if (component != null)
>>>>> {
>>>>> component.render(markupStream);
>>>>> return true;
>>>>> }
>>>>> return false;
MarkupStream markupStream, ComponentTag tag) {
>>>>>
>>>>> Component component = get(tag.getId());
>>>>> if (component != null)
>>>>> {
>>>>> comp
On Tue, Nov 9, 2010 at 9:38 AM, Martin Makundi
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 parent component, it 's their
> c
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 wrote:
> On Tue, Nov 9, 2010 at 12:38 PM, Mar
null)
>>>> {
>>>> component.render(markupStream);
>>>> return true;
>>>> }
>>>> return false;
>>>> }
>>>> }
>>
> }
>>> }
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Nov 9, 2010 at 16:29, Frank Silbermann
>>> wrote:
>>>> Progress is made by people who have understanding,
n Tue, Nov 9, 2010 at 16:29, Frank Silbermann
>> wrote:
>>> Progress is made by people who have understanding, not by the ignorant.
>>> You're not in a position to make suggestions about extending Wicket if
>>> you don't yet understand how to use the powers it a
ng, not by the ignorant.
>> You're not in a position to make 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
010 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
&g
>> 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. Rem
On Tue, Nov 9, 2010 at 12:43 PM, Martin Makundi
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. You apparently aren't open to a
> 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:38 PM, Martin Makundi
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 saying they're not
consciously
> 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 comple
On Tue, Nov 9, 2010 at 12:33 PM, Martin Makundi
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 valid point and we should respect hi
On Tue, Nov 9, 2010 at 12:29 PM, Martin Makundi
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 later a markup change could
compl
> 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 l
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)
child2.add(child3)
> 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 Tue, Nov 9, 2010 at 12:22 PM, Martin Makundi
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 something that allows stuff to brea
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(...))
>
On Tue, Nov 9, 2010 at 12:06 PM, Martin Makundi
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 to do:
someSubComponent.add(ne
> 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
>
> -
> T
On Tue, Nov 9, 2010 at 12:00 PM, Martin Makundi
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 unsubscribe, e-mail: users-unsubscr...
> 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 inappropri
On Tue, Nov 9, 2010 at 12:00 PM, Igor Vaynberg 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 times you dont car
> On Tue, Nov 9, 2010 at 11:55 AM, Martin Makundi
> 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"?
http://apache-wicket.1842946
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 yo
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 wrote:
> On Tue, Nov 9, 2010 at 11:55 AM, Martin Makundi
> wrote:
>> For security reasons in general, you might want to use:
>>
>> formA.queue(formAstuff);
>> fo
On Tue, Nov 9, 2010 at 11:50 AM, Frank Silbermann
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 another panel. To the oth
On Tue, Nov 9, 2010 at 11:55 AM, Igor Vaynberg 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 now.
>
I'm not say
On Tue, Nov 9, 2010 at 11:55 AM, Martin Makundi
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"?
--
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 wrote:
> On Tue, Nov 9,
> 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 gen
On Tue, Nov 9, 2010 at 8:10 AM, Carl-Eric Menzel wrote:
> On Tue, 9 Nov 2010 10:51:49 -0500
> James Carman wrote:
>
>> On Tue, Nov 9, 2010 at 10:48 AM, Frank Silbermann
>> wrote:
>> > If the component hierarchy can be changed without changing behavior
>> > or semantics, then why are the componen
nconsulting.com]
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
wrote:
>
> I think you misunderstood Frank's point. Why are the comp
On Tue, Nov 9, 2010 at 11:48 AM, Igor Vaynberg 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 moving fields around
e constructor to create the 2nd component hierarchy,
>>> and provide the new panel its own HTML page.
>>>
>>> If you don't like overriding the constructor along with the HTML, then
>>> you can build some sort of configurable constructor-constructor.
>>>
>>> /Fr
On Tue, Nov 9, 2010 at 11:47 AM, Carl-Eric Menzel 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 different values on the
> 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
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 wrote:
> On Tue, Nov 9, 2010 at 11:40 AM, Martin Makundi
> wrote:
>>
>> Yeah ids must be unique per each level and ofcourse if you have ma
On Tue, 9 Nov 2010 11:33:31 -0500
James Carman 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
> approach. With the "queued" a
On Tue, Nov 9, 2010 at 11:40 AM, Martin Makundi
wrote:
>
> Yeah ids must be unique per each level and ofcourse if you have markup like:
>
>
>
> If you have code like:
> panel {
> queue(a("a"));
> a.queue(a("a"));
> }
>
This could be a problem. Say you do have two forms on the same page.
One f
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
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 the
>> @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 s
>> 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 compone
On Tue, Nov 9, 2010 at 11:10 AM, Carl-Eric Menzel 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.
>
Say you have
On Tue, Nov 9, 2010 at 11:34 AM, Martin Makundi
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 these typical use
cases. I us
>> 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 gr
On Tue, Nov 9, 2010 at 11:04 AM, Martin Makundi
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"
>
> https://github.com/ivaynberg/wicket/tree/component-q
> 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 p
1 - 100 of 214 matches
Mail list logo
