You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Paul Stanton <pa...@gunnsoft.com.au> on 2007/05/30 07:36:32 UTC

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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: dojo dialog to populate portion of form and submit

Posted by Steve Shucker <ss...@vmsinfo.com>.
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) {
            Map<String,Object> symbols = new HashMap<String,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
>> 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: dojo dialog to populate portion of form and submit

Posted by Paul Stanton <pa...@gunnsoft.com.au>.
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: dojo dialog to populate portion of form and submit

Posted by Jesse Kuhnert <jk...@gmail.com>.
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 <pa...@gunnsoft.com.au> 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 <pa...@gunnsoft.com.au> wrote:
> >>
> >> how did you handle population of the dialog form portion?
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>


-- 
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

Posted by Paul Stanton <pa...@gunnsoft.com.au>.
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 <pa...@gunnsoft.com.au> wrote:
>>
>> how did you handle population of the dialog form portion? 
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: dojo dialog to populate portion of form and submit

Posted by Miguel Angel Hernández <mi...@gmail.com>.
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 <pa...@gunnsoft.com.au> 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>

Re: dojo dialog to populate portion of form and submit

Posted by Paul Stanton <pa...@gunnsoft.com.au>.
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: dojo dialog to populate portion of form and submit

Posted by Miguel Angel Hernández <mi...@gmail.com>.
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 <pa...@gunnsoft.com.au> 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: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>

Re: dojo dialog to populate portion of form and submit

Posted by Paul Stanton <pa...@gunnsoft.com.au>.
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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: 4.1.2 Cometd Implimentation

Posted by Jesse Kuhnert <jk...@gmail.com>.
Yes I'd love to get it going Craig.  I'm sure Alex from Dojo and Greg from
jetty would be happy to see it done as well.

I can make myself available to resolve whatever hurdles need moving / etc in
Tapestry to make this happen.

On 5/30/07, Craig Spry <cr...@redflex.com.au> wrote:
>
> I'm looking at adding cometd type functionality to the tapestry
> 4.1.2-snapshot application that I'm currently developing.  I would like
> to do it as follows:
>
> Have only one cometd subscription per page.  This would be bound to a
> javascript function that would have the updates sent to it, much like
> XHR works at the moment, except in reverse.
>
> Then in the Java code for that page I would have a thread that would
> have code in it that would look something like this:
>
> private void poll()
> {
>         while(true)
>         {
>                 Thread.sleep(1000)
>                 {
>                         if(some_condition)
>                         {
>
> MyTapestryCometdClient.updateComponent('component_id');
>                         }
>                 }
>         }
> }
>
> Where MyTapestryCometdClient would be my implementation to send out the
> cometd request to all the waiting javascript functions.
>
> I'm going to use Jetty's implementation of cometd.
>
> What I would like to know is what I'm trying to achieve feasible, can
> Tapestry 4.1.2 even be made work with comet?
>
> Has anyone else already got Tapestry to work with cometd?
>
> Or is there a better way to get events from the server to a waiting web
> page that doesn't involve polling?
>
> If no one has and I do manage to get it to work, would anyone else be
> interested in how I got it to work?
>
> Thanks,
> Craig Spry
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>


-- 
Jesse Kuhnert
Tapestry/Dojo team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com

4.1.2 Cometd Implimentation

Posted by Craig Spry <cr...@redflex.com.au>.
I'm looking at adding cometd type functionality to the tapestry
4.1.2-snapshot application that I'm currently developing.  I would like
to do it as follows:

Have only one cometd subscription per page.  This would be bound to a
javascript function that would have the updates sent to it, much like
XHR works at the moment, except in reverse.

Then in the Java code for that page I would have a thread that would
have code in it that would look something like this:

private void poll()
{
	while(true)
	{
		Thread.sleep(1000)
		{
			if(some_condition)
			{
	
MyTapestryCometdClient.updateComponent('component_id');
			}
		}
	}
} 

Where MyTapestryCometdClient would be my implementation to send out the
cometd request to all the waiting javascript functions. 

I'm going to use Jetty's implementation of cometd.
 
What I would like to know is what I'm trying to achieve feasible, can
Tapestry 4.1.2 even be made work with comet?

Has anyone else already got Tapestry to work with cometd?

Or is there a better way to get events from the server to a waiting web
page that doesn't involve polling?

If no one has and I do manage to get it to work, would anyone else be
interested in how I got it to work?

Thanks,
Craig Spry

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org