<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>OpenEdit Company Blog</title>
    <link>http://www.openedit.org</link>
    <description>OpenEdit Company Blog</description>
    <item>
      <title>Christopher Burkey to Speak in Santiago, Chile</title>
      <link>http://www.openedit.org/community/permalink/2009/1/13/071008.html</link>
      <description>&lt;p&gt;&lt;img width="94" height="108" align="left" src="/layouts/OE2008/images/chris.jpg" alt="" /&gt;Christopher Burkey, CEO of OpenEdit, has been invited to speak at Chile Global in Santiago, Chile Wednesday, January 14, 2009. &lt;br /&gt;&#xD;
&lt;br /&gt;&#xD;
&lt;a href="http://www.chileglobal.org/" target="_blank"&gt;Chile Global&lt;/a&gt; is an international network of successful Chilean business owners and high level executives who have an interest to contribute and share in the Chilean economic development.&lt;br /&gt;&#xD;
&lt;br /&gt;&#xD;
Christopher will be demonstrating &lt;a href="../../../../../" target="_blank"&gt;OpenEdit&lt;/a&gt;, a web application framework used to create and maintain dynamic websites and custom web applications such as &lt;a href="http://www.openeditdam.com/" target="_blank"&gt;OpenEdit Digital Asset Management&lt;/a&gt;.&lt;br /&gt;&#xD;
&lt;br /&gt;&#xD;
If you would like Christopher or another OpenEdit member to speak at your JAVA technology event or demo OpenEdit for you, &lt;a href="mailto:julie@openedit.org?subject=Speak%20at%20our%20JAVA%20group"&gt;let us know&lt;/a&gt;. We love the opportunity to talk about OpenEdit!&lt;/p&gt;</description>
      <pubDate>Tue, 13 Jan 2009 12:10:08 GMT</pubDate>
      <guid>http://www.openedit.org/community/permalink/2009/1/13/071008.html</guid>
      <dc:creator>Julie Riley</dc:creator>
      <dc:date>2009-01-13T12:10:08Z</dc:date>
    </item>
    <item>
      <title>Redirect API Change</title>
      <link>http://www.openedit.org/community/permalink/2008/12/4/151146.html</link>
      <description>&lt;p&gt;I've written a new redirect action that I think should replace Admin.redirectToOriginal and Page.jumpToPage, which were both designed to handle very specific cases, and yet are complicated and otherwise inflexible. Mine uses one parameter and works with any number and combination of known paths and user inputs.&lt;br /&gt;&#xD;
