Feature #986
closedWApplication::setBaseURL(std::string url);
0%
Description
This will be needed by
1) applications deployed under FastCGI protocol,
2) WTHTTP connector
1) When using DocumentRoot (/var/www) and directory under DocumentRoot (/var/www/abc) with FascCGI app deployed there, WApplication will have to set dynamically base url(but only once perhaps, or more if WApplication::redirect() is used) from
const std::string & WEnvironment::hostName () const;
const std::string & WEnvironment::urlScheme () const;
(WApplication::setBaseURL(env.urlScheme + "://" + env.hostName() + "/abc/");
since urlScheme is chosen by user (and hosted by web server), and host name can also be chosen by user.
2) changing base directory for all resources
You just can't tell what scheme will be used, when deploying FastCGI app which will run both http and https mode.
Files
Updated by Koen Deforche about 13 years ago
Hey Lukasz,
Using absolute paths in an application should really not be needed. We've spent alot of time so that your application will work just well while using relative paths, regardless of deployments using FastCGI (with the proper configuration of the web server), and wthttpd.
In fact, several people will be using wthttpd for development and FastCGI for deployment, without any change to the code, and without the need for absolute paths.
The main reason to avoid absolute paths is that they are totally deployment unfriendly once you involve reverse proxies.
Regards,
koen
Updated by Koen Deforche about 13 years ago
Hey,
just for completeness, this is the place this is being discussed: http://redmine.emweb.be/boards/2/topics/2719
Regards,
koen
Updated by Koen Deforche about 13 years ago
- Status changed from Resolved to Feedback
Updated by Łukasz Matuszewski about 13 years ago
My only question is, can i use relative urls in baseURL property. I mean my conf looks like this:
<application-settings location="/var/www/wt/SyNaTPG.wt">
<properties>
<property name="baseURL">/wt/</property>
<property name="resourcesURL">/wt/resources</property>
<property name="extBaseURL">/wt/ext</property>
<property name="favicon">/wt/favicon.ico</property>
</properties>
</application-settings>
</server>
It works with http and https, but baseURL is relative, not absolute... and this may infere the std::string WApplication::resolveRelativeUrl (const std::string &url) const. It seems that relative baseURL works, but still i want an answer.
BR
Lukasz Matuszewski.
Updated by Koen Deforche about 13 years ago
- Status changed from Feedback to Resolved
- Assignee set to Koen Deforche
- Target version set to 3.1.11
Hey Lukasz,
Thanks for your persistence --- finally we got the root the cause: a problem in internal path handling and progressive bootstrap.
The latest git should contain a fix. Can you see if indeed this is now solved ?
Regards,
koen
Updated by Łukasz Matuszewski about 13 years ago
- File SyNaTPG.7z SyNaTPG.7z added
I have tested your git version and seems that this bug is still alive.
What i really do is to inherit form QueryModel<dbo::ptr > and i use my own update method:
if ((role == DisplayRole || role == EditRole))
{
if (index.column() < 4)
return this->dbo::QueryModel<dbo::ptr<NazArtNazAlbItp> >::data(index, role);
else if (index.column() == 4)
return WString::tr(MIR_TABLE_EXP_DOWNLOAD_PARAMS);
else if (index.column() == 5)
return WString::tr(MIR_TABLE_EXP_DOWNLOAD);
}
else if (role == LinkRole)
{
if (index.column() == 4)
{
return WLink(new ParamsResource(this->m_dm, this->resultRow(index.row())->m_naa_id));
}
else if (index.column() == 5)
return WLink(new MusicResource(1, this->m_dm, this->resultRow(index.row())->m_naa_id));
}
return boost::any();
I now do not use any ItemDelegates... it is to wt to render WLink with its url.
I have included as attachment my app (only without real passwords) so you can test... or you can go to http://synat.eti.pg.gda.pl and see that this bug really persist.
Hope it helps.
As a curiosity i have deployed same app but using WStandardItemModel as model (without query), and there it seems to work ok (i tried to reproduce the error with simple app).
So i think the bug is around QueryModel or its affiliates (perhaps am wrong, i play with wt only about a year till now).
Hope it help.
Updated by Łukasz Matuszewski about 13 years ago
The bug we all talking about is only set on Sign Out WMenuItem, and only when the mentioned WCustomTableView is rendered as first (WCustomTableView is WCompositeWidget which uses WTableView). When we click on some column to resort it, the bug disappears form mentioned WLink. The WCustomTableView is sorted initially in:
wtv->sortByColumn(0, AscendingOrder);
So i think the bug can be around WTableView (it breaks WMenu, which can be free of bugs, and so Sign Out menu item is not rendered properly (it doesn't have /wt/ as part of url)).
Hope it helps.
Updated by Koen Deforche about 13 years ago
Hey Lukasz,
Just yesterday I fixed another small bug in internal path handling that may have caused this.
So you might want to give it another try...
Regards,
koen
Updated by Łukasz Matuszewski about 13 years ago
I have updated to today version (22.09.2011) and bug still persist. But after you log by lukasz and anakin you can resort the WCustomTableView (that is WTableView inside) and see that this bug disappears... So bug should be after initial loading of table.
BR,
Łukasz Matuszewski
Updated by Koen Deforche about 13 years ago
- Status changed from Resolved to Closed
Resolved in Wt 3.1.11