I’m trying to understand how the Sampler application does its bookmarking magic
I haven’t been able to figure out where, given a URL of http://demo.vaadin.com/sampler/#Components/Common/Tooltips (for example) the application parses it out and figures out the corresponding Feature to activate. I see code for the source window, but can’t see the corresponding code for the main window.
the application seems to be relying on ActiveLink for its magic (creating links with # in them); is there a way to use a MenuItem and have each menu entry send the user to a page with a different URL ?
Next step will be to for me to break down and actually install a JDK 1.5 compiler so I can build the application from source and trace it down :*) (build.xml doesn’t seem to like 1.6 even with the -D switch to tell it not to validate).
The key part of bookmarking/back button magic comes via UriFragmentHandler component. It is an invisible helper component used to read the #something part of URI which is not commonly available by servers at all. It provides events for changed fragments and also an api to change to fragment via servers side api (like to create a linkable view).
The ActiveLink component is pretty much just a normal link, but it also sends an event to server on each click. With it one can detect if the link was opened to a different tab or separate browser window. It may be useful in some cases when really fine tuning your browser experience.
Well, I broke down and compiled things so I could trace down the Sample application, which worked (of course).
The only difference between my code and the sampler was that the uriFragmentUtility was being added to a Component (in the Sampler), and not to the Window (in my broken code).
I proceeded to change my code as follows (moved the utility to my main layout), which solved my problem – I now get the fragment changes,
mainWindow = new Window(Messages.getString("CompetitionApplication.Title",getLocale())); //$NON-NLS-1$
setMainWindow(.mainWindow);
setTheme("competition"); //$NON-NLS-1$
VerticalLayout mainLayout = new VerticalLayout();
// back and bookmark processing
UriFragmentUtility uriFragmentUtility = new UriFragmentUtility();
mainLayout.addComponent(uriFragmentUtility);
uriFragmentUtility.addListener(new FragmentChangedListener() {
private static final long serialVersionUID = 1L;
@Override
public void fragmentChanged(FragmentChangedEvent source) {
String frag = source.getUriFragmentUtility().getFragment();
System.err.println("fragment changed to: "+frag);
displayView(frag);
}
});
mainLayout.setSizeFull();
mainLayout.setStyleName("blue"); //$NON-NLS-1$
getMainWindow().setContent(mainLayout);
Please add a section to the Book (note the capital B) and kindly document this quirkiness.
This sounds a bit odd, since all components you add to a window are in effect added to the contained layout in that window.
Therefore I assume you earlier added the UriFragmentUtility to your mainWindow before you set the content of that window (getMainWindow().setContent(mainLayout)), which then in effect replaced all previous content/components of that window and removed the previously added UriFragmentUtility.
Yes, you are dead on. Painfully obvious, now. What got me sidetracked is that the fragment listener is added to the navigation bar in the sampler. Without such a bar, the knee-jerk reaction is to add it to the window; without thinking deeply it is easy to think of “setContent” as being similar to “addComponent”.
I hope we can get to building next major version soon. We plan to integrate uri fragment handling to top level windows in 7.0. Things ought to become much easier then.