I believe I have verified that this is a layering issue. I create two modal 
dialogs in an identical fashion and access them in the following way:

Page contains commandLink1 to first modalDialog1.
modalDialog1 contains a commandLink2 to modalDialog2.

Clicking on commandLink1 will cause modalDialog1 to appear.  I am unable to 
select any text behind the dialog.
Clicking on commandLink2 (from within modalDialog1) will cause modalDialog2 to 
appear on top of modalDialog1.

I am able to select the text within modalDialog1 while modalDialog2 is visible. 
 At this point, I am unable to type into the text field in modalDialog2 
(h:inputText component).  I am able to click on the commandButton in 
modalDialog1 and close modalDialog1 while modalDialog2 is still open.  Once 
modalDialog1 is closed modalDialog2's text field is now editable.

Regards,
Joshua Pheneger

-----Original Message-----
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Werner Punz
Sent: Wednesday, January 31, 2007 11:54 AM
To: users@myfaces.apache.org
Subject: Re: modalDialog scrolls endlessly on page

Ok I only see one problem
you mix and match html input fields
with jsf forms there ,
I am not sure how facelets behave
there, but you ask for trouble regarding other stuff (like automatic value 
assigment, automatic validation etc...) try to replace your simple input field 
with the jsf equivalent h:inputText or t:inputText.

What should happen is, first, you should be able to edit the fields secondly, 
you should be able to submit the form, and get the values into the  beans 
assigned to the field.

Check the tomahawk-sandbox-examples for exactly this usecase, like gerald 
pointed it out.

As for stacking dialogs, yes it is possible, but i do not know how it behaves 
formwise, but I assume following first dialog has a form, second one is opened 
after the first one, it should be stacked on top of the first one also has a 
form, you submit the form in the second dialog and trigger a page refresh, the 
values of the second form should be assigned to the backend beans, and you will 
basically lose both dialogs, the changed values of the first dialog will be 
lost however!.


Joshua Pheneger schrieb:
> I will file a bug with the dojo team to investigate the dialog scrolling 
> issue.
> 
> Can you clarify your response on the form text field issue?  Is it 
> possible/recommended to use a form within a dialog that is sitting on top of 
> another dialog?  What would the code look like?  The following code does not 
> allow the text field to be edited.
> 
> <b:modalDialog dialogId="TripDatesDialogContent" dialogVar="tripDatesDialog"
>       dialogAttr="bgColor='white' bgOpacity='0.5' toggle='fade' 
> toggleDuration='250'"
>       hiderIds="cancel2" styleClass="dojoDialog">
>       <h:form>
>               <h:panelGrid>
>                       <input type="text" name="something" value="myvalue" 
> id="newdates" size="25"/>
>                       <b:commandButton id="cancel2" forceId="true" 
> value="Cancel"
>                               
> onclick="dojo.widget.byId('TripDatesDialogContent').hide();" />
>               </h:panelGrid>
>       </h:form>
> </b:modalDialog>
> 
> 
> Regards,
> Joshua Pheneger
> 
> -----Original Message-----
> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Werner Punz
> Sent: Wednesday, January 31, 2007 8:22 AM
> To: users@myfaces.apache.org
> Subject: Re: modalDialog scrolls endlessly on page
> 
> Gerald Müllan schrieb:
>> Hi,
>>
>> the modalDialog component uses the dojo js-lib dialog widget. Any js 
>> related problems can not be solved by myfaces developers, they are 
>> only dojo-related. Maybe you can find help with this issue on the 
>> dojo list.
>>
> The dialog issue is an issue with the dojo dialog itself, there is a 
> parameter in the dojo baselib which can prevent this behavior (it is 
> called centerdialog or so, you really have to check the dialog sources 
> for this) I rember having such a param at least in dojo 0.4.1 which is 
> the latest currently being in tomahawk
> 
> I am not sure if it already is exposed.
> There also is the possibility to use floating panes instead of the dialog.
> 
> 
>> Apart from this, it maybe an issue you can live with; i also use the 
>> modalDialog in an application and it works very well.
>>
>> The current sandbox snapshot with the dialog component is deployed here:
>>
>> http://example.irian.at/example-sandbox-20070131/dojo/dojoDialog.jsf
>>
>> If you click on "searchOuterForm", the dialog accomplishes the same 
>> usecase as you have with the form. Seems to work there.Have a look at 
>> the source of the example, maybe it can assist.
>>
>> What you mean by unable to enter? Are the input fields hidden, or 
>> disabled? Does the post not happen?
>>
> The code looks to me as if the form is declared outside of the dialog this is 
> not possible due to browser limitations, mainly caused by the broken ie css 
> implementation.
> If you want to use the dialog in conjunction with forms use it outside of any 
> form definition and put the form into the dialog, there are various ways to 
> savestate the affected values, so that you do not have to push all page 
> related values into the dialog.
> (for most cases a simple savestate on a bean should do it)
> 

Reply via email to