Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Force a submit() on parent from child?

Reply
Thread Tools

Force a submit() on parent from child?

 
 
The Natural Philosopher
Guest
Posts: n/a
 
      09-14-2007
Hmm. Thanks to good advice, the screen I am working on is ALMOST working.

Basically I spawn a subscreen if needed from the main screen to allow
the user to add some elements to a drop down <SELECT> list 'on the fly'
as it were.

These elements are added to a database, so I have to reload the main
page in order for the changes to take effect.

Thanks to Erwin, this works using opener.location.reload(true)

HOWEVER. There is one snag: Any data already entered in this pretty
massive form is thereby lost.

Now I am sort of looking for a way to do a SUBMIT instead of a RELOAD in
order that the data can be POSTED back to the server, and will reappear
in the correct fields.

This would be a dummy submit and wouldn't actually update the database.
Although there is no reason why it shouldn't, but if I do an actual
submit/update before calling the sub window, I guess I lose the code
that had decided to do the window spawn...submit being a sort of 'GOTO'
if you like..

In principle the sequence of events I want to see, is this:-

User clicks on something.
This spawns a new window, which independently fiddles with the database.
On closing that window, the main window does a submit(), to force post
data back to the server, and reload it, and the new data.

(I hasten to add that the post data and the new data are independent:
the post data contains an index INTO this new data, but the assumption
is that the index is not valid for that field anyway, since thats why
they clicked..)
 
Reply With Quote
 
 
 
 
The Natural Philosopher
Guest
Posts: n/a
 
      09-15-2007
Randy Webb wrote:
> The Natural Philosopher said the following on 9/14/2007 6:52 PM:
>> Hmm. Thanks to good advice, the screen I am working on is ALMOST working.

>
> Nice to see you followed half of the good advice you got.
>
>> Basically I spawn a subscreen if needed from the main screen to allow
>> the user to add some elements to a drop down <SELECT> list 'on the
>> fly' as it were.

>
> And ignored the good advice you got about popup windows.
>
>> These elements are added to a database, so I have to reload the main
>> page in order for the changes to take effect.

>
> I don't believe that but ok. There are too many sites with code to
> update select lists without reloading the page for me to believe that.
>
>> Thanks to Erwin, this works using opener.location.reload(true)
>>
>> HOWEVER. There is one snag: Any data already entered in this pretty
>> massive form is thereby lost.

>
> Instead of reloading the main page, submit the form in the main page.
> Then, hope your entry into the database happens before the main page
> gets submitted.
>
>> Now I am sort of looking for a way to do a SUBMIT instead of a RELOAD
>> in order that the data can be POSTED back to the server, and will
>> reappear in the correct fields.

>
> window.opener.document.formName.submit();
>


That was really all I wanted..

Thanks.

>> This would be a dummy submit and wouldn't actually update the
>> database. Although there is no reason why it shouldn't, but if I do an
>> actual submit/update before calling the sub window, I guess I lose the
>> code that had decided to do the window spawn...submit being a sort of
>> 'GOTO' if you like..

>
> Please don't mention GOTO in connection with JS.
>


Offends your religious beliefs?

>> In principle the sequence of events I want to see, is this:-
>>
>> User clicks on something.
>> This spawns a new window, which independently fiddles with the database.

>
> Instead, you show/hide a div element in the page that has the form in it
> that "fiddles with the database".
>
>> On closing that window, the main window does a submit(), to force post
>> data back to the server, and reload it, and the new data.

>
> The part of the form that "fiddles with the database" (Is that opposed
> to drumming or guitaring with the database?) is hidden and shown. When
> it is filled out, you submit the *entire form* to the server. The server
> updates the database and sends a modified page back to the browser.
>
> Stop making it harder than it has to be.
>


Randy: hardness is relative. To carry the code for ALL of this would be
a nightmare. Especially as the data sizes grow. Believe me, there are
good reasons to do it this way. I don't want to have to duplicate code
that is already there on a separate screen.


>> (I hasten to add that the post data and the new data are independent:
>> the post data contains an index INTO this new data, but the assumption
>> is that the index is not valid for that field anyway, since thats why
>> they clicked..)

>
> And I hasten to add that you selectively follow the good advice you are
> given.
>


Always have. 'Rules are for he guidance of wise men and the obedience of
fools'

