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
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 vi
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 use
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
>
---
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.Standalon
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 ch
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://s
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 b
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
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,
10 matches
Mail list logo
