Silva

Bug #100856 (silva-742)
Comment #6

Comment 6 for bug 100856

Revision history for this message

Andy Altepeter (aaltepet) wrote on 2008-09-14:

I've just re-confirmed that it isn't possible to provide a fix for this in the SMI -- the fix will likely have to go into SilvaMetadata to adjust the API of Element.renderEdit and Binding.renderElementEdit to accept a value as a parameter. These methods currently only use the already saved metadata. As thisfred suggests, we need to reevaluate.

One possibility would be to "ajax" this form. When you click the save button, an the metadata is serialized and posted to save_metadata_validate. The response to this would be any fields with errors and what those errors are. Of course, this means that validation happens twice, since it would also need to be validated within save_metadata for security reasons.

The alternative is to adjust SilvaMetadata. The key problem here is that SilvaMetadata's renderEdit code doesn't know if there is was an error saving in this transaction, and doesn't have the currently value for the element from the REQUEST. Here's one possibility to fix this:

all_errors will contain a dictionary of the fields with errors. This is passed to tab_metadata and could be accessible from macro_metadata_edit (the pt that actually renders a set). If all_errors is not empty, it can be assumed that the current transaction was an attempt to save the metadata, and some values in the request did not pass validation. macro_edit_metadata(SMI) gets the metadata from a helper script, get_metadata(SMI). This script could accept a parameter, fromRequest, which if true indicates that the metadata should be rendered from the values in REQUEST rather than from the saved metadata. get_metadata calls Binding.renderElementEdit. renderElementEdit could accept the request object, which if present will be passed to Element.renderEdit instead of the old/saved metadata value.
Elemenent.renderEdit will be changed to accept two values:
renderEdit(value, REQUEST)
both of these parameters will be passed to the formulator fields render method, which has the following docstring:
if value and REQUEST are both None, the 'default' property of
the field will be used for the value.
This is why the saved data will not be sent if there was an error saving.

Thoughts? I understand you're concern about escalation with SilvaMetadata. The changes I'm proposing should not affect the default behavior of SilvaMetadata, and the changes should be well documented, including addition of testing suites.

I've just re-confirmed that it isn't possible to provide a fix for this in the SMI -- the fix will likely have to go into SilvaMetadata to adjust the API of Element.renderEdit and Binding.renderElementEdit to accept a value as a parameter.  These methods currently only use the already saved metadata.  As thisfred suggests, we need to reevaluate.

One possibility would be to "ajax" this form.  When you click the save button, an the metadata is serialized and posted to save_metadata_validate.  The response to this would be any fields with errors and what those errors are.  Of course, this means that validation happens twice, since it would also need to be validated within save_metadata for security reasons.

The alternative is to adjust SilvaMetadata.  The key problem here is that SilvaMetadata's renderEdit code doesn't know if there is was an error saving in this transaction, and doesn't have the currently value for the element from the REQUEST.  Here's one possibility to fix this:

all_errors will contain a dictionary of the fields with errors.  This is passed to tab_metadata and could be accessible from macro_metadata_edit (the pt that actually renders a set).  If all_errors is not empty, it can be assumed that the current transaction was an attempt to save the metadata, and some values in the request did not pass validation.  macro_edit_metadata(SMI) gets the metadata from a helper script, get_metadata(SMI).  This script could accept a parameter, fromRequest, which if true indicates that the metadata should be rendered from the values in REQUEST rather than from the saved metadata.  get_metadata calls Binding.renderElementEdit.  renderElementEdit could accept the request object, which if present will be passed to Element.renderEdit instead of the old/saved metadata value. 
Elemenent.renderEdit will be changed to accept two values:
renderEdit(value, REQUEST)
both of these parameters will be passed to the formulator fields render method, which has the following docstring:
        if value and REQUEST are both None, the 'default' property of
        the field will be used for the value.
This is why the saved data will not be sent if there was an error saving.

Thoughts?  I understand you're concern about escalation with SilvaMetadata.  The changes I'm proposing should not affect the default behavior of SilvaMetadata, and the changes should be well documented, including addition of testing suites.