User Interaction for Background Form submit.
Locked
User Interaction for Background Form submit.
 
|
Hi,
We have a working example of Background form submit. The way it is now, After successful submit, form is reset. This is a clean new form to start entering new record. In some situations we may want to do something different, Like 1) When we are editing a form then sometime we want to keep the information in the form after form submit. 2) Sometime we want to hide form on successful form submit 3) We want to turn form into View only after form submit There can be many more such situations. I'll like to collect all such After form submit situations together first. Once we have all that we can think about attributes or subelement inside of form element that will let us choose our option from all that is available. Looking forward to see inputs from all interested parties. Thanks and Regards Anil Patel |
smime.p7s (3K)
Re: User Interaction for Background Form submit.
|
|
Re: User Interaction for Background Form submit.
|
|
Adrian,
To me <on-event-update-area> is good element for doing some thing like what is done current implementation. Like update the list to reflect the new addition. What I am talking about is 1) Should form reset after submit 2) Should form hide after submit 3) Should form keep showing the same data, well this is same as DO_NOT_RESET after submit 4) Show data in View only mode. These are few options that come to my mind, I'll like to get more listed if there are any other. Come up with final list of those items. Once we have such list we can implement them. For implementation I don't see this one element fit in this need. I see this as Behavior of Form on its "SUBMIT". To me <on-event-update- area> is for telling system to update certain area on successful execution of some form event. Regards Anil K Patel On Jun 26, 2008, at 4:54 PM, Adrian Crum wrote: > Anil, > > Many thanks for your continuing work on the Ajax stuff! > > Why wouldn't the existing <on-event-update-area> element handle > these requirements? What you are describing are different responses > to the event, not different events. > > -Adrian > > Anil Patel wrote: >> Hi, >> We have a working example of Background form submit. The way it is >> now, After successful submit, form is reset. This is a clean new >> form to start entering new record. >> In some situations we may want to do something different, Like >> 1) When we are editing a form then sometime we want to keep the >> information in the form after form submit. >> 2) Sometime we want to hide form on successful form submit >> 3) We want to turn form into View only after form submit >> There can be many more such situations. >> I'll like to collect all such After form submit situations together >> first. Once we have all that we can think about attributes or >> subelement inside of form element that will let us choose our >> option from all that is available. >> Looking forward to see inputs from all interested parties. >> Thanks and Regards >> Anil Patel |
Re: User Interaction for Background Form submit.
|
|
Re: User Interaction for Background Form submit.
|
|
Then I'll rather add element <on-submit> that tells me exactly that
what needs to happen on form submit. This will make lot easier for developer because it will be as easy for developer as answering certain questions and get a standard out of box behavior. Adding so much on way too generic element like is <on-event-update- area> adds complexity for average developer. Regards Anil Patel On Jun 26, 2008, at 5:19 PM, Adrian Crum wrote: > Your list of ideas all revolve around a form submit. So just like in > the Example component, you can have different responses to the event. > > For example, if you want a form changed to read-only after a submit, > use the on-event-update-area element and use a target that returns a > read-only form. > > -Adrian > > Anil Patel wrote: >> Adrian, >> To me <on-event-update-area> is good element for doing some thing >> like what is done current implementation. Like update the list to >> reflect the new addition. What I am talking about is >> 1) Should form reset after submit >> 2) Should form hide after submit >> 3) Should form keep showing the same data, well this is same as >> DO_NOT_RESET after submit >> 4) Show data in View only mode. >> These are few options that come to my mind, I'll like to get more >> listed if there are any other. Come up with final list of those >> items. Once we have such list we can implement them. >> For implementation I don't see this one element fit in this need. I >> see this as Behavior of Form on its "SUBMIT". To me <on-event- >> update-area> is for telling system to update certain area on >> successful execution of some form event. >> Regards >> Anil K Patel >> On Jun 26, 2008, at 4:54 PM, Adrian Crum wrote: >>> Anil, >>> >>> Many thanks for your continuing work on the Ajax stuff! >>> >>> Why wouldn't the existing <on-event-update-area> element handle >>> these requirements? What you are describing are different >>> responses to the event, not different events. >>> >>> -Adrian >>> >>> Anil Patel wrote: >>>> Hi, >>>> We have a working example of Background form submit. The way it >>>> is now, After successful submit, form is reset. This is a clean >>>> new form to start entering new record. >>>> In some situations we may want to do something different, Like >>>> 1) When we are editing a form then sometime we want to keep the >>>> information in the form after form submit. >>>> 2) Sometime we want to hide form on successful form submit >>>> 3) We want to turn form into View only after form submit >>>> There can be many more such situations. >>>> I'll like to collect all such After form submit situations >>>> together first. Once we have all that we can think about >>>> attributes or subelement inside of form element that will let us >>>> choose our option from all that is available. >>>> Looking forward to see inputs from all interested parties. >>>> Thanks and Regards >>>> Anil Patel |
Re: User Interaction for Background Form submit.
|
|
Re: User Interaction for Background Form submit.
|
|
On Jun 26, 2008, at 5:36 PM, Adrian Crum wrote: > I don't how <on-event-update-area event-type="submit"> is harder to > understand than <on-submit>, but then maybe I'm smarter than the > average developer. ;-) > I Agree that its true. > If you want to have different elements for different events, that's > fine. I just see a lot of overlap down the road. > > By the way, the Ajax Example is broken. The Status dropdown doesn't > work anymore, and it looks like the <on-event-update-area> element > for the form refresh was removed. > I worked on the Ajax example. Now we don't have to refresh form section by updating the html. Actually that was not right way. So I removed it and added code in javascript to take care of resetting the form after submit. Also now its reporting errors that it never did earlier. The Status drop down is now using Autocompleter dropdown. I'll check it for problems it might have. > -Adrian > > Anil Patel wrote: >> Then I'll rather add element <on-submit> that tells me exactly that >> what needs to happen on form submit. This will make lot easier for >> developer because it will be as easy for developer as answering >> certain questions and get a standard out of box behavior. >> Adding so much on way too generic element like is <on-event-update- >> area> adds complexity for average developer. >> Regards >> Anil Patel >> On Jun 26, 2008, at 5:19 PM, Adrian Crum wrote: >>> Your list of ideas all revolve around a form submit. So just like >>> in the Example component, you can have different responses to the >>> event. >>> >>> For example, if you want a form changed to read-only after a >>> submit, use the on-event-update-area element and use a target that >>> returns a read-only form. >>> >>> -Adrian >>> >>> Anil Patel wrote: >>>> Adrian, >>>> To me <on-event-update-area> is good element for doing some thing >>>> like what is done current implementation. Like update the list to >>>> reflect the new addition. What I am talking about is >>>> 1) Should form reset after submit >>>> 2) Should form hide after submit >>>> 3) Should form keep showing the same data, well this is same as >>>> DO_NOT_RESET after submit >>>> 4) Show data in View only mode. >>>> These are few options that come to my mind, I'll like to get more >>>> listed if there are any other. Come up with final list of those >>>> items. Once we have such list we can implement them. >>>> For implementation I don't see this one element fit in this need. >>>> I see this as Behavior of Form on its "SUBMIT". To me <on-event- >>>> update-area> is for telling system to update certain area on >>>> successful execution of some form event. >>>> Regards >>>> Anil K Patel >>>> On Jun 26, 2008, at 4:54 PM, Adrian Crum wrote: >>>>> Anil, >>>>> >>>>> Many thanks for your continuing work on the Ajax stuff! >>>>> >>>>> Why wouldn't the existing <on-event-update-area> element handle >>>>> these requirements? What you are describing are different >>>>> responses to the event, not different events. >>>>> >>>>> -Adrian >>>>> >>>>> Anil Patel wrote: >>>>>> Hi, >>>>>> We have a working example of Background form submit. The way it >>>>>> is now, After successful submit, form is reset. This is a clean >>>>>> new form to start entering new record. >>>>>> In some situations we may want to do something different, Like >>>>>> 1) When we are editing a form then sometime we want to keep the >>>>>> information in the form after form submit. >>>>>> 2) Sometime we want to hide form on successful form submit >>>>>> 3) We want to turn form into View only after form submit >>>>>> There can be many more such situations. >>>>>> I'll like to collect all such After form submit situations >>>>>> together first. Once we have all that we can think about >>>>>> attributes or subelement inside of form element that will let >>>>>> us choose our option from all that is available. >>>>>> Looking forward to see inputs from all interested parties. >>>>>> Thanks and Regards >>>>>> Anil Patel |
Re: User Interaction for Background Form submit.
|
|
Adrian,
I am sorry, Its ok to update form section on form submit and should not use form reset in javascript. I'll modify that part to back where it was. But then the problem is, I'll have to add code in update area part of javascript to execute any javascript block inside of new html loaded. Regards Anil Patel On Jun 26, 2008, at 5:42 PM, Anil Patel wrote: > > On Jun 26, 2008, at 5:36 PM, Adrian Crum wrote: > >> I don't how <on-event-update-area event-type="submit"> is harder to >> understand than <on-submit>, but then maybe I'm smarter than the >> average developer. ;-) >> > > I Agree that its true. > >> If you want to have different elements for different events, that's >> fine. I just see a lot of overlap down the road. >> >> By the way, the Ajax Example is broken. The Status dropdown doesn't >> work anymore, and it looks like the <on-event-update-area> element >> for the form refresh was removed. >> > > I worked on the Ajax example. Now we don't have to refresh form > section by updating the html. Actually that was not right way. So I > removed it and added code in javascript to take care of resetting > the form after submit. Also now its reporting errors that it never > did earlier. > > The Status drop down is now using Autocompleter dropdown. I'll check > it for problems it might have. > > >> -Adrian >> >> Anil Patel wrote: >>> Then I'll rather add element <on-submit> that tells me exactly >>> that what needs to happen on form submit. This will make lot >>> easier for developer because it will be as easy for developer as >>> answering certain questions and get a standard out of box behavior. >>> Adding so much on way too generic element like is <on-event- >>> update-area> adds complexity for average developer. >>> Regards >>> Anil Patel >>> On Jun 26, 2008, at 5:19 PM, Adrian Crum wrote: >>>> Your list of ideas all revolve around a form submit. So just like >>>> in the Example component, you can have different responses to the >>>> event. >>>> >>>> For example, if you want a form changed to read-only after a >>>> submit, use the on-event-update-area element and use a target >>>> that returns a read-only form. >>>> >>>> -Adrian >>>> >>>> Anil Patel wrote: >>>>> Adrian, >>>>> To me <on-event-update-area> is good element for doing some >>>>> thing like what is done current implementation. Like update the >>>>> list to reflect the new addition. What I am talking about is >>>>> 1) Should form reset after submit >>>>> 2) Should form hide after submit >>>>> 3) Should form keep showing the same data, well this is same as >>>>> DO_NOT_RESET after submit >>>>> 4) Show data in View only mode. >>>>> These are few options that come to my mind, I'll like to get >>>>> more listed if there are any other. Come up with final list of >>>>> those items. Once we have such list we can implement them. >>>>> For implementation I don't see this one element fit in this >>>>> need. I see this as Behavior of Form on its "SUBMIT". To me <on- >>>>> event-update-area> is for telling system to update certain area >>>>> on successful execution of some form event. >>>>> Regards >>>>> Anil K Patel >>>>> On Jun 26, 2008, at 4:54 PM, Adrian Crum wrote: >>>>>> Anil, >>>>>> >>>>>> Many thanks for your continuing work on the Ajax stuff! >>>>>> >>>>>> Why wouldn't the existing <on-event-update-area> element handle >>>>>> these requirements? What you are describing are different >>>>>> responses to the event, not different events. >>>>>> >>>>>> -Adrian >>>>>> >>>>>> Anil Patel wrote: >>>>>>> Hi, >>>>>>> We have a working example of Background form submit. The way >>>>>>> it is now, After successful submit, form is reset. This is a >>>>>>> clean new form to start entering new record. >>>>>>> In some situations we may want to do something different, Like >>>>>>> 1) When we are editing a form then sometime we want to keep >>>>>>> the information in the form after form submit. >>>>>>> 2) Sometime we want to hide form on successful form submit >>>>>>> 3) We want to turn form into View only after form submit >>>>>>> There can be many more such situations. >>>>>>> I'll like to collect all such After form submit situations >>>>>>> together first. Once we have all that we can think about >>>>>>> attributes or subelement inside of form element that will let >>>>>>> us choose our option from all that is available. >>>>>>> Looking forward to see inputs from all interested parties. >>>>>>> Thanks and Regards >>>>>>> Anil Patel > |
Re: User Interaction for Background Form submit.
|
|
Re: User Interaction for Background Form submit.
|
|
Re: User Interaction for Background Form submit.
|
|
I'll get back the needed code soon.
Regards Anil Patel On Jun 26, 2008, at 5:55 PM, Adrian Crum wrote: > If you can get the form refresh back the way it was, and show me the > difficulty you were having with JavaScript, then I'll try to help > figure it out. > > -Adrian > > Anil Patel wrote: >> Adrian, >> I am sorry, Its ok to update form section on form submit and should >> not use form reset in javascript. I'll modify that part to back >> where it was. But then the problem is, I'll have to add code in >> update area part of javascript to execute any javascript block >> inside of new html loaded. >> Regards >> Anil Patel >> On Jun 26, 2008, at 5:42 PM, Anil Patel wrote: >>> >>> On Jun 26, 2008, at 5:36 PM, Adrian Crum wrote: >>> >>>> I don't how <on-event-update-area event-type="submit"> is harder >>>> to understand than <on-submit>, but then maybe I'm smarter than >>>> the average developer. ;-) >>>> >>> >>> I Agree that its true. >>> >>>> If you want to have different elements for different events, >>>> that's fine. I just see a lot of overlap down the road. >>>> >>>> By the way, the Ajax Example is broken. The Status dropdown >>>> doesn't work anymore, and it looks like the <on-event-update- >>>> area> element for the form refresh was removed. >>>> >>> >>> I worked on the Ajax example. Now we don't have to refresh form >>> section by updating the html. Actually that was not right way. So >>> I removed it and added code in javascript to take care of >>> resetting the form after submit. Also now its reporting errors >>> that it never did earlier. >>> >>> The Status drop down is now using Autocompleter dropdown. I'll >>> check it for problems it might have. >>> >>> >>>> -Adrian >>>> >>>> Anil Patel wrote: >>>>> Then I'll rather add element <on-submit> that tells me exactly >>>>> that what needs to happen on form submit. This will make lot >>>>> easier for developer because it will be as easy for developer as >>>>> answering certain questions and get a standard out of box >>>>> behavior. >>>>> Adding so much on way too generic element like is <on-event- >>>>> update-area> adds complexity for average developer. >>>>> Regards >>>>> Anil Patel >>>>> On Jun 26, 2008, at 5:19 PM, Adrian Crum wrote: >>>>>> Your list of ideas all revolve around a form submit. So just >>>>>> like in the Example component, you can have different responses >>>>>> to the event. >>>>>> >>>>>> For example, if you want a form changed to read-only after a >>>>>> submit, use the on-event-update-area element and use a target >>>>>> that returns a read-only form. >>>>>> >>>>>> -Adrian >>>>>> >>>>>> Anil Patel wrote: >>>>>>> Adrian, >>>>>>> To me <on-event-update-area> is good element for doing some >>>>>>> thing like what is done current implementation. Like update >>>>>>> the list to reflect the new addition. What I am talking about is >>>>>>> 1) Should form reset after submit >>>>>>> 2) Should form hide after submit >>>>>>> 3) Should form keep showing the same data, well this is same >>>>>>> as DO_NOT_RESET after submit >>>>>>> 4) Show data in View only mode. >>>>>>> These are few options that come to my mind, I'll like to get >>>>>>> more listed if there are any other. Come up with final list of >>>>>>> those items. Once we have such list we can implement them. >>>>>>> For implementation I don't see this one element fit in this >>>>>>> need. I see this as Behavior of Form on its "SUBMIT". To me >>>>>>> <on-event-update-area> is for telling system to update certain >>>>>>> area on successful execution of some form event. >>>>>>> Regards >>>>>>> Anil K Patel >>>>>>> On Jun 26, 2008, at 4:54 PM, Adrian Crum wrote: >>>>>>>> Anil, >>>>>>>> >>>>>>>> Many thanks for your continuing work on the Ajax stuff! >>>>>>>> >>>>>>>> Why wouldn't the existing <on-event-update-area> element >>>>>>>> handle these requirements? What you are describing are >>>>>>>> different responses to the event, not different events. >>>>>>>> >>>>>>>> -Adrian >>>>>>>> >>>>>>>> Anil Patel wrote: >>>>>>>>> Hi, >>>>>>>>> We have a working example of Background form submit. The way >>>>>>>>> it is now, After successful submit, form is reset. This is a >>>>>>>>> clean new form to start entering new record. >>>>>>>>> In some situations we may want to do something different, Like >>>>>>>>> 1) When we are editing a form then sometime we want to keep >>>>>>>>> the information in the form after form submit. >>>>>>>>> 2) Sometime we want to hide form on successful form submit >>>>>>>>> 3) We want to turn form into View only after form submit >>>>>>>>> There can be many more such situations. >>>>>>>>> I'll like to collect all such After form submit situations >>>>>>>>> together first. Once we have all that we can think about >>>>>>>>> attributes or subelement inside of form element that will >>>>>>>>> let us choose our option from all that is available. >>>>>>>>> Looking forward to see inputs from all interested parties. >>>>>>>>> Thanks and Regards >>>>>>>>> Anil Patel >>> |
Re: User Interaction for Background Form submit.
|
|
Adrian,
The Ajax.Updater that is used for updating section of screen on event take third parameters "options". I don't see a way to pass values for this parameters form on-event-update-area, Do you know how I can do that. I want to be able to set evalScript options to true. Regards Anil Patel On Jun 26, 2008, at 6:00 PM, Anil Patel wrote: > I'll get back the needed code soon. > > Regards > Anil Patel > > On Jun 26, 2008, at 5:55 PM, Adrian Crum wrote: > >> If you can get the form refresh back the way it was, and show me >> the difficulty you were having with JavaScript, then I'll try to >> help figure it out. >> >> -Adrian >> >> Anil Patel wrote: >>> Adrian, >>> I am sorry, Its ok to update form section on form submit and >>> should not use form reset in javascript. I'll modify that part to >>> back where it was. But then the problem is, I'll have to add code >>> in update area part of javascript to execute any javascript block >>> inside of new html loaded. >>> Regards >>> Anil Patel >>> On Jun 26, 2008, at 5:42 PM, Anil Patel wrote: >>>> >>>> On Jun 26, 2008, at 5:36 PM, Adrian Crum wrote: >>>> >>>>> I don't how <on-event-update-area event-type="submit"> is harder >>>>> to understand than <on-submit>, but then maybe I'm smarter than >>>>> the average developer. ;-) >>>>> >>>> >>>> I Agree that its true. >>>> >>>>> If you want to have different elements for different events, >>>>> that's fine. I just see a lot of overlap down the road. >>>>> >>>>> By the way, the Ajax Example is broken. The Status dropdown >>>>> doesn't work anymore, and it looks like the <on-event-update- >>>>> area> element for the form refresh was removed. >>>>> >>>> >>>> I worked on the Ajax example. Now we don't have to refresh form >>>> section by updating the html. Actually that was not right way. So >>>> I removed it and added code in javascript to take care of >>>> resetting the form after submit. Also now its reporting errors >>>> that it never did earlier. >>>> >>>> The Status drop down is now using Autocompleter dropdown. I'll >>>> check it for problems it might have. >>>> >>>> >>>>> -Adrian >>>>> >>>>> Anil Patel wrote: >>>>>> Then I'll rather add element <on-submit> that tells me exactly >>>>>> that what needs to happen on form submit. This will make lot >>>>>> easier for developer because it will be as easy for developer >>>>>> as answering certain questions and get a standard out of box >>>>>> behavior. >>>>>> Adding so much on way too generic element like is <on-event- >>>>>> update-area> adds complexity for average developer. >>>>>> Regards >>>>>> Anil Patel >>>>>> On Jun 26, 2008, at 5:19 PM, Adrian Crum wrote: >>>>>>> Your list of ideas all revolve around a form submit. So just >>>>>>> like in the Example component, you can have different >>>>>>> responses to the event. >>>>>>> >>>>>>> For example, if you want a form changed to read-only after a >>>>>>> submit, use the on-event-update-area element and use a target >>>>>>> that returns a read-only form. >>>>>>> >>>>>>> -Adrian >>>>>>> >>>>>>> Anil Patel wrote: >>>>>>>> Adrian, >>>>>>>> To me <on-event-update-area> is good element for doing some >>>>>>>> thing like what is done current implementation. Like update >>>>>>>> the list to reflect the new addition. What I am talking about >>>>>>>> is >>>>>>>> 1) Should form reset after submit >>>>>>>> 2) Should form hide after submit >>>>>>>> 3) Should form keep showing the same data, well this is same >>>>>>>> as DO_NOT_RESET after submit >>>>>>>> 4) Show data in View only mode. >>>>>>>> These are few options that come to my mind, I'll like to get >>>>>>>> more listed if there are any other. Come up with final list >>>>>>>> of those items. Once we have such list we can implement them. >>>>>>>> For implementation I don't see this one element fit in this >>>>>>>> need. I see this as Behavior of Form on its "SUBMIT". To me >>>>>>>> <on-event-update-area> is for telling system to update >>>>>>>> certain area on successful execution of some form event. >>>>>>>> Regards >>>>>>>> Anil K Patel >>>>>>>> On Jun 26, 2008, at 4:54 PM, Adrian Crum wrote: >>>>>>>>> Anil, >>>>>>>>> >>>>>>>>> Many thanks for your continuing work on the Ajax stuff! >>>>>>>>> >>>>>>>>> Why wouldn't the existing <on-event-update-area> element >>>>>>>>> handle these requirements? What you are describing are >>>>>>>>> different responses to the event, not different events. >>>>>>>>> >>>>>>>>> -Adrian >>>>>>>>> >>>>>>>>> Anil Patel wrote: >>>>>>>>>> Hi, >>>>>>>>>> We have a working example of Background form submit. The >>>>>>>>>> way it is now, After successful submit, form is reset. This >>>>>>>>>> is a clean new form to start entering new record. >>>>>>>>>> In some situations we may want to do something different, >>>>>>>>>> Like >>>>>>>>>> 1) When we are editing a form then sometime we want to keep >>>>>>>>>> the information in the form after form submit. >>>>>>>>>> 2) Sometime we want to hide form on successful form submit >>>>>>>>>> 3) We want to turn form into View only after form submit >>>>>>>>>> There can be many more such situations. >>>>>>>>>> I'll like to collect all such After form submit situations >>>>>>>>>> together first. Once we have all that we can think about >>>>>>>>>> attributes or subelement inside of form element that will >>>>>>>>>> let us choose our option from all that is available. >>>>>>>>>> Looking forward to see inputs from all interested parties. >>>>>>>>>> Thanks and Regards >>>>>>>>>> Anil Patel >>>> > |
Re: User Interaction for Background Form submit.
|
|
| Free forum by Nabble | Edit this page |