If you should meet triumph or failure, treat these impostors just the same.
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.
- properties files
- custom text files
- and so on...
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.
- making sure app programmers always have read-access to the config
- perhaps allow for N config sources in a single app
- perhaps allow web4j's config to be separate from the app's config
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.
- memcached distributed caching.
- master-slave schemes.
- "sharding" large tables, by splitting them apart into N tables, on N databases.
- generating sequence ids such that no collisions occur between sharded tables.