"Peter Hunt" <[EMAIL PROTECTED]> writes: > - Do the merge as patches and changes to TG to integrate some of > Subway's features into TG rather than break complete TG compatibility > and use a new codebase, as TG is far more popular and as such should > not have any gigantic sweeping changes.
Creating a new branch for this would be very interesting since it would allow Kevin working to release 0.9 and merging both his changes and subway code at the same time on this branch. Working with patches is not as comfortable as with a branch where you can see some evolution at the codebase. > - 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. Could you elaborate on that? I dunno Subway. How does it work? > - CherryFlow would be a quick addition to TG that wouldn't require much else > other than some refactoring and some documentation. Using continuations looks very interesting. :-) I was willing to try it sometime. Using it to ease form processing looks even more interesting. :-) > - Change TG's controller style slightly. In Subway, we opted for multiple > .py files with functions rather than classes with methods. This is _not_ > the big picture, however. The important thing was that Subway automatically > assembled the tree of controllers rather than forcing the user to add > attributes to their root controller manually. On my hacked up local SVN of > TurboGears, I implemented a minor change which allows the user to write > classes like this: > > class MyRoot(controllers.Controller): > mount_path = "/" > # methods would go here > > and they would be automatically assembled via a metaclass. I'd also propose > making controllers a package and not a module, since a lot of code will go > in there and it would be easier to split up into multiple .py files. In > addition, using the new mount_path system would let us just do a "from > controllers import *" to set up the controller tree. I can post my updated > code if anyone's interested. I am not sure what I think about it. I already have my modules separated today. And I also have a "lib" directory, with common stuff that is used in more than one module. The advantage of using it as it is today is that you can arrange the layout as you see fit, and you can have common files that aren't "exposed" or visible to the user mixed with files that are part of the interface -- sometimes it is easier to just put everything there, specially for very small and simple apps... On the other hand, having controllers automatically added is not bad. Specially if we can put everything together and count on the 'expose' decorator to choose what is or isn't available on the browser. > - Templating. I cannot stress enough how important it is for TG to emphasize > ONE and ONLY ONE templating language (we don't want another templating > war). I also feel that Cheetah is far superior to Kid in terms of > performance, extensibility, and the ability to process malformed HTML > documents and create non-XML formats such as CSS and plaintext. That said, > however, I think TG should stick with Kid, even if we merge, because > applications are already built with it and changing the templating language > at this stage would be a Bad Idea. I started "loving" Kid :-) After you start working with it, it becomes very productive. Specially when you have to send your "html" -- aka Kid template -- for somebody doing the design / layout and then using this new template. This is a huge plus to me. I'm not a designer and even though I can appreciate a beautiful website I have lots of troubles creating one :-) > - 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 can't talk about it... I haven't looked at Paste yet :-( > Alright, that's all I have for now for ideas with the merge. Thoughts? > Ruby books are now outselling Python books; let's do something about > it! :-) -- Jorge Godoy <[EMAIL PROTECTED]>
