-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tres Seaver wrote: > Rocky Burt wrote: >> On Wed, 2007-10-01 at 11:09 -0500, Tres Seaver wrote: >>> While I am vehemently opposed to code generation per se, one alternative >>> which I think is important is to generate stuff *at runtime* from >>> artifacts which are more understandable to business users than Python >>> code. E.g., they might specify schema in a spreadsheet, an HTML form, >>> or a UML diagram, which we then use to create a schema interface (my >>> 'userschema' package[1] does this already for the first two). >> Not sure which mailing list my questions belong on but for the time >> being I'll ask them here (any list subscribers feel free to tell me to >> take this discussion offline). > >> This userschema package looks very cool and it's nice to see all the >> cool ways you can produce schema's from user contributed data (ie csv, >> html). But I'm curious to know what sort of use cases you have for the >> end-result schema's ... simple formlib form generation? content type + >> edit form (via formlib) generation? > > Obviously generated UI is the main use-case; I have some notions about > making it easier to use schema stuff from within "custom" UI, but they > aren't fleshed out yet. > > I do have a notion of allowing the template which *specifies* the schema > to be used to *render* its fields, but haven't got that part working > yet. Chris McDonough and I have talked about using a meld3-based > approach to that, as well.
(Sorry to follow up to myself, and so late). While at the BBQ sprint last month, Philipp and I worked on a prototype for this last idea. Although it isn't cleaned up yet for a release, the essence of it is to put the 'index' and 'edit' templates (hand-rolled, of course) into the appropriate subdirectory, and then use a new grok directive to get the class and all its views wired up. E.g.:: $ cat simple_templates/index.pt <html> <body> <div tal:content="structure context/body | nothing"> BODY </div> </body> </html> $ cat simple_templates/edit.pt <html> <body> <form name="simple_edit" action="." method="POST"> <fieldset id="body_fs"> <legend>Simple Body</legend> <textarea id="doc_body" name="body" rows="20" cols="80" tal:attributes="name view/widget/body/name|default" tal:content="view/widgets/body/_getFormValue"></textarea> </fieldset> <div> <input type="submit" name="form.submitted" value=" Save Changes " tal:repeat="action view/actions" tal:attributes="name action/__name__; value action/label" /> </div> </form> </body> </html> $ cat app.py import grok import grok_crud from zope.formlib import form class SimpleApp(grok.Application, grok.Container): pass class Index(grok.View): grok.context(SimpleApp) class Simple(grok_crud.Crud): grok_crud.directory('simple') With something like meld3, we could even get rid of the hairy TALES expressions in the tmeplates, making them purely the domain of the designer. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGKNxM+gerLs4ltQ4RAu0AAJ9/l7K9l5TkMLCOAp/rdExACfpItACgxRpq X4p0vh6t5WKEJPmihBjf3qo= =CHwU -----END PGP SIGNATURE----- _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com