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

[Edgar Whipple]

Andrew Sterling Hanenkamp wrote:
> Well, I think the simple solution would be to add a new API function
> called during schema init that could hold the warning. However, I think
> a better solution is to expand the type system to make the warning
> unnecessary.
>
> Edgar Whipple's "user-defined data types" suggestion posted to the list
> recently looks like a good start in this direction. I could see the
> built-in types providing structure to this problem so that it's harder
> to make the mistake, while providing flexibility to easily customize the
> types if you really want to.  Then you provide a Storable type built-in
> that bundles "blob" with the Storable filter.
>
> Then these object types become the basic solutions and examples in the
> tutorial and such. Type customization and filters become an advanced
> topic. If you go off and customize the Storable type to use "text"
> without making the other requisite changes or use the Storable filter on
> your own, it's your own fault when it blows up.
>   
I had two things in mind with the U-D types.

First, as with a pure database app, it bolsters conceptual and syntactic
consistency and thus helps with bug avoidance. I grok this with great
depth, as the primary database app at work *doesn't* use U-D types at
all, and sometimes it's a nightmare.

Second, I'm trying to outline a Jifty-based design that duplicates one
of Drupal's best features, composable node types. I'll post separately
about what I'm trying to do with that.

So, Andrew's suggestion makes a lot of sense.

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. That would give the new guy a set of cut-and-paste components
to help him get started. It would also provide an initial feature
specification for the real implementation. (Damian Conway's suggestion
about play-testing your interfaces before implementing them comes to mind.)

Based on what Andrew wrote, it seems plain that a class-based approach
to U-D types would be better than a string- or list-based one. But,
would it be better to have the U-D type be the class of the column data,
or should it be the class of the metadata object that describes the
column data? In other words, should we have a separate subclass for each
U-D type, or just one, each instance of which represents a U-D type? The
latter seems better, top of my head, but I'm biased by my
composable-node-type agenda.

Great, now I'm going to be hallucinating class-inheritance diagrams all
day. :-)

Edgar