On Tue, Jul 28, 2009 at 9:58 PM, Vladimir K<koval...@gmail.com> wrote: > > Matej, > > one of the problems is that when ajax submit happens (by pressing ajax > submit button that resides in a form that resides in a ModalWindow that is > put into another form) it contains no data for the components of enclosing > form but the process of handling the submit handles the eclosing form and > the validation fails or the values become empty. (If I remember all the > details correctly - it was 3 months ago) How can this happen? The submit should only process nested form and leave the outer forms alone. When nested form is submitted there is no reason for validating any component in the outer form. > > Another problem happens when you don't use ajax submit but regular one > instead. If I'm not wrong Wicket can't find components of inner form. Modal Window is an ajax component. Submitting it with regular submit is not supported and it never was. > > In case if some pieces are missed in sandwitch Form>ModalWinwod>Form the > mismatch occurs immediately. > > Having no acces to hardcoded form element makes impossible to enhance > ModalWindow as well as to implement just regular upload submit from within > ModalWindow without patching .js file. If you could fix that (preventing > wicket from making it a div) and make the form configurable it would be > great! Again, modal window doesn't support regular submits (by design) so if you want to do file upload you'll have to use a hidden iframe or some other approach like that. > > Concerning Tree. It is my subjective opinion. It is the API that was > difficult to figure out how to employ to solve my tasks. I find the > difference betwen DataTable and TreeTable APIs to be unnecessary difficulty > to users. At least they are two different things that requires more time to > learn and work with. And if you have a panel where you switch between table > and tree you have to write an abstraction layer. Sven's TableTree just fits > where it should be. I completely added it within 2 hours. TreeTable took 2 > days to learn and employ. Once again, I'm subjective here. It was just my > experience. My idea is that diversity is a good thing when the original > component dont meet our needs makes the development more complicated. TreeTable is slightly problematic because it doesn't use regular table but it builds the layout by css. There was a good reason back then for building it like this but it's not relevant anymore. Apart from that - tree table gets list of IColumns and a TreeModel. How is this complicated? > > I'm aware of CSS positioning model and I have ideas to investigate. Besides > there are a jQuery popup window which example is embedded into enclosing div > and can be freely relocated inside the body. I just looked at jquery dialog example. The dialog is declared in markup but it is then reparented as top level DOM element. Same thing wicket modalwindow does. > > Anyway it is possible to do what the modal.js is doing by Wicket means and > don't have a component tree mismatch with DOM. Is it really? Mind sharing with me how?
-Matej > > > 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-tp21214357p24706784.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
