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

Compare with Current View Page History

« Previous Version 57 Next »

Model refactoring

Model Refactoring

create interface generation for .html markup files in order to ensure validity of wicket:ids.
public HelloWorld()
    {
        add(new Label("message", "Hello World!"));
    }

The wicket:id list is known at compile time for every .html. The java code could have been safer:

public HelloWorld() implements HelloWorldHtml
    {
        add(new Label(MESSAGE, "Hello World!"));
    }

Constant MESSAGE might have been defined in the interface extracted from HelloWorld.html.

create abstraction for content types

currently, wicket has a concept of "markup type" that is actually the markup extension. in doing work on wml support for "mobile wicket", i'm discovering a need for full mime type support. if it doesn't break too many people, it would ideally be best to introduce a formal MarkupType class with a getExtension() and getContentType(), where ContentType includes mime type information. there quite a bit to think through here in terms of request/response markup type mappings, but i'd be up for working on this. this problem is definitely generic to problems outside mobile wicket. – jonathan

multiply child/extend inheritance

https://issues.apache.org/jira/browse/WICKET-1134

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

A few advantages to making our javascript more OO:

  • conform to Yahoo recommendations on page rendering performance by putting javascript just before </body>
  • more component oriented development through object literals (JSON)
  • separate javascript from markup
ListView users = new ListView("users", usersModel);
users.setOutputMarkupId(true);
// DomQuery-esque selector (http://extjs.com/learn/Tutorial:DomQuery_v1.1_Basics)... 
//selector could be turned into a Builder object instead of string
Event e = new ClickEvent("a[class=deleteLink]"); 
e.addHandler(new ConfirmDialog("Are you sure you want to delete?"));

users.addEvent(e); // can be shortened to new ClickEvent("...", new ConfirmDialog("..."))

serializes to:

{ element: "{usersMarkupId}:", // generated by Component
  events: [
      { event: "click", [  // generated by ClickEvent
          { selector: "a[class=deleteLink]",
            handlers: [
              function() { // generated by ConfirmDialog
                if(confirm("Are you sure you want to delete?") {
                  // Wicket.ajax...
                }
              }
            ]
          }
        ]
      }
    ]
}

Wrap the above in an 'ondomready' event and we have unobtrusive javascript that should be easier to abstract going forward.

– brian

New Inspectors

Add inspector to look for empty src="" attrs which cause extra requests to the server

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)
(this is already pushed to the store package i guess, version manager and pagemap are created by the httpsession store already,
the problem with removing this is that it will break all stuff that cant depend on the file based store are really need to be in mem,
the disk based store already doesn't do anything with Change and also the version manager, it only uses the version number from the vm, johan)

Cleanup component visibility

Currently we have Component.set/isVisible, Component.isRenderAllowed, Component.set/isVisibilityAllowed

The reason for Component.set/isVisible is simply - allow users to control visibility of their component

The reason for Component.isRenderAllowed is for security strategy to be able to force component to be invisible

Now if i am a user and want to test if the component will be rendered or not I need to do

boolean visible=component.isVisible()&&component.isRenderAllowed()

This is ugly as I have to remember both checks all the time. Because of this I have introduced Component.determineVisibility() in 1.3.3 which encapsulates all necessary checks.
Now, what if I want to write a component that controls visibility of its children or other components. It can call child.setVisible(false), but that is not guaranteed to work because the child might have its isVisible() overridden and thus any call to setVisible() will be ignored. For this reason I have introduced Component.set/isVisibilityAllowed() in 1.3.3. Both setter and getter are final so it is impossible for the user to break the contract.

So now to check for visibility I need to call component.determineVisibility() which is very kludgy. I also have two sets of getters and setters that seemingly control visibility. Bad.

I think we should rename/refactor some of this to make it cleaner. The best solution would be to have isVisible() be final and equivalent of what determineVisibility() does now because that is the most natural way to query a component for its visibility. Also whatever the equivalent of current isVisible ends up being ( an overridable getter) it should not have a setter.

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?)
(see above points, johan)

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

Rewrite repeaters to make it easier to work with
  • boundless datasets
    • unknown size or too expensive to calculate every request
    • provide pager with first/pref/next only?
  • data stores that return count and window at the same time
    • need to know the window boundaries without querying the size first (no culling? fallback?)

(see WICKET-1784)

Take a good look at PagingNavigator and AjaxPagingNavigator

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

Replace ImageMap with a better one

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

WICKET-1456: rewrite existing ImageMap or create a new one?

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

done in 1.4, looks for package.properties, see PackageStringResourceLoader

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

Improve url generation

Instead of urlFor returning a CharSequence it should return a UrlBuilder that contains methods to append parameters and would encode them automatically.

The problem currently this: suppose you want to generate a callback, it should be pretty simple:

String url=urlfor(ilinklistener.interface)+"&myparam="+value;

However, if the page is bookmarkable+stateless the encoding is different - /param/value/ by default or whatever the coding strategy is, so simply doing +"&myparam="+value will not work.

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:

Portlet 2.0 (jsr 286)

Support jsr 286 portlet specification:

Previous page / Back button support

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>)
  • let validators use IModel instead/in addition to fixed values
Make JavascriptStripper more flexible

Currently, stripping of comments and whitespaces is implemented as static method. Therefore, the default implementation cannot be extended (e.g. with an implementation that strips Firebug's logging, i.e. console.log(), consoloe.debug(), ...) or replaced (e.g. by a JS compressor like http://developer.yahoo.com/yui/compressor/).

Support JSR 303 Bean Validation

Validation in the presentation layer, like in Wicket, conflicts with the don't repeat yourself principle. The same validation rule may be needed in different (Wicket) forms, in web services, in the domain layer and so on. The constraints should therefore be concentrated in one place - the domain class (take a look at Grailshttp://www.grails.org/Validation). Bean Validation is an easy and smart way to validate input.

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.

Dynamic setting of a link labels is a very common usecase and should be supported by wicket directly. LinkLabel discussion

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.

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.

  • No labels