Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #34959 > unrolled thread

Blob write complete event ?

Back to article view | Back to comp.lang.javascript

Contents

  Blob write complete event ? Dr.Kral@nyc.rr.com - 2018-05-01 14:49 -0400
    Re: Blob write complete event ? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-05-05 19:14 -0700
      Re: Blob write complete event ? Julio Di Egidio <julio@diegidio.name> - 2018-05-06 03:50 -0700
        Re: Blob write complete event ? Dr.Kral@nyc.rr.com - 2018-05-06 11:08 -0400
          Re: Blob write complete event ? Julio Di Egidio <julio@diegidio.name> - 2018-05-06 11:36 -0700
        Re: Blob write complete event ? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-05-06 10:26 -0700
          Re: Blob write complete event ? Julio Di Egidio <julio@diegidio.name> - 2018-05-06 11:33 -0700
            Re: Blob write complete event ? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-05-06 12:08 -0700
      Re: Blob write complete event ? Dr.Kral@nyc.rr.com - 2018-05-06 11:02 -0400
        Re: Blob write complete event ? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-05-06 10:56 -0700

#34959 — Blob write complete event ?

				
I can not find the write local file complete event for a blob which is just
as necessary as the read complete event "onload" .

I am running in my browser and within the security features and locally.
Getting the file list, reading each file, editing and rewriting are working
well.  I have taken the read/write stuff from this example: <<
thiscouldbebetter.wordpress.com/2012/12/18/loading-editing-and-saving-a-text-file-in-html5-using-javascrip/
>> with minor modifications.

Here is the essential code --
function saveTextAsFile() {
    var textToSaveAsBlob = new Blob
         ([dataToSave], {type:"text/html" , endings:"native"});
    var downloadLink = document.createElement("a");
    downloadLink.download = input.files[j].name;   // fileNameToSaveAs;
    downloadLink.innerHTML = "Download File";
    downloadLink.href = window.URL.createObjectURL(textToSaveAsBlob)
                                                     // textToSaveAsURL;
    downloadLink.onclick = destroyClickedElement;
//    downloadLink.?????? = event handler  (I suspect it would be here.)
    downloadLink.style.display="none";
    document.body.appendChild(downloadLink);
    downloadLink.click(); 
}

It was trivial to add another function call to start the editing from the
‘onload event’ handler which assures the read is complete.  I would like to
have the same assurance for the write.  I could just add a short delay
(1-2second) but that not "clean".

Unfortunately << developer.mozilla.org/en-US/docs/Web/Events >> was not
helpful for this.

I did notice mention of some other API file methods but they were mention
as obsolete or to come.

TIA

K.

[toc] | [next] | [standalone]

#34985

Dr....@nyc.rr.com wrote:
> I can not find the write local file complete event for a blob which is just
> as necessary as the read complete event "onload" .
> 
> I am running in my browser and within the security features and locally.
> Getting the file list, reading each file, editing and rewriting are working
> well.  I have taken the read/write stuff from this example: <<
> thiscouldbebetter.wordpress.com/2012/12/18/loading-editing-and-saving-a-text-file-in-html5-using-javascrip/
> >> with minor modifications.
> 
> [...]
> 
> It was trivial to add another function call to start the editing from the
> ‘onload event’ handler which assures the read is complete.  I would like to
> have the same assurance for the write.  I could just add a short delay
> (1-2second) but that not "clean".
> 
> Unfortunately << developer.mozilla.org/en-US/docs/Web/Events >> was not
> helpful for this.
> 
> I did notice mention of some other API file methods but they were mention
> as obsolete or to come.


I wonder if this is even the right way to think about it or approach it. If I was to build a in-browser file-editor I would approach these features like this:

1. Open File
2. Save File
3. Download File

1- Opening a file happens the usual way with <input type="file"> and the FileReader API
2- The file is saved to IndexDB
3- A prompt is given for download using the method you're describing above.

In case #2 you would be able to listen for completion and have confidence that the file saved properly

In case #3 you don't care as it's not being used in by application (like auto-save). Treat this last case like "Export" instead of "Save"

[toc] | [prev] | [next] | [standalone]

#34988

On Sunday, 6 May 2018 04:14:58 UTC+2, Michael Haufe (TNO)  wrote:

> I wonder if this is even the right way to think about it or approach it.

If you don't know the answer just do not answer: guesswork is totally
unacceptable in programming.

Julio

[toc] | [prev] | [next] | [standalone]

#34992

