Page History

...

Most items fall in categories 1 and 2, see each item for the details.

...

Remove redundant Java component-hierarchy

...

The component hierarchy has to be defined twice; it has to be specified in HTML, and then it has to be matched in Java. This second hierarchy therefore is redundant.

There has been much discussion whether this is really a problem. The consensus seems to be this is not an issue, although some strongly object. See, for instance
Wicket has unnecessary binding between wicket:id and component hierarchy and here.

Also see JIRA ticket.

==> 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.

We discussd before that Wicket has unnecessary binding between wicket:id and component hierarchy. Currently wicket:id's have "doubly linked hierarchy", which is unnecessary: hierarchy in HTML and exaclty identical hierarchy in Java. Only either one of these two is needed, HTML component hierearchy. Currently the Java-side wicket hardcoded component hierarchy slows down development and is totally redundant whereas the information could be automatically parsed from markup.

When there is a will, there is a way.

further discussion: http://markmail.org/thread/rpf5oxnlbwjptkjv^{Image Removed}

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.

...

Coming in Wicket 1.3.1 WICKET-1272

Window scope

this will basically replace PageMap and allow users to store per browser tab/window attributesstore per browser tab/window attributes

Pagemaps/windows were dropped from 1.5+ in favor of simpler page versioning mechanics.

JDK-1.5 support

• Generify models
• Annotation for mounting a bookmarkable page - done in wicketstuff-annotation
• Use varargs, for instance (a bad example) MarkupContainer#add(Component) -> MarkupContainer#add(Component...)
• Take advantage of new classes (java.util.concurrent, LinkedHashMap that can be used as an LRUMap, etc) to remove some of the wicket.util classes

...

Support jsr 286 portlet specification:

• -* http://jcp.org/aboutJava/communityprocess/pfd/jsr286/index.html-

-See this issue for Portlet 2.0 related issues: -
-https://issues.apache.org/jira/browse/WICKET-1620-^{Image Removed}
Update: Portlet support has been dropped for Wicket 1.5 WICKET-2976

...

Using the pagemap isn't very elegant and passing in the current page isn't always convenient.

Make Validators more flexible

• let validators be a behavior to contribute to the markup (eg. maxlength attribute for <input>) Done
• let validators use IModel instead/in addition to fixed values (in 1.5 see ivalidatable#getmodel() in 1.4 see imodelawarevalidatable to which validtable in validators can be cast)

Make JavascriptStripper more flexible

...

  /**
   * @param <DataType> 
   * @param formComponent
   * @return DataType
   */
  public static <DataType> DataType getFreshValue(FormComponent<DataType> formComponent) {
    return (DataType) formComponent.getConverter(formComponent.getType()).convertToObject(formComponent.getValue(), formComponent.getLocale()); 
  }

-
Done in 1.5.

Integrate more widgets

A component framework like Wicket lives on the compents it provides. A rich set of easy to use gui components would increase Wickets popularity.

See https://github.com/wicketstuff/core^{Image Removed}

Add LabelLink

...

See AbstractLink#setBody(IModel)

Accelerate Serialization

Serialization is heavy used in wicket, therefore it would be good to accelerate it with JBossSerialization. It should be at least as twice as fast as default serialization.

See org.apache.wicket.serialize.ISerializer and IFrameworkSettings.setSerializer(). With these tools you are welcome to implement any custom serialization strategy.

Scala Support

Event handlers are an important part of Wicket applications. Today they are implemented usually with anonymous inner classes. Functional programming would be more concise and elegant. Scala is an object oriented and functional programming language, which would be a good choice to write Wicket Applications. A small Scala layer on top of wicket should be sufficient to use the benefits of Scala.

Effort to this effect has already been started, and proved working and very useful:https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/scala-extensions-parent/^{Image Removed}

Separate Examples

...

Consider using enumerations etc.

Also IVisitor.CONTINUE_TRAVERSAL and String NO_RAW_INPUT = "-NO-RAW-INPUT-" etc. could be more OOD.

...

You may want to look at wicketstuff-merged-resources.

See http://www.wicket-library.com/wicket-examples/resourceaggregation^{Image Removed}

Sprites/ImageBundle for wicket.

...