Redirect API Change

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.

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.

Once the user has submitted the create form, they need to be redirected to their new page. This url is composed of:
1. The base file manager URL, example: ${page.filerootpath}/index.html?path=
2. The folder that the new file is located in, example: /test/dir/
3. The file name, example: new.html

So, ultimately we should redirect to ${page.filerootpath}/index.html?path=/test/dir/new.html
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.

How would the old actions handle this?

Admin.redirectToOriginal:
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.
This can also handle a more complicated case. When editPath is set, it appends "?path=" + editPath + "&cache=false". This would only be useful if our redirected URL used the path= parameter, so I think few pages actually use it.

Page.jumpToPage:
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.

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 "destinationPath" as the file name.

My new action takes one parameter, "path-part". 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:

    <input type="hidden" name="path" value="$basePath"/>
        <input type="text" name="name">

     <input type="hidden" name="path-part" value="${page.filerootpath}/index.html?path=" />   
    <input type="hidden" name="path-part" value="req.path" />   
    <input type="hidden" name="path-part" value="req.name" />   
   
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.
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.
I think this is simpler and much more flexible. Any suggestions for improvement are welcome, especially for the name and syntax of the "path-part" parameter. This technique could be used for any action that accepts a path or long complicated string. Would it be useful anywhere else?
 

Axis Sivitz Thu, Dec 4 2008 3:11 PM 0 comments

OpenEdit Weekly Update

This week the OpenEdit team has added yet another way to help classify your digital assets.  We now have Related Products, whereby you can mark two assets as being related to eachother.

We have increased security for downloading original assets through OpenEdit.

There is also a new feature which allows you to override certain aspects of a property for a particular view.  Previously, all settings for a product property were defined in configuration/productproperties.xml.  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. 

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.  This will allow a property to be editable in one place, but not editable somewhere else.  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.  To do this, just specify the settings in the view xml file, like this:

<property id="name" editable="true" required="true" html="false">Enter the Asset's Name</property>

This would override the default label for the 'name' property (the one defined in productproperties.xml) with "Enter the Asset's Name".  The properties which are now overridable are: 'text' (the label), 'editable', 'required', 'listid', 'listchild', and 'html'.

Taylor Cornett Fri, Nov 14 2008 11:39 AM 0 comments

OpenEdit Updates

The OpenEdit team continues to work hard to improve the OpenEdit experience.  We have added a new feature that allows users to create their own RSS feeds using customized searches.  This is available from the "Tools" menu in the OpenEdit archive. 

We have also added versioning for assets.  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.

Taylor Cornett Mon, Nov 10 2008 11:31 AM 0 comments

OpenEdit Development 8-14-08

Features

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.

OE now works with Resin 3.2 virtual hosts.

Improvements

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.

New Archive interface.

Bug Fixes

Fixed group permission editor.

Axis Sivitz Thu, Aug 14 2008 4:50 PM 1 comment

8 Deployments a Day..

During the launch of the RMC network this past week, and since the launch of VoisinHQ three weeks ago, we have built and deployed Voisin countless times. During the first few days of an new application, we deploy a new version of the software up to 8 times per day.

This has everything to do with OEF's fallback directory structure, build server set-up, and tools for plug-in upgrades.

The process of getting bug fixes committed into the base code and upgrading live installations is incredibly smooth with OEF. In fact, it's so straight forward that we make changes, test, commit and upgrade live installations daily.

The result of our rapid deployment cycles from an end user perspective is very significant. Our users often get receive an outline of the implemented solution to the bug they encountered the same day they post their complaint. This turns frustrated users into big fans of the software.

Could you imagine Microsoft implementing a fix to your software complaints within 24 hours?

Being able to provide an immediate and permanent resolution to most small issues preventing an enjoyable user experience is making a huge difference to the success of Voisin.

Our initial success is very much a result of OEF. Thank you.

Joel Halse Wed, Aug 13 2008 11:27 AM 0 comments

A List Apart Survey, 2008

This is a bit off topic from OpenEdit but I think many of our users might find this interesting:

Take a look at A List Apart and participate in their survey. They are looking for all "designers, developers, information architects, project managers, writers, editors, marketers, and everyone else who makes websites. It is time once again to pool our information so as to begin sketching a true picture of the way our profession is practiced worldwide."

A List Apart is a webzine for web designers. It covers various topics of interest and advocates the use of web standards in the design process.

By the way, you can see the results of last years survey here.

Julie Riley Mon, Aug 11 2008 3:10 PM 1 comment

OpenEdit Development 8-10-08

Features

New OpenEdit toolbar allows easy setup of new OE applications

The new Mount Editor let's the admin manage all of the external directories used by OpenEdit in one central place

Improvements

Greatly improved XML document writing speed, and simplified API

Product folders can be indexed and searched by their _site.xconf properties.

Product properties may be pulled in from .xconfs

Axis Sivitz Mon, Aug 11 2008 10:10 AM 0 comments

OpenEdit Development 8-1-08

Features

Download button in filemanager and gallery to directly download file

Default filetype icons in Archive for non-images

Folders can now be indexed along with products for searching

Axis Sivitz Fri, Aug 1 2008 4:51 PM 0 comments

New Ideas

Does anyone have feedback on this new OpenEdit Admin toolbar idea? The way it would work is that you would hover over the plugin type and it will drop down some sub options. This also allows you to setup multiple blogs, ecommerce or archive store fronts. Once you install a plugin then a new drop down will automatically appear.

Christopher Burkey Fri, Aug 1 2008 12:04 AM 2 comments

Source Statistics

I gathered some statistics on OpenEdit's source code. I wonder how these will change over the next few years?

Commands Used

lines: find openedit/src/ -iname '*.java' | xargs wc -l

files: find openedit/src/ -iname '*.java' | wc -l

biggest: find openedit/src/ -iname '*.java' | xargs wc -l | sort -n

Data

openedit (core)

java source:  25055 total lines in 161 files
unit tests:  3367 total lines in 36 files

biggest:    932 lines: openedit/src/java/com/openedit/users/filesystem/FileSystemUserManager.java
 

openedit editor

java source:  32730 total lines in 190 files
unit tests:   4115 total lines in 59 files

biggest:   1269 lines: openedit-editor/src/com/openedit/modules/admin/users/UserManagerModule.java
 

openedit cart

java source:  24131 total lines in 111 files
unit tests:   3453 total lines in 26 files

biggest:   1607 lines: openedit-cart/src/org/openedit/store/modules/CatalogEditModule.java
 

openedit archive

java source: 8036 total lines in 46 files
unit tests:  1785 total lines in 19 files

biggest: 665 lines: openedit-archive/src/com/openedit/archive/collection/CollectionModule.java

openedit-blog

java source: 2586 total lines in 15 files
unit tests: 314 total lines in 4 files

biggest:   520 lines: openedit-blog/src/org/openedit/blog/modules/BlogModule.java

 

Axis Sivitz Tue, Jul 29 2008 3:11 PM 2 comments