<?xml version="1.0" encoding="UTF-8"?><!-- -*- sgml-indent-step: 2 -*- -->
<!--
The contents of this file are subject to the terms of the Common Development
and Distribution License (the License). You may not use this file except in
compliance with the License.

You can obtain a copy of the License at http://www.netbeans.org/cddl.html
or http://www.netbeans.org/cddl.txt.

When distributing Covered Code, include this CDDL Header Notice in each file
and include the License file at http://www.netbeans.org/cddl.txt.
If applicable, add the following below the CDDL Header, with the fields
enclosed by brackets [] replaced by your own identifying information:
"Portions Copyrighted [year] [name of copyright owner]"

The Original Software is NetBeans. The Initial Developer of the Original
Software is Sun Microsystems, Inc. Portions Copyright 1997-2006 Sun
Microsystems, Inc. All Rights Reserved.
-->
<?xml-stylesheet type="text/xml" href="../../../nbbuild/javadoctools/apichanges.xsl"?>
<!DOCTYPE apichanges PUBLIC "-//NetBeans//DTD API changes list 1.0//EN" "../../../nbbuild/javadoctools/apichanges.dtd">

<!--

INFO FOR PEOPLE ADDING CHANGES:

Check the DTD (apichanges.dtd) for details on the syntax. You do not
need to regenerate the HTML, as this is part of Javadoc generation; just
change the XML. Rough syntax of a change (several parts optional):

<change>
    <api name="compiler"/>
    <summary>Some brief description here, can use <b>XHTML</b></summary>
    <version major="1" minor="99"/>
    <date day="13" month="6" year="2001"/>
    <author login="jrhacker"/>
    <compatibility addition="yes"/>
    <description>
        The main description of the change here.
        Again can use full <b>XHTML</b> as needed.
    </description>
    <class package="org.openide.compiler" name="DoWhatIWantCompiler"/>
    <issue number="14309"/>
</change>

Also permitted elements: <package>, <branch>. <version> is API spec
version, recommended for all new changes. <compatibility> should say
if things were added/modified/deprecated/etc. and give all information
related to upgrading old code. List affected top-level classes and
link to issue numbers if applicable. See the DTD for more details.

Changes need not be in any particular order, they are sorted in various
ways by the stylesheet anyway.

Dates are assumed to mean "on the trunk". If you *also* make the same
change on a stabilization branch, use the <branch> tag to indicate this
and explain why the change was made on a branch in the <description>.

Please only change this file on the trunk! Rather: you can change it
on branches if you want, but these changes will be ignored; only the
trunk version of this file is important.

Deprecations do not count as incompatible, assuming that code using the
deprecated calls continues to see their documented behavior. But do
specify deprecation="yes" in <compatibility>.

This file is not a replacement for Javadoc: it is intended to list changes,
not describe the complete current behavior, for which ordinary documentation
is the proper place.

-->

<apichanges>

  <!-- First, a list of API names you may use: -->
  <apidefs>
    <!-- Probably should not be used much: -->
    <apidef name="loaders">Loaders API</apidef>
    <apidef name="editor">Loaders Editor Extensions</apidef>
    <apidef name="awt">Loaders AWT Extensions</apidef>
  </apidefs>

