[jifty-devel] RE: [Jifty-commit] r2859 - in Jifty-DBI/trunk:lib/Jifty/DBI

[Edgar Whipple]

Jesse Vincent wrote:
>> Perhaps the/a next step would be to identify a portfolio of basic column
>> types, and implement them at first as just a pod full of column
>> examples.
>>     
>
> Ok. a rough list off the top of my head:
>
> * String
> * Int
> * Float
> * Money (composite of currency and value)
> * Email Address
> * URL
> * Password
> * Tags  (which is actually a column with a whole nother able behind it)
> * Big block of text
> * Image
> * File
> * Avatar/Icon
> * List fed from a static source
> * List fed from a collection
> * List fed from a computation
> * Version (?)
> * Boolean
>
>   
We might want to expand that to include different presentations. For
comparison, here is a list of field types from a certain Other Web
Framework.

Node Reference
    Select List
    Autocomplete Text Field
Integer
    Text Field
    Select list
    Check boxes/radio buttons
    Single on/off checkbox
Decimal
    Text Field
    Select list
    Check boxes/radio buttons
    Single on/off checkbox
Text
    Select list
    Check boxes/radio buttons
    Single on/off checkbox
    Text Field
User Reference
    Select List
    Autocomplete Text Field
Computed
    Computed
Date
    Select List
    Text Field with strtotime validation
    Text Field with javascript pop-up calendar
Datestamp
    Select List
    Text Field with strtotime validation
    Text Field with javascript pop-up calendar
E-Mail
    Textfield
Link
    Text Fields for Title and URL
Matrix Field
    Textfields
View Reference
    Select List
Voting API: Choice
    Choice
Voting API: Score
    Score
Voting API: Percent
    Percent

A couple things spring to mind:

-- The types vary both by storage type and by presentation mode (and in
some cases validation).

-- A good, flexible set of baseline type/column definitions might go a
long way toward lowering Jifty's first-use barrier.

-- I'm thinking even more that pluggable U-D type definitions would be a
Good Thing.

-- If we implement user-defined types, we can expect at some point
people will produce modules that do nothing but provide collections of
type definitions for columns, records, and/or tuples. Jifty already
accommodates that, but I have specifically in mind the publishing of
CMS-related *components* that don't do anything by themselves. There may
be additional concerns, especially in namespace-related decisions.

-- The J::Plugin pod says "Actions and models under a plugin's namespace
are automatically discovered and made available to applications." Can
this accomodate partial models? (The question might make more sense
after post about "composable node types".) (I confess I haven't looked
into Jifty's existing plugin features yet.)

Edgar