= New-admin changes =

The new-admin branch contains a number of changes. All of these changes may be reverted (more likely with some than others) or further modified. 

== View Functions ==

For view functions to work properly with all new features, a few changes are in order. 

From: 
{{{
def style_edit(request, object_id):    
    try:
        manipulator = styles.ChangeManipulator(object_id)
    except ObjectDoesNotExist:
        raise Http404

    if request.POST:
        new_data = request.POST.copy()
        
        errors = manipulator.get_validation_errors(new_data)
        
        if not errors:
            manipulator.do_html2python(new_data)   # WRONG!!
            manipulator.save(new_data)
            return HttpResponseRedirect("")
    else:
        # Populate new_data with a "flattened" version of the current data.
        new_data = manipulator.original_object.__dict__ # WRONG!!
        errors = {}
       
        mash_around_with_the_data_dict_to_make_foreign_keys_work(new_data) # WRONG!!   

    # Populate the FormWrapper.
    form = formfields.FormWrapper(manipulator, new_data, errors)
    
    return render_to_response('style_edit', { 'form': form })
}}}

To:
{{{
def style_edit(request, object_id):    
    try:
        manipulator = styles.ChangeManipulator(object_id)
    except ObjectDoesNotExist:
        raise Http404

    if request.POST:
        new_data = request.POST.copy()
        errors = manipulator.get_validation_errors(new_data)
        
        manipulator.do_html2python(new_data) # CORRECT!!
        if not errors:
            manipulator.save(new_data)
            return HttpResponseRedirect("")
    else:
        # Populate new_data with a "flattened" version of the current data.
        new_data = manipulator.flatten_data() # CORRECT!!
        errors = {}
       

    # Populate the FormWrapper.
    form = formfields.FormWrapper(manipulator, new_data, errors)
    
    return render_to_response('style_edit', { 'form': form })

}}}
Without these changes, the new fixes will not work. It should work about as well as the trunk without these changes. 

So, 

 1. Make sure html2python is called regardless of whether there are errors, but '''after''' validation. 
 2. Make sure you use flatten_data to get your new_data to fill in your forms, NOT just the {{{__dict__}}} of the object you are editing. Otherwise, dates, foreign keys, inline editing and a  whole host of other things will NOT work properly, just like they do not work on trunk. 
 3. Make sure you remove any hacks for modifying the data in your view function. This is now done by the fields themselves in flatten_data and instances where it works unexpectedly should be filed as bugs. 

== Manipulators ==

Manipulators have a new optional argument to their constructors: {{{follow}}}. The argument is a dictionary indicating which fields and related objects to extract in flatten_data and examine when saving the object.

The default set to follow is:

 * Any fields without {{{editable=False}}}.
 * Any related objects with {{{edit_inline}}} set on the {{{ForeignKey}}} relating to the class the manipulator is concerned with.

This is the set of fields shown by the admin. 

(insert example)

Manipulators have a new method, {{{flatten_data()}}}. This takes the data from the existing object (or the defaults in the case of an {{{AddManipulator}}}) and turns it into a suitable form for an HTTP post. It must be called before creating the formfield wrapper is created.

The data from a post must have {{{manipulator.do_html2python(new_data)}}} called on it before it is used to repopulate a formfieldwrapper.


== Templates ==

A new tag, called {{{include}}}, which is an improvement on ssi parsed. See #598.

Improved error reporting when debug is on. See #603. Also note that loaders must return a tuple of (source, filename) rather than just the source of a loaded template.

== Admin converted to separate templates ==

The admin is now rendered using separate templates. These can be overloaded, meaning the admin is a bit easily customizable. 
Inline editing can use a custom template, reather than using edit_inline=meta.TABULAR or meta.SOURCE, just use a path to a template, eg edit_inline="edit_inline_horizontal".

 This does require knowing the contents of the context for that template which is undocumented. Also this will probably change to a class to allow more flexibility, eg processing for style/grouping logic etc.