Notes from meeting with VWP team

Disclaimer: These are just notes from a meeting, all dates and plans are subject to change and should not be taken as a commitment.



The proposed plan is to have VWP code base in NetBeans repository around Jan 10 buildable on 5.5 based branch (modified from 5.5, see bellow). Staging in c/s repository could be done by Dec 22. This will exclude the CSS editor, the page flow and the query builder. These three components will be moved to NetBeans separately and will be moved to other clusters (css and query builder to IDE cluster, page flow to enterprise cluster).

5.5 code base will be originally used to build VWP until there is basic integration with the new Java infrastructure. Since the module names of VWP will change during opensourcing there will be changes to 5.5 code base. Specifically, NetBeans modules which expose friend API to VWP modules will need change the friend module names in project.xml.

The plan is to switch to building on top of NetBeans 6.0 code base in Milestone 7. Main part of insync should be converted to retouche. Designer and component palette should be inluded. It should be possible to create a visual web project, create a page, drag'n'drop components to it and run the application. Refactoring will not work, changing properties of components in visual designer will not work, other features may not work.

Since some parts of the code will move between the development teams (e.g. CSS) and some other parts will be used more generally then in the scope of VWP (e.g. query builder) there was a question about QA ownership. Needs to be solved offline.


VWP modules will be developed using a module suite and will be built against a binary distribution of NetBeans.

  • Need to review location of modules in nb repository (Pavel). We want to avoid placing modules in one location (by default visualweb top level module) and moving them later. Location in cvs does not make it impossible to move modules between clusters, but it means developers will need to check out more sources (if they use module suite they only need sources for their modules, but c/o is specified at the level of top-level cvs modules).
  • Need to investigate extension/* modules (Pavel, PeterZ). These modules contains extensions to NetBeans code and they should not be needed in the long run. The content should be either added to the NetBeans module or dropped.

Page Flow

  • (Joelle) Need to rewrite to the new version of graphlib
  • (Joelle) Need to rewrite to JSF config API, the config API will be integrated into insync and insync will not be accessing the JSF config files directly.
  • (PetrP) The JSF config API needs to be made public or friend, should be moved into a separate module from the rest of JSF (CRUD generator should also be separated from JSF framework implementation)

Services Navigator

  • Service navigator will provide UI for EJBs, web services, databases and/or data sources consumed by user's application.
  • The UI should be common for mattise data binding, possibly mobility, etc. (mattise databinding now uses Runtime tab like VWP 5.5)
  • This UI covers different use cases then Server navigator which is for j2ee servers, db drivers, etc.
  • Not clear if it should contain DB nodes, data sources or both.
  • Seems to be concensus that palette would not server very well for this purpose. Palette is not a tree view and does not support the use case that the user can browse and test these services before using them.
  • Winston plans to write a proposal.

Query Editor

  • Get rid of the forked implementation of JDBC rowset. This implementation lives in com.sun.rave package and is not distributed with every VWP application. We first need to investigate if there are in fact any issues with the rowset in RI, this should be done ASAP.
  • Migrate the UI to graphlib. Similar migration has been done for page flow. This should happen before moving to O/S so we do not have to depend on jgraph.
  • Split the visual editor part from the SQL text editor. The text editor will be merged with the current NetBeans SQL editor.
  • Jim plans to write a proposal.

Java Persistence API

  • Can we target JPA in 6.0? Table component can work with java.util.List, but a lot of other things will probably need to happen. Editing of data bindings will not work, for example, the JPA code needs to be generated for access to EntityManager, etc.

Error Handler

The error handler consists of a servlet that is registered and deployed as part of the user's application and a client that lives in IDE, they communicate via socket. The servlet wraps stack traces for exceptions on app server and creates hyperlinks. When the user clicks on a line in stact trace the servlet calls the client and a source file corresponding to that line is open in IDE.

  • This should be part of enterprise (web) cluster and should work for any web app
  • The code should not be packaged into user's war file. I proposed that we may be able to use the same approach as http monitor - to deploy the server part of error handler to the development server. Perhaps the error handler should be merged into the http monitor module completely.

Web Project

  • There is a concensus that we want to decouple the visual designer from the web project. This means that the special project implementation used in VWP 5.5 should be changed to use a web frameworks API in 6.0. In future it would be possible to support the visual designer is freeform project, but it's not a goal for 6.0.
  • VW framework will be added either explicitly or as a result of using a visual JSF template.

Component Authoring Project

A target feature for 6.0 is support component development. This will require a special project type, it should be possible to add it as a library to web project to test the components. Details TBD (Edwin).

Portlet Development

There is a support for portlet development in a non visual way which deals with deployment, etc. distributed with the portal server (as a set of NBMs). The visual development provided by VWP should be integrated with it and extend it similarly as the JSF visual editor should extend the web development (share the same project, etc.).

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