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
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---
Gareth, are you sure custom attributes is a good idea? Dan brings some good points regarding this issue: http://www.danwebb.net/2007/10/7/custom-attributes-and-class-names --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
kangax wrote:> Gareth, are you sure custom attributes is a good idea? > Dan brings some good points regarding this issue: > http://www.danwebb.net/2007/10/7/custom-attributes-and-class-names >Interesting article. Dan doesn''t mention using xml namespaces with xhtml but i''m wondering: assuming everyone stuck to xhtml, couldn''t the dojo example be written with an attribute dojo:type? I''ve seen some js libraries do this. Are there any other pitfalls to using xml namespaces other than incompatibility with html 4? Do namespaces work with dynamically inserted nodes? - Ken Snyder --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
I''m afraid bringing in xhtml would get us into more trouble http://www.autisticcuckoo.net/archive.php?id=2005/03/14/xhtml-is-dead : ) The issue is obviously debatable. --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
kangax wrote:> I''m afraid bringing in xhtml would get us into more trouble > http://www.autisticcuckoo.net/archive.php?id=2005/03/14/xhtml-is-dead > : ) > > The issue is obviously debatable.Very interesting indeed. What do list members think about XHTML versus HTML? It is interesting especially since the prototype and scriptaculous authors consistently use XHTML. IMO the root of the debate is what to do about IE being so far behind the curve. I think some of Ian''s ideas are made on bad assumptions (http://www.hixie.ch/advocacy/xhtml). 1) He assumes support of legacy browsers is important. In the 2 1/2 years since this article, almost all web authors have stopped targeting IE5 and Netscape 4. A lot of the problems with XHTML go away when legacy support is dropped. 2) He assumes that web authors cannot push browser technology. Here are a few examples of how authors can push technology: - If every page stopped working (e.g. showed an xml tree) in IE one day, Microsoft would have no choice but to release patches. - If every author made a feature rich page for non-IE browsers and a boring text-page for IE browsers, Microsoft would be highly pressured to come up to speed with Gecko, Opera, and WebKit. - From Microsoft''s perspective, it is important that their product work well in normal operating conditions. If 90% of web pages are XHTML by IE8''s release, maybe Microsoft would consider better support for both "fake" and "true" XTHML. In such a case, web authors could quickly convert their fake XHTML into true HTML with a few adjustments (e.g. add an XML header). 3) He ignores the importance of new browser technology such as mobile-device browsers. If all web pages were XHTML, CPU-savvy mobile devices would save a lot of cycles by assuming the document was well-formed. 4) He seems to be advocating making web pages that will last forever. In the evolving and fast-moving web world, there are a lot of exciting things coming along: SVG images, columnar layout, full PNG support, multiple background images, and super useful JavaScript such as getElementsByClassName and getElementsBySelector. I feel like the best way to pressure Microsoft is to start giving non-IE users a better experience by using these newly emerging technologies. Sure, SVG might fizzle out, but such risks are often worth taking. Basically, I think that Ian''s perspective is to sit and wait for Microsoft while I would rather fight and push! - Ken Snyder --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
The two reasons most users stay with old browsers are:
1. It shipped with the OS and they were too lazy to update (and
ignored the Windows update plea to do so)
- or -
2. They work in a company environment that requires a specific version
My opinion is that (1) went away after Windows XP significantly
replaced Windows 9x/ME and Windows 2000. Really, how many people are
running Windows 95? Go ahead, raise your hands. My guess is that for
security reasons if nothing else, scenario (2) doesn''t exist. IE has
had security problems that have been patched. It''s not perfect but
compared to IE 5, it''s much better. I still don''t use it :)
Given the facts that Netscape 4 was seldom preinstalled on systems
and that anyone smart enough to get it back then is probably smart
enough to get Firefox now, it''s unlikely that computers are running
NS4 by accident, laziness or stupidity.
IE 6, Safari and Firefox are all very real and have the predominant
chunk of the market. My policy has been to support Safari, Firefox
and IE 6+. There are edge cases were someone just has to run an
arcane or archaic browser, but how much of your underlying code do
you need to have wrapped up in supporting these cases? A simple: alert
(''Sorry, your browser hasn''t been supported since the
pre-Cambrian
era. Time to update.''); would do.
Note that companies who really do bet a lot on capturing casual
arrivals are willing to bet on platforms. Zillow.com, up until
recently, focused their development effort on making things work in
IE and Firefox. Safari was only recently added. They calculated that
any Mac user would be pissed off but not so much so that they would
have a problem downloading Firefox. Google documents have typically
lagged in supporting Safari. Again, these are big bets and tough
prioritizations but smart people are coming to the conclusion that it
is not a prudent use of their development resources to support every
browser all at once.
Just some thoughts...
On Nov 30, 2007, at 3:37 PM, Ken Snyder wrote:
>
> kangax wrote:
>> I''m afraid bringing in xhtml would get us into more trouble
>> http://www.autisticcuckoo.net/archive.php?id=2005/03/14/xhtml-is-dead
>> : )
>>
>> The issue is obviously debatable.
> Very interesting indeed. What do list members think about XHTML versus
> HTML? It is interesting especially since the prototype and
> scriptaculous
> authors consistently use XHTML. IMO the root of the debate is what to
> do about IE being so far behind the curve.
>
>
> I think some of Ian''s ideas are made on bad assumptions
> (http://www.hixie.ch/advocacy/xhtml).
>
> 1) He assumes support of legacy browsers is important. In the 2 1/2
> years since this article, almost all web authors have stopped
> targeting
> IE5 and Netscape 4. A lot of the problems with XHTML go away when
> legacy support is dropped.
>
> 2) He assumes that web authors cannot push browser technology.
> Here are
> a few examples of how authors can push technology:
> - If every page stopped working (e.g. showed an xml tree) in IE one
> day,
> Microsoft would have no choice but to release patches.
> - If every author made a feature rich page for non-IE browsers and a
> boring text-page for IE browsers, Microsoft would be highly
> pressured to
> come up to speed with Gecko, Opera, and WebKit.
> - From Microsoft''s perspective, it is important that their product
> work
> well in normal operating conditions. If 90% of web pages are XHTML by
> IE8''s release, maybe Microsoft would consider better support for
both
> "fake" and "true" XTHML. In such a case, web authors
could quickly
> convert their fake XHTML into true HTML with a few adjustments
> (e.g. add
> an XML header).
>
> 3) He ignores the importance of new browser technology such as
> mobile-device browsers. If all web pages were XHTML, CPU-savvy mobile
> devices would save a lot of cycles by assuming the document was
> well-formed.
>
> 4) He seems to be advocating making web pages that will last forever.
> In the evolving and fast-moving web world, there are a lot of exciting
> things coming along: SVG images, columnar layout, full PNG support,
> multiple background images, and super useful JavaScript such as
> getElementsByClassName and getElementsBySelector. I feel like the
> best
> way to pressure Microsoft is to start giving non-IE users a better
> experience by using these newly emerging technologies. Sure, SVG
> might
> fizzle out, but such risks are often worth taking.
>
> Basically, I think that Ian''s perspective is to sit and wait for
> Microsoft while I would rather fight and push!
>
> - Ken Snyder
>
>
> >
--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---
On Dec 1, 9:37 am, Ken Snyder <kendsny...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> kangax wrote: > > I''m afraid bringing in xhtml would get us into more trouble > >http://www.autisticcuckoo.net/archive.php?id=2005/03/14/xhtml-is-dead > > : ) > > > The issue is obviously debatable. > > Very interesting indeed. What do list members think about XHTML versus > HTML? It is interesting especially since the prototype and scriptaculous > authors consistently use XHTML. IMO the root of the debate is what to > do about IE being so far behind the curve.The debate should be about whether XHTML delivers any benefits over HTML, and the proper place to have it is at: news:comp.infosystems.www.authoring.html <URL: http://groups.google.com/group/comp.infosystems.www.authoring.html?hl=en&lnk=li>I has been discussed there many times by people who know what they are talking about: <URL: http://groups.google.com/group/comp.infosystems.www.authoring.html/browse_frm/thread/934948a25a434eea/d230081f00342c0f?hl=en&lnk=gst&q=HTML+vs+XHTML#d230081f00342c0f><URL: http://groups.google.com/group/comp.infosystems.www.authoring.html/search?group=comp.infosystems.www.authoring.html&q=xhtml+vs+html>> 2) He assumes that web authors cannot push browser technology.You assume that XHTML is *required* to "push browser technology".> Here are > a few examples of how authors can push technology: > - If every page stopped working (e.g. showed an xml tree) in IE one day, > Microsoft would have no choice but to release patches.That isn''t "pushing technology", that''s simply wishing that everyone will write pages that deliberately don''t work in IE. You may as well just detect the browser and show an empty page.> - If every author made a feature rich page for non-IE browsers and a > boring text-page for IE browsers, Microsoft would be highly pressured to > come up to speed with Gecko, Opera, and WebKit.That is just your first point re-factored slightly.> - From Microsoft''s perspective, it is important that their product work > well in normal operating conditions. If 90% of web pages are XHTML by > IE8''s release, maybe Microsoft would consider better support for both > "fake" and "true" XTHML.It is not helpful to introduce impossible, idealistic scenarios. And how is that "pushing technology"?> In such a case, web authors could quickly > convert their fake XHTML into true HTML with a few adjustments (e.g. add > an XML header).Spot the typo. :-) Most authors seem to believe that they can write their pages as XHTML and simply serve it as HTML. The position has been discussed at length in the above links, but simply results in them serving invalid HTML, which really defeats the purpose of attempting to use XML in the first place.> 3) He ignores the importance of new browser technology such as > mobile-device browsers. If all web pages were XHTML, CPU-savvy mobile > devices would save a lot of cycles by assuming the document was well-formed.I think you are way off the track there. I have no idea how many mobile devices support XHTML, but I expect it is a very small number. You also assume that there is an issue with parsing HTML that is fixed by assuming XHTML. I don''t think anyone has identified the first issue as a problem, so the second is moot. Also, you seem to be assuming that XHTML will usher in a new age of interactive web pages, which infers that a zillion more CPU cycles will be wasted delivering visual effects that, for many, are just plain annoying. So is CPU power a real issue, or just a red herring? You still haven''t provided a reason why XHTML is better> 4) He seems to be advocating making web pages that will last forever. > In the evolving and fast-moving web world, there are a lot of exciting > things coming along: SVG images, columnar layout, full PNG support, > multiple background images, and super useful JavaScript such as > getElementsByClassName and getElementsBySelector.None of which require XHTML, nor does supporting them mean ditching HTML.> I feel like the best > way to pressure Microsoft is to start giving non-IE users a better > experience by using these newly emerging technologies. Sure, SVG might > fizzle out, but such risks are often worth taking.So your real motive is to pressure Microsoft into supporting XML in IE. You have yet to put forward any practical benefits of XHTML over HTML.> Basically, I think that Ian''s perspective is to sit and wait for > Microsoft while I would rather fight and push!Knock yourself out, but you should be doing it in a group or forum that has some impact on Microsoft''s plans for IE. -- Rob --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
> ... > news:comp.infosystems.www.authoring.html > http://groups.google.com/group/comp.infosystems.www.authoring.html?hl=en&lnk=li > > It has been discussed there many times by people who know what they aretalking about:> http://groups.google.com/group/comp.infosystems.www.authoring.html/browse_frm/thread/934948a25a434eea/d230081f00342c0f?hl=en&lnk=gst&q=HTML+vs+XHTML#d230081f00342c0f > > http://groups.google.com/group/comp.infosystems.www.authoring.html/search?group=comp.infosystems.www.authoring.html&q=xhtml+vs+html > ... > RobThank''s Rob--that is exactly what I''m looking for. I''ll definitely visit links you''ve posted. I''m interested in other people''s conclusions in the debate about how to serve web pages. I don''t mean to stir debate on this list, just to hear other people''s _conclusions_ and what type of research they recommend. I consider rails developers to be high caliber and value their opinions. The main idea of my comments is to point out that it isn''t _always_ smartest to adopt the best and most correct technology. For example, adopting Betamax instead of VHS you might get stuck with a bunch of Betamax movies with no way to watch them. And you can''t just sit around and wait for the next thing; when you start buying DVD''s, Blu-Ray discs will come out; when you buy Blu-Ray discs, some new-fangled holographic or florescent multilayer disc will come out. Probably not a prominent point in this debate, but something Ian seems to miss-- and seeing something missed makes me interested to find out more. - Ken Snyder --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---