TITLE OF PAPER: FormEncode (some thoughts on framework design)
URL OF PRESENTATION: _URL_of_powerpoint_presentation_
PRESENTED BY: Ian Bicking
REPRESENTING: _name_of_the_company_they_represent_

CONFERENCE: PyCON 2004
DATE: 20040326
LOCATION: _venue_and_room_in_venue_

--------------------------------------------------------------------------
REAL-TIME NOTES / ANNOTATIONS OF THE PAPER:
{If you've contributed, add your name, e-mail & URL at the bottom}

Really this is thoughts about frameworks dsicvoered while working on FormEncode
(30 mins not enough time to describe FormEncode well enough for people to use it)

Like to be able to get up and running quickly (remember: print "hello world"?)
Unfortunately, this is hard enough with even some standard libraries (e.g. email); it's even hard with a framework, where you can't just "use" it but must interact with it (you call it and it calls you).

How to make a framework suck less

1. Aspire to be a library instead of a framework
   (easier to just use)
1b. Use built-in data structures
1c. Clever is bad
2. Don't require people to reorganize their code
3. Don't require people to reorganize their thoughts
   (this is targeted at MVC design for web interfaces)
4. [missed it]
5. Let the programmer (user) keep control wherever possible.
6. Delegate callback and customization completely (even if it means subclassing)
7. Use rich descriptions:
7b. Dont' be afraid of using a lot of keyword args
    (identify common patterns and make them easy to use)
8. Facilitate programmatic access
   If a user finds specific patterns are useful, they can form their own wrapper / higher-level interfaces.
   Avoid require configuration (either data files or objects)
9. Make the system hackable [in the good sense]
   Walls put up by encapsulation become barriers that get in the way of just getting stuff done
   (but provide guidance for the "right way")
   example - FormEncode allows you to pass in a "state object" which it never looks at, but passes back to all the callbacks - this allows the application to provide its own environment
10. Be humble.
    "When you explain something and they don't understand, it's your fault":
    an API is an explanation of how to use the system.

Q: Ever possible to get a library right the first time?
A: No. :-)

Q: Requiring libraries outside of std lib -- distribute with, or point to them?
A: For extra functionality, load lazily and give warning. Pure Python code put in subpackage with "ugly" name. Extra 10K not worth effort. [may be misquoting here]

Q: How usable is it?
A: As of three or four days ago, fairly usable. I'm open to suggestions (but that means the API might change)

Q: Roadmap?
A: Not yet. Documentation not yet totally reliable.

Q: Reports on use with web templating system?
A: No. Currently generates its own HTML. Starting on a system that introspects the HTML to eg. put up default values.

Q: Push execution down into browser (using Jython)?
A: THought experiment only; not using in that environment. Design doesn't rule it out.

Q: [followup] compare to Jkarta validating framework
A: another idea to use LivePage to query the server without submitting the whole form

Q: state object correct place to cause one field to be invalid based on another?
A: no, use form validator


--------------------------------------------------------------------------
REFERENCES: {as documents / sites are referenced add them below}

<http://formencode.org>

--------------------------------------------------------------------------
QUOTES:



--------------------------------------------------------------------------
CONTRIBUTORS: {add your name, e-mail address and URL below}
Ted Leung, twl@osafoundation.org, http://www.sauria.com/blog
Russell Finn, rsf@sprucehill.com, http://www.sprucehill.com/rsf/blog/ [future]


--------------------------------------------------------------------------
E-MAIL BOUNCEBACK: {add your e-mail address separated by commas }



--------------------------------------------------------------------------
NOTES ON / KEY TO THIS TEMPLATE:
A headline (like a field in a database) will be CAPITALISED
    This differentiates from the text that follows
A variable that you can change will be surrounded by _underscores_
    Spaces in variables are also replaced with under_scores
    This allows people to select the whole variable with a simple double-click
A tool-tip is lower case and surrounded by {curly brackets / parentheses}
    These supply helpful contextual information.

--------------------------------------------------------------------------
Copyright shared between all the participants unless otherwise stated...