WebBuilder2

[ AdvancedSearch | AreaMap ]

The WebBuilder2 is by far not finished. This is especially the case since the WebBuilder2 was first developed for internal purposes and we obviously dont have the ressources to make the necessary adjustments in one go. Instead we are commited to making the necessary changes step by step. Hopefully other people will be able to quickly realize enough benefits in the WebBuilder2 so that it becomes useful for them to help as along the way.

The WebBuilder2 framework was mainly developed to give a maximum of flexibility when developing intranet applications. This means that performance hasn´t been the main focus. Also elaborate caching or search features have also not been a focus. However given every module a flexible basis to work of has very much been a focus. Flexible handling of parameters and output formats has seen alot of attention as well as we often had to have the same modules callable via a browser and via a crontab as well as having to output not only HTML but pdf, excel sheets or even word documents.

So where are we at?

the good

We do think that we did a good job in these areas. I think we managed to do a nice FrontController implementation. We also think the way we have defined our ApplicationModules interface makes sense. We also think that having our ApplicationTemplates be plain PhP code makes sense. We also think that the way we handle parameters makes sense. This enables us to do nice stuff like UrlRewriting transparently. It also enables us to accept parameters not only via the Get, Post etc but also via the shell or email (or any other way you can think of). This means you can write a single module that is callable from any source. Our OutputWriter in turn makes it possible to easily output to any format you can think of as the final output: html, pdf, xml and even emails.

the bad

The core components are written quite cleanly. Some of the modules experienced fairly rapid growth, a euphimism for hacky appearence. But overall the code we released does follow a common CS (except of course for any third party code which of course follows its own CS). We do realize though that CS is a touchy subject. We also realize that since we make heavy use of PEAR we probably have the best chances of getting other PEAR developers on board. As such we are about to adopt the PEAR CS with the minor difference of going with tabs instead of spaces. So there is hope. SOLVED

We also think we need to better provide ways to prevent XSS hacking by providing an object interface to the parameters. We also think we need to provide a few helper methods to better output php variables in the ApplicationTemplates. SOLVED

A few adjustments to the DirectoryTree and class names should also be made in order to provide a clear "_" to "/" mapping of class names to directory location (with the exception of third party code of course which resides in the library directory).

Finally we need to make it more transparent what the given code can do, what kind of config options it supports and what kind of structures/data it passed to the templates. Here we might need to cut down the flexibility in some areas maybe to ensure that things are registered in central locations a bit more. SOLVED

This site powered by YaWiki 0.22 beta.