-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> I think that it almost always safe to spider the results of a form; the
> only question is whether to post the form in the first place.
ALWAYS post the form data back _first_, before fetching the results
of that form (in the case of a POST). For other GET-based forms, generalized
on the security concerns of the person running it, you can get by with the
form fields in the URI in most cases. This of course, doesn't count the
logic needed Palm-side to draw form elements; dropdowns, selects, lists,
checkboxes, radio, etc. and the logic to parse those items (grouped radio
buttons for example, default checkboxes, etc.)
> Sometimes the data will be known in advance. (Example: plucking a
> weather or map site for a known location.)
Advance or not, POST first, always, regardless of whether or not you
can "predict" the outcome of the form. It's the right way to do it, and it's
scalable. Using this approach, you don't have to have two types of form
processing cases in your code; one for predicted outcomes, and one for
posted outcomes.
> To get the data off - plucker can already export an url to memopad.
> Could it also export data? I think there was an experimental version (by
> masakaze?) that took the memopads as new urls to launch, or some such.
Exporting a url to memopad doesn't directly equate to processing
form data. Polluting MemoDB.pdb with Plucker form data is also not the best
approach to solving the problem. What if we just had a generalized
PlkrFormData.pdb for Plucker form metadata, and had it keyed to each doc
that needed to seek into it.
Of course, this brings up another issue about "orphaned" form data,
if I populate a form, data gets stored into the PlkrFormData.pdb metadata
file, and then I delete the doc itself, before I sync that form data
upstream back to the server that it came from. Now there's "stale" data in
the form data metadata cache.
What about external storage cards where docs may reside, with form
data in PlkrFormData.pdb, but are "offline"? How do you begin to manage what
is truly "gone", and what is just "offline" until a later date?
> (1) recognize variables, including default values
It's all just parsing, of course, depending on how the form is
constructed. Multiply the amount of bad HTML we've seen so far, times about
2-3 and you'll be dealing with that level of brokenness in forms, for sure.
> (2) allow editing the values
New Palm-side form elements have to be created and posted into the
view. This means at a bare minimum:
- text entry fields
- checkboxes
- radio buttons
- dropdown select lists
- option select lists (multi-select?)
What about "changing" form data? Is it WORM? Or do we allow the user
to go back into an "Edit forms for this page" type of (Plucker) form, and
change the data they've previously entered? If you just post it to
MemoDB.pdb, that could get pretty ugly.
> (3) put them into a memo (or even a new database, so long as it had the
> backup bit set)
I don't think we should be backing up form data to the desktop..
Once you sync, the form data is posted, and it no longer has context, and
should be tossed..
> As in, should I look at what I would need to do on the parser side, or is
> this hard enough that I'll have to wait until I'm ready to do both ends?
It's going to require a quorum, I think, on these issues.
> javascript support would not be in version 1 of forms processing. :D
That's a relief. Since Javascript has no place in forms, any forms
which use it for processing, are not using HTML, and should henceforth, be
ignored.. If it doesn't work in a text-mode browser (lynx, links, etc.) then
Plucker should not support it. Just my strong opinion on the matter. It's a
slippery slope from here to supporting all kinds of other non-HTML "pseudo
HTML" that is out there in the wild.
d.
perldoc -qa.j | perl -lpe '($_)=m("(.*)")'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE+/J06kRQERnB1rkoRApVNAKCFd4IcCmuIRYwJtCFwC5Zizr7MiQCfVeF6
nHy1zJyOOyIvpYsvQHHtZCo=
=vA0/
-----END PGP SIGNATURE-----
_______________________________________________
plucker-list mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-list