The company before last that I had, my partner came to me insisting that
we have key man insurance 'what hapens if you die'

I told him 'the company is finished: The amount they want in premiums
for key man insurance would finish it without me dying, thats all!'
 
Reply With Quote
 
 
 
 
The Natural Philosopher
Guest
Posts: n/a
 
      09-15-2007
Randy Webb wrote:
> The Natural Philosopher said the following on 9/15/2007 3:38 AM:
>> Randy Webb wrote:
>>> The Natural Philosopher said the following on 9/14/2007 6:52 PM:

>
> <snip>
>
>>>> This would be a dummy submit and wouldn't actually update the
>>>> database. Although there is no reason why it shouldn't, but if I do
>>>> an actual submit/update before calling the sub window, I guess I
>>>> lose the code that had decided to do the window spawn...submit being
>>>> a sort of 'GOTO' if you like..
>>>
>>> Please don't mention GOTO in connection with JS.
>>>

>>
>> Offends your religious beliefs?
>>

>
> Nah, my common sense.
>
>>>> In principle the sequence of events I want to see, is this:-
>>>>
>>>> User clicks on something.
>>>> This spawns a new window, which independently fiddles with the
>>>> database.
>>>
>>> Instead, you show/hide a div element in the page that has the form in
>>> it that "fiddles with the database".
>>>
>>>> On closing that window, the main window does a submit(), to force
>>>> post data back to the server, and reload it, and the new data.
>>>
>>> The part of the form that "fiddles with the database" (Is that
>>> opposed to drumming or guitaring with the database?) is hidden and
>>> shown. When it is filled out, you submit the *entire form* to the
>>> server. The server updates the database and sends a modified page
>>> back to the browser.
>>>
>>> Stop making it harder than it has to be.
>>>

>>
>> Randy: hardness is relative. To carry the code for ALL of this would
>> be a nightmare. Especially as the data sizes grow. Believe me, there
>> are good reasons to do it this way. I don't want to have to duplicate
>> code that is already there on a separate screen.

>
> Based on the other recent threads you have posted, I am not convinced of
> that. And also because I know better. It is your choice to make it
> harder than it has to be, not mine.
>


Just two points randy.

First, your syntax was all to **** on what you gave me, however the idea
was basically sound. Thank you for that.

Secondly, you cannot possibly know the context of what I am doing here,
and to claim you know what's best for me without that knowledge makes
you a fool or an arrogant prick.

 
Reply With Quote
 
Lee
Guest
Posts: n/a
 
      09-15-2007
The Natural Philosopher said:
>
>Randy Webb wrote:
>> The Natural Philosopher said the following on 9/15/2007 3:38 AM:
>>> Randy Webb wrote:
>>>> The Natural Philosopher said the following on 9/14/2007 6:52 PM:

>>
>> <snip>
>>
>>>>> This would be a dummy submit and wouldn't actually update the
>>>>> database. Although there is no reason why it shouldn't, but if I do
>>>>> an actual submit/update before calling the sub window, I guess I
>>>>> lose the code that had decided to do the window spawn...submit being
>>>>> a sort of 'GOTO' if you like..
>>>>
>>>> Please don't mention GOTO in connection with JS.
>>>>
>>>
>>> Offends your religious beliefs?
>>>

>>
>> Nah, my common sense.
>>
>>>>> In principle the sequence of events I want to see, is this:-
>>>>>
>>>>> User clicks on something.
>>>>> This spawns a new window, which independently fiddles with the
>>>>> database.
>>>>
>>>> Instead, you show/hide a div element in the page that has the form in
>>>> it that "fiddles with the database".
>>>>
>>>>> On closing that window, the main window does a submit(), to force
>>>>> post data back to the server, and reload it, and the new data.
>>>>
>>>> The part of the form that "fiddles with the database" (Is that
>>>> opposed to drumming or guitaring with the database?) is hidden and
>>>> shown. When it is filled out, you submit the *entire form* to the
>>>> server. The server updates the database and sends a modified page
>>>> back to the browser.
>>>>
>>>> Stop making it harder than it has to be.
>>>>
>>>
>>> Randy: hardness is relative. To carry the code for ALL of this would
>>> be a nightmare. Especially as the data sizes grow. Believe me, there
>>> are good reasons to do it this way. I don't want to have to duplicate
>>> code that is already there on a separate screen.

