User Interaction for Background Form submit.

[Anil Patel <an...@hotwaxmedia.com>]

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 Crum <ad...@hlmksw.com>]

Anil Patel wrote:
> 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.

But doesn't that way of doing things conflict with the ideas you are 
presenting now?

The original code called an Ajax event to refresh the data entry form. 
You changed it so the form refresh is hard-coded in JavaScript. What if 
you don't want the form refreshed after submit but instead want to use 
one of the responses that you mentioned in your list?

-Adrian

Re: User Interaction for Background Form submit.

[Adrian Crum <ad...@hlmksw.com>]

Just set it true in selectall.js - it should be the default for our 
purposes anyway.

-Adrian

Anil Patel wrote:
> 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.

[Anil Patel <an...@hotwaxmedia.com>]

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.

[Anil Patel <an...@hotwaxmedia.com>]

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 Crum <ad...@hlmksw.com>]

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.

[Anil Patel <an...@hotwaxmedia.com>]

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.

[Anil Patel <an...@hotwaxmedia.com>]

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 Crum <ad...@hlmksw.com>]

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. ;-)

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.

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

[Anil Patel <an...@hotwaxmedia.com>]

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 Crum <ad...@hlmksw.com>]

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.

[Anil Patel <an...@hotwaxmedia.com>]

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 Crum <ad...@hlmksw.com>]

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
>