Warning: Can't synchronize with repository "(default)" (Unsupported version control system "svn": No module named svn). Look in the Trac log for more information.

Ticket #1675 (closed enhancement: fixed)

Opened 11 years ago

Last modified 9 years ago

Create "meaningful" field types for SQLAlchemy table definitions

Reported by: mramm Owned by: anonymous
Priority: normal Milestone: 2.1rc1
Component: TurboGears Version: trunk
Severity: normal Keywords:
Cc:

Description

We're not actually sure where this ought to go, but it would be interesting to have a set of meaningful types for SQLAlchemy table object definition so that we can later introspect those objects and build up validators, or choose widgets more intelligently.

So, given table definitions like this:

table = Table('page', meta,
   Column('id', Integer, primary_key=True),
   Column('location', URL()),
   Column('author',  Unicode(64),
   Column('e-mail', EMail()),
   )

We could introspect the model objects as is done here:

 http://dpaste.com/30732/

And use that type information to choose widgets for rendering and FormEncode validators for automatic schema generation.

These could also be used to check field validity at the model-object level.

Change History

comment:1 Changed 11 years ago by paj

Interesting idea; the model certainly looks very neat.

In the short term though, I'd suggest using the info tag on SA columns. This is a bucket for storing arbitrary information. I am using this with a hacked version of fieldfactory to do more-or-less what you propose.

Column('location', String(64), info={'validator': UrlValidator?})

comment:2 Changed 11 years ago by mramm

Info seems like a very useful tool for us as far as model introspection goes.

Though I still like the fact that meaningful column types could enforce additional data constraints at the model level.

comment:3 Changed 11 years ago by mramm

  • Milestone changed from 2.0 to __future__

This would require changes to SA to work in a reasonable way, and raises lots of issues. Perhaps we can do it in 2.1.. ;)

comment:4 Changed 10 years ago by lszyba1

How is this different then automatic widget generation in something like rum? I figured the project like rum would be able to figure out proper match from sa column type to widget type ?

comment:5 Changed 10 years ago by jorge.vargas

  • Milestone changed from __future__ to 2.x

both rum and sprox, now provide a very nice solution for this. Yet I still think it will be nice to insert that functionality into SA itself.

comment:6 Changed 10 years ago by percious

I think this ticket should be closed because sprox handles this issue.

comment:7 follow-up: ↓ 10 Changed 10 years ago by percious

  • Milestone changed from 2.x to 2.1

comment:8 Changed 10 years ago by percious

Im -1 on this issue, can we close it out?

comment:9 Changed 10 years ago by jorge.vargas

  • Status changed from new to closed
  • Resolution set to fixed
  • Type changed from defect to enhancement

+1 use sprox

comment:10 in reply to: ↑ 7 ; follow-up: ↓ 11 Changed 10 years ago by mramm

Replying to percious:

Unless I am missing something here I don't think sprox does the above at all, so I'm a bit confused. How does it handle this issue?

comment:11 in reply to: ↑ 10 Changed 10 years ago by percious

Replying to mramm:

Replying to percious:

Unless I am missing something here I don't think sprox does the above at all, so I'm a bit confused. How does it handle this issue?

I'm just not sure what the _purpose_ of the special fields is. I say sprox is a replacement since it provides ways to use db schema to generate meaningful forms.

comment:12 Changed 9 years ago by percious

  • Milestone changed from 2.1 to 2.1rc1
Note: See TracTickets for help on using tickets.