WebBee is a framework providing building blocks for rapid Java application development for both web and desktop applications including mobile ones. One of main goal of WebBee is reducing learning curve of another product and pretty much stay with basic knowledge of Java, SQL, HTML, JavaScript, CSS and general common software development practices. So WebBee offers very limited additional APIs, scripting languages, and configuration files to learn. WebBee conceptually utilizes just few application design patterns and make a developer to think in the patterns. WebBee also stays on decoupling business and presentation layers giving very flexible ways of connections.. WebBee doesn’t dictate a specific way of creation of an application; it gives much freedom of selecting desired approaches, using 3rd party libraries and etc. It isn’t also overloaded with 3rd party libraries and just defines ways of integration and a use them. WebBee differentiator from other frameworks is giving common building blocks which can be easily customized to fit in a shape of a developed application. However a developer is still free to create own building blocks or work on base level without utilizing building block concepts. It is like using Lego blocks however with possibility to put custom elements making final application look as custom developed.
WebBee is a collection of several frameworks and ready to use solutions build on them. WebBee is SOA friendly and generally encourage of using SOA for applications. WebBee is offering multipurpose container, registry, JDO services, servlet framework with MVC and front controller, template engine, resource manager, object pool, cache and some other utilities and services. . It provides extremely light weight Ajax framework with server push capabilities in addition, however doesn’t limit to use any 3rd party Ajax wramework. WebBee doesn’t replace any EJB container and actually targets POJO. WebBee doesn’t dictate any patterns for adding and initializing services like inversion of control. WebBee stays on reducing amount configuration files and utilizing declarative programming based on Java annotations. WebBee is transparent to use any container based services. When WebBee is combined with TJWS web container, Java recompilation and restart of application so fast, that config based approach of customization can hardly compete with code changes and apply.
WebBee itself is wrapped as ready to use web application. It requires only one simple table created on backend. The table has to have three columns id, username and password. Id can be defined as auto increment column.
insert into users (login,id,password) values ('username',3,'password')
A data source to this table has to be configured with name ‘jdbc/mysql/webbee-app’ in application server. There is no restriction to use MySQL database server, and name of data source can be changed accordingly application server requirements as context parameter with name model_datasource in web.xml
Please use the link
Every development platform specifies own rules of development applications. Webbee isn’t an exception. So this guide covers major steps required for successful and rapid building of web applications. Webbee building blocks are based on Aldan 3 framework. So application development looks very similar. Every application is built on Front Controller and MVC design patterns. Although all views may have separate models, application itself has to define master application data model. Models staying behind of particular views are defined as Java objects with JDO annotations. So development process itself has very good natural separation of views, models and controllers. It helps in collaborative work on application, when every developer can work on own part without interfering with others.
WebBee recommends certain code source and deployment organizations. Actually every modern development platform dictates certain project file organization, like Android or iOS/XCODE. The following directory structure is recommended for WebBee projects
Project home
WebBee uses standard war/ear deployment structure with possibility of detaching not protected resources as static HTML, CSS, images and scripts and serviced by different server for better scalability.
war context name contains HTML on first level
Webbee requires just few elements in web.xml
The file has format of standard java properties file. Application model or just base block gives access to the property file, so entire application can read or modify the file. However modifications are not persistent. Name of config file usually matching application context name. The file location is specified as application servelt parameter properties. Read more information about content of the file below.
7Bee building tool and corresponding scripts supplied with WebBee can be used for population initial directory structures and follow build abilities. Scripts have to be modified to cover any application specific resources all 3rd parties libraries.
Any Webbee based application h as to provide own implementation of application model class extending com.beegman.webbee.model.AppModel. The implementation class has to be also specified in web.xml as listener, see above. The following methods should be overridden for purpose:
User locale is always available in page services, and all resource loading get verified against current user locale. So all application text constants have to be stored in resource files for easier localization if applied.
There are several standard resource files which suppose to be supplied for normal app functioning.
View resources are templates, JSP or other renderer type resources. WebBee encourages using only template based view resources.
All resources related to a particular page service have to carry page service name with corresponding to resource type extension. Text resources have extension .properties. View related resources have extension helping to pick correct view renderer approach. Since base WebBee view renderer is template engine, template resource extension can be configured. Parameter viewext in application properties file.
Webbee softly dictate certain UI layout based on common practice of creation web application UI. So entire screen consists of the following areas
Standard UI layout is defined in canvas template. The template can be changed to provide any other layout or customize existing one.
Property name used for ordering tabs in alphabetic order. Value is comma separated values with page service name, label, and description correspondingly. Commas have to be HTML encoded. Only first value is required.
This wrapper defines general layout of application UI. If it isn’t planned to customize it, then include to Webbee standard application layout can be provided there, like
@%'canvas.htmt'@
A web push handler URL has to be specified and also requester loop started. This code can be added in initFields handler as below:
<script>
function initFields() {
handlerUrl = Status/ajax/Asyncupdate';
// run it async
updateUI();
}
</script>
<script src="@contextpath@/js/ui.js" language="Javascript"></script>
All WebBee data objects have to be inherited from SimpleCoordinator, it gives access to application model from data object and can be used for requesting additional information from common data model required for normal functionality of data object. Fields of data object have to be defined as public and JDO and form presentation annotations can be added to provide as automatic persistence of data object as automatic form rendering built of the data object.
Any user interaction with application happens through page service class. The class gives access to a page model which is rendered by view, and the class can also process control events and update corresponding model as needed. All page service classes have to be stored in the same package and name of this package has to be defined in PresentServicePackage config parameter. Such classes can be dispatched by Front Controller. Page service class must be inherited from BaseBlock or from corresponding functional block.
A view resource or some other active renderer component as JSP has to be added with corresponding page service name in corresponding to renderer type location. Normally views are stored in template resource folder which location is defined by TEMPLATEROOT configuration parameter. Controls are part of page service classes
All background processes have to be wrapped in services and instantiated and started in initServices of application model class.
A final application will require most of resources from WebBee base application, so is recommended to copy all these resources blindly. However to avoid security risk, it I s recommended to redefine as default view extension as page services package name. So if application requires some template resources from WebBee base packaging, then such resources can be renamed with required extensions, or resource delegation approach (as include) should be used. Former provide better application upgradability to next versions of WebBee.