WaveMaker Studio 4.0 Release Notes ----------------------------------- This release addresses some 400 issues that have been reported against the 3.2, Alpha and Beta versions. This includes defects, improvement requests and issues logged by customers, community users, beta testers and development. Due to the overwhelming size of the fixed issue list, it is not being included with the release. If you have a concern about a specific issue or defect, please post your question to the developer forums at dev.wavemaker.com/forums. These notes document the fixes, issues, and workarounds that we think are most important for you to be aware of. WaveMaker extends its thanks and appreciation to the many users who contributed to the testing and overall improvement of this release. ------------------- NEW FEATURES ------------------- WaveMaker 4.0 contains a number of new features that are documented in the WaveMaker Tutorial and User Guide. These release notes mention only features that are not yet documented there. --- Custom CSS Classes --- There is a new "Application CSS" section on the source editor, classes pasted in there can be referenced by classname in the styles section of the property inspector for any given element. ------------------- KNOWN ISSUES ------------------- --- IE6 Issue and Workaround --- Users of IE6 must disable the compression option in the installation Tomcat in order to avoid severe performance penalties. The /tomcat/conf/server.xml, on line 83, contains an attribute tag that reads ‘compression="on"’; to disable compression, this option should be changed to read ‘compression="off”’. --- Binding to Project-level Objects --- In the 4.0 release, it's not possible to make bindings to project level objects, including Variables, LiveVariables, ServiceVariables, and NavigationCalls. We will be addressing this issue in the next point release. Until that time, it's recommended that users avoid these bindings or create them via Javascript code, if they are absolutely necessary. --- LiveForm Known Issues and Limitations --- LiveForm replaces AutoForm. LiveForm generates editors for each of the fields in its data set. If the data set is based on a LiveView or LiveTable (via a LiveVariable or selected item in grid) then LiveForm automatically generates database CRUD functionality. There are a number of issues and limitations. 1. LiveForms based on LiveTables: There is a known issue when a liveTable is used as the liveSource: a default view is created which contains all top level properties in the data type. However this currently does NOT include composite key fields, since these currently appear to the client as a structured related object. It’s safest to base LiveForms on LiveViews. 2. LiveForms based on LiveViews: When you create a LiveView in the LiveView editor, required fields are marked with a red *. Required fields are needed for some CRUD operations. If you don’t include all the fields that are marked required then a LiveForm based on this LiveView will not have all the editors necessary for CRUD and it will generate errors when performing CRUD operations. 3. When a view contains related objects, a LiveForm creates a special editor called a RelatedEditor for the related object. This RelatedEditor is a hybrid between an editor and a form. There is a limitation for the case where relatedEditors are nested. When relatedEditors are nested, their editingModes depend on each other. In order for a child relatedEditor to be editable or lookup, its parent relatedEditor must be editable. When a parent's editingMode it changed, its children are updated to acceptable settings. When a child is changed to an unacceptable setting the change is disallowed and you receive a message about the form settings. --- Java Services --- Currently, if your project has more than one Java service, it fails. The workaround is as follows. For every Java service that you have defined, do the following 1. Go into the services directory (MYPROJECT/services/MYSERVICE) 2. Edit the file: designtime/servicedef.xml, and add a springFile="MYSERVICE.spring.xml" entry to the service def line if it doesn't already exist. It should look like this 3. save and quit. 4. Edit src/MYSERVICE.spring.xml. If it already exists, quit and continue to the next Java service. If the file is empty, paste in contents like this (replacing MYSERVICE with that service's id and SomeClass with the appropriate class): --- Deploying to non-Tomcat Containers --- Before you deploy to a non-Tomcat container, you should edit the log4j.properties file (in your project's src directory) and remove the references to the wmlog appender. If the top lines look like this: log4j.rootLogger=warn, stdout, wmlog log4j.appender.stdout=org.apache.log4j.ConsoleAppender log4j.appender.stdout.layout=org.apache.log4j.PatternLayout log4j.appender.stdout.layout.ConversionPattern=%d %p [%c] - <%m> (%x) %n # default catalina.home; when the System property isn't set, this will be # used catalina.home=. log4j.appender.wmlog=org.apache.log4j.RollingFileAppender log4j.appender.wmlog.File=${catalina.home}/logs/wm.log log4j.appender.wmlog.MaxFileSize=10MB log4j.appender.wmlog.MaxBackupIndex=10 log4j.appender.wmlog.layout=org.apache.log4j.PatternLayout log4j.appender.wmlog.layout.ConversionPattern=%d %p [%c] - <%m> (%x) %n removing the wmlog references (and the catalina.home reference as well): log4j.rootLogger=warn, stdout log4j.appender.stdout=org.apache.log4j.ConsoleAppender log4j.appender.stdout.layout=org.apache.log4j.PatternLayout log4j.appender.stdout.layout.ConversionPattern=%d %p [%c] - <%m> (%x) %n --- Column Aliases in Query Code --- In HQL, each object (table row) that is involved in a query is generally given an alias. These aliases must use a lowercase first letter. ------------------- NOTES ------------------- To revert to 3.x styling: 1) rename webapproot/lib/wm/base/widget/theme/theme.css to theme4.css 2) rename webapproot/lib/wm/base/widget/theme/theme_3x.css to theme.css 3) refresh browser