A prototype form generation/handling (CRUD) framework

1 view
Skip to first unread message

Ivo van der Wijk

unread,
Oct 24, 2005, 11:52:31 AM10/24/05
to turbo...@googlegroups.com
Hi All,

I've been thinking for a while about a toolkit that can generate
"views" on top of SQLObjects automatically through a minimal (but
extendible) set of configurations/attributes.

Recently I discovered TurboGears and although it doesn't seem to
provide such a toolkit yet, it seemed like an excellent platform to
prototype such a system.

For anyone who's interested, I've created a first prorotype, capable
of handling simple SQLObject definitions (with ForeignKeys though) and
generating create/edit/view and list views on top of it.

The sample application is "racetrack", an hour registration utility
(though it doesn't work at all yet, except presenting the forms and
storing the data :), the toolkit itself is included and named
"turboengine"

Documentation and 98% of the required functionality is missing, but
it's still interesting to see what people thing of my approach/ideas.
All feedback is very welcome.

The prototype is at:

http://m3r.nl/~ivo/tmp/racetrack20051024.tgz

It somewhat resembles catwalk, but it's meant to be extendible (which
catwalk isn't)

(I'll try to provide a list of actual GOALS as soon as possible as well :)

Regards,

Ivo

--
Drs. I.R. van der Wijk / m3r Consultancy B.V.
Linux/Python/Zope/Plone and Open Source solutions
PO-box 51091, 1007 EB Amsterdam, The Netherlands
Email: ivo <at> m3r.nl

Michele Cella

unread,
Oct 24, 2005, 4:37:14 PM10/24/05
to TurboGears
I've added (hope you don't mind Kevin) your work to this turbogears
wiki page:

http://trac.turbogears.org/turbogears/wiki/SimpleAdminIdeas

Maybe you should also take a closer look at this discussion:

http://tinyurl.com/9afbk

Ciao
Michele

David Bernard

unread,
Oct 25, 2005, 7:44:50 AM10/25/05
to TurboGears
Michele Cella wrote:
> I've added (hope you don't mind Kevin) your work to this turbogears
> wiki page:
>
> http://trac.turbogears.org/turbogears/wiki/SimpleAdminIdeas

I take a look over wiki and proposal about CRUD. And I've got a
question :
Why generate form at runtime, why not at design time ?
May be a tool could generate from the SQLObject :
* the controler
* the templates

Then developer could customize like they want the result.

Ronald Jaramillo

unread,
Oct 25, 2005, 7:55:54 AM10/25/05
to turbo...@googlegroups.com
There is an icky problem when a new iteration of your application/
model has to be merged with
the existing (and probably already customised) templates.

If you could keep the templates and the customisations apart in some
way, maybe it could work. But what do I know, the devil is in the
details =)
Cheers
Ronald

Michele Cella

unread,
Oct 25, 2005, 8:33:27 AM10/25/05
to TurboGears
Today I was thinking exactly the same thing.

AFAIK, at least from looking at the RubyonRails screencast, that's how
the ROR scaffolding thing works.
They have a set of scripts, scaffold it's one of these, and you can do:

./script/generate scaffold ModelName ControllerName

With this you get a view and a controller properly populated which you
can elaborate on.

There is also a dynamic scaffold function that you can call from inside
your controller:

scaffold :ModelName

If I got it correctly this solution suffers from the problems Ronald
already pointed out.

Ciao
Michele

Ivo van der Wijk

unread,
Oct 25, 2005, 10:10:24 AM10/25/05
to turbo...@googlegroups.com
On 10/25/05, Michele Cella <michel...@gmail.com> wrote:
>
> Today I was thinking exactly the same thing.
>
> AFAIK, at least from looking at the RubyonRails screencast, that's how
> the ROR scaffolding thing works.
> They have a set of scripts, scaffold it's one of these, and you can do:
>
> ./script/generate scaffold ModelName ControllerName
>
> With this you get a view and a controller properly populated which you
> can elaborate on.
>

I agree. Generating code is usually not what you want (though it
provides a nice quickstart, like the skeleton "tg-admin quickstart"
providers.

My idea's are somewhat inspired by the way the Plone/Zope3 machinery
works - generate "defaults" out of standard definitions (either
existing definitions like interfaces or sqlobject definitions) or
explicit ones (like formdefinitions). On top of this, you should be
able to customize everything through html fragments/macro's, skinning,
python inheritance, etc.

I'l not really sure how all of this fits into TG - I'm too
inexperienced with it at this moment :)

Kevin Dangoor

unread,
Oct 25, 2005, 11:08:27 AM10/25/05
to turbo...@googlegroups.com
On 10/25/05, Ivo van der Wijk <vlad...@gmail.com> wrote:
> My idea's are somewhat inspired by the way the Plone/Zope3 machinery
> works - generate "defaults" out of standard definitions (either
> existing definitions like interfaces or sqlobject definitions) or
> explicit ones (like formdefinitions). On top of this, you should be
> able to customize everything through html fragments/macro's, skinning,
> python inheritance, etc.

My thoughts exactly.

> I'l not really sure how all of this fits into TG - I'm too
> inexperienced with it at this moment :)

This is what I'm working on... there are quite a few form solutions
out there, and I'm going to make an attempt to see how they fit into
TurboGears. It's my goal that TurboGears 0.9 has something in this
area, so that we can collectively look at it and decide if it's a good
position to start from for 1.0.

