• DOMSGUIUnderstandingFromMjoelner

From meeting with Mjølner developers 26-02-2009

Meeting held to have questions answered regarding the DOMS GUI code.

Present: ABR (late), JRG, Lennert, Henrik

1. The choice of technologies involved.
   • Seam. Seam is the standard for web java EE development. Not a choice.
   • SDO. Only thing they found that could parse xml schemas
   • JBoss. The standard environment for Seam. You can do Seam in many environments, but no real setup is needed on the JBoss.
   • Hibernate. Not used, but part of the gui due to dependencies from Seam.
   • Richfaces. One of the nicer frontends. Icefaces should be equivalent. Apache Myfaces not studied. Chosen because one of the developers had experience with it. There exist a great community and many solutions for Richfaces.
2. Recommended technologies, for self study.
   • These are good technologies to use ourselves.
   • EJB3 could be used as well, no real information was given.
3. Running Gui in a Tomcat.
   • There should be no principal problem, if you can get Seam in a tomcat. Probably not a trivial process, but not too difficult either. No explicit ties to JBoss.
4. How Mjølner made the data model
   • By hand. This came as a surprise. Lennert revealed an interesting development pattern. When needing some container, he makes the container class. It will often just contain a list, and some accessor methods. If specific information is needed in the container, it can easily be added, and if it turns out none is needed, the container can be refactored away to reveal the list.
5. How SDO is used.
   • SDO can basically construct object trees from xml structures. When a content model is loaded, the xml schema is fed to the generate method, and a schema DOMSXmlDocument is produced. When a data object is loaded, the schema DOMSXMLDocument and the datastream xml is fed to the load method, and an instance DOMSXMLDocument is produced. This is fed to the view to generate the interface.
   • SDO should work without the schema as well. So, we could make non-schemaed datastreams appear in the gui as well. This is relevant for Readonly and perhaps importable datastreams.
6. To Mjølner: What would you have refactored, had you had the time?

   • GuiFactory is a big nasty blob. It grew with the project, and should really be restructured.

   • The GUI makes popup boxes a number of places. These are all made individually. There should be a factory method for making such boxes, to ensure common standards.
   • There is a lot of places where dropdown boxes and other stuff needs to be selected. There should be a factory for a component to remember such information.
   • Many beans are scope page. Many can be made scope request, as they hold no information that needs to be preserved. This will speed up the gui and reduce the memory footprint.
   • From ABR: A proper framework for parsing OWL, such as OWL API.

The meeting was finished before planned, as the SB team had nothing further to ask about. ABR would like Mjølner to help in the factory refactorings, if they can do it in a day. The SB team feels that they have a quite good understanding of the workings of the GUI by now.