oh... good one! didn't realize you could do that! :) as part of the
admin, would it be worth it to put that functionality as a "pre-setup"
of apps? hum.... jquery + drag&drop in to a db design canvas for
designing tables? or while we are on it, maybe a lot of app setup
steps could be done this way (even permissions - after choosing the
permission type, you drop a grid onto the permission canvas, then
maybe a group object into the CRUD object we just threw in. The CRUD
object is_clickable which the event triggers one of your very cool
widget_builder widgets appear where you fill then close. then we throw
a couple of user object into the group objects.... etc.) then why
not, draw the app's basic layout in the same manner? we have an app
canvas, where we could drop form objects, grid objects, etc... where
they would also have the is_clickable flag set to them, where the
event would, again, provoke a widget_build window to appear (where we
could set basic/available properties, link to tables, etc...).... then
isn't our app just about setup (at least a good part of the way)?
just a thought :)
Mart
On Sep 17, 9:54 am, mdipierro <mdipie...@cs.depaul.edu> wrote:
> Before we do this, I suggest you install plugin_wiki and do
>
> db.define_table('lists', Field('name'))
>
> def create_list():
> return dict(form=crud.create(db.lists))
>
> def edit_list():
> mylist=db.lists(request.args(0)) or redirect(URL('create_list'))
> return dict(items=plugin_wiki.widget('tags',db.lists,mylist.id))
>
> Instead of
>
> db.define_table('list_items', Field('list',db.lists),
> Field('name'))
>
> Plugin_wiki defines for you a many to many:
>
> db.define_table('plugin_wiki_tag',
>
> Field('name',requires=IS_NOT_IN_DB(db,'plugin_wiki_tag.name')),
> Field('links','integer',default=0,writable=False),
>
> Field('created_by',db.auth_user,writable=False,readable=False,
> default=auth.user_id),
> Field('created_on','datetime',
>
> default=request.now,writable=False,readable=False),
> format='%(name)s', migrate=plugin_wiki_migrate)
> db.define_table('plugin_wiki_link',
> Field('tag',db.plugin_wiki_tag),
> Field('table_name'),
> Field('record_id','integer'), migrate=plugin_wiki_migrate)
>
> Then you can move code into your app, rename the tables and actions,
> delete plugin_wiki, and you get what you want.
>
> On Sep 17, 5:13 am, Omri <omri...@gmail.com> wrote:
>
> > Hello,
>
> > I'm writing a relatively big database application. A small part of it
> > requires me to handle lists of values, where every list can only exist
> > once, and where each item in the list can only exist once (but
> > different lists can have items named the same way).
> > A simplified model is:
>
> > db.define_table('lists', Field('name'))
> > and
> > db.define_table('list_items', Field('list',db.lists), Field('name')).
>
> > (there exists more fields but they are irrelevant to the current
> > case).
>
> > I am now writing an interface to define new lists. I would like to use
> > SQLFORM to generate the forms required. I would like to use the
> > validators IS_NOT_EMPTY() and IS_NOT_IN_DB() to make sure there will
> > not exist two lists with the same name. The problem is that I would
> > also like to make a similar validation on the items of the list, but
> > to restrict the IS_NOT_IN_DB() to a set containing the list items.
>
> > In the book it gives an example using SQLFORM.factory() on how this
> > should be done, but when I simply use SQLFORM(db.list_items) I don't
> > know how to access the different fields to add a requires validator in
> > the action.
>
> > I've tried looking in the book and the group but was unable to find a
> > way to do so.
>
> > Thanks,
> > Omri Har-Shemesh
>
>