Kevin

Kevin Dangoor

unread,
Oct 25, 2005, 11:09:19 AM10/25/05
to turbo...@googlegroups.com
On 10/24/05, Michele Cella <michel...@gmail.com> wrote:
>
> I've added (hope you don't mind Kevin) your work to this turbogears
> wiki page:
>
> http://trac.turbogears.org/turbogears/wiki/SimpleAdminIdeas

I don't mind at all! I appreciate very much when people update the
wiki... I'll just have to figure out a spam solution before the wiki
gets attacked like the pysqlite wiki.

Kevin

Ian Bicking

unread,
Oct 25, 2005, 11:47:55 AM10/25/05
to turbo...@googlegroups.com
Michele Cella wrote:
> Today I was thinking exactly the same thing.
>
> AFAIK, at least from looking at the RubyonRails screencast, that's how
> the ROR scaffolding thing works.
> They have a set of scripts, scaffold it's one of these, and you can do:
>
> ./script/generate scaffold ModelName ControllerName
>
> With this you get a view and a controller properly populated which you
> can elaborate on.

This might be slightly more sensible in a Rails context, as they are
already using runtime code generation for a lot of their
metaprogramming. I.e., they generating a function body string and eval
it. So it's not much harder to just write it to disk.

IMHO, code generation is lame. But anyway... one kind of code
generation I *wouldn't* think was lame would be HTML generation,
possibly with Subway/htmlfill_schemabuilder annotations. What's useful
about this is that it gives a really concrete starting point for doing
design work, while getting rid of a lot of otherwise necessary tedium
(since writing a large HTML form from scratch is annoying). Generating
Python code *should* be unnecessary, as it is better to make more
expressive constructs in Python; but the same kinds of abstractions
simply aren't available in HTML.

--
Ian Bicking / ia...@colorstudy.com / http://blog.ianbicking.org

Lee McFadden

unread,
Oct 25, 2005, 11:55:51 AM10/25/05
to turbo...@googlegroups.com
A simple logon may help to stop the automated spammers, but the manual
ones will soon find the password.

I believe that trac (via apache) can be set up to authenticate against
MySQL... Again, that would be hassle but would stop the spammers. It
just depends how much attention the wiki is going to attract.

An alternative to the wiki may be to use a writeboard[1] or some
similar collaboration tool? That is still hassle though, perhaps even
more so.

Lee

[1] http://www.writeboard.com/

David Bernard

unread,
Oct 25, 2005, 3:01:57 PM10/25/05
to TurboGears
My proposal is a tool that generate :
* controller
* html templates
* a checksum (md5) for all generated files

The generated file could be used as is or could be modified.

If the model change :
* if checksum matches, then file could be regenerated
* else (or if no checksum), file generated is prefixed with "new_"

Modication in the model could be apply manually into the controller and
html, like for the database.

Runtime widget generation need +/- to understand the widget generation
framework and how-to customize it. If you look at zope3, it's some
study and configuration. In the case of a tool, users don't need to
understand/learn a new framework to customize its application. They
only need to learn it if they want to customize the generation (adding
widgets, create a new set of widget,...)

Ivo van der Wijk

unread,
Oct 26, 2005, 2:26:31 AM10/26/05
to turbo...@googlegroups.com
On 10/25/05, David Bernard <dwa...@java-fan.com> wrote:
>
> My proposal is a tool that generate :
> * controller
> * html templates
> * a checksum (md5) for all generated files
>
> The generated file could be used as is or could be modified.
>
> If the model change :
> * if checksum matches, then file could be regenerated
> * else (or if no checksum), file generated is prefixed with "new_"
>

So you need to apply your changes over an over again to newly
generated files? I know that is not what I want and I doubt if it'll
work for others.

I like the Plone/Archetypes way: Yoi can do verything through a schema
definition and customize alot (i.e. by defining your own widget
macros, standard css customization, header/footer customization) and
eventually, you can always create your completely own template. I
guess that template could be generated (as a starting base) but it
should not be the mailn way of creating forms/views

> Modication in the model could be apply manually into the controller and
> html, like for the database.
>
> Runtime widget generation need +/- to understand the widget generation
> framework and how-to customize it. If you look at zope3, it's some
> study and configuration. In the case of a tool, users don't need to
> understand/learn a new framework to customize its application. They
> only need to learn it if they want to customize the generation (adding
> widgets, create a new set of widget,...)
>
>

My goal (with TurboEngine) is to be able to create something
acceptable/usable (but not perfect) without touching *any* html. I'm
not planning on building a complex framework with a steep learning
curve, but it's unavoidable to introduce some new
concepts/classes/rules.

Just because everyone "knows" HTML doesn't make it the correct
approach to do further customization :)

Regards

David Bernard

unread,
Oct 26, 2005, 3:23:59 AM10/26/05
to TurboGears
> So you need to apply your changes over an over again to newly generated files?

No, generated files are suggestions. So, from the "new_*" files, the
user could take the missing widget to copy it into his own "customized"
files. User could change the model without generate files.

I like also the Plone/Archetypes (only read doc about it a year ago).
Those framework doesn't support all customization, But the user could
need to be able to manage the layout, to add help anchor,... And do
this with a full api is like provide a api for desktop gui (wxwidget,
Qt, Gtk...)

Reply all
Reply to author
Forward
0 new messages