Hi.
I've just been learning how to get client side page updated with
server side progress and to allow the process to be stopped by the
client.
Client runs a periodic updater to ask the server what progress is
being made on its task.
Client starts a server process which takes a LONG time.
Serve
On Feb 22, 7:51 pm, "Tobie Langel" <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I've committed my work on JSON to the new ajax branch Mislav just set
> up (thanks!).
How are you planning to do date serialization for json? I did some
work in Rails and noticed it used "Thu Mar 08 15:41:36 CST 2007",
whi
On Mar 8, 3:43 pm, "Rick Olson" <[EMAIL PROTECTED]> wrote:
> How are you planning to do date serialization for json? I did some
> work in Rails and noticed it used "Thu Mar 08 15:41:36 CST 2007",
> which is no good. I wrote a json plugin for rails that uses the fjson
> gem to parse incoming js
The JSON format doesn't define a format for date.
http://www.json.org/
You'd need to use either a string or a number, and that decision
should be made by the client and/or the server, not the serlializer.
(I haven't checked the code to figure out whether it treats dates as
an object (bleh)
> After reflecting on my response, above, I figured you were probably
> aware of the JSON limitation, and simply disagree with me regarding
> the library's responsibility in this manner. =)
Madness. I'll add it myself then. I can't see why you'd pass
xmlschema dates around and want to treat th
You've led me to an interesting thought, though. Would you support
tweaking Form.serialize and/or $F to check for the presence of an
onSerailize callback attached to the element, whose result is
returned instead of element.value if the callback exists? It would
make it easier for you to
On Mar 8, 4:00 pm, "Rick Olson" <[EMAIL PROTECTED]> wrote:
> Madness. I'll add it myself then. I can't see why you'd pass
> xmlschema dates around and want to treat them like strings.
You wouldn't, but all other data types can be parsed by a simple eval
call. (Obviously you'd want to sanitize,
On 3/8/07, Tom Gregory <[EMAIL PROTECTED]> wrote:
>
> You've led me to an interesting thought, though. Would you support
> tweaking Form.serialize and/or $F to check for the presence of an
> onSerailize callback attached to the element, whose result is
> returned instead of element.value if the c
> And at that point, you've introduced a weird convention for treating
> some strings differently from others. Better, in my opinion, to let
> the developer introduce whatever convention works best for him.
> Date.parse makes this easy.
That is true... the ruby parser uses a tokenizer, so I was
I had to write something similar back before I knew about prototype (running
an import of a csv in a web app) and wow was it a hassle.
I had all sorts of problems with no-more-than-2 simultaneous connections
(needed one for the long running process, one for the updates, and one for
the original pag
Actually, Douglas Crockford's JSON parser is a bit different, in order
to deal with issues such as Date format. From http://www.json.org/js.html:
The optional filter parameter is a function which will be called for
every key and value at every level of the final result. Each value
will be replace
11 matches
Mail list logo
