Hey Guys

On a project i'm working on, I make use of Form.Serialize to serialize a
form to then be sent in an Ajax.Request.
Since i don't know what fields i'll have at the time the form is generated,
I can't use a statically constructed parameter string for the 'save'...
('value=' + $F('field_1') + '&value2='...)

I ran into a problem where I had date values in an input field (which is
picked from a date-picker) but when they get posted to the server side, i
was faced with doing value identification to determine the data type of the
passed data.
For example, an input with '08/09/2007' in it, which in turn, can't easily
be set to a datetime field in a database.

I did a bit of research and determined that custom serializers for an input
box was not an available option so I looked into implementing it, allowing
me to munge the value returned from the serializer before it is built into
the Ajax.Request.
(the other option was get the result of Form.Serialize and post-process it,
or pass the 'UI datatype' as part of my form data, for each field)

I came up with what I think is a fairly elegant solution, although possibly
it could do with a slight bit more error checking...

Here it is:

1) In prototype.js, I modified the Form.Element.Serializers default case
like so:

NEW
      default:
      {
        if(Form.Element.Serializers[element.readAttribute("customserializer")]
!= undefined)
            return Form.Element.Serializers[element.readAttribute
("customserializer")](element,value);
        return Form.Element.Serializers.textarea(element, value);
      }

ORIG
      default:
        return Form.Element.Serializers.textarea(element, value);

This means it checks for the existence of a serializer matching the custom
attribute's value, and calls it if it exists, or falls back to standard
behaviour.


2) In my own code, I set Form.Element.Serializers.date (adding a new
serializer)
     (at the moment i'm just prepending Date to the value, I'm going to
parse it and change it to an ISO format)

        Form.Element.Serializers.date = function (element,value) { return
'Date' + element.value };

3) In my own code, I added a custom attribute to my input box, which tells
prototype which serializer (non default) should be used

<input type='text' customserializer='date' name='Start_Date' id='Start_Date'
value='08/08/2007'>

or

<input type='text' name='Start_Date' id='Start_Date' value='08/08/2007'>
$('StartDate').writeAttribute('customserializer','date')

or

$(document.body).insert(new Element('input',{id:'Start_Date',
name:'Start_Date', value:'08/08/2007'
}).writeAttribute('customserializer','date'));

or

$(document.body).insert(new Element('input',{id:'Start_Date',
name:'Start_Date', value:'08/08/2007', customserializer:'date' }));


Now, when an input has a customserializer attribute, and i've added a
matching serializer function to the library (from an extensions.js file of
course), the element value can be preprocessed before the Ajax Request (or
consumption within the application)

Thoughts? Criticisms? Compliments?

I don't know if this is really fit for inclusion in core, since it's really
an edge case but I figured i'd share it up- i'll also put it on my blog at
some point in the future.
Admittedly, it's only 2 lines and adds what I think is a large amount of
flexibility to the serialization but it also relies on you knowing that you
can set that attribute for that behaviour.

Gareth

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Spinoffs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to