&lt;br /&gt;&#xD;
I came across the problem of the old actions when I was working on the file manager. The file manager requires fairly complex redirections. Consider the case of creating a new file.&lt;br /&gt;&#xD;
&lt;br /&gt;&#xD;
Once the user has submitted the create form, they need to be redirected to their new page. This url is composed of:&lt;br /&gt;&#xD;
1. The base file manager URL, example: ${page.filerootpath}/index.html?path=&lt;br /&gt;&#xD;
2. The folder that the new file is located in, example: /test/dir/&lt;br /&gt;&#xD;
3. The file name, example: new.html&lt;br /&gt;&#xD;
&lt;br /&gt;&#xD;
So, ultimately we should redirect to ${page.filerootpath}/index.html?path=/test/dir/new.html&lt;br /&gt;&#xD;
The problem is that #2 is not known until we actually visit the create form, and #3 is not known until the user enters a filename into the form. &lt;br /&gt;&#xD;
&lt;br /&gt;&#xD;
How would the old actions handle this?&lt;br /&gt;&#xD;
&lt;br /&gt;&#xD;
Admin.redirectToOriginal:&lt;br /&gt;&#xD;
This takes two request parameters, origURL, and editPath. Usually we end up using this action because in the simplest case, origURL is set to the desired URL and and it simply redirects there.&lt;br /&gt;&#xD;
This can also handle a more complicated case. When editPath is set, it appends &amp;quot;?path=&amp;quot; + editPath + &amp;quot;&amp;amp;cache=false&amp;quot;. This would only be useful if our redirected URL used the path= parameter, so I think few pages actually use it.&lt;br /&gt;&#xD;
&lt;br /&gt;&#xD;
Page.jumpToPage:&lt;br /&gt;&#xD;
This takes three request parameters, destinationPath, forcedDestinationPath, and redirectPrefix. destinationPath acts like origURL; redirectPrefix will add any prefix to the url, and forcedDestinationPath will override the path if supplied. &lt;br /&gt;&#xD;
&lt;br /&gt;&#xD;
Both of these actions handle a maximum of two different pieces of information, and because the example needs three, we would have to use javascript or something to dynamically combine information into one parameter. Also, our parameters on our create file form would need to match the names in the redirect action so they can be reused, so our create file action would end up accepting &amp;quot;destinationPath&amp;quot; as the file name.&lt;br /&gt;&#xD;
&lt;br /&gt;&#xD;
My new action takes one parameter, &amp;quot;path-part&amp;quot;. It can specify either a string to add to the redirect path, or the name of a parameter to collect as part of the path. Our original example would be written as:&lt;br /&gt;&#xD;
&lt;br /&gt;&#xD;
&amp;nbsp;&amp;nbsp;&amp;nbsp; &amp;lt;input type=&amp;quot;hidden&amp;quot; name=&amp;quot;path&amp;quot; value=&amp;quot;$basePath&amp;quot;/&amp;gt;&lt;br /&gt;&#xD;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; &amp;lt;input type=&amp;quot;text&amp;quot; name=&amp;quot;name&amp;quot;&amp;gt;&lt;br /&gt;&#xD;
&lt;br /&gt;&#xD;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; &amp;lt;input type=&amp;quot;hidden&amp;quot; name=&amp;quot;path-part&amp;quot; value=&amp;quot;${page.filerootpath}/index.html?path=&amp;quot; /&amp;gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; &lt;br /&gt;&#xD;
&amp;nbsp;&amp;nbsp;&amp;nbsp; &amp;lt;input type=&amp;quot;hidden&amp;quot; name=&amp;quot;path-part&amp;quot; value=&amp;quot;req.path&amp;quot; /&amp;gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; &lt;br /&gt;&#xD;
&amp;nbsp;&amp;nbsp;&amp;nbsp; &amp;lt;input type=&amp;quot;hidden&amp;quot; name=&amp;quot;path-part&amp;quot; value=&amp;quot;req.name&amp;quot; /&amp;gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; &lt;br /&gt;&#xD;
&amp;nbsp;&amp;nbsp;&amp;nbsp; &lt;br /&gt;&#xD;
The first input is #2, the path that we find out when we load the page. The second input is #3, the name that the user inputs. These are used in the create file action.&lt;br /&gt;&#xD;
The next three inputs specify how to construct the redirect path. They can either specify a literal string, or else the name of a request parameter to look for.&lt;br /&gt;&#xD;
I think this is simpler and much more flexible. Any suggestions for improvement are welcome, especially for the name and syntax of the &amp;quot;path-part&amp;quot; parameter. This technique could be used for any action that accepts a path or long complicated string. Would it be useful anywhere else?&lt;br /&gt;&#xD;
&amp;nbsp;&lt;/p&gt;</description>
      <pubDate>Thu, 04 Dec 2008 20:11:46 GMT</pubDate>
      <guid>http://www.openedit.org/community/permalink/2008/12/4/151146.html</guid>
      <dc:creator>Axis Sivitz</dc:creator>
      <dc:date>2008-12-04T20:11:46Z</dc:date>
    </item>
    <item>
      <title>OpenEdit Weekly Update</title>
      <link>http://www.openedit.org/community/permalink/2008/11/14/113920.html</link>
      <description>&lt;p&gt;This week the OpenEdit team has added yet another way to help classify your digital assets.&amp;nbsp; We now have Related Products, whereby you can mark two assets as being related to eachother.&lt;/p&gt;&#xD;
