qooxdoo

links to the qooxdoo application

Classic

List

Threaded

11 messages Options

voger

links to the qooxdoo application

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

Tom Saddul

Re: links to the qooxdoo application

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.

John Spackman-3

Re: links to the qooxdoo application

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

Dietrich Streifert

Re: links to the qooxdoo application

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

voger

Re: links to the qooxdoo application

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

Dietrich Streifert

Re: links to the qooxdoo application

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

Dietrich Streifert

Re: links to the qooxdoo application

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
>
> ?
>
>
>

Dietrich Streifert

Re: links to the qooxdoo application

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

voger

Re: links to the qooxdoo application

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

John Spackman-3

Re: links to the qooxdoo application

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

voger

Re: links to the qooxdoo application

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
>