VWProjects

Visual Web Project in NetBeans 6.0

In NetBeans 6.0 VW projects infrastructure should share as much as possible with the NetBeans JSF project infrastructure (implemented via frameworks API).

Contents


Configuration

One difference betweem VWP and NetBeans 5.5 is in the JSF config files. Creator and VWP in 5.5 uses separate files for navigation and managed beans. In 6.0 new projects created in NetBeans will use only one file: faces-config.xml. For the purpose of backward compatibility and for projects from imported sources we will also support the case with multiple config files.

Data Objects

There will continue to be separate data loaders for plain JSP (which supports text editing of any JSP page) and visual JSP (which can only be used for visual pages created in VW and supports visual editing). The plain JSP data object works in any web project. The visual data object only allows visual editing if there is the VWF in the project. The user can use plain JSPs in a project with VWF.

Web Project Framework

VW uses a separate project type in NetBeans 5.5. This approach was used to make the integration possible in limitted timeframe with minimal impact on NetBeans 5.5. In NetBeans 6.0 we will use web frameworks API and visual web pages will not require a separate project type. There will be a Visual JSF Web framework (VWF) which will be an extension of the JSF framework. VWF will add its own sample pages to the project, add the libraries needed for visual web development, etc.

The flow of user actions will be as follows:

  • User creates a project. They will be able to select either only JSF framework or VWF (which will select JSF also) or neither of these.
  • User goes to project properties dialog and can add the VWF into an exisitng project unless the project already contains a framework that is incompatible with VWF (such as maybe wicket or struts?). Note that the project may already contain JSF (details below).
  • User selects a "Visual JSF Page" template (we need to distinguish the visual template name clearly from the plain JSF page template since both will be visible in the same project). A few different things can happen based on what frameworks are (not) in the project:
  • If the project has VWF the page will just be created and open.
  • It the project does not contain VWF and contains a framework that is incompatible with VWF then the page cannot be created. A warning will be displayed to the user in New File wizard.
  • If the project does not have VWF but has JSF framework then VWF will be added (not that VWF needs to know how to add itself into a prj with existing JSF support). Then the page will be created and open.
  • If the project does has neither VWF nor JSF framework then VWF will be added, inluding the basic JSF setup (not that VWF needs to know how to add itself into a prj with OUT existing JSF support). Then the page will be created and open.

Note: in 5.5 for the most part if the user chooses a template and it's framework is not in the project the template refuses to instantiate itself. The exception is JSF from entity classes which will just add JSF framework silently. The above approach should be used for all templates provided by frameworks.

We need to add several features to frameworks API:

  • Ability to say that a framework A is incompatible w/framework B
  • Ability to say that a framework A requires framework B.
  • It would be desirable if the framework was able to add it prefered templates.

If framework A requires framework B then B will be automatically selected (and disabled, so the user cannot unselect it) in project wizard and the frameworks tab in project properties dialog when the user selects A. When the frameworks API instantiates the frameworks it will NOT call framework B to add itself into project, it will only call project A. Project A will thus have full control - it can choose either to call initialization of framework B as the framework API would call it or it can have a special contract with project B and call this contract or it can do all work by itself. (Here A is visual web framework, B is vanilla JSF framework in NetBeans). This is mainly to optimize what will be created when the user selects A, for example we probably do not want the sample pages of B to be instantiated, only those of A, etc. Similarly, project A should define the preferred templates, but not project B. It is project A's responsibility to add any of the preferred templates of B if it so chooses (think visual JSF project wanting to add visual page template but probably not a non visual JSF template).

Project View

Unlike VW project in 5.5, the standard NetBeans JSF framework does not provide the additional nodes for page flow and various types of managed beans.

We want to make the page flow editor to work for both visual web apps and plain JSF apps. In NetBeans 6.0 the Page Navigation node will be show in any web module with JSF support.

The Theme node, Component Libraries node, and Data Source References node will be visible only if the visual web framework is present in the project.

The managed beans nodes will not for the NetBeans 6 feature. The proposed view will be; All managed bean nodes will be organized under one node:

  • Managed Beans
  • Request Scope
  • Page1
  • Page2
  • RequestBean1
  • OtherBean2
  • Session Scope
  • SessionBean1
  • Application Scope
  • ApplciationBean1
  • No Scope
  • ...

The nodes for request, session and application beans are important artefacts in visual web application but do not have a special value for developers using plaing JSF framework. Therefore, they will be visible only if the visual web framework is present in the project.

Creator 2 / Visual Web Pack Project Migration

For project migration, when a Creator 2 or Creator 2 Update 1 project is opened in NetBeans 6, NetBeans 6 will no longer display a warning as in Visual Web Pack 5.5. This is because in NetBeans 6, Visual Web will fully support all functions in Creator 2 while Visual Web Pack 5.5 is not. Once the project is opened to NetBeans 6, it may not be backward compatible in the old Creator 2 or 2 Update 1 IDE environment anymore. Same behavior is for opening Visual Web Pack 5.5 projects.

