- From: Jared Morse <jarcoal@gmail.com>
- Date: Fri, 29 Jan 2010 10:33:41 -0800
- To: Jeremy Orlow <jorlow@chromium.org>
- Cc: Olli@pettay.fi, public-webapps@w3.org
- Message-ID: <19e6d9a31001291033g62b749dan10fe5826aad17e77@mail.gmail.com>
Hi Jeremy, your patch (https://bugs.webkit.org/show_bug.cgi?id=30546) is actually what brought this to my attention. I cannot think of an example where iframe's would not be sufficient as a work-around, however it could potentially be inconvenient to use them, especially when your app may be open in several tabs. Each other tab would get two events triggered, one for the primary document and one for the iframe inside of it. While this isn't the end of the world, clearly you would need to always check the source of the iframe event, to make sure it came from it's parent, and not another tab. Between this and Olli's prototype suggestion, it is clear there are definitely ways around this issue should a developer face it. However, I do think the advantage of having your "glue" code written for you would be of great benefit to developers. -J On Thu, Jan 28, 2010 at 3:06 PM, Jeremy Orlow <jorlow@chromium.org> wrote: > On Thu, Jan 28, 2010 at 2:22 PM, Jared Morse <jarcoal@gmail.com> wrote: > >> Perhaps I am mistaken, but I believe you would still have to go around and >> add that trigger to all the places the value is changed from. >> > > That is true. > > Can you give some clear examples of when having local storage events being > fired in your frame would be useful? Bonus points if they're something that > can't be handled by simply creating an iframe within your doc and using it > to monitor events (which is the obvious work-around). > > J > > >> On Thu, Jan 28, 2010 at 2:06 PM, Olli Pettay <Olli.Pettay@helsinki.fi>wrote: >> >>> On 1/28/10 11:57 PM, Jared Morse wrote: >>> >>>> Even though it occurs on the same document, doesn't mean loosely coupled >>>> code can't benefit from it. >>>> >>>> Imagine if each time you added a feature to a web app that depended on >>>> knowing a current value from the storage, you'd have to go around to all >>>> the places that value is changed and add some code to alert your new >>>> code. If storage events triggered on the same document, all you would >>>> have to do is set a listener. >>>> >>> >>> If you really need this behavior, you can always dispatch your own event >>> to the window when you change the data. >>> >>> >>> -Olli >>> >>> >>> >>>> -J >>>> >>>> On Thu, Jan 28, 2010 at 1:41 PM, Olli Pettay <Olli.Pettay@helsinki.fi >>>> <mailto:Olli.Pettay@helsinki.fi>> wrote: >>>> >>>> On 1/28/10 9:34 PM, Jared Morse wrote: >>>> >>>> Hi, I have a concern about the web storage event spec >>>> (http://dev.w3.org/html5/webstorage/). >>>> >>>> The spec states: >>>> "When the setItem(), removeItem(), and clear() methods are >>>> called on a >>>> Storage object x that is associated with a local storage area, >>>> if the >>>> methods did something, then in every HTMLDocument object whose >>>> Window >>>> object's localStorage attribute's Storage object is associated >>>> with the >>>> same storage area, other than x, a storage event must be >>>> fired..." >>>> >>>> My concern lies with the "other than x" part. Unless I'm missing >>>> something, these events would be even more useful if they also >>>> fired in >>>> the HTMLDocument that initially made the storage call. >>>> >>>> >>>> The page which is changing storage object knows already that the >>>> storage object is being changed. Why would it need explicit >>>> notification (event) about that? >>>> >>>> >>>> -Olli >>>> >>>> >>>> >>>> >>>> >>>> Thanks for your time. >>>> >>>> -Jared >>>> >>>> >>>> >>>> >>> >> >
Received on Friday, 29 January 2010 18:34:15 UTC