&lt;p&gt;We have increased security for downloading original assets through OpenEdit.&lt;/p&gt;&#xD;
&lt;p&gt;There is also a new feature which allows you to override certain aspects of a property for a particular view.&amp;nbsp; Previously, all settings for a product property were defined in configuration/productproperties.xml.&amp;nbsp; If you included that property in more than one view (such as the advanced search and the product details page), the label and all other setttings for the property would be identical in each of those views.&amp;nbsp;&lt;/p&gt;&#xD;
&lt;p&gt;With this override capability, you can change the label of a field, whether or not it is editable or required, and several other settings for each of the different views.&amp;nbsp; This will allow a property to be editable in one place, but not editable somewhere else.&amp;nbsp; Currently this must be accomplished by editing the view's XML by hand, but we intend to add these features to the data editor very soon.&amp;nbsp; To do this, just specify the settings in the view xml file, like this:&lt;/p&gt;&#xD;
&lt;p&gt;&amp;lt;property id=&amp;quot;name&amp;quot; editable=&amp;quot;true&amp;quot; required=&amp;quot;true&amp;quot; html=&amp;quot;false&amp;quot;&amp;gt;Enter the Asset's Name&amp;lt;/property&amp;gt;&lt;/p&gt;&#xD;
&lt;p&gt;This would override the default label for the 'name' property (the one defined in productproperties.xml) with &amp;quot;Enter the Asset's Name&amp;quot;.&amp;nbsp; The properties which are now overridable are: 'text' (the label), 'editable', 'required', 'listid', 'listchild', and 'html'.&lt;/p&gt;</description>
      <pubDate>Fri, 14 Nov 2008 16:39:20 GMT</pubDate>
      <guid>http://www.openedit.org/community/permalink/2008/11/14/113920.html</guid>
      <dc:creator>Taylor Cornett</dc:creator>
      <dc:date>2008-11-14T16:39:20Z</dc:date>
    </item>
    <item>
      <title>OpenEdit Updates</title>
      <link>http://www.openedit.org/community/permalink/2008/11/10/113108.html</link>
      <description>&lt;p&gt;The OpenEdit team continues to work hard to improve the OpenEdit experience.&amp;nbsp; We have added a new feature that allows users to create their own RSS feeds using customized searches.&amp;nbsp; This is available from the &amp;quot;Tools&amp;quot; menu in the OpenEdit archive.&amp;nbsp; &lt;/p&gt;&#xD;
&lt;p&gt;We have also added versioning for assets.&amp;nbsp; You can now keep track of different versions of the same asset within the OpenEdit archive. We have also revamped the product details page to allow easier access to this new feature, as well as meta-data editing, more download format options, and commenting on individual assets. &lt;/p&gt;&#xD;
&lt;p&gt;&amp;nbsp;&lt;/p&gt;</description>
      <pubDate>Mon, 10 Nov 2008 16:31:08 GMT</pubDate>
      <guid>http://www.openedit.org/community/permalink/2008/11/10/113108.html</guid>
      <dc:creator>Taylor Cornett</dc:creator>
      <dc:date>2008-11-10T16:31:08Z</dc:date>
    </item>
    <item>
      <title>OpenEdit Development 8-14-08</title>
      <link>http://www.openedit.org/community/permalink/2008/8/14/165019.html</link>
      <description>&lt;p&gt;Features&lt;/p&gt;&#xD;
&lt;hr /&gt;&#xD;
&lt;p&gt;Further integration of product folders into the archive search functionality. You can now search for folders, view their contents, and download them as a zip file.&lt;/p&gt;&#xD;
&lt;p&gt;OE now works with Resin 3.2 virtual hosts.&lt;/p&gt;&#xD;
&lt;p&gt;&amp;nbsp;&lt;/p&gt;&#xD;
&lt;p&gt;Improvements&lt;/p&gt;&#xD;
&lt;hr /&gt;&#xD;
&lt;p&gt;The OE Zip utility class now uses the file repository, which means mounted folders can now be zipped, as well as any other implementation of the repository interface. Also, we don't unzip OS X meta data in zip files.&lt;/p&gt;&#xD;
&lt;p&gt;New Archive interface. &lt;/p&gt;&#xD;
&lt;p&gt;&amp;nbsp;&lt;/p&gt;&#xD;
&lt;p&gt;Bug Fixes&lt;/p&gt;&#xD;
&lt;hr /&gt;&#xD;
&lt;p&gt;Fixed group permission editor.&lt;/p&gt;</description>
      <pubDate>Thu, 14 Aug 2008 20:50:19 GMT</pubDate>
      <guid>http://www.openedit.org/community/permalink/2008/8/14/165019.html</guid>
      <dc:creator>Axis Sivitz</dc:creator>
      <dc:date>2008-08-14T20:50:19Z</dc:date>
    </item>
  </channel>
</rss>


