-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> Correct, so the default really should be not to submit forms. Suppose I
> wanted to extend either PyPlucker or JPluck to do that, what would be a
> good rule to decide when a form is to be treated like a link and when not?
Here's a problem.. not everyone uses a Palm in a cradle to sync
their Plucker content. What this means, is that with the implementation of
forms support in Plucker, you now need a way to fetch the form data back OFF
the Palm handheld, post it, parse and collect the results of that post, and
then push that back to the Palm. Definately changes the way Plucker works,
and the earlier main design goals (client driven, disconnection operation).
> I can think of one criteria that should prevent submitting a form: if the
> form has visible input fields, then an automated posting probably makes no
> sense. Unfortunately the opposite is not true: even if all fields are
> hidden, posting the form might still have undesired side effects.
What about forms that (incorrectly) use Javascript to validate
input, or draw buttons and checkboxes? There are quite a few like this (in
fact, Palm's own devzone site uses one. If you have Javascript disabled, you
see one-less button on the screen, which causes the form submit to fail).
d.
perldoc -qa.j | perl -lpe '($_)=m("(.*)")'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE++ta0kRQERnB1rkoRAlGCAJ9A3XDEiANhwYNLMmi2t0a95TfGAQCfRpIP
+6CRkB0u1m9XBc8AD/Yag5g=
=h1pO
-----END PGP SIGNATURE-----
_______________________________________________
plucker-list mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-list
