The Web is all about links and a qooxdoo application is still a web
application. So how it can be done so a link from another source perform a specific action in the qooxdoo application. A concrete example I have is with password reset links. Let's say a user receives a link that he can click, go to the web page types twice the password, the form is submitted and the new password is valid. In qooxdoo desktop the workflow would be somehow different. The user clicks the link, **goes to the main app, the main app opens a window with two password fields**, the user submits the form and the new password is valid. But how can I make the main app see the link and open the appropriate window? I saw the code of Apiviewer and the only relevant part I found is this https://github.com/qooxdoo/qooxdoo/blob/master/component/apiviewer/source/class/apiviewer/Viewer.js#L78 I couldn't find the part where it loads the class from a bookmarked link Also I don't know how to implement such functionality. An idea I have is this: The user clicks the link http://mypage.com/bookmarkable/stuff The server returns a stuff.html page with javascript that writes instructions in the cookie for the main app and then redirects to the main page In the main page the main app looks at the cookie and if it finds instructions acts upon them and then deletes them. Is this a good idea? Any criticism or pointers to better ideas? ------------------------------------------------------------------------------ _______________________________________________ qooxdoo-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel |
This post has NOT been accepted by the mailing list yet.
IMHO, a button or menu click would do for a reset or change password. In the click event, activate a window where he could input old (once) and new password twice.
|
In reply to this post by voger
Hi Voger
As the second tab will be opened by a link, you won’t have a window to postMessage to/from and AIUI there is no way to get one. This means that the only way to communicate with the main application in the first tab is via the server - and the only way to do that is to poll the server for changes. How quickly that updates the main app obviously depends on how often you poll, but there is a technique called “long poll” where you asynchronously poll the server and the server waits for a “long” time until there is something to return. This minimises the number of round trips you have and can simulate server push, although it does mean that your server will always have a connection open for every client. Regards John On 09/12/2015, 20:20, "voger" <[hidden email]> wrote: >The Web is all about links and a qooxdoo application is still a web >application. So how it can be done so a link from another source perform >a specific action in the qooxdoo application. A concrete example I have >is with password reset links. Let's say a user receives a link that he >can click, go to the web page types twice the password, the form is >submitted and the new password is valid. > >In qooxdoo desktop the workflow would be somehow different. The user >clicks the link, **goes to the main app, the main app opens a window >with two password fields**, the user submits the form and the new >password is valid. > >But how can I make the main app see the link and open the appropriate >window? > >I saw the code of Apiviewer and the only relevant part I found is this >https://github.com/qooxdoo/qooxdoo/blob/master/component/apiviewer/source/class/apiviewer/Viewer.js#L78 > >I couldn't find the part where it loads the class from a bookmarked link > >Also I don't know how to implement such functionality. An idea I have is >this: >The user clicks the link http://mypage.com/bookmarkable/stuff >The server returns a stuff.html page with javascript that writes >instructions in the cookie for the main app and then redirects to the >main page >In the main page the main app looks at the cookie and if it finds >instructions acts upon them and then deletes them. > >Is this a good idea? Any criticism or pointers to better ideas? > >------------------------------------------------------------------------------ >_______________________________________________ >qooxdoo-devel mailing list >[hidden email] >https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel ------------------------------------------------------------------------------ _______________________________________________ qooxdoo-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel |
In reply to this post by voger
Hi Voger,
I would choose to create a mini app or even a bare html page which is solely created for exactly that purpose: changing the password. It is common to present the user a link via mail, which navigates to the password recovery or change page. But none of them re use a formerly opened browser window or tab of the password change requesting site, but creates a new window or tab. So after the user changed/recovered his password, you can simply navigate him to your main app and let him login with his new credentials. Regards Dietrich Am 09.12.2015 um 21:20 schrieb voger: > The Web is all about links and a qooxdoo application is still a web > application. So how it can be done so a link from another source perform > a specific action in the qooxdoo application. A concrete example I have > is with password reset links. Let's say a user receives a link that he > can click, go to the web page types twice the password, the form is > submitted and the new password is valid. > > In qooxdoo desktop the workflow would be somehow different. The user > clicks the link, **goes to the main app, the main app opens a window > with two password fields**, the user submits the form and the new > password is valid. > > But how can I make the main app see the link and open the appropriate > window? > > I saw the code of Apiviewer and the only relevant part I found is this > https://github.com/qooxdoo/qooxdoo/blob/master/component/apiviewer/source/class/apiviewer/Viewer.js#L78 > > I couldn't find the part where it loads the class from a bookmarked link > > Also I don't know how to implement such functionality. An idea I have is > this: > The user clicks the link http://mypage.com/bookmarkable/stuff > The server returns a stuff.html page with javascript that writes > instructions in the cookie for the main app and then redirects to the > main page > In the main page the main app looks at the cookie and if it finds > instructions acts upon them and then deletes them. > > Is this a good idea? Any criticism or pointers to better ideas? > > ------------------------------------------------------------------------------ > _______________________________________________ > qooxdoo-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel ------------------------------------------------------------------------------ _______________________________________________ qooxdoo-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel |
In reply to this post by voger
Thank you for your ideas. The password reset feature was an example. I
did a bit more research and more thinking and now my idea of using cookies and redirects doesn't seem that good any more. From the research I found out about window.history.pushState and window.history.replaceState http://spoiledmilk.com/blog/html5-changing-the-browser-url-without-refreshing-page/ and the qooxdoo's own history module http://demo.qooxdoo.org/current/apiviewer/?search=qx.ui.window.Window#qx.bom.History I still don't understand how these could fit together and how to implement the _readState and _writeState methods. I guess I will find out with trial and error. Any examples are welcome :D Anyway, my new idea is that all the URIS when are not being requested via AJAX, will return the .html file of the main app with additional data in the <body?. Something like this stackoverflow answer http://stackoverflow.com/a/28705599/2604378 The main app will detect that data during loading and perform the according action. For example a link could be a presentation of some article. There would be a permalink to that article and when the link is requested with a simple GET the application would load, find the data in the html and maybe open a window with that article. Or if it is a password reset link, find the data and popup the password reset dialog. ------------------------------------------------------------------------------ _______________________________________________ qooxdoo-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel |
Good Morning Voger,
OK I think I just don't get it. Do you have a scenario for us (besides the password change) what you are trying to achieve? Something like a workflow description? Do you mean something like: 1. Start app in default mode: http://mysite.com/ 2. Start app in password change mode: http://mysite.com/pwdchange?someparameter=somevalue 3. Start app and Show apps register user wizard: http://mysite.com/register ? Am 10.12.2015 um 21:22 schrieb voger: > Thank you for your ideas. The password reset feature was an example. I > did a bit more research and more thinking and now my idea of using > cookies and redirects doesn't seem that good any more. From the research > I found out about window.history.pushState and > window.history.replaceState > http://spoiledmilk.com/blog/html5-changing-the-browser-url-without-refreshing-page/ > and the qooxdoo's own history module > http://demo.qooxdoo.org/current/apiviewer/?search=qx.ui.window.Window#qx.bom.History > > I still don't understand how these could fit together and how to > implement the _readState and _writeState methods. I guess I will find > out with trial and error. Any examples are welcome :D > > Anyway, my new idea is that all the URIS when are not being requested > via AJAX, will return the .html file of the main app with additional > data in the <body?. Something like this stackoverflow answer > http://stackoverflow.com/a/28705599/2604378 > The main app will detect that data during loading and perform the > according action. > > For example a link could be a presentation of some article. There would > be a permalink to that article and when the link is requested with a > simple GET the application would load, find the data in the html and > maybe open a window with that article. Or if it is a password reset > link, find the data and popup the password reset dialog. > > ------------------------------------------------------------------------------ > _______________________________________________ > qooxdoo-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel ------------------------------------------------------------------------------ _______________________________________________ qooxdoo-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel |
If using URI parameters is a way to go, you could use
qx.util.Uri.parseUri and detect parameters added along with the main URI of you app. You could have a link like http://mysite.com?pwdchange=123456&foo=bar still opening your app and detecting the parameters in qx.application.Standalone.main: var uri = qx.util.Uri.parseUri(window.location); /* yields uri.queryKey === { pwdchange: "123456", foo: "bar" }; */ if(uri.queryKey && uri.queryKey.pwdchange) { this.showPwdChangeWindow(uri.queryKey); } else { // default code } For more sophisticated URI parsing you could use a library like http://medialize.github.io/URI.js/ And in the end you could rewrite URLs on the webservers side which turn links like http://mysite.com/pwdchange/123456 into http://mysite.com?pwdchange=123456 Am 11.12.2015 um 08:28 schrieb Dietrich Streifert: > Good Morning Voger, > > OK I think I just don't get it. > > Do you have a scenario for us (besides the password change) what you > are trying to achieve? Something like a workflow description? > > Do you mean something like: > > 1. Start app in default mode: > > http://mysite.com/ > > 2. Start app in password change mode: > > http://mysite.com/pwdchange?someparameter=somevalue > > 3. Start app and Show apps register user wizard: > > http://mysite.com/register > > ? > > > ------------------------------------------------------------------------------ _______________________________________________ qooxdoo-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel |
forget that. It won't work, because the browser does not see the rewrite:
Am 11.12.2015 um 09:35 schrieb Dietrich Streifert: > And in the end you could rewrite URLs on the webservers side which > turn links like http://mysite.com/pwdchange/123456 into > http://mysite.com?pwdchange=123456 > ------------------------------------------------------------------------------ _______________________________________________ qooxdoo-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel |
In reply to this post by Dietrich Streifert
What I want to do is to create bookmarkable and clickable links.
for example http://example.com/accounts/password/reset/key/2-47k-0ab765eddbf39c6656aa/ Will open the main app with a dialog for reset password http://example.com/accounts/user/voger Will open the main app with a window with the users profile http://example.com/users/voger/posts Will open the main app with a window with voger's posts http://example.com/users/voger/post/123456 Will open the main app with a window displaying the specific post Kind of like the apiviewer does it. I am reading it's code and try to understand how it works. I try to get as much information as and I haven't clarified yet in my mind how to design it. Should the content be somewhere in the HTML minimizing trips to the server and maximizing SEO potential or should I rely in parsing the URL? Should I use the qx.bom.History module or some other library or rely in pure javascript? Also it gets more confusing with the note in the top of Back-Button and Bookmark Support page in the manual http://manual.qooxdoo.org/current/pages/website/back-button_and_bookmark_support.html?highlight=history "This document is outdated and does not reflect the proposed way of working with qx.Website. The history module is still under development. As soon as the module is ready, this document will be updated as well." ------------------------------------------------------------------------------ _______________________________________________ qooxdoo-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel |
If you do that then doesn’t that mean that you’ll have to serve the app up from several URLs (in which case the browser will see each URL as a separate app and cache the results independently), or redirect the user back to a common URL with a parameter?
I think the differences with the API viewer is that because the app is already running when the user clicks a link, it can intercept the event and modify the history (and the URL in the address bar) so it appears that there are these different URLs, but the API viewer modifies the URL to change the bookmark (ie the part after a #) and not the change the path to the app itself. EG the URLs are http://demo.qooxdoo.org/current/apiviewer/#qx.ui.layout.HBox and http://demo.qooxdoo.org/current/apiviewer/#qx.ui.layout.Grow, and *not* http://demo.qooxdoo.org/current/apiviewer/qx.ui.layout.Grow This is essential because it means that the app is always being loaded from the same place, and the app can determine when it starts up what the bookmark is referring to. So your bookmark able URLs would need to be something like: http://example.com/mainapp/#accounts/password/reset/key/2-47k-0ab765eddbf39c6656aa/ http://example.com/mainapp/#accounts/user/voger http://example.com/mainapp/#users/voger/posts http://example.com/mainapp/#users/voger/post/123456 Regarding the docs, the link you gave is for qx.Website - I assumed you were writing a Desktop app, but I guess that’s not the case? I don’t know how different qx.Website and Desktop are from each other John On 11/12/2015, 17:50, "voger" <[hidden email]> wrote: >What I want to do is to create bookmarkable and clickable links. > >for example > >http://example.com/accounts/password/reset/key/2-47k-0ab765eddbf39c6656aa/ >Will open the main app with a dialog for reset password > >http://example.com/accounts/user/voger >Will open the main app with a window with the users profile > >http://example.com/users/voger/posts >Will open the main app with a window with voger's posts > >http://example.com/users/voger/post/123456 >Will open the main app with a window displaying the specific post > >Kind of like the apiviewer does it. I am reading it's code and try to >understand how it works. > >I try to get as much information as and I haven't clarified yet in my >mind how to design it. Should the content be somewhere in the HTML >minimizing trips to the server and maximizing SEO potential or should I >rely in parsing the URL? Should I use the qx.bom.History module or some >other library or rely in pure javascript? > >Also it gets more confusing with the note in the top of Back-Button and >Bookmark Support page in the manual >http://manual.qooxdoo.org/current/pages/website/back-button_and_bookmark_support.html?highlight=history > >"This document is outdated and does not reflect the proposed way of >working with qx.Website. The history module is still under development. >As soon as the module is ready, this document will be updated as well." > >------------------------------------------------------------------------------ >_______________________________________________ >qooxdoo-devel mailing list >[hidden email] >https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel ------------------------------------------------------------------------------ _______________________________________________ qooxdoo-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel |
Thanks. Serving the app from different places was one of the options. I
haven't thought about independent caches etc. I see now it was a bad idea :-D I saw that the apiviewer uses the hash for the generated link but I assumed the hash is only for describing document fragment. But yeah, it could be shared around as a link and simplifies a lot of things. > Regarding the docs, the link you gave is for qx.Website - I assumed you were writing a Desktop app, but I guess that’s not the case? I don’t know how different qx.Website and Desktop are from each other I am writing a Desktop app but Apiviewer also uses that module and I also use some other qx.bom modules. Thank you very much for the advice On 11/12/2015 08:06 μμ, John Spackman wrote: > If you do that then doesn’t that mean that you’ll have to serve the app up from several URLs (in which case the browser will see each URL as a separate app and cache the results independently), or redirect the user back to a common URL with a parameter? > > I think the differences with the API viewer is that because the app is already running when the user clicks a link, it can intercept the event and modify the history (and the URL in the address bar) so it appears that there are these different URLs, but the API viewer modifies the URL to change the bookmark (ie the part after a #) and not the change the path to the app itself. EG the URLs are http://demo.qooxdoo.org/current/apiviewer/#qx.ui.layout.HBox and http://demo.qooxdoo.org/current/apiviewer/#qx.ui.layout.Grow, and *not* http://demo.qooxdoo.org/current/apiviewer/qx.ui.layout.Grow > > This is essential because it means that the app is always being loaded from the same place, and the app can determine when it starts up what the bookmark is referring to. > > So your bookmark able URLs would need to be something like: > > > > http://example.com/mainapp/#accounts/password/reset/key/2-47k-0ab765eddbf39c6656aa/ > http://example.com/mainapp/#accounts/user/voger > http://example.com/mainapp/#users/voger/posts > http://example.com/mainapp/#users/voger/post/123456 > > Regarding the docs, the link you gave is for qx.Website - I assumed you were writing a Desktop app, but I guess that’s not the case? I don’t know how different qx.Website and Desktop are from each other > > John > > > On 11/12/2015, 17:50, "voger" <[hidden email]> wrote: > >> What I want to do is to create bookmarkable and clickable links. >> >> for example >> >> http://example.com/accounts/password/reset/key/2-47k-0ab765eddbf39c6656aa/ >> Will open the main app with a dialog for reset password >> >> http://example.com/accounts/user/voger >> Will open the main app with a window with the users profile >> >> http://example.com/users/voger/posts >> Will open the main app with a window with voger's posts >> >> http://example.com/users/voger/post/123456 >> Will open the main app with a window displaying the specific post >> >> Kind of like the apiviewer does it. I am reading it's code and try to >> understand how it works. >> >> I try to get as much information as and I haven't clarified yet in my >> mind how to design it. Should the content be somewhere in the HTML >> minimizing trips to the server and maximizing SEO potential or should I >> rely in parsing the URL? Should I use the qx.bom.History module or some >> other library or rely in pure javascript? >> >> Also it gets more confusing with the note in the top of Back-Button and >> Bookmark Support page in the manual >> http://manual.qooxdoo.org/current/pages/website/back-button_and_bookmark_support.html?highlight=history >> >> "This document is outdated and does not reflect the proposed way of >> working with qx.Website. The history module is still under development. >> As soon as the module is ready, this document will be updated as well." >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> qooxdoo-devel mailing list >> [hidden email] >> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > > > > ------------------------------------------------------------------------------ > _______________________________________________ > qooxdoo-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > ------------------------------------------------------------------------------ _______________________________________________ qooxdoo-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel |
Free forum by Nabble | Edit this page |