>>
>> Based on the other recent threads you have posted, I am not convinced of
>> that. And also because I know better. It is your choice to make it
>> harder than it has to be, not mine.
>>

>
>Just two points randy.
>
>First, your syntax was all to **** on what you gave me, however the idea
>was basically sound. Thank you for that.
>
>Secondly, you cannot possibly know the context of what I am doing here,
>and to claim you know what's best for me without that knowledge makes
>you a fool or an arrogant prick.


Or far more experienced and competent. Based on your postings,
I know which way I'm leaning.


--

 
Reply With Quote
 
The Natural Philosopher
Guest
Posts: n/a
 
      09-16-2007
Lee wrote:
> The Natural Philosopher said:
>> Randy Webb wrote:
>>> The Natural Philosopher said the following on 9/15/2007 3:38 AM:
>>>> Randy Webb wrote:
>>>>> The Natural Philosopher said the following on 9/14/2007 6:52 PM:
>>> <snip>
>>>
>>>>>> This would be a dummy submit and wouldn't actually update the
>>>>>> database. Although there is no reason why it shouldn't, but if I do
>>>>>> an actual submit/update before calling the sub window, I guess I
>>>>>> lose the code that had decided to do the window spawn...submit being
>>>>>> a sort of 'GOTO' if you like..
>>>>> Please don't mention GOTO in connection with JS.
>>>>>
>>>> Offends your religious beliefs?
>>>>
>>> Nah, my common sense.
>>>
>>>>>> In principle the sequence of events I want to see, is this:-
>>>>>>
>>>>>> User clicks on something.
>>>>>> This spawns a new window, which independently fiddles with the
>>>>>> database.
>>>>> Instead, you show/hide a div element in the page that has the form in
>>>>> it that "fiddles with the database".
>>>>>
>>>>>> On closing that window, the main window does a submit(), to force
>>>>>> post data back to the server, and reload it, and the new data.
>>>>> The part of the form that "fiddles with the database" (Is that
>>>>> opposed to drumming or guitaring with the database?) is hidden and
>>>>> shown. When it is filled out, you submit the *entire form* to the
>>>>> server. The server updates the database and sends a modified page
>>>>> back to the browser.
>>>>>
>>>>> Stop making it harder than it has to be.
>>>>>
>>>> Randy: hardness is relative. To carry the code for ALL of this would
>>>> be a nightmare. Especially as the data sizes grow. Believe me, there
>>>> are good reasons to do it this way. I don't want to have to duplicate
>>>> code that is already there on a separate screen.
>>> Based on the other recent threads you have posted, I am not convinced of
>>> that. And also because I know better. It is your choice to make it
>>> harder than it has to be, not mine.
>>>

>> Just two points randy.
>>
>> First, your syntax was all to **** on what you gave me, however the idea
>> was basically sound. Thank you for that.
>>
>> Secondly, you cannot possibly know the context of what I am doing here,
>> and to claim you know what's best for me without that knowledge makes
>> you a fool or an arrogant prick.

>
> Or far more experienced and competent. Based on your postings,
> I know which way I'm leaning.
>

Its not an "or" thing. I am sure that Randys Javascript experience far
exceeds mine. I have a specific job to do that needs it. Thats why I am
here. This is the first time I have used it in anger.

And in terms of actual javascript implementation, I am not in the
competition,sure.

However, when it comes to the application I am developing, and the way
in which I want to to interact with the user, and the server, I can and
do claim expert knowledge. If Randy wants my respect for what he knows
that I don't, I would suggest he might get it more readily if he pays me
the respect for what I know, that he doesn't.



>

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
If a class Child inherits from Parent, how to implementChild.some_method if Parent.some_method() returns Parent instance ? metal Python 8 10-30-2009 10:31 AM
Nike air force one, air force 1, air force one low cut, air force one abdul_razak@indiatimes.com Digital Photography 2 12-31-2008 04:29 PM
Nike Air Force Ones,Air Force One Air Force One-1 lky52193@gmail.com Computer Support 0 01-17-2008 04:40 PM
Nike Air Force Ones,Air Force One Air Force One-1,25th anniversary lky52112@gmail.com Digital Photography 0 01-15-2008 04:46 PM
Nike Air Force Ones,Air Force One Air Force One-1,25th anniversary lky52112@gmail.com Digital Photography 0 01-15-2008 04:34 PM



Advertisments