Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.freenet.ag!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.029 X-Spam-Evidence: '*H*': 0.94; '*S*': 0.00; 'ideally': 0.04; 'anyway.': 0.05; '(using': 0.07; 'frontend': 0.07; 'forms,': 0.09; 'plug': 0.09; 'django': 0.11; '(both': 0.16; 'codebase,': 0.16; 'noone': 0.16; 'scalable,': 0.16; 'subject:generation': 0.16; 'backend': 0.19; 'dependent': 0.19; 'forms.': 0.24; 'define': 0.26; 'message- id:@mail.gmail.com': 0.30; "i'm": 0.30; 'quite': 0.32; 'are:': 0.33; 'to:name:python-list': 0.33; 'moment': 0.34; 'received:74.125.82': 0.34; 'could': 0.34; 'problem': 0.35; 'something': 0.35; 'but': 0.35; 'received:google.com': 0.35; 'there': 0.35; 'really': 0.36; 'possible': 0.36; 'should': 0.36; 'too': 0.37; 'server': 0.38; 'to:addr:python-list': 0.38; 'short': 0.38; 'received:74.125': 0.39; 'sure': 0.39; 'to:addr:python.org': 0.39; 'simply': 0.61; 'soon': 0.63; 'our': 0.64; 'become': 0.64; 'more': 0.64; 'worth': 0.66; 'between': 0.67; 'client-side': 0.84; 'dry': 0.84; 'dsl': 0.84; 'hands': 0.96 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=xCHKz1tnl3+toM+vLbkkei2a4mz7QtNs/KyX0fQal1M=; b=ipYycirdGjaho+zDvSagMOg3x7dXle0OncXsJ3lI3dTQDOcxlsNthGyKpkgaNIcIeV HULKdSGdeDUvgV30BuWta0TyIGbR9Av8jOjYzZ1Iuo/JEpwGGR9uAFmvpGKXFXdEMgHd 6VQyDd1IX5EloY52V7KHX6t+jfvBDkrRbb13SfTcWJiKXasLiOqOzNqYPreaFq1V0hzv 7kA/0T7sdfA66qTq7zBuubkNrkBxpUYs4ZKGaIyrPGg7ZMde8iuaa9Ch7FC1ts1GL/h9 zHAT3tEs9KKVhag/QOJNNAqkQ3IIaAu6v/XDWqfzhSO3xf9amFi6FCHFhew1HoM3Jflt V4ow== MIME-Version: 1.0 X-Received: by 10.194.121.129 with SMTP id lk1mr2634241wjb.45.1366107686196; Tue, 16 Apr 2013 03:21:26 -0700 (PDT) Date: Tue, 16 Apr 2013 11:21:26 +0100 Subject: dynamic forms generation From: andrea crotti To: python-list Content-Type: multipart/alternative; boundary=089e011779f55c621104da77bb9d X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 50 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1366107694 news.xs4all.nl 2660 [2001:888:2000:d::a6]:32956 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:43666 --089e011779f55c621104da77bb9d Content-Type: text/plain; charset=ISO-8859-1 We are re-designing a part of our codebase, which should in short be able to generate forms with custom fields. We use django for the frontend and bottle for the backend (using CouchDB as database), and at the moment we simply plug extra fields on normal django forms. This is not really scalable, and we want to make the whole thing more generic. So ideally there could be a DSL (YAML or something else) that we could define to then generate the forms, but the problem is that I'm quite sure that this DSL would soon become too complex and inadeguate, so I'm not sure if it's worth since noone should write forms by hands anyway. Between the things that we should be able to do there are: - dependent fields - validation (both server and client side, better if client-side auto-generated) - following DRY as much as possible Any suggestions of possible designs or things I can look at? --089e011779f55c621104da77bb9d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
We are re-designing a part of our codebase, which sho= uld in short be
able to generate forms with custom fields.
<= div>
We use django for the frontend and bottle for the backen= d (using CouchDB
as database), and at the moment we simply plug extra fields on normal<= /div>
django forms.

This is not really scalabl= e, and we want to make the whole thing more
generic.

So ideally there could be a DSL (YAML or something else) tha= t we could
define to then generate the forms, but the problem is = that I'm quite
sure that this DSL would soon become too compl= ex and inadeguate, so I'm
not sure if it's worth since noone should write forms by hands any= way.

Between the things that we should be able to = do there are:
- dependent fields
- validation (both ser= ver and client side, better if client-side
=A0 auto-generated)
- following DRY as much as possible

Any suggestions of possible designs or things I can lo= ok at?
--089e011779f55c621104da77bb9d--