Re: dojo dialog to populate portion of form and submit
Fair enough, it was a pretty jumbled structure and as a result difficult to describe. Unfortunately I've moved on with my form separation method (as you describe how you use dialog forms) which works well enough. Essentially I had form some form elements/ link onclick=async:load data into dialog and show it/ submit onclick=sync:save form, dialog portion blank and ignored/ dialog hidden=true some form elements/ submit onclick=sync:save whole form including dialog part and reload page/ /dialog /form Now, when I used the dialog submit the dialog's form elements were submitting null/empty values. My theory was that when the dialog and child components were re-rendered when the dialog was updated in the async request, they were becoming detached form the original form. Come to think of it, I wasn't specifying the component Id's (ie i was just doing jwcid=@TextField) maybe if I specified an Id it would work? Thanks for the interest jesse. does any of this make sense? Jesse Kuhnert wrote: I can't really piece together what you are doing vs. what is not working as expected but the Dialog component essentially does nothing other than wrap a block of html. Tapestry does maintain form state during ajax requests - so if that's not happening then something is wrong. It's possible that the client side javascript code implementing the dialog moves the html nodes around in such a way that if you don't have a form within the dialog itself that the nodes will become separated from the original form and start to break things. I have always placed forms within my dialogs even when on pages with one big form as the placement of the dialog outside of the big form makes no difference as the html displayed is always centered anyways. Maybe an example would help but I just am not getting it looking at the paragraphs of text. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dojo dialog to populate portion of form and submit
The dojo dialog control moves the rendered dialog around in the DOM so it's just inside the closing /body tag. They do this so it's in a known place and they can make some assumptions about (lack of) nesting when it renders. However, this effectively moves it outside any forms. Use firebug to inspect the DOM when you show the dialog and you'll see it at the very end instead of where you placed it. To make things work, you have to place the dojo dialog outside any existing forms and it needs to include it's own @Form tag. Alternately, I made a dirty hack to move the dialog just inside a closing form tag instead of a body tag. It works for me because my form is just inside body, but I don't know how well it'll work on other structures. FormDialog.java: package com.vms.infrastructure.tapestry.components; import java.util.HashMap; import java.util.Map; import org.apache.tapestry.IForm; import org.apache.tapestry.IMarkupWriter; import org.apache.tapestry.IRequestCycle; import org.apache.tapestry.IScript; import org.apache.tapestry.TapestryUtils; import org.apache.tapestry.annotations.ComponentClass; import org.apache.tapestry.annotations.InjectScript; import org.apache.tapestry.annotations.Parameter; import org.apache.tapestry.dojo.html.Dialog; @ComponentClass(allowBody=true, allowInformalParameters=true) public abstract class FormDialog extends Dialog { @Parameter(defaultValue=ognl:true) public abstract boolean isHidden(); @Parameter(defaultValue=literal:black) public abstract String getBackgroundColor(); @Parameter(defaultValue=0.4) public abstract float getOpacity(); @Parameter public abstract String getParent(); @InjectScript(FormNest.script) public abstract IScript getMoveScript(); @InjectScript(Dialog.script) public abstract IScript getScript(); public void renderComponent(IMarkupWriter writer, IRequestCycle cycle) { super.renderComponent(writer, cycle); if (cycle.isRewinding()) { return; } // don't need this during rewind String resolvedParent = null; if (isParameterBound(parent)) { resolvedParent = getParent(); } else { IForm form = (IForm) cycle.getAttribute(TapestryUtils.FORM_ATTRIBUTE); if (form != null) { resolvedParent = form.getClientId(); } } if (resolvedParent != null) { MapString,Object symbols = new HashMapString,Object(); symbols.put(dialogId, getClientId()); symbols.put(parent, resolvedParent); getMoveScript().execute(this, cycle, TapestryUtils.getPageRenderSupport(cycle, this), symbols); } } } FormNest.script: ?xml version=1.0? !DOCTYPE script PUBLIC -//Apache Software Foundation//Tapestry Script Specification 3.0//EN http://jakarta.apache.org/tapestry/dtd/Script_3_0.dtd; script input-symbol key=dialogId class=java.lang.String required=yes/ input-symbol key=parent class=java.lang.String required=yes/ initialization dojo.byId('${parent}').appendChild(dojo.byId('${dialogId}')) /initialization /script I also had to copy Dialog.script into my scripts folder. -Steve Paul Stanton wrote: Fair enough, it was a pretty jumbled structure and as a result difficult to describe. Unfortunately I've moved on with my form separation method (as you describe how you use dialog forms) which works well enough. Essentially I had form some form elements/ link onclick=async:load data into dialog and show it/ submit onclick=sync:save form, dialog portion blank and ignored/ dialog hidden=true some form elements/ submit onclick=sync:save whole form including dialog part and reload page/ /dialog /form Now, when I used the dialog submit the dialog's form elements were submitting null/empty values. My theory was that when the dialog and child components were re-rendered when the dialog was updated in the async request, they were becoming detached form the original form. Come to think of it, I wasn't specifying the component Id's (ie i was just doing jwcid=@TextField) maybe if I specified an Id it would work? Thanks for the interest jesse. does any of this make sense? Jesse Kuhnert wrote: I can't really piece together what you are doing vs. what is not working as expected but the Dialog component essentially does nothing other than wrap a block of html. Tapestry does maintain form state during ajax requests - so if that's not happening then something is wrong. It's possible that the client side javascript code implementing the dialog moves the html nodes around in such a way that if you don't have a form within the dialog itself that the nodes will become separated from the original form and start to break things. I have always placed forms within my dialogs even when on pages with one big form as the placement of the dialog outside of the big form makes no
Re: dojo dialog to populate portion of form and submit
The trick is that the dialog its always inside the Form, as a hidden part of the dom i,e: visibility='hidden': div id=ognl:contenedorId jwcid=@Any style=position:absolute;visibility:hidden;z-index: 555 span jwcid=@RenderBody/ /div Whenever I need such dialog to show(and render or populate its bindings) I update the @Any component, and change the visibility and position via javascript (it has to be done with js to paint it right). regards, Miguel On 5/30/07, Paul Stanton [EMAIL PROTECTED] wrote: how did you handle population of the dialog form portion? Miguel Angel Hernández wrote: Hi Paul I've been in a very similar situation(but in tap4 with tacos) you're in. To solve it I decided to implement my own Dialog component which can be contained inside a form, and this worked fine for me. I've controlled the show and hide issue with Javascript and css. So the component its always rendered. I'll post the code if you are interested. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dojo dialog to populate portion of form and submit
Ok, but I need to populate the form content with ajax. I could edit 1 of 50 elements, and i don't want to load in all of the editable data until it's selected. The problem as I see it is less that the dialog is shown/hidden, but that the form components are essentially detached from the page's form once they are updated via ajax. FYI I've solved this by reworking my border component so that I can have more than one form per page. The only drawback is that if I change the enabled/disabled status of an element (click checkbox), then load the dialog and save that, my enable/disable change is not registered, as the page's form is not submitted. Anyway, I think it's a small price to pay, however it would have been nice if tapestry could maintain the link with updated form components as described. Thanks for the help Miguel. Miguel Angel Hernández wrote: The trick is that the dialog its always inside the Form, as a hidden part of the dom i,e: visibility='hidden': div id=ognl:contenedorId jwcid=@Any style=position:absolute;visibility:hidden;z-index: 555 span jwcid=@RenderBody/ /div Whenever I need such dialog to show(and render or populate its bindings) I update the @Any component, and change the visibility and position via javascript (it has to be done with js to paint it right). regards, Miguel On 5/30/07, Paul Stanton [EMAIL PROTECTED] wrote: how did you handle population of the dialog form portion? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dojo dialog to populate portion of form and submit
I can't really piece together what you are doing vs. what is not working as expected but the Dialog component essentially does nothing other than wrap a block of html. Tapestry does maintain form state during ajax requests - so if that's not happening then something is wrong. It's possible that the client side javascript code implementing the dialog moves the html nodes around in such a way that if you don't have a form within the dialog itself that the nodes will become separated from the original form and start to break things. I have always placed forms within my dialogs even when on pages with one big form as the placement of the dialog outside of the big form makes no difference as the html displayed is always centered anyways. Maybe an example would help but I just am not getting it looking at the paragraphs of text. On 5/31/07, Paul Stanton [EMAIL PROTECTED] wrote: Ok, but I need to populate the form content with ajax. I could edit 1 of 50 elements, and i don't want to load in all of the editable data until it's selected. The problem as I see it is less that the dialog is shown/hidden, but that the form components are essentially detached from the page's form once they are updated via ajax. FYI I've solved this by reworking my border component so that I can have more than one form per page. The only drawback is that if I change the enabled/disabled status of an element (click checkbox), then load the dialog and save that, my enable/disable change is not registered, as the page's form is not submitted. Anyway, I think it's a small price to pay, however it would have been nice if tapestry could maintain the link with updated form components as described. Thanks for the help Miguel. Miguel Angel Hernández wrote: The trick is that the dialog its always inside the Form, as a hidden part of the dom i,e: visibility='hidden': div id=ognl:contenedorId jwcid=@Any style=position:absolute;visibility:hidden;z-index: 555 span jwcid=@RenderBody/ /div Whenever I need such dialog to show(and render or populate its bindings) I update the @Any component, and change the visibility and position via javascript (it has to be done with js to paint it right). regards, Miguel On 5/30/07, Paul Stanton [EMAIL PROTECTED] wrote: how did you handle population of the dialog form portion? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
Re: dojo dialog to populate portion of form and submit
I've just tried a javascript writeback hack (trying to keep it tapestry-ish, yet it's a hack for sure) basically, the dialog's form elements are Any's so they populate correctly, but don't submit to tapestry. then when the submit button is clicked they Any's values are sucked into some hidden (TextField with display:none in css) and the form is submitted. I figured this would take advantage of the ajax parts that work for me, and avoid what isn't working. the problem with this is that: 1. I need to make use of a converter to make sure that tapestry can find the appropriate object on rewind; i can't figure out how to use a converter on a plain old TextField or Hidden 2. If there are validation issues with the user input, the Any component needs to receive the validator message etc, not the invisible TextField. I'd love to be able to change my border component so that the LinkSubmit's can sit outside of the form (substitute them with something else) so that pages can define their own forms and where they begin/end, however that in it's self will be a hack and it means changing ten pages to include a hack vs changing 1 page to include a hack (if i can hack through this dialog issue). Any suggestions welcome. Paul. Paul Stanton wrote: 4.1.1 Firstly, I'm pretty sure what I'm trying to do is not possible, so read on with that in mind. My border component defines my form. This is necessary because I have a tabbed structure where the tabs are LinkSubmit's and need to be associated with a Form. My page has part of the form content always displayed, normally without ajax or anything dynamic. This part is a list of elements with checkboxes to enable/disable. When clicking on an element in the list, a dojo Dialog is displayed containing a previously existant yet hidden portion of the form to edit the attributes of the element along with a LinkSubmit to submit the whole form (border form) when the user is done. Note that I must continue the existing border's form as the dialog code needs to sit within the border, otherwise it would fall outside of the html element. I can't for the life of me get this to work. I think because the Dialog is re-rendered (updateComponent) the dialogs portion of the form is essentially detached from the border forms request cycle. No matter what I enter in the dialog, nothing comes back to the listener when the form is submitted. Is what I'm trying to do possible, or do I need to rip apart my border component so that I can embed a separate form in the dialog? Thanks, Paul. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dojo dialog to populate portion of form and submit
Hi Paul I've been in a very similar situation(but in tap4 with tacos) you're in. To solve it I decided to implement my own Dialog component which can be contained inside a form, and this worked fine for me. I've controlled the show and hide issue with Javascript and css. So the component its always rendered. I'll post the code if you are interested. On 5/30/07, Paul Stanton [EMAIL PROTECTED] wrote: I've just tried a javascript writeback hack (trying to keep it tapestry-ish, yet it's a hack for sure) basically, the dialog's form elements are Any's so they populate correctly, but don't submit to tapestry. then when the submit button is clicked they Any's values are sucked into some hidden (TextField with display:none in css) and the form is submitted. I figured this would take advantage of the ajax parts that work for me, and avoid what isn't working. the problem with this is that: 1. I need to make use of a converter to make sure that tapestry can find the appropriate object on rewind; i can't figure out how to use a converter on a plain old TextField or Hidden 2. If there are validation issues with the user input, the Any component needs to receive the validator message etc, not the invisible TextField. I'd love to be able to change my border component so that the LinkSubmit's can sit outside of the form (substitute them with something else) so that pages can define their own forms and where they begin/end, however that in it's self will be a hack and it means changing ten pages to include a hack vs changing 1 page to include a hack (if i can hack through this dialog issue). Any suggestions welcome. Paul. Paul Stanton wrote: 4.1.1 Firstly, I'm pretty sure what I'm trying to do is not possible, so read on with that in mind. My border component defines my form. This is necessary because I have a tabbed structure where the tabs are LinkSubmit's and need to be associated with a Form. My page has part of the form content always displayed, normally without ajax or anything dynamic. This part is a list of elements with checkboxes to enable/disable. When clicking on an element in the list, a dojo Dialog is displayed containing a previously existant yet hidden portion of the form to edit the attributes of the element along with a LinkSubmit to submit the whole form (border form) when the user is done. Note that I must continue the existing border's form as the dialog code needs to sit within the border, otherwise it would fall outside of the html element. I can't for the life of me get this to work. I think because the Dialog is re-rendered (updateComponent) the dialogs portion of the form is essentially detached from the border forms request cycle. No matter what I enter in the dialog, nothing comes back to the listener when the form is submitted. Is what I'm trying to do possible, or do I need to rip apart my border component so that I can embed a separate form in the dialog? Thanks, Paul. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
dojo dialog to populate portion of form and submit
4.1.1 Firstly, I'm pretty sure what I'm trying to do is not possible, so read on with that in mind. My border component defines my form. This is necessary because I have a tabbed structure where the tabs are LinkSubmit's and need to be associated with a Form. My page has part of the form content always displayed, normally without ajax or anything dynamic. This part is a list of elements with checkboxes to enable/disable. When clicking on an element in the list, a dojo Dialog is displayed containing a previously existant yet hidden portion of the form to edit the attributes of the element along with a LinkSubmit to submit the whole form (border form) when the user is done. Note that I must continue the existing border's form as the dialog code needs to sit within the border, otherwise it would fall outside of the html element. I can't for the life of me get this to work. I think because the Dialog is re-rendered (updateComponent) the dialogs portion of the form is essentially detached from the border forms request cycle. No matter what I enter in the dialog, nothing comes back to the listener when the form is submitted. Is what I'm trying to do possible, or do I need to rip apart my border component so that I can embed a separate form in the dialog? Thanks, Paul. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]