Description / Use Case

  • Import Creator 2004Q2 Project
  • It is not a supported feature! User needs to first use Creator 2 to import 2004Q2 project and convert it into Creator 2 project.
  • Import Creator 2 or Creator 2 Update 1 Project
  • without Visual Web Pack installed:
  NetBeans 6 will open the project without the visual editor support. The JSP page will be opened by the standard NetBeans pure text JSP editor instead of Visual Web visual editor.
  • with Visual Web Pack installed:
  NetBeans 6 will detect this and show Visual Web Framework existence in the NetBeans web project. Visual Web Framework will then support the visual editor for the JSP/Java paired JSF pages.
  Issues: After project has been opened, user needs to manually resolve the following unresolved references, see Issues for more details.

Backward Compatible

  • It is a requirement to support one way import of projects from Creator 2 into NetBeans 6. Moving projects back and forth or sharing the same project between NetBeans 6 and Creator 2 is not supported.
  • After the Creator 2 project has been opened by NetBeans 6, the contents will be automatically updated to NetBeans 6 project. It is still openable by Creator 2 or 2 Update 1 if no any new item or reference been added. But this action is not supported.
  • Since the project type does not change from Creator 2 to NetBeans 6, use Creator 2 or Creator 2 Update 1 IDE to open NetBeans 6 project is possible. If the project does not contain new NetBeans 6 components nor services, then there may be no major issue to continue working on the project. Otherwise, it will not work and this is not a supported feature. See Project Type for more design details.

Issues

After Creator 2 project has been opened, user needs to manually resolve the following unresolved references. Automatically modify the project configure files to migrate to the NetBeans 6 references is not always possible nor suitable.

  • Server:
  • Symptom: A dialog shows "One or more projects do not have the target server set properly. Right-click the project in the Project window and choose Resolve Missing Server Problem to set the target server.
  • Manually Resolved: Right-click the project in the Project window and choose Resolve Missing Server Problem.
  • Comments: We agree to let users manually resolve the servers is the best solution. the same strategy for Visual Web Pack 5.5

NetBeans API Extension

  • 72441: API for inserting nodes into project ui


  • 73197: ProjectClassPathExtender should allow more parameters for adding libraries
  • 73198: WebProjectClassPathExtender should handle different kinds of libraries
  • 75471: Review of a new API for adding/removing entries from project classpaths
  • 100114: Libraries modifier - enhancement required by visual web framework
  • For the Web project framework development, the developers need 3 kinds of classpath qualifiers:
  • ClassPath.DESIGN: Used for the IDE itself. To avoid showing the contents in the code-completion and does not allow users' codes to use it.
  • ClassPath.COMPILE: Used for the editor's code-completion, compiler's classpath, ...
  • ClassPath.EXECUTE: Used for applications' runtime libraries. I.e., 'Packaging' for the Web project that this kind of libraries will go into the WAR file.


  • 55371: Public API to manage library instances


  • 73352: WebProjectUtilities.createProject should have API for handling the Welcome page
  • WebProjectUtilities.createProject should not create any page by default, but supply API to create the Welcome page that will only be called by the framework. The API will accept a customized name, and put the link into the web.xml file.
  • The API should also include a 'Set As Start Page' call that will update the web.xml to link the Welcome page to the framework's customized page.


  • 73616: Project developers need these UI APIs
  • 57073: API for retrieving recent projects is needed
  • When adding a new item, IDE should highlight the new added item in the Projects window. API needed: org.netbeans.modules.project.ui.ProjectTab.findDefault(ProjectTab.ID_LOGICAL).selectNodeAsync(newFileObject)
  • To get the default project location. API needed: org.netbeans.modules.project.ui.OpenProjectListSettings.getInstance().getProjectsFolder()
  • To Set/Check/Update the Recent Opened Project list. API needed: org.netbeans.modules.project.ui.OpenProjectList.{addPropertyChangeListener,isRecentProjectsEmpty,getRecentProjects,open,setMainProject,PROPERTY_RECENT_PROJECTS}
  • After opened a recent project, IDE should select the just opened project node, open the Logical view and make it active. API needed: org.netbeans.modules.project.ui.ProjectTab.findDefault(ProjectTab.ID_LOGICAL).{getExplorerManager,open,requestActive}


  • 73717: API request for Project Properties Set/Get/ChangeListener
  • It turns out that VWP should not use 'Project Properties' to store these Creator/VWP specific 'states'. VWP should use AuxilaryConfiguration lookup instead. The reason to not use Properties is, the Properties are mainly used by the Ant build and it's unsafe to allow public access for set and get. For migrating Creator 2 project, VWP may still needs API to retrieve 'Project Properties' from the old project.
  • For the ChangeListener, VWP needs it to change the 'Start Page' indicator of the Web Page icon. Idealy NetBeans should implement addPropertyChangeListener and removePropertyChangeListener for AuxilaryConfiguration. We may want to request another API issue for this. Meanwhile it's easy to wrap the calls and implement Creator's own listener.


  • 73352: WebProjectUtilities.createProject should have API for handling the Welcome page
  • WebProjectUtilities.createProject should not create any page by default, but supply API to create the Welcome page that will only be called by the framework. The API will accept a customized name, and put the link into the web.xml file.
  • The API should also include a 'Set As Start Page' call that will update the web.xml to link the Welcome page to the framework's customized page. (Done in Visual Web itself; no need for this function)


  • 75950: API for creating projects should be a public API
  • The general requirement is to allow an external module to create web projects programatically with some parameters to control the certain project settings (this will allow any module to create their own UI (i.e. wizard iterators) while reusing the underlying web project machinery for instantiating the project.

Useful Link

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