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 have to change the code for trivial markup change/requirement which is inconvenient.
So I suggest instead of tampering with code hierarchy, let markup override it with some special format in wicket:id - for example both these markups can work with the same java code: <a wicket:id="edit"><span wicket:id="name"/></a> <b wicket:id=":edit:name"/> (<a wicket:id="edit">edit</a>) (wicket:id=":edit:name" means relative path "edit:name" from the panel that owns the markup) We just check for colon at markup id, resolve the component by relative path, determine it's visibility & enabled-ness the traditional way and render it. For ajax, I guess when rendering components we can check if it has children that have been rendered outside itself, if the child has outputMarkupId enabled just render that too, if not print a warn message that the markup designer has made a mistake there. What do you think? Does this do what you want? Is there something I overlooked? Omid On Mon, Nov 8, 2010 at 8:28 PM, Igor Vaynberg <igor.vaynb...@gmail.com> wrote: > 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 defined in >> the markup. So the markup is only used to determine the child's location >> below a given (code controlled) parent. This means if you replace the >> current add method with the behavior of the queue method, existing code will >> still work and we would not have two separate ways to add components. That >> sounds like a good solution. > > hrm. i was thinking to have queue() in addition to add(). i havent > looked into it enough to be able to say that we can replace add() with > queue() completely and not lose anything. if, however, that is the > case, then i would prefer tweaking add() itself to work like queue(). > > -igor > > >> >> @Martin: please start arguing with the given arguments and stop moaning. >> Thanks. >> >> Regards, >> Seb >> >> On 08.11.2010 17:28, Igor Vaynberg wrote: >>> >>> 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<vitaly.tsap...@gmail.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 >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>>> For additional commands, e-mail: users-h...@wicket.apache.org >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
