Hi Wim,
Thanks again for your reply.
Wim Dumon wrote:
The documentation of wt 2.2.0 contains an explanation. Start with the
WApplication::setInternalPath and friends.
http://www.webtoolkit.eu/wt/doc/reference/html/classWt_1_1WApplication.html
When the user surfs to a new URL, the signal
Wt::WApplication::internalPathChanged is emited. It is up to you to
decide, based on the extra string appended to the application path,
what changes you will make on the widget tree.
Hmmm... for some reason all my browsers on various machines had cached
the 2.1.5 docs so I could not see the 2.2.0 docs (wondered why they
weren't up :) I've rectified this now of course and will have a read.
You can indeed search a
database in order to present the contents.
Yes, I have created a couple of small apps with wt which present data
from a database.
The homepage does not use static URLs - at least, not static pages.
Understood, they are created by the homepage app each time a browser
requests the corresponding URL.
Granted, we always show the same content when the user surfs to a
particular URL, but the homepage is a web application that is deployed
on http://www.webtoolkit.eu/wt/. Aso, the href of the homepage URL's
is set to something that looks like a static URL, but that is part of
the strategy of being search-engine friendly (and to enable users to
right-click and open a link in a new window etc). But look closely at
the location bar on top of your browser: there is a hash mark (#)
between the application path and the internal path. Mouse clicks are
handled by the onClicked() handler rather than following the
user-visible URL.
I get this.
The remainder of the URL string, be it 'documentation', 'download', or
whatever, is parsed by the WMenu class, which uses the normal
setInternalPath and listens to the internalPathChanged signal.
Finally, you end up in WMenu::setFromState(), who dynamically looks up
the path in a set. You can do whatever database access here. The WMenu
class is therefore an example of the use of this interface like you
would like to use it.
OK, I think I get this but will need to look at WMenu's implementation
as you suggest below to make sure. I'll post any questions I have here I
guess, hopefully not many. So I don't necessarily have to implement a
WMenu to acheive what I'm after but it may be the easiest way? The
alternative would be to write something that implements the equivalent
of setFromState(), setInternalPathEnabled(), and something to listen for
the internalPathChanged signal? I'd say I'll use at least one WMenu anyway.
In order to generate pages for products that I am not aware of at
compile time I need to be able to pass variables to a witty URL either
as an appendage to the "real" URL or as
?id=abc&manufacturer=garmin&model=nuvi350 style arguments. At the moment
I can't see how to do this, a simple example of how to do this would not
go astray I believe and I would be happy to donate such an example
(subject to peer review of course) if someone can tell me where to start?
I recommend src/Wt/WMenu.C
I'll take a look at this too. Am I crazy or is there no mention of
setFromState in
http://www.webtoolkit.eu/wt/doc/reference/html/classWt_1_1WMenu.html ? I
can see the relevant code in the most recent CVS anyway so no matter.
Thanks Wim, I WILL keep you guys posted. I am serious about this, I am
tired of programming in C++ and PHP, I want to use C++ for everything LOL.
Cheers,
Brad Hubbard
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
witty-interest mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/witty-interest
