Future Releases

If you should meet triumph or failure, treat these impostors just the same.
- Rudyard Kipling

Bug Fixes for the Next Release

No known bugs.

Bug fixes for historical releases are listed in the Version History.

Possible Features for Future Release

The following are some possible ideas for features that may be added to web4j. They are listed in no particular order.

Alternate Config Sources

Currently, configuration is always placed in web.xml. It should be relatively simple to allow arbitrary sources of config data: An important side-effect to implementing this would be that the web4j database layer could then likely be used outside the web context, for example in a Swing app. The current web4j data layer assumes the config comes from ServletContext. This is a true defect in the design, since it ties it unnecessarily to the servlet API. As long as you are building a web app, it doesn't matter much. But as soon as you move out of the web context (for example, when testing), it matters a lot.

Implementing this idea would likely mean defining a new interface. A default implementation would be supplied, which would simply use web.xml (as is done currently). Thus, existing apps would not break.

Related items:

Batch Processing of Multiple SQL Statements

Some users would like to use the web4j data layer outside of the Servlet context. This can already be done by using the fake objects supplied with the Fish And Chips Club example app. However, it's clearly inelegant. If a way of defining an alternate config source (see above) was built into the tool, then adding this capability should be possible.

Make Dynamic Page Titles More Elegant

With current classes, dynamic <TITLE> content is not hard to implement. But it could likely be made a bit more elegant and simpler. Perhaps a setTitle(String) method in the ResponsePage class.

Should the ResponsePage class take a SafeText parameter instead of a String? Given the second class nature of Strings in web4j, it would seem likely. This would likely have non-trivial ripple effects. Any negative interaction with the <w:txt> tag?

More Support For HTML5

The Populate class supports some HTML5 form controls. The date-time controls have been left out. See the Populate class for more information.

'Spreadsheet' Style Parameters, With 'Indexed' Values

Many apps have forms whose parameters are variable in number. Currently, WEB4J's default implementation of the RequestParser assumes all request params have been declared as RequestParameter objects somewhere in your code. This default isn't friendly to dynamic params that vary in number. It would be good to allow for that style, in a reasonable way. (The design of this has been attempted twice, but no reasonable design was found.)

Ensure XHTML Can be Used Instead of HTML

Three custom tags are very likely incompatible with XHTML, because their underlying regular expressions assume HTML. This can likely be amended fairly easily. The 3 problematic tags are:

Make It Easy To Use Memcached, Master-slave, and "Sharding"

The majority of apps have traffic which can be handled with plain deployments. For the few sites that have large amounts of traffic, the data layer is almost always the bottleneck. It would be best if WEB4J's data layer could be made as compatible as possible with the major ways of handling large amounts of traffic: Both master-slave and sharding come down to dynamically deciding which database to hit. That can be done presently by simply creating the appropriate SqlId object on the fly, but it would be nice to add a simple convenience method to SqlId for that express purpose. There may be a related interface as well, in which the app tells the framework which database to hit.