First, a big THANKS goes out to my current and previous employers who have patiently let me scratch this itch intentfully for their benefit. Thanks to the developers whose excellent code this is built upon, especially the Java, Eclipse and Firbird SQL teams. To CJSW for the box arrangement. To all my friends, hopefully you understand why I haven't seen you as much as I'd like. To my girlfriend... oh sorry, drifted off there. If I spent as much time on one as I have on this she'd be a delicate beautiful trembling neurotic devoted sociopath, perhaps.

BRIEF
The BeNOW web framework is a java servlet based web application development environment. It is somewhat lightweight (for what it does) and very powerful, as it leverages many of the other BeNOW apis. The goal of the web framework is to make appropriate design quick and easy, resulting in robust, appropriate and reuseable web based applications. It makes pretty dynamic pages pretty easy, and it makes this site go.

DOWNLOAD
benow-web.nightly.tar.gz - current source bundle as checked out nightly from CVS.
benow-service-client.jar - nightly web service connector client jar.
benow-service-client15.jar - nightly web service connector client jar (for java 1.5).
/project/web - browse the nightly checkout

DOCUMENTATION
Documentation, including tutorials, development walkthru and JavaDoc API is available online or within the bundle.

TECH
The API uses the following technologies:

• java 1.5 , jetty, log4j, ant, firebird SQL, etc.
• Easy object fetching from database via BeNOW repository api
• Processing exposure and remote invocation via the BeNOW service api
• Object to XML marshalling via the BeNOW XML api.
• Tight security via the BeNOW security api

FEATURES
Uses XSL formatting. XML representation of request objects is converted to HTML via XSL. Includes the ability to 'get back to java', access query params, session info, user and rendering options from the XSL pages, as well as to output different presentation, such as text, pdf, svg, etc. Overall site templates allows for themes and internationalization. Many XSL libraries have been built to facilitate page creation and reduce presentation bugs.

Themes and Internationalization Presentation themes and internationalization are supported within the framework, allowing for presentation as intended for individual visitors.

Built to be dynamic. The pages delivered can be designed and tweaked within the framework itself... ie dynamic pages (XSL) can be edited directly in a browser, although traditional ide editing is also supported. Page creation is facilitated by easy inspection of the XML which makes up the request(s) within a page.

Menu management. Pages, urls, wiki sheets or javascript can be added as items or subitems within the site menu. The menu is editable (move up, down, remove, edit, etc) from the browser by an administrator. The menu entries themselves may have permissions assigned so as to only be shown to certain users, etc.

Integrated help. Context sensitive help for pages. Page and topic linking into wiki based help pages, so users can figure it out for themselves (whatever _it_ is).

Security management. User, role and permission management pages which allow for fine grained permissions throughout. Permissions are carried through to the XSL, of course, so sections of pages are only shown to select users, etc. Permissions can be altered for anonymous guests, and defaults set for new users, etc. User validation process is in place, with email user activation and captcha validation.

Easy object based handling of posts. HTTP form posts are automatically converted to service requests, allowing code to easily be invoked from a form (with appropriate security measures, of course). No need to manually assemble form submissions in order to do something, just have it done.

Straight up java processing. The processing of the input is performed within defined services. The services have access to the repository api for easy database queries, integrated security, and may use any java based apis (of course). Once processing within a service, there should be no need to touch the HTTP or servlet level code, but it is there if you really need it. The results of service calls are converted to become input for the next page (if appropriate).

Automatic web service exposure. The web page rendering process calls the service api to do the actual processing (storing a topic submission, getting users, etc). The service api also exposes itself for access to other clients. Other clients may directly use http post requests to request operations and provide input or may use the java client, which provides a direct interface to the remote service. Security is enforced at the service and method level. The same user and permissions defined for the web application apply to service invocation, so there's only on place to maintain. As the service invocation can be done with a simple form submission and replies with xml, it is very easy to work with in AJAX situations. In fact, the entire service structure is addressable from javascript. Calling services from javascript is as easy and as similar as calling them from Java itself.

Modular. Modularity is used thoughout, allowing for the easy development of web modules which contain all functionality and presentation for descrete tasks. Deploying modules within a fledgling application is trivially simple, which is great for assembling often used bits of code together in a cohesive application. Modularity is carried though to the security api, allowing for custom modules to have information associated with the current user. All often used module functionality is moved into the web framework so as to require very little overhead in designing new modules.

