If vuejs is the way to go (thank you massimo for the choice...) i think it should evolve also to vuex for client store and use something like this for persistence. https://flaviocopes.com/vuex-persist-localstorage/ I think we can kill 2 rabbits with just one bullet...
Em ter, 30 de abr de 2019 às 12:42, villas <villa...@gmail.com> escreveu: > Hi Scott > > It's probably unrealistic to imagine that a proper DB would be stored > locally. I mean, where would its contents come from? If the answer is a > remote DB, then you are already back at square one. > > However, it still makes sense to cache data on the client side. When the > cache gets larger, it makes sense to think more about Local Storage. But > we already have that now. > <https://www.w3schools.com/html/html5_webstorage.asp> > > The main obstacle for local storage is keeping the data fresh, and that > includes the user himself updating it. > > Most of the logic leads us back to web services, REST interfaces and DBs > in the 'cloud'. I guess that's where we're all heading! > > Regards, D > > > > On Tuesday, 30 April 2019 01:47:36 UTC+1, Scott Hunter wrote: >> >> >> The direction from web2py to web3py seems to be applications where the >> server is responsible for (relatively) static pages which use Javascript >> for their dynamic aspects & talking to the server via an API, primarily for >> interaction w/ the database. >> >> In the spirit of Progressive Web Apps, one could imagine getting to the >> point where instead of making calls to the server, Javascript functions are >> called instead to interact w/ an SQLite DB under the browser's control. >> Doing so via something like pyDAL, but replacing Python with Javascript & >> only needing to support SQLite would not only ease the burden of writing >> such code, but make it easier to make a transition between these two DB >> locations. >> >> I'm actually thinking specifically of being able to deploy a pared-down >> version of a "normal" application which could perform most of its >> functionality off-line, and use online access only for transferring >> information in bulk between the local DB and the one in the cloud. The >> more that those applications can share code, the better. (I've >> accomplished this goal, somewhat clunkily, by deploying the web2py binary >> w/ a limited version of the app in the cloud; an approach as I've described >> above seems that it wouldn't be nearly as brittle.) >> >> Does this make any sense? Would something like a jsDAL be prohibitively >> difficult to write, or not really worth the effort? >> > -- > Resources: > - http://web2py.com > - http://web2py.com/book (Documentation) > - http://github.com/web2py/web2py (Source code) > - https://code.google.com/p/web2py/issues/list (Report Issues) > --- > You received this message because you are subscribed to the Google Groups > "web2py-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to web2py+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
