|
|
Re: Database Denormalization and the NoSQL Movement
|
Posted: Sep 18, 2009 3:48 PM
|
|
> To answer the question, if the data is BCNF, with proper
> constraints, then any application can, optionally, provide
> client editing. This can be done fully dynamically, reading
> the catalog and shipping constraints; more commonly the
> client side code (html/javascript/ajax/whatever) is
> generated from the catalog. Andromeda and sprox are two
> examples.
Thanks for the mention of sprox - never heard of it before. There are other examples of this, too. Zoho Creator actually allows you to build your own DSL for manipulating the contents of the database.
sprox, though, has some pretty clear flaws, in my humble opinion, that I do not want in my architecture. Observe:
from sprox.formbase import AddRecordForm
from formencode import Schema
from formencode.validators import FieldsMatch
from tw.forms import PasswordField, TextField
form_validator = Schema(chained_validators=(FieldsMatch('password',
'verify_password',
messages={'invalidNoMatch':
'Passwords do not match'}),))
class RegistrationForm(AddRecordForm):
__model__ = User
__require_fields__ = ['password', 'user_name', 'email_address']
__omit_fields__ = ['_password', 'groups', 'created', 'user_id', 'town_id']
__field_order__ = ['user_name', 'email_address', 'display_name', 'password', 'verify_password']
__base_validator__ = form_validator
email_address = TextField
display_name = TextField
verify_password = PasswordField('verify_password')
__omit_fields__ is pretty nasty, if it is what I think it is. I'd rather this be constructed using a computation, rather than a entity-attribute-value tuple (represented in this code as a list).
Yes, you want to omit fields, but usually the reason WHY is more important than the list of what to omit, itself. The list should therefore be constructed declaratively from WHY.
|
|
Previous Topic
