Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Multi homing support missing

...

==> You can easily achieve that by registering an application wide IComponentResolver with app.getPageSettings().addComponentResolver(). In addition we'll support "queuing" components in the near future, which is kind of what you are looking at but not exactly. You can queue a component with a parent container but eventually it'll be added to the container providing the child markup. That way the hierarchy remains in sync.

Wicket should have native support for multiple homepages, or "multi homing"

Quite often your application has multipe home pages: front page (not logged in), login page, and possible mobile login page and other "home pages" for various purposes / use cases. The problem is that wicket 1.4.12 does not currently support multiple home pages "out-of-the-box". You can achieve support for multiple homepage, errorpage, etc. with quite lot of work, but it would be beneficial to have it out-of-the-box.

MartinG: isn't that already supported ?

...

and in 1.5 you can use a request mapper to intercept the root url and return whatever page you want.

MartinM: Multi homing is not properly supported in many cases, for example assuming user's session timeouts -> what homepage to redirect him to?

Modal window built-in

Modal window capability should be built in such that coder don't need to insert <div wicket:id=modal-window-placeholder/>. It seems very futile. It should be enough to just override "isUsingModalWindow" in component hierarchy and the Wicket will provide one. Modal window implementation can be some interface, abstract one, or current one.

...