Peter Hunt wrote:
- Integrate Subway's form handling. I think Subway's form handling system is innovative and a very productive way of validating forms. TG seems to be a bit lacking in form validation, anyway, so I think this won't be too controversial.
My impression is that TG has already been going down the same development path that Subway went down with respect to validation; Subway is a couple iterations further, but they feel similar.
Also, htmlfill_schemabuilder (which came from Peter) is already in TG (by way of FormEncode), it's just a matter of using it. I think htmlfill and the schemabuilder have a distinct set of use cases from widgets, and that it's worth supporting that well.
Again, it has something to do with work flow -- htmlfill is written with designers in mind, while widgets are more programmer-centric. There should be room for both techniques, without trying to encorporate both cases into the same interface.
- Full integration with Python Paste could be a good idea, too. Subway used to do it, but Paste was changing too quickly for us to keep up, and we haven't had support for it for a while.
I would certainly welcome that. When Subway tried to use Paste I was still trying to figure out how plugins should work, and it was pretty messy -- since then I've been using eggs and entry points and everything stabalized quickly. Paste interfaces have been stable for some time now.
I also think TG should consider using other pieces of Paste besides the creation templates. People who use the evaluating exception handler (myself included, of course) have found it very useful. And if Kid adopts some of the conventions I've suggested for mapping exceptions to source positions, Paste is also set up to display those well (and those conventions are substantially better than other conventions I've seen used in templates).
To make TG more Paste friendly really means two things -- first, I believe there are still some outstanding issues with CherryPy, and how well it isolates requests, and how well it respects the meaning of SCRIPT_NAME and PATH_INFO. I doubt these are big issues, but they require someone in the core of CherryPy to actually fix them all. I'm not sure about the details, but I'm willing to look into it all more closely from my perspective if someone from the CherryPy side is ready to follow up on this stuff.
The second is configuration and making it possible/easier to set up WSGI stacks. Paste Deploy offers one model using configuration files, but I'm actually more interested in what it uses underneath -- namely, simple function calls with configuration expressed as keyword parameters. If a CherryPy or TG app can consume those functions, then that's great; if there's just an easy way to wrap the entirety of a CherryPy app in a WSGI wrapper, then that's fine too. I'm happy to discuss more of the particulars and look into it more closely, again if there's someone on the other side who wants to follow up on that from the other side.
So... after going into that, I'll note that another thing Paste offers is the potential for a really good deployment story. This isn't complete in Paste, but it's well along in progress, and many of the issues with Paste support are just about formalizing what the boundary of the application looks like, and that's simply what's necessary for making a good deployment situation. Also, it makes nesting of applications a real possibility -- I know non-TG users are interested in CatWalk (and no doubt lots of the other toolbox apps coming up), and I expect we'll see other apps like Tasty that are just asking to be embedded. I think it will be good for TG if people get a taste of it by way of using things built in it, just like people often get used to PHP by installing and tweaking PHP apps.
-- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
