WEB4J. Because simple is beautiful.

Future Releases

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 :

• properties files
• JNDI
• database
• web.xml
• custom text files
• and so on...

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 seems to be a 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 :

• making sure app programmers always have read-access to the config
• perhaps allow updated config values to be read in at runtime (Servlet 3.0 has something for this)
• 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?

Serve XML Without Needing a JSP

Serving XML can be accomplished by building the XML content in code, storing the result in a request scope object, and then forwarding to a simple JSP to render the text. As a convenience, it would be nice to not have to create a JSP for this purpose. Rather, it would be nice to be able to serve the text directly.

This is likely do-able already. See the ServeBinaryAction class in the example app. It essentially takes over the production of the output stream, and creates the output directly in code. If this is viable, then it should be made more explicit in the documentation.

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 :

• Populate
• Tooltips
• TextFlow

Support HTML 5

Support should be added someday for the relatively new HTML 5 specification. The new form controls should be straightforward to add. The new form controls are more about improving the user experience on the client side, not the interaction with the server. On the server side, the POSTed data will not be changed simply because a form input widget's type has changed from 'text' to 'email', for example, so, as far as the new form controls go, the changes will be minimal. The population of forms will need to be expanded to support the new types of controls.

The new verbs PUT and DELETE will be added to GET and POST. That will likely need to be accounted for. It's likely that other items will be significant as well.

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

Templated Page

The example apps all use the same mechanism to implement templating of pages. It seems like a good candidate for a default templating mechanism, as part of web4j itself.

Audit Tracking Fields in Database Tables

Can anything be done to reduce repetition associated with CreatedBy and ChangedBy fields in database tables?

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 :

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

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

Servlet Spec 3.0

Version 3.0 of the Servlet Specification was released December 2009. Tomcat 7 was released August 2010, and supports 3.0. Interesting items include:

• asynchronous communication between client and server
• file upload improvements
• programmatic login - automatically log in a user after they create an account
• jsp-config includes content-type
• Tomcat 7 has CRSF protection; easily embedded; more strict implementation of the spec