Koen Deforche wrote:
I had to google for SEO... Search Engine Optimization.
LOL, you probably should familiarize yourself with the concept at some
stage :-)
Don't forget usability as a main benefit of internal paths: people
really expect back and forward buttons to work, as well as bookmarks
and opening links in a new window/tab.
Acknowledged.
I think you are absolutely right that we urgently need a good example
using the internalpath API directly (i.e. not through a WMenu), to
make it more useful.
Hopefully what i've started playing with can "morph" into a useful example.
The idea behind the internal path API is to not end up with a central
"controller" that manages all paths in your application.
Ahh..... OK, I will need to modify my angle of attack.
Instead, we
want any widget to be able to handle its part of the path URL. A
widget will be hosted at a particular path (say "/jobs/") and be only
interested in interpreting the next component as you call it, in order
to set its internal state. In this way, every widget that participates
in the internal path API will be listening for internalPathChanged
events, but only be interested in certain events.
This was also the inspiration to have the internalPathChanged signal
to be called consecutively, for every prefix at which an change
happened.
I understand, I need to investigate this more thoroughly. I hadn't
really considered it from the perspective of widget "ownership" of a
path although, now you mention it, it's making a lot of sense.
To answer your immediate question, you can determine that a path is
the final path, like this:
void MyWidget::onInternalPathChange(std::string prefix)
{
std::string nextPart = wApp->internalPathNextPart(prefix)
if (nextPart.empty()) {
// deal with prefix being the last part.
// internalPath() is now set to the entire internal path.
} else {
// nextPart at prefix
// internalPath() is now set to prefix + nextPart.
}
}
Other ways to know if the current prefix terminates the internal path:
if (prefix.length() >= internalPath().length())
// ... last part
(it will be at most equal to the internalPath, or one character longer
since prefix
is always terminated by '/').
One thing I currently dislike about the API is that it seems too
complex for what it should do.
Would it be a good idea to somehow expose the CGI SCRIPT_FILENAME
variable and/or others directly?
As above, I need to further digest this information.
Also, internalPath() should probably simply be the new internal path
while propagating internalPathChanges, which will avoid confusion and
simplify detecting what is the last prefix (since now you may only
know one internalPathChange event too late, depending on how you deal
with internal paths).
The reason that the internalPath() is now always limited to the
current relevant part, is to make it easier to develop widgets that
will assume on widget creation that they are located on the current
internalPath() (e.g. the WMenu widget does that by default). In that
way, by feeding the new internal path piecewise to the application, it
is as if the user really navigated piecewise to the new path.
Because of all these issues, we would really like to hear what you
feel makes more sense ?
I think there are readers of this list that are eminently more qualified
to put forward an opinion on this. I am not a great C++ programmer, I'm
working on it though. I do have a reasonable amount of experience in web
development (primarily using PHP, some C++ CGI) though so I will dive in
at some stage. At this point in time I would like to read more of the wt
source and use the API some more before I get too vocal.
Better to keep you mouth shut and be thought a fool than to open it and
remove all doubt.
I like the concept of your example. It would be even more useful if we
divert the logging also to the application itself.
Will do, hope to get some time to play with this on the weekend.
Thanks for the great work you guys are doing, I know it will play a
significant part in my future web development efforts.
Kindest regards,
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
