Re: [Repoze-dev] form generation package recommended for use with BFG?
Fergus Doyle wrote: +1 I also normally set up a bunch form fields as template macros and then write a template for each form pulling the widgets together (allowing for default values and errors to be displayed in a standard way) instead of using a form generation utility. I find it allows for much greater flexibility if you are dealing with highly stylised / customised forms throughout a project. Yup, the KARL project was using FormEncode (and repoze.enformed) until recently. It works well for smaller projects, but as things got more complicated, it turned out that the template macros and the form fields pulling them together were evolving into a form generation package, and not a very good one. So the decision was made to switch to Formish, since it sucks less than the ad-hoc form generation that was happening. KARL is a bit of a beast, though; for smaller projects (read: most of them) FormEncode and manual form templating is a fine idea. -r On 30 Apr 2010, at 01:40, Darryl Cousins wrote: Hi, I happily use FormEncode with BFG. http://formencode.org/Design.html Best, Darryl On Thu, Apr 29, 2010 at 10:23 AM, Rob Miller r...@kalistra.com wrote: Chris Withers wrote: Hi All, Is there anything akin to Django's form generation and handling stuff that's recommended for use with BFG? repoze.bfg.formish is probably your best bet right now: http://svn.repoze.org/repoze.bfg.formish/trunk/docs/index.rst it's being used pretty heavily by the KARL project, so there's lots of in-use code to look at, the formish:form tags (and the classes they refer to) in this file are a good place to start: http://osi.agendaless.com/bfgsvn/karl/trunk/karl/content/views/configure.zcml chris has been working on repoze.deform, which is similar in many ways to repoze.bfg.formish, but takes a different approach to serialization, along w/ some other differences. see: http://docs.repoze.org/deform/ and: http://www.plope.com/peppercorn the deform stuff is much less battle-worn, however; not only has repoze.bfg.formish been around for longer, but formish itself has a life of its own outside of repoze-land, whereas i'm not sure if deform has even seen any production use yet. -r ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] form generation package recommended for use with BFG?
Chris Withers wrote: Hi All, Is there anything akin to Django's form generation and handling stuff that's recommended for use with BFG? repoze.bfg.formish is probably your best bet right now: http://svn.repoze.org/repoze.bfg.formish/trunk/docs/index.rst it's being used pretty heavily by the KARL project, so there's lots of in-use code to look at, the formish:form tags (and the classes they refer to) in this file are a good place to start: http://osi.agendaless.com/bfgsvn/karl/trunk/karl/content/views/configure.zcml chris has been working on repoze.deform, which is similar in many ways to repoze.bfg.formish, but takes a different approach to serialization, along w/ some other differences. see: http://docs.repoze.org/deform/ and: http://www.plope.com/peppercorn the deform stuff is much less battle-worn, however; not only has repoze.bfg.formish been around for longer, but formish itself has a life of its own outside of repoze-land, whereas i'm not sure if deform has even seen any production use yet. -r ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] custom Request and Response classes in repoze.bfg
hey all, so in building my first repoze.bfg app, it's occurred to me that i'd like to use a custom Request and Response classes, just simple subclasses of the WebOb defaults so that i can set configurable class variables like default_charset. unless i'm missing something in the code, there's currently no support for this. how would folks feel about the following changes: - in repoze.bfg.router, the paster config would be checked for request_class setting, which would be a dotted path to a request class to use. absence of this setting means use the default class, nothing changes. - every place that a response object is currently instantiated, use request.ResponseClass instead of explicitly using the WebOb class. AFAICT, response objects are instantiated in the following repoze.bfg modules: - chameleon_[genshi|text|zpt] - view - wsgi - xslt in the 'view' and 'wsgi' modules, we're already holding the request object when the response is instantiated, so there's very little to change. in all of the other modules, the response is being instantiated in a render_[template|transform]_to_response function. the biggest change, then, would be to have all of the render-to-response methods start requiring request objects as arguments. this could be optional at first, w/ a deprecation warning if it's left out, until such time as we might see fit to force the issue. whaddayareckon? -r ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] custom Request and Response classes in repoze.bfg
Malthe Borch wrote: 2009/1/14 Rob Miller r...@burningman.com: so in building my first repoze.bfg app, it's occurred to me that i'd like to use a custom Request and Response classes, just simple subclasses of the WebOb defaults so that i can set configurable class variables like default_charset. unless i'm missing something in the code, there's currently no support for this. You do have the INewRequest event. yeah, i saw that, and that's what i'll use as a workaround. but: a) it's less efficient and smells a little bit bad to me to add an event handler and touch every request instance after it's been created when what i really want to do is add a class variable to the request class b) it doesn't address the response object issue. WebOb provides the ResponseClass attribute on the request object specifically for this purpose, it seems silly not to use it. yes, there's an INewResponse event... see a). put another way, ian bicking specifically recommends that subclasses of Request and Response are a good way to handle certain use cases, and WebOb was designed with that in mind. it seems reasonable to me to support doing so. -r ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] custom Request and Response classes in repoze.bfg
Chris McDonough wrote: Rob Miller wrote: hey all, so in building my first repoze.bfg app, it's occurred to me that i'd like to use a custom Request and Response classes, just simple subclasses of the WebOb defaults so that i can set configurable class variables like default_charset. unless i'm missing something in the code, there's currently no support for this. how would folks feel about the following changes: - in repoze.bfg.router, the paster config would be checked for request_class setting, which would be a dotted path to a request class to use. absence of this setting means use the default class, nothing changes. I think this is more application configuration than deployment configuration so I think it might be better if an IRequestFactory utility was registered via ZCML to be able to override the request factory used by the Router. I'd be willing to put something like this in there if it didn't cause a noticeable slowdown. yes, that occurred to me as well. i'd be fine w/ a utility. - every place that a response object is currently instantiated, use request.ResponseClass instead of explicitly using the WebOb class. AFAICT, response objects are instantiated in the following repoze.bfg modules: - chameleon_[genshi|text|zpt] - view - wsgi - xslt in the 'view' and 'wsgi' modules, we're already holding the request object when the response is instantiated, so there's very little to change. in all of the other modules, the response is being instantiated in a render_[template|transform]_to_response function. Note that you could just write your own render_template_to_response function that used render_template and constructed its own kind of response object with the the result of render_template as the response body. That's effectively all that render_template_to_response does. Such a function could be a single line and you could even give it a shorter name! ;-) yes, that's easy enough, although it seems quite reasonable to me to use the pattern that WebOb intended for this in the bfg core. the biggest change, then, would be to have all of the render-to-response methods start requiring request objects as arguments. this could be optional at first, w/ a deprecation warning if it's left out, until such time as we might see fit to force the issue. I'd also be willing to make a IResponseFactory utility that chameleon_*, view, wsgi, and xslt used to find what kind of response object to get as long as it didn't slow things down much. It would accept no arguments and always return the same kind of response object. I *think* having a global IRequestFactory utility would give you what you wanted; although it wouldn't be able to use request.ResponseClass, as long as what request.ResponseClass means doesn't differ from request-to-request, you would be able to differ the response class for a particular application. i'm not really following you here. i'm -1 on the idea of an IResponseFactory utility. i think having the ResponseClass available on the request objects meets the need here; the hook is already in WebOb, why not just use it? if anything, i'd rather see an ICurrentRequest utility, which always returned the request object for the current request... or some other way to always get at the request object, regardless of whether or not it's been explicitly passed in. if request.ResponseClass is always used when instantiating a response object, then there's no need to support any other pluggability; the request object serves the need just fine w/o requiring another utility. -r ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