Built in validation and error handling. Page recording and testing is built into the framework. When page recording is enabled, pages can be browsed and the results (as they would appear to a visitor) recorded. The test results can be checked for correctness and stamped as good. The tests can then automatically be re-run to ensure that all pages are functioning correctly and that no problems have crept in. This allows for ongoing site development, so that you don't have to slow down and ensure everything is correct as the codebase changes. (You should, of course, think of implications, but this covers your butt if you miss any). If errors do occur during the processing (java), page assembly (xsl) or client processing (javscript via a quiet ajax callback) stage(s) the errors are caught and handled by an error handler. There are error handlers to log, report via email or add as a bug to the appropriate project within the project management web module. Not only is it easy for you to find bugs, but users find bugs for you as they browse the site... basically, only high level intent and design bugs won't easily be caught, and those types of bugs can be resolved through facilitated redesign.

Easy to develop and maintain. It was built by a coder for coders, with an eye to users. If the users see crap, it's the developers/designer fault, so it must be good for them

Easy debugging. Self managed servlet engine (via jetty) means that it starts up like a normal application and can be run within a debugger (within eclipse, stopping at breakpoints, lookups from stack traces, reloading classes on source modification, etc). A nifty trick kills existing instances, so application restart (aka redeployment or turnaround) time is very short (ie ~15s on this box), allowing for quick development-test cycles.

Easy deployment. Once solid code has been cut, the application can easily be deployed for visitors. The application is self contained, meaning that all required libraries and support files are included in a familiar directory structure. The application can be run on its own (as root binding to port 80), as a user on a high port (possibly bound to localhost and possibly surfaced via an existing apache instance via mod_rewrite, ajp, etc) or can be run in an existing servlet engine (websphere, etc).

All in one place. Extensive use of annotations and other tricks provide in class tailoring of the different aspects of the various systems. For example, the security exposure (to exec this method must have permission), sql table refinement (this string field is 256 characters long), XML rendering specifics (this field is an attribute) and other class-subsystem related interactions are within the class itself, so there is only one thing to maintain. This really reduces the mental overhead of having to search to find the place to change.

No mapping. You'll not have to write a single line of code to create databases, create tables or otherwise interact with the database (automatic schema generation, resultset to object population, query facilitation, etc as provided by the repository api), or code to generate appropriate XML from objects (as provided by the XML api). All system translation mapping is generated at runtime via reflection, directly from the running code.

Code generation (in progress). There is code generation when appropriate. For example, when a designer hits a page that doesn't exist the xsl page can be automatically created, when a designer attempts to invoke a non-existing service method a prompt is given and the service method java declaration is created. There is even (basic) support for template generation. Service interaction xsl code can be generated for classes... XSL to produce a form to create an object, a table to display an object, a form to edit an object or tables to show multiple objects can be created according what is being worked with. The generated code can then be modified to fit your exact tastes and requirements.

RSS and subscription support (in progress). Generation of RSS feeds from services is facilitated and provides pull subscription. API for push subscription to notifications is provided to modules, allowing the user to subscribe to events (changes, additions, etc) occuring on content. Subscriptions and methods can be managed centrally (i.e. notify by email, click to unsubscribe from project change notification and forum post notification).

If your still reading this, great! There's alot to describe in the web framework.

MODULES
There are several modules which have been designed for use with the web framework, in addition to the design, security and subscription modules mentioned above:
- basic wiki. Pages and portions of pages can be edited within web pages, which is great for changing content and for content maintenance by those without application system level knowledge, ie contributors.
- forum. (in web-extras) Forums around a certain subject with topics relating to the subject. Topics may commented upon, managed, etc.
- project management. (in project) Module to manage projects, modules within projects, bugs, feature requests and project exposure (you're looking at it - it's what this project page is provided by).
- basic inventory management (in progress). (in web-extras) Products within classifications with inventory tracking.
- basic shopping cart and checkout (in progress). (in web-extras) Add products to shopping cart, modify cart and checkout via payment processor (currently ebay).

USE IT!
Specific installation and use instructions are included in the download (if you're lucky), as is javadoc documentation.

So, as you can see, there's alot to this sucker. If you wish to try it out, go ahead. I've done this work so you don't have to. It's licensed as GPL, so code away but feed your improvements back into the project. Your code built to work with the API is yours, of course, however if you think the project would benefit from your code, I welcome submissions. I would appreciate any feedback and fixes. Any feature requests will be given priority if they coincide with my plans, others can be tackled if small or made note of, at the very least. Contact me if you would like to financially support custom extension. If you're happy and you know it, I'd also be happy for any donations. I'm also available for support (free, within reason), so email me.