<!-- ACTUAL CHANGES BEGIN HERE: -->

  <changes>
     <change id="more-actionContexts">
        <api name="loaders"/>
      <summary>All standard loaders reads their data from the layer</summary>
        <version major="5" minor="8"/>
        <date day="26" month="10" year="2005"/>
        <author login="jtulach"/>
        <compatibility addition="yes" binary="compatible" semantic="compatible" />
        <description>
        <p>
            Default loaders, default XML loader and instances loader read their
            actions from <code>Loaders/content/unknown/Actions</code>, 
            <code>Loaders/text/xml/Actions</code> and <code>Loaders/application/x-nbsettings/Actions</code>.
        </p>
        </description>
        <class package="org.openide.loaders" name="DataLoaderPool" />
        <issue number="64200"/>
    </change>
    
    
    
    
      <change>
        <api name="awt"/>
        <summary>Enhanced the <code>org.openide.awt.MenuBar</code>
          to understand <code>Component</code>s.</summary>
        <version major="3" minor="2"/>
        <date day="15" month="7" year="2002"/>
        <author login="pnejedly"/>
        <compatibility addition="yes" binary="compatible" source="compatible" semantic="compatible" deprecation="no" deletion="no" modification="no"/>
        <description>
          This is not the Java API change but rather a change in treating
          of the content of the folder from which the <code>MenuBar</code>
          is built. Prevoiusly only folders were recognized and turned into
          top-level menus. Now also <code>Component</code> instances found
          in the folder are directly added to the resulting <code>MenuBar</code>
          and <code>Presenter.Toolbar</code> instances are asked for
          the presentation component and added to the <code>MenuBar</code>.
        </description>
        <class package="org.openide.awt" name="MenuBar"/>
    </change>
     <change id="DataEditorSupport.create">
        <api name="editor"/>
      <summary>A factory method to simplify creation of <code>DataEditorSupport</code></summary>
        <version major="5" minor="2"/>
        <date day="9" month="3" year="2005"/>
        <author login="jtulach"/>
        <compatibility addition="yes" binary="compatible" semantic="compatible" />
        <description>
        <p>
            Many people subclass <code>DataEditorSupport</code> to provide editing ability for data
            objects. The great majority of them wish to provide an editor cookie 
            and with standard semantics for open, modify, save, undo,
            close, reload, etc. By using the 
            <code>DataEditorSupport.create</code> factory 
            method this task is simplified to two lines of code.
        </p>
        </description>
        <class package="org.openide.text" name="DataEditorSupport" />
        <issue number="17081"/>
    </change>
    
     <change id="DataLoaderPool.getDefault">
        <api name="loaders"/>
      <summary>Added <code>DataLoaderPool.getDefault()</code></summary>
        <version major="5" minor="1"/>
        <date day="7" month="2" year="2005"/>
        <author login="jtulach"/>
        <compatibility addition="yes" binary="compatible" semantic="compatible" />
        <description>
        <p>
            <code>DataLoaderPool</code> now has a new method <code>getDefault()</code>
            to allow simple access to the default system loader pool.
        </p>
        </description>
        <class package="org.openide.loaders" name="DataLoaderPool" />
        <issue number="41650"/>
    </change>

     <change id="DataLoader.actionsContext">
        <api name="loaders"/>
      <summary>Actions for <code>DataLoader</code> can be specified in a layer</summary>
        <version major="5" minor="0"/>
        <date day="23" month="11" year="2004"/>
        <author login="jtulach"/>
        <compatibility addition="yes" binary="compatible" semantic="compatible" />
        <description>
        <p>
            <code>DataLoader</code> now has a new method <code>protected String actionsContext()</code>
            which by default returns <code>null</code> but can be overriden to identify name
            of a place on default file system where layers can store instances of <code>javax.swing.Action</code>
            that will then be used as a return value of <code>DataNode.getActions(boolean)</code>.
            This allows smooth extensibility of one data object's node with actions 
            from other modules.
        </p>
        <p>
            The change is compatible, as if one does not override this method, 
            the behaviour remains the same as it used to be. If the method is overridden
            and returns non-null value, 
            the <code>DataLoader.setActions</code> uses the given context to 
            store the actions into it.
        </p>
        <p>
            The standard loader for folder use <code>Loaders/folder/any/Actions</code> 
            as its context, so any module who wishes to add anything to its 
            popup menu, may register actions layer file like 
            <a href="@org-openide-actions@/org/openide/actions/doc-files/api.html#adv-install">
            any regular actions</a> just into the folder <code>Loaders/folder/any/Actions</code>.
        </p>
        </description>
        <class package="org.openide.loaders" name="DataLoader"/>
        <issue number="45137"/>
    </change>

     <change id="ChangeableDataFilter">
        <api name="loaders"/>
      <summary>Added <code>ChangeableDataFilter</code> interface</summary>
        <version major="4" minor="16"/>
        <date day="11" month="6" year="2004"/>
        <author login="phrebejk"/>
        <compatibility addition="yes"/>
        <description>
        <p>
        The class <code>FolderChildren</code> was able to filter the children
        using <code>DataFilter</code>. But the data filter was constant for the
        entire life of the <code>FolderChildren</code> instance. <code>ChangeableDataFilter</code>
        class adds the ability to change the filtering strategy, where 
        the change is reflected immediatley in the folder children.
        </p>
        </description>
        <class package="org.openide.loaders" name="ChangeableDataFilter" />
        <issue number="44368"/>
    </change>

  
    <change>
        <api name="loaders"/>
        <summary>Support for 24x24 icons</summary>
        <version major="4" minor="15"/>
        <date day="18" month="5" year="2004"/>
        <author login="mslama"/>
        <compatibility addition="yes" deprecation="yes"/>
        <description>
            <code>Toolbar.getBasicHeight()</code> was added to replace <code>Toolbar.BASIC_HEIGHT</code>.
            <code>ToolbarPool.getPreferredIconSize()</code> and <code>ToolbarPool.setPreferredIconSize(int)</code>
            were added.
        </description>
        <class package="org.openide.awt" name="Toolbar" />
        <class package="org.openide.awt" name="ToolbarPool" />
        <issue number="34574"/>
    </change>

    <change>
        <api name="loaders"/>
         <summary><code>DataShadow</code> uses URL for storage</summary>
        <version major="4" minor="14"/>
        <date day="12" month="5" year="2004"/>
        <author login="dkonecny"/>
        <compatibility addition="yes" semantic="compatible"/>
        <description>
            Two changes in DataShadow. The implementation was changed to
            store link as URL instead of FileSystem + Path pair. DataShadow
            declaration was extended and "originalFile" attribute can be
            defined not only as stringvalue but also as urlvalue.
        </description>
        <issue number="42091"/>
    </change>

    <change>
      <api name="loaders"/>
         <summary><code>DataNode.getHtmlDisplayName</code> was implemented</summary>
      <version major="4" minor="13"/>
      <date day="3" month="5" year="2004"/>
      <author login="tboudreau"/>
      <compatibility addition="yes"/>
      <description>
            <code>DataNode</code> now implements <code>getHtmlDisplayName()</code> as follows:  If the
            underlying filesystem implements the new <code>FileSystem.HtmlStatus</code>, it will
            call <code>FileSystem.HtmlStatus.annotateNameHtml()</code> and return the result.
      This enables, for example, CVS annotations to be shown with a different
      font color.
      </description>
      <class package="org.openide.loaders" name="DataNode"/>
      <issue number="29466"/>
    </change>

    <change id="SortMode.LAST_MODIFIED-SIZE">
      <api name="loaders"/>
      <summary>Two new folder sort modes</summary>
      <version major="4" minor="10"/>
      <date day="9" month="9" year="2003"/>
      <author login="jglick"/>
      <compatibility addition="yes"/>
      <description>
        Two new folder sort modes, <code>LAST_MODIFIED</code> and
        <code>SIZE</code>, were added.
      </description>
      <class package="org.openide.loaders" name="DataFolder"/>
      <issue number="26667"/>
    </change>

    <change >
     <api name="loaders"/>
     <summary>Tighter synchronization during copy/move/rename</summary>
     <version major="4" minor="9"/>
     <date day="28" month="5" year="2003"/>
     <author login="jtulach"/>
     <compatibility semantic="incompatible" />
     <description>
        In previous version of Loaders a thread can access
        unfinished files copied/moved/createFromTemplated
        by another Thread. This change prevent such accidental
        access and provides more robust behaviour to writers
        of own <code>DataObjects</code> and <code>DataLoaders</code>.
        <p/>
        This change has been introduced to make the behaviour
        safer and more predicatable. Its goal is not to introduce
        new deadlocks, but everybody writing its own loaders has
        to keep in mind that it is dangerous to perform a long
        running operation in the handleCopy, handleMove,
        handleRename, handleCreateFromTemplate methods.
     </description>
     <class package="org.openide.loaders" name="DataObject" />
     <issue number="33750"/>
    </change>
  
    <change >
     <api name="loaders"/>
     <summary>Calls to DataObject constructor restricted</summary>
     <version major="4" minor="7"/>
     <date day="16" month="5" year="2003"/>
     <author login="jtulach"/>
     <compatibility semantic="incompatible" />
     <description>
        In order to fix timing issues in <code>org.openide.loaders</code> package
        the possibility to invoke <code>DataObject</code>'s constructor has been
        restricted. 
        <p/>
        There is an <code>OperationListener</code> class in the org.openide.loaders 
        package that shall be notified about every created DataObject. It is easy 
        to be notified when the DataObject is being created, but the notification 
        shall be done when its constructor finishes otherwise magic race 
        conditions can happen, see for example 
        <a href="http://www.netbeans.org/issues/show_bug.cgi?id=20022">issue 20022</a>.
        The previous solution was to wait 500ms after the start of DataObject's 
        constructor and notifying the creation than, but of course it means 
        that if the constructor takes longer time, we were in the same problem again.
        <p/>
        Because DataObjects shall be created only by DataLoaders in method 
        <code>DataLoader.handleFindDataObject</code>, we can notify each data 
        object when the execution is returning from DataLoader.handleFindDataObject, 
        but in order for the system to work correctly we shall prevent creation 
        of DataObjects outside of this place.
        <p/>
        DataObject constructor will throw an exception if invoked outside of 
        <code>DataLoader.handleFindDataObject</code> or <code>MultiFileLoader.createDataObject</code>
        methods. This is incompatible change, but nobody should really be affected, 
        as creating data objects outside of DataLoader has no real 
        meaning. 
     </description>
     <class package="org.openide.loaders" name="DataObject" />
     <issue number="33469"/>
    </change>
  
  
    <change >
     <api name="loaders"/>
     <summary>Separated out from the openide</summary>
     <version major="4" minor="5"/>
     <date day="18" month="4" year="2003"/>
     <author login="jtulach"/>
     <compatibility  binary="compatible" source="compatible" />
     <description>
     Classes of <code>org.openide.loaders</code> package were separated
     out from the whole openide.jar into their own openide-loaders.jar.
     </description>
     <issue number="32937"/>
    </change>

    <change id="FolderRenameHandler" >
        <api name="loaders"/>
        <summary>Introduction of a new interface FolderRenameHandler which allows plugging into <code>DataFolder.FolderNode.setName()</code></summary>
        <version major="5" minor="4"/>
        <date day="11" month="5" year="2005"/>
        <author login="jbecicka"/>
        <compatibility addition="yes" binary="compatible" source="compatible" semantic="compatible" deprecation="no" deletion="no" modification="no"/>
        <description>
        Refactoring needs to handle rename of DataFolder's Node. It is allowed through FolderRenameHandler.
        Any client can put it's FolderRenameHandler into Lookup (only one instance is allowed). 
        Implementation of FolderNode.setName() will use this instance to handle rename request.
        </description>
        <class package="org.openide.loaders" name="FolderRenameHandler"/>
        <issue number="53295"/>
    </change>

    <change id="DataNodeLookupContructor" >
        <api name="loaders"/>
        <summary>New <a href="@TOP@/org/openide/loaders/DataNode.html">DataNode</a> constructor that takes Lookup</summary>
        <version major="5" minor="6"/>
        <date day="19" month="9" year="2005"/>
        <author login="jtulach"/>
        <compatibility addition="yes" binary="compatible" source="compatible" semantic="compatible" deprecation="no" deletion="no" modification="no"/>
        <description>
            It was not possible to use <a href="@TOP@/org/openide/loaders/DataNode.html">DataNode</a> with own Lookup as the
            constructor that takes it was available only on <a href="@org-openide-nodes@/org/openide/nodes/Node.html">Node</a>
            and there was no way to pass it thru <a href="@TOP@/org/openide/loaders/DataNode.html">DataNode</a>.
        </description>
        <class package="org.openide.loaders" name="DataNode"/>
        <issue number="61824"/>
    </change>

  </changes>

  <!-- Now the surrounding HTML text and document structure: -->

  <htmlcontents>
<!--

                            NO NO NO NO NO!

         ==============>    DO NOT EDIT ME!  <======================

          AUTOMATICALLY GENERATED FROM APICHANGES.XML, DO NOT EDIT

                SEE openide/loaders/api/apichanges.xml

-->
    <head>
      <title>Change History for the Loaders API</title>
      <link rel="stylesheet" href="prose.css" type="text/css"/>
    </head>
    <body>

<p class="overviewlink"><a href="overview-summary.html">Overview</a></p>

<h1>Introduction</h1>

<p>This document lists changes made to the <a href="@TOP@">Loaders
API</a>. Please ask on the <code>dev@openide.netbeans.org</code> mailing list
if you have any questions about the details of a
change, or are wondering how to convert existing code to be compatible.</p>

<!-- The actual lists of changes, as summaries and details: -->

      <hr/><standard-changelists module-code-name="org.openide.loaders"/>

      <hr/><p>@FOOTER@</p>

    </body>
  </htmlcontents>

</apichanges>
