Discussion:
[Wt-interest] Where should internalPaths be processed?
K. Frank
2016-06-07 17:09:03 UTC
Permalink
Hello List!

Am I right that there are precisely two places where I need to
respond to the internalPath?

Namely:

WApplication construction
internalPathChanged signal

Is this the right way to look at it? Are there any other places
I need to process the value of internalPath in order to keep
the "page" displayed consistent with what the user sees as
the url?

For example, consider this code-sample fragment:

class MyApp : public WApplication {
public:
MyApp (const WEnvironment& env) : WApplication (env) {
internalPathChanged().connect (this, MyApp::onInternalPathChanged);
makePage();
}
void onInternalPathChanged() {
makePage();
}
void makePage() {
root()->clear();
std::string ip = internalPath();
// add internalPath-dependent content to root() ...
}
};

MyApp has different "pages," depending on the url. For this
example, each "page" is just different content put in root().

I need to check the value of internalPath when the app is
first constructed in order to display the correct page (that
might correspond to a "deep link") when the app first comes
up. I also need to process internalPath and show the new
"page" when the internalPathChanged signal fires because
the user navigated with in-app links or history.

In this simple example, both the constructor and
onInternalPathChanged delegate the internalPath processing
and page construction to the same makePage() function that
simply rebuilds the appropriate page from scratch.

Is this basically the whole story?


Thanks.


K. Frank

Loading...