You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 30 Next »

improve ajax support of javascript

i still think we should be doing something more object oriented in terms of composing javascript for ajax purposes. i'd like to see us adopt something like that JavaScript class i was promoting a while back. one thing that occurs to me today is that not only could you easily compose javascript this way, but there might be a whole host of reusable javascript behaviors we could all leverage. for example, instead of having bits of javascript code hacked into strings all over projects to accomplish deletion confirmation on link/button clicks, we could have ConfirmJavaScript extends JavaScript and take care of the gory details in there (string resources for localization, whatever). as hunks of javascript get more complex and prevalent, creating this abstraction could really serve us nicely as a community. i personally would have loved to reuse things like FadeComponentJavaScript or DisableComponentJavaScript. the subclasses will all take a lot of work to create, but let's make an abstraction for JS code so we can do this work at all. – jonathan

Remove Change and possibly VersionManager

no longer needed since we serialize the entire page. Downside - makes HttpSessionStore not as space efficient
(possibly move these implementation details down into the session store package? - jonathan)

Remove PageMap

PageMap is a misnomer and isnt really needed anymore - not with second level session store around.
(again, move into httpsessionstore package for backwards compat?)

Transparent clustering support out of the box and enabled by default

Coming in Wicket 1.3.1 WICKET-1272

Window scope

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

JDK-1.5 support
  • Generify models
  • Annotation for mounting a bookmarkable page
  • Use varargs, for instance (a bad example) MarkupContainer#add(Component) -> MarkupContainer#add(Component...)
Make WicketTester a first class citizen

Currently WicketTester is one of the less mature parts of the core project. It really is useful and great, but the API is not thought through and there are lots of areas you still can't test.

Migrating the API to a Junit 4.4 + Hamcrest style of programming would be a very nice addition.

IDataProvider#size() should return long

The JPA spec has count queries return long instead of int. This change has been attempted earlier, and it was not found to be trivial. It is also a major break in API so we need to consider this carefully.

Take a good look at PagingNavigator and AjaxPagingNavigator

The PagingNavigator has been with us since 1.0 and might need some cleaning up.

Establish Wicket Security strategies sub project
  • Make Swarm part of wicket core - Giving users easier access to a security framework.
  • Move auth-roles into sub project
Improve Tree model

the tree can use a more web-friendly model then swing's tree model

Add Rapid Prototyping Forms

The Idea of Alistair Maw and Jonathan Locke (ROR? No. Wicket on Wheels.) should be included in next Wicket. A set of nice looking Defaultformcomponents and a Beanresolver to automatically let create forms from just the plain bean but still allow to customize it later by overiding parts of it. Beside nice looking (to show/ even may go live with it in first place) and fast it should have enabled possibility to integrate security on a Form as well as Field-level.

See Wicket Web Beans.

Clean up/ Have a look at Models

With now having a CompoundPropertyModel that has the same abilities as BoundCompundPropertyModel it might be nice to have someone overwork all models and decide if we really need all. Stiping out/ Migrating ino one e.g.: BoundCompoundProperty and CompoundProperty model as well as others (if possible) would really ease wicket for beginners as well as save experienced users some thoughts about what model to use.

Already done in 1.3, there is not much that needs to be improved other than apply generics.

Postprocessing Response

Can be interesting for me have a feature (configurable in application) that apply a xsl postprocessig for each response. Now i can use a Border o XslBehaivor to have same feature but is not transparent for page.

see IResponseFilter

Package Level Properties / resources
Add support for SSL pages/components out-of-the-box

The wiki describes a nice way (though still diamond in the rough) to switch from/to SSL connections using an annotation. This could/should go into core.

Add possibility to use interface implementation instead of extending Panel

Allow components (for example formComponents) have their own markup without the need to extend Panel. The change should not change/brake any existing stuff, only add additional possibility how to solve some problems easier then currently. For example instead of wrapping TextField in Panel just subclass the TextField and implement the given interface.

Mounting with "nicer URLs"

Ability to mount page so it will have one instance per session which will be always accessable by mounted URL.

Normalize page URLs

so when user hits a page /my/page/a/b/c//// redirect immediately to /my/page/a/b/c

Investigate JDK-7 properties support/libraries

Java properties are probably something we will have to deal with sooner or later. We should try to look at what is proposed, and what is readily available. The following blogs have links to sources:

  • No labels