Hey Brad,
2008/10/28 Brad Hubbard <[EMAIL PROTECTED]>:
> Below is the beginnings of something I hope will grow into an example of
> URL/internalPath/pretty urls creation in wt. This is crucial for me (and
> others I'm sure) to understand to get SEO aspects correct in future
I had to google for SEO... Search Engine Optimization.
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.
> developments. In an attempt to understand this better I have come up
> with the following code which I submit for review (be as harsh as you
> like :) ) As i said it's very rough and I guess I'm feeling it out to
> see if I have the general concept right and if this can evolve into a
> useful example.
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.
As you also noticed, the API is something new, as is the feature, and
the API has not been tested by time, unlike most of the rest of the
API in Wt, of which most were greatly inspired by another toolkit :-).
As such, we are also very much open to suggestions on how to improve
the API.
> One thing I would like to ask is when pathChange is called it appears to
> be called for each component of the path (a component being a string
> following a "/") in turn. How do I determine which is the final path,
> that is, pathChange will not be called again?
The idea behind the internal path API is to not end up with a central
"controller" that manages all paths in your application. 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.
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.
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 like the concept of your example. It would be even more useful if we
divert the logging also to the application itself.
Regards,
koen
-------------------------------------------------------------------------
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