On Sun, 6 May 2018 03:50:33 -0700 (PDT), Julio Di Egidio
<julio@diegidio.name> wrote in
<6ab3a788-a1c2-4a28-965b-27b55a114f2c@googlegroups.com>:

>On Sunday, 6 May 2018 04:14:58 UTC+2, Michael Haufe (TNO)  wrote:
>
>> I wonder if this is even the right way to think about it or approach it.
>
>If you don't know the answer just do not answer: guesswork is totally
>unacceptable in programming.
>
>Julio

Thank for your comment.

I will agree that guesswork is not acceptable in programming but suggesting
a different approach -- to be investigated -- is acceptable.  After an
investigation, it can be decided if the idea is worthwhile.

K

[toc] | [prev] | [next] | [standalone]

#34996

On Sunday, 6 May 2018 17:08:53 UTC+2, Dr....@nyc.rr.com  wrote:
> On Sun, 6 May 2018 03:50:33 -0700 (PDT), Julio Di Egidio
> <julio@diegidio.name> wrote in
> <6ab3a788-a1c2-4a28-965b-27b55a114f2c@googlegroups.com>:
> 
> >On Sunday, 6 May 2018 04:14:58 UTC+2, Michael Haufe (TNO)  wrote:
> >
> >> I wonder if this is even the right way to think about it or approach it.
> >
> >If you don't know the answer just do not answer: guesswork is totally
> >unacceptable in programming.
> >
> >Julio
> 
> Thank for your comment.
> 
> I will agree that guesswork is not acceptable in programming but suggesting
> a different approach -- to be investigated -- is acceptable.

No, that's nonsense: the opposite of guesswork is "do your own analysis"!
But of course that takes at least some 10/15 years of trying and trying hard,
it's the *last* skill one learns...  But if one has ham stuck in the ears, not
even a life time is enough.

HTH,

Julio

P.S.  Please do not copy my personal address in, reply to the group only:
private email is for private conversation, when one *follows-up* elsewhere...

[toc] | [prev] | [next] | [standalone]

#34993

Julio Di Egidio wrote:
Michael Haufe (TNO)  wrote:
> 
> > I wonder if this is even the right way to think about it or approach it.
> 
> If you don't know the answer just do not answer: guesswork is totally
> unacceptable in programming.

This is one of the dumber things you've ever said. Especially given how I've never seen you give a proper response to any issue in this group. 

You're not even wrong once here, but twice, can you count the ways?

[toc] | [prev] | [next] | [standalone]

#34995

On Sunday, 6 May 2018 19:27:05 UTC+2, Michael Haufe (TNO)  wrote:
> Julio Di Egidio wrote:
> Michael Haufe (TNO)  wrote:
> > 
> > > I wonder if this is even the right way to think about it or approach it.
> > 
> > If you don't know the answer just do not answer: guesswork is totally
> > unacceptable in programming.
> 
> This is one of the dumber things you've ever said.

I hardly think so, LOL...  Actually, once upon a time the answer to 80%+ of the
questions in technical groups was *RTFM* and period.  Just now the incompetence
as well as the lack of any professional integrity have been globalised: it's
of course easier to sell bullshit of all sorts, including political and ethical
to just dumb fucks.  And you won't get it but I did not even insult you, it's
really just you who keep shitting all over the place...

*Plonk*

Julio

[toc] | [prev] | [next] | [standalone]

#34997

Julio Di Egidio wrote:
> Michael Haufe (TNO)  wrote:

> > This is one of the dumber things you've ever said.
> 
> I hardly think so, LOL...  Actually, once upon a time the answer to 80%+ of the
> questions in technical groups was *RTFM* and period.  Just now the incompetence
> as well as the lack of any professional integrity have been globalised: it's
> of course easier to sell bullshit of all sorts, including political and ethical
> to just dumb fucks.  And you won't get it but I did not even insult you, it's
> really just you who keep shitting all over the place...
> 
> *Plonk*


I generally don't feel insulted by the ignorant statements of lesser mortals. It seems your responses are always one of two things: insults or retreating into useless generalizations. This time it's both and of course once again entirely unrelated to the topic of the thread.

[toc] | [prev] | [next] | [standalone]

#34991

On Sat, 5 May 2018 19:14:49 -0700 (PDT), "Michael Haufe (TNO)"
<tno@thenewobjective.com> wrote in
<0f01a2fa-2da1-40d6-ad9c-a262f86c85cf@googlegroups.com>:

>Dr....@nyc.rr.com wrote:
>> I can not find the write local file complete event for a blob which is just
>> as necessary as the read complete event "onload" .
>> 
>> I am running in my browser and within the security features and locally.
>> Getting the file list, reading each file, editing and rewriting are working
>> well.  I have taken the read/write stuff from this example: <<
>> thiscouldbebetter.wordpress.com/2012/12/18/loading-editing-and-saving-a-text-file-in-html5-using-javascrip/
>> >> with minor modifications.
>> 
>> [...]
>> 
>> It was trivial to add another function call to start the editing from the
>> ‘onload event’ handler which assures the read is complete.  I would like to
>> have the same assurance for the write.  I could just add a short delay
>> (1-2second) but that not "clean".
>> 
>> Unfortunately << developer.mozilla.org/en-US/docs/Web/Events >> was not
>> helpful for this.
>> 
>> I did notice mention of some other API file methods but they were mention
>> as obsolete or to come.

Thank you for your response.  However, it leaves me confused.

>I wonder if this is even the right way to think about it or approach it. If I was to build a in-browser file-editor I would approach these features like this:
This would be reasonable it the database was the objective.  It is not for
me.

>1. Open File
>2. Save File
>3. Download File
>
>1- Opening a file happens the usual way with <input type="file"> and the FileReader API
This is what I have been doing along with the onload event.  That provides
the confidence that the files have been completely read and stored in the
DOM in the browser.  (Of course, they could have been read incorrectly but
that's another issue.)

>2- The file is saved to IndexDB
>In case #2 you would be able to listen for completion and have confidence that the file saved properly
This, as I understand it would create/use a database.  That is a lot of
over head and I do not need nor want that unless it provide a way to save
each file back into my computer's file system.

>3- A prompt is given for download using the method you're describing above.
>In case #3 you don't care as it's not being used in by application (like auto-save). Treat this last case like "Export" instead of "Save"
Here you say that I should do what I am doing except not worry about a
completion event.  This makes the database redundant.

Perhaps you could explain what you feel that I am missing.

K.

[toc] | [prev] | [next] | [standalone]

#34994

 Dr....@nyc.rr.com wrote:
"Michael Haufe (TNO)" wrote:
> 
> Thank you for your response.  However, it leaves me confused.
> 
> >I wonder if this is even the right way to think about it or approach it. If I was to build a in-browser file-editor I would approach these features like this:
> 
> This would be reasonable it the database was the objective.  It is not for
> me.
> 
> >1. Open File
> >2. Save File
> >3. Download File
> >
> >1- Opening a file happens the usual way with <input type="file"> and the FileReader API
> 
> This is what I have been doing along with the onload event.  That provides
> the confidence that the files have been completely read and stored in the
> DOM in the browser.  (Of course, they could have been read incorrectly but
> that's another issue.)
> 
> >2- The file is saved to IndexDB
> >In case #2 you would be able to listen for completion and have confidence that the file saved properly
> 
> This, as I understand it would create/use a database.  That is a lot of
> over head and I do not need nor want that unless it provide a way to save
> each file back into my computer's file system.
> 
> >3- A prompt is given for download using the method you're describing above.
> >In case #3 you don't care as it's not being used in by application (like auto-save). Treat this last case like "Export" instead of "Save"
> Here you say that I should do what I am doing except not worry about a
> completion event.  This makes the database redundant.
> 
> Perhaps you could explain what you feel that I am missing.

My assumption is that you are building some form of file editor correct? For the sake of argument a text-editor yes?

Two of the main features being open and save of that file.

1- Opening the file you've solved. 

2- Saving the file you have not

For #2 the proper solution would have been the FileSystem API which does not have cross-browser support and may even be dropped from Chrome in the future as well:

<https://developer.mozilla.org/en-US/docs/Web/API/FileSystem>
<https://caniuse.com/#search=FileSystem>
<https://hacks.mozilla.org/2012/07/why-no-filesystem-api-in-firefox/>

If you need a notification on success/failure of the file being saved to an arbitrary location to the filesystem by the user, then you have no way to do so with web-based APIs *currently* AFAICT. This is why I'm suggesting an alternate user experience if it will fulfill your application requirements namely:

#1 - File(s) imported/loaded in the application stays in the application until they export/download it. 

Subsequent saving and re-opening of the files is done with IndexDB which is native to the browser and relatively efficient and will provide you with the save/load/error confirmations you are looking for

<https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API>

#2 - When the user wants the file(s) removed or copied from your application they can download/export using the approach you already have. You still can not get a notification of success/failure

Depending on your requirements, does that matter in #2?

My only additional question would be: Is this a webpage, or is it a standalone web application of some type installed on the user's machine? If it's the latter you may have other options with more privileged APIs.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web