Post date: Nov 10, 2011 1:07:57 AM
(FC, PB/V) Fixed a bug that prevented rendering of a raster node as a histogram.
(FC, PB/S) The format of the binary dataset source file has changed significantly. The new format supports random-access retrieval as well as faster performance when adding and removing datasets, even if the file contains many sets. Unlike the previous binary format, the file is modified in place and does not require a full rewrite. This really speeds up the process of making changes to a file that contains many large datasets; the disadvantage is that an IO failure could corrupt the file. DataNav can still open files in the older binary format, but any newly created files will be in the new format. Both versions of the binary dataset source file will show up in the Workspace Browser.
The Matlab utility function putdatanavsrc() was updated. The flag argument append is now called replace. If the destination file already contains a dataset as specified by the id argument, the function fails unless this flag is set, in which case the new dataset replaces the old one.
New Matlab utility function, datanavhub(), was introduced to automate the construction of the data repository for a hub in the user's local workspace portal. By using datanavhub() in a Matlab script, authors can quickly construct (or reconstruct!) a hub's data repository, or push new data into an existing hub as it is collected. Other aspects of defining a portal hub, such a creating navigational views or setting attributes, must still be done manually within the Portal Builder application.
(PB/S) Significant structural changes to a DataNav portal's backing store: (1) Redesigned hub dataset repository (a single, growable repository file instead of multiple fixed-capacity files). (2) The portal now maintains a simple list of independent hubs rather than a "hub tree". (3) Hubs may be marked as "publication-ready" or not (applicable to hubs on a portal server, not those within the user's local workspace portal). In the future, the portal's public mirror will have two HTTP anonymous access points, one that is intended for general public use and exposes only "publication-ready" hubs, and one that is intended for internal use and provides read-only access to all hubs stored on the public mirror, "publication-ready" or not.(PB) Significant redesign of the Portal Builder GUI. The left-hand side of the splitter pane has been completely reworked to reflect the fact that a portal contains a list of hubs rather than a tree. Near the top is a "hub table" listing all hubs in the local workspace portal, followed by all hubs in the remote portal to which the user is connected. For remote hubs, the table cell in the first column reflects the state of the hub's "publication-ready" flag. If the hub is marked as publication-ready, a check mark appears in that cell; else it is blank. Click on the cell to toggle the flag. New toolbar buttons above the table let the user open/close the local portal and log into/log out of a remote portal. Login is faster and more intuitive -- pressing the login button raises a modal dialog with the keyboard focus on the password field. Assuming you've logged into the remote portal previously, all you have to do is enter your password to login. Below the hub table are remote portal-related widgets for managing the authorized users list, synchronizing the portal's public mirror with the current contents of its private mirror, and so on. The right-hand side of the splitter pane is the complex Hub Editor component, which is now always visible and always reflects the contents of the hub (local or remote) selected on the left-hand side. If no hub is selected, the Hub Editor will be empty.
Warning: Existing portal content lost!
Since Portal Builder and the Portal Server application are still very much in early development, we decided not to support migrating existing content to the new backing store infrastructure introduced in this version. When you first run Portal Builder v3.3.0, any existing content in your local workspace portal will be removed and a brand-new, empty portal created in its place. Similarly, the contents of a portal managed by the Portal Server enterprise app be lost when version 3.3 of the Portal Server is installed and launched.