This would be then a bug in nested forms support and not in the modal
window itself. If a form inside modal window is submitted only that
form should be processed. I still don't understand what problem
exactly this fixes.
-Matej
On Tue, Jul 28, 2009 at 10:04 PM, Vladimir K<koval...@gmail.com> wrote:
>
> The following class fixes the problem. It is the evidence of mismatch I'm
> saying about.
>
> public class ModalWindowForm<T> extends Form<T> {
> public ModalWindowForm(String id) {
> super(id);
> }
>
> �...@override
> public Form<?> getRootForm() {
> Form<?> form = super.getRootForm();
>
> if ((findParent(ModalWindow.class) != null) &&
> (form.findParent(ModalWindow.class) == null))
> return this;
> else
> return form;
> }
> }
>
> I assume I don't understand something. But anyway I expect following the
> least surprise rule.
>
>
>
> Matej Knopp-2 wrote:
>>
>> On Tue, Jul 28, 2009 at 8:31 PM, Vladimir K<koval...@gmail.com> wrote:
>>>
>>> Jeremy,
>>>
>>> from my perspective ModalWindow is a mix of javascript widget that works
>>> in
>>> non-wicket mode and an wicket wrapper that bridges js widget with wicket.
>>> It
>>> is always created at the body level. That's why I said it's a cheat. Thus
>>> are problems with form submitting when nested forms are used.
>> There is a good reason why the modal window has to be created on body
>> level. That's the only reliable way to have element
>> with absolute position. If you create the DOM structure deeper you are
>> risking that a container has position:relative somewhere which will
>> essentially break it. Welcome to the wonderful world of CSS.
>>
>>> Community
>>> introduced a solution (a wrapping form that is threated as the root) to
>>> work
>>> around the mismatch of ModalWindow structure. There is an issue
>>> registered
>>> about that. But Matej keeps stating that we should put MW into a form.
>>> What
>>> says that he is not aware what the problem is. And there are more
>>> problems
>>> caused by the fact that the <form> element is created by javascript.
>> Is it, really?
>>
>> I've already explained why the DOM structure is created on root level.
>> If you have form component inside modal window, chances are that
>> wicket will (to support nested forms) render it as div. If this
>> happens it is no longer possible to serialize the form when doing an
>> ajax submit. That's why the actual modal window markup contains a real
>> form.
>>
>> And this is why it is necessary to put a modal window inside a form if
>> you want to have form in modal window. What we should have done is to
>> put a wicket form inside the modal window panel itself (just to force
>> all forms in modal window content) to be rendered as nested. But for
>> some reason i thought that a simple mention in javadoc about putting
>> modal window to form would be sufficient. My bad.
>>
>>>
>>> From the other hand I believe it is possible to write pure Wicket
>>> component
>>> that would be as trice as simpler and won't suffer with problems with
>>> request lifecycle. Probably I'm wrong and it is not worth turning the old
>>> ModalWindow into pure Wicket component due to expensiveness of the effort
>>> that would be spent to remain it compatible.
>> Would you mind specifying the actual problems with "request
>> lifecycle"? And how exactly would a "pure wicket modal window" look
>> like? No javascript?
>>>
>>> The same about tree components. The API is very difficult to comprehend.
>>> Component does not work as I expect in dynamic context. But thankfully
>>> Sven
>>> implemented different implementation that does what is expect and usable
>>> as
>>> well as DataTable component. I believe forking and fixing the original
>>> component would be much more expensive. After that so many people should
>>> start complaining about that to convince core team that there is not just
>>> one person who is experiencing problems. It is always difficult to
>>> accomplish.
>> I would like to have some clarification on this. What is so difficult
>> about the Wicket Tree API? (apart from the fact that it uses swing
>> TreeModel which seem to be too confusing for some people). What does
>> "dynamic" context mean? Assuming you have properly implemented
>> TreeModel that fires the proper notifications, wicket tree is capable
>> for updating itself on ajax request by only transmitting the changed
>> part to the clients. How much more dynamic can you get?
>>
>> For next version we will probably ditch swing TreeModel for something
>> simpler but we will still need some kind of modal change notification.
>> Wicket tree has many objectives, simplicity is only one of them.
>> Having simple tree is nice as long as you don't have to refresh the
>> entire thing every time you expand a node or add a node child.
>>
>> -Matej
>>>
>>>
>>> jthomerson wrote:
>>>>
>>>> Why create your own? Submit a patch to fix what you see is wrong with
>>>> the current one. Everyone wins.
>>>>
>>>> --
>>>> Jeremy Thomerson
>>>> http://www.wickettraining.com
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Jul 28, 2009 at 12:20 PM, Vladimir K<koval...@gmail.com> wrote:
>>>>>
>>>>> ModalWindow (being a wicket cheat :) ) deserves a sole book of tricks.
>>>>> I'll
>>>>> definitely author my own modal window unless someone fixes the original
>>>>> one.
>>>>> -1 on including ModalWindow to the book.
>>>>>
>>>>>
>>>>> egolan74 wrote:
>>>>>>
>>>>>> I can't wait for yet another great Wicket book.
>>>>>> I will surly buy it.
>>>>>>
>>>>>> regarding tricks,
>>>>>> using Modal window can be nice.
>>>>>> Integrating Wicket with JS libs (If it's not a topic for a small book
>>>>>> by
>>>>>> itself).
>>>>>> Cool stuff with Ajax.
>>>>>>
>>>>>>
>>>>>> Eyal Golan
>>>>>> egola...@gmail.com
>>>>>>
>>>>>> Visit: http://jvdrums.sourceforge.net/
>>>>>> LinkedIn: http://www.linkedin.com/in/egolan74
>>>>>>
>>>>>> P Save a tree. Please don't print this e-mail unless it's really
>>>>>> necessary
>>>>>>
>>>>>>
>>>>>> On Tue, Dec 30, 2008 at 10:32 AM, Jonathan Locke
>>>>>> <jonathan.lo...@gmail.com>wrote:
>>>>>>
>>>>>>>
>>>>>>> Well, over the break here I've started something I swore I would
>>>>>>> never
>>>>>>> do
>>>>>>> again (well, two things, if you include the JavaOne talk I'm working
>>>>>>> on).
>>>>>>> I'm writing a (hopefully relatively short) book. It's called
>>>>>>> "Twenty-Six
>>>>>>> Wicket Tricks". Each trick in the book (lettered from A-Z)
>>>>>>> demonstrates
>>>>>>> something that people typically want to do and in the process builds
>>>>>>> a
>>>>>>> reusable and educational component. I've got 13 tricks coded up now
>>>>>>> and
>>>>>>> ideas for a handful more, but if there are any requests out there,
>>>>>>> please
>>>>>>> let me know. I'd also be interested in getting some idea how many
>>>>>>> people
>>>>>>> would be interested in this book (would provide some fuel for me to
>>>>>>> get
>>>>>>> it
>>>>>>> done). It does not cover any of the same ground as Wicket in Action
>>>>>>> (which
>>>>>>> you should buy if you have not already!), BTW. It's more of a
>>>>>>> companion
>>>>>>> to
>>>>>>> that book.
>>>>>>>
>>>>>>> Happy Holidays!
>>>>>>>
>>>>>>> Best,
>>>>>>>
>>>>>>> Jonathan
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> View this message in context:
>>>>>>> http://www.nabble.com/Twenty-Six-Wicket-Tricks-tp21214357p21214357.html
>>>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> -----
>>>>>> Eyal Golan
>>>>>> egola...@gmail.com
>>>>>>
>>>>>> Visit: JVDrums
>>>>>> LinkedIn: LinkedIn
>>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/Twenty-Six-Wicket-Tricks-tp21214357p24704037.html
>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Twenty-Six-Wicket-Tricks-tp21214357p24705381.html
>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/Twenty-Six-Wicket-Tricks-tp21214357p24706890.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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
