DesignerModules

Designer Modules

This document describes status of the designer modules and goals for the future.

Current Status

Currently the designer modules are under refactoring, which goal is to devide the functionality the way so it could be better developed and also reused in the future. See the picture No 1, currently it consist of:

  • Designer this is actual designer module, which (tries) to implement the CSS Box modeling (CSS 2.1).
  • Issues: The implementation is not full, and is also buggy. Also it was implemented purely for the JSF, i.e. with JSF specifics, currently represented by dependency on Designtime API module (in the past also on Insync, Project, Braveheart, Woodstock etc. modules).
  • Designer/CSSEngine and Apache Batik Modified these modules provide css support for the provided markup document (DOM).
  • Issues: This engine doesn't provide specified CSS values, but directly computed values, which in turn depend on actual layout of the box model in the Designer, thus requiring callbacks and also spreading the layout functionality outside the Designer module. Also, big problem is that the Batik code is heavily modified comparing to the original.
  • Designer/Markup and Apache Xerces these modules provide implementation of DOM which is possible to use in the Designer/CSSEngine module.
  • Issues: It is in fact a problem there is required a subclass of regular DOM impl, due to usage of the Batik for retrieval of CSS values.
  • Designer HTML Tags small library defining HTML Taga, used also by other modules.
  • Designtime API this module represents API for the component authors, currently JSF specifics,
  • Issues: Designer module shouldn't use it because it shouldn't be JSF specific, and also doesn't need to be in order to provide the CSS box modeling.
  • Designer Hack API module created in order to provide some API from designer module, and also by pass otherwise created cyclic dependencies
  • Issues: There shouldn't be such an architecture hitting cyclic dependencies, We need to get rid of this hacking module completely.
  • Designer/JSF module which should be a client of the Designer module, which would provide a nice API in order to provide rendering of CSS Box model and also user interaction with it.
  • Issues: Currently it contains stuff, which used to be directly in the desgner, and didn't have to do anything with the CSS Box modeling, but rather with JSF processing etc.

Image:designer1_DesignerModules.gif
Picture No 1 Current designer modules and their main dependencies.

Future Goals

This describes vaguely the future desired state of designer and its interaction with the other modules. Future goal of designer module and interaction with the others. See the picture No 2.

  • CSSEngine module which will provide CSS specified values for provided elements
  • Designer module which will provide the layout and rendering of the DOM with CSS information according CSS Box Model and also provide a feedback of user interaction with it.
  • HTML, JSF, <Some Module> etc. are client modules of the Designer which use its capability of the layout and rendering of the provided DOM structure with CSS information accoring the CSS Box Model. Also listen on user interaction. It will be up to these client models to control the changes in the provided DOM's based on the user interaction.

Image:designer2_DesignerModules.gif
Picture No 2 Future goal of Designer module

Next Tasks

  • Factoring out dependency on Designtime API module from Designer module.
  • Factoring out Designer Hack API module.
  • Provide nice/stable API of the Designer module.
  • Provide better implementation of CSSEngine in order to avoid computing CSS values on the fly but rather passing specified values.
  • Provide better implementation of the CSS Box Model in the Designer module.
Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo