Combine TG and Subway?
paron
http://groups.google.com/group/comp.lang.python/browse_frm/thread/fa5d78b901a56cb/c27b84e415f540e0
Peter Hunt wrote:
<snip>
I'm the founder and lead developer of Subway.
I am all for it. TG would have to change a couple of things IMHO, but I
think it would be a great idea.
If we were to merge projects, we would have to get a serious
TurbowaySubgears blogging hype train going.
- Peter Hunt
</snip>
Sorry for the almost-cross-posting, but this looked important to me,
and it was kind of buried in yet another discussion of the "Ultimate
python Ruby-on-rails killer" or some such.
Ron
martin....@gmail.com
position Kevin ?
Martin
Sylvain Hellegouarch
I mean would it be a simple interopability or a full integration of both
products?
- Sylvain
Selon "martin....@gmail.com" <martin....@gmail.com>:
>
> Important ? that's the understatement of the year. What is your
> position Kevin ?
>
> Martin
>
>
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
Steven Kryskalla
> What you guys mean by "Combine"?
>
> I mean would it be a simple interopability or a full integration of both
> products?
I think they mean a full integration, taking the best of Subway's
features, and integrating them into TurboGears. Take a look at this
ticket in their Trac:
http://subway.python-hosting.com/ticket/216
Also, the head developer of Subway said:
> I would plan on sticking with the Turbogears name if we were to merge.
So that means that after the merge Subway will cease to exist, and
TurboGears will absorb Subway's features/developers/users. One more
step towards becoming The One Python Web Framework!
This seems like the best possible outcome for the two projects, but it
will need some momentum and approval from Kevin.
Also be sure to check out / comment on this message from the
subway-devel list:
http://tinyurl.com/cpwf9
Steve
Jared Kuolt
David Stanek
This seems like the best possible outcome for the two projects, but it
will need some momentum and approval from Kevin.
Why not just start creating patches and tickets? Anything that doesn't fundamentally change TG would probably be easily accepted.
Just my $.02.
-- David
jorge....@gmail.com
- cheetah seems more stablish, but a lot more complicated and IHMO kid
can make all that with less keywords
- this seems interesting -> http://www.gosubway.org/docs/helpers.shtml
- I don't like the functions idea, remenber the problem we had with
identity framework because SQLObject doesn't undestand packages, that
could happen here too but even worst
- the structure of TG is more compact and simple.
- check out http://subway.python-hosting.com/browser/examples/ most of
them are ports of other frameworks
- I see a lot of atom, /me doesn't likes atom
- I can't find the "other features"
Mark Ramm
> > products?
>
> I think they mean a full integration, taking the best of Subway's
> features, and integrating them into TurboGears. Take a look at this
> ticket in their Trac:
> http://subway.python-hosting.com/ticket/216
>
> Also, the head developer of Subway said:
> > I would plan on sticking with the Turbogears name if we were to merge.
OK, so if there were to be a merge what would the benefits be for:
1) The TurboGears project?
2) The Subway project?
3) The python community?
I think the answer to 3 is that there will be less framework chaos,
and more developer cooperation. The answer to 1 might be more
developers and therefore more features, and the answer to 2 might be
getting more people to use their code.
On the downside, it looks like the there will be some contention about
controllers as classes and about the use of Kid as the template
system. And this friction could easily slow down the whole TurboGears
project.
--Mark Ramm
Steven Kryskalla
> What Subway features stand out over TurboGears?
One neat feature is CherryFlow
(http://subway.python-hosting.com/wiki/CherryFlow), which allows you to
write continuation based pages (see the examples).
Another interesting feature is CrackAJAX, which allows you to write an
Ajax page with Python code. It's kind of like 'jsonify', but instead
of Python datatypes, it converts the actual Python code to javascript.
Rails does this in some places (like form_remote_tag which can update a
div remotely using only Ruby code), and it can make rapid development
of Ajax apps easier.
Helpers (http://www.gosubway.org/docs/helpers.shtml) would give a quick
and easy boost to the current stdvars functions.
Overall, it might not look like there are many gotta-have features, but
Subway does some things in a different way, which may be better in a
certain situations. Plus, having more developers and users on board is
always a good thing.
Steve
Jorge Godoy
> Another interesting feature is CrackAJAX, which allows you to write an
> Ajax page with Python code. It's kind of like 'jsonify', but instead
> of Python datatypes, it converts the actual Python code to javascript.
> Rails does this in some places (like form_remote_tag which can update a
> div remotely using only Ruby code), and it can make rapid development
> of Ajax apps easier.
This is really interesting, after all, Python is easier to read and maintain
than JavaScript. :-)
--
Jorge Godoy <jgo...@gmail.com>
Kevin Dangoor
Hunt emailed me early last week about this. Answering this question
requires me to provide some context, and I hope to write that up
tonight. My travel has kept me from responding to this public
discussion thus far.
Kevin
--
Kevin Dangoor
Author of the Zesty News RSS newsreader
email: k...@blazingthings.com
company: http://www.BlazingThings.com
blog: http://www.BlueSkyOnMars.com
Michele Cella
Personally I don't like CracAjax (at least ATM), to me it seems just
like writing javascript code into a python file instead of where it
belongs (a js file):
http://www.aminus.org/blogs/index.php/phunt/2005/10/06/subway_s_new_ajax_framework
JavaScript can be considered a bad or a good language, anyway it's a
language and you need to use it (on the client side) thus I don't like
the idea of hiding it in this way, MochiKit is just brilliant IMHO.
Regarding TG/Subway I like much more the class as controller approach
and Kid.
Merging will sure benefit the two projects but only if done in the
right way, for example I don't think that providing the option of
choosing between cheetah or Kid will provide any benefit but only
increased difficult to support two totally different templates language
and documenting them.
I'm totally in favor of this:
"There should be one-- and preferably only one --obvious way to do
it."
Anyway that's only my personal opinion as a TG fan. :-)
Ciao
Michele
Richard (koorb)
> Personally I don't like CracAjax (at least ATM), to me it seems just
> like writing javascript code into a python file instead of where it
> belongs (a js file):
Here, here!
> JavaScript can be considered a bad or a good language, anyway it's a
> language and you need to use it (on the client side) thus I don't like
> the idea of hiding it in this way, MochiKit is just brilliant IMHO.
Go, go MochiKit
> Anyway that's only my personal opinion as a TG fan. :-)
:-D
Ronald Jaramillo
-Ronald
ps. Most of this ajax fairy dust can be added to subclassing
existing widgets. For instance Jared's select widget can be
subclassed to include a 'loadFromUrl' or an
'updateFromUrlWhenThatSelectWidgetChanges' parameter =).
________________________________
Ronald Jaramillo
mail: ronald AT checkandshare DOT com
blog: http://www.checkandshare.com/blog
Michele Cella
> I hate to post a me-too, but hell, me too =)
:D
> -Ronald
>
> ps. Most of this ajax fairy dust can be added to subclassing
> existing widgets. For instance Jared's select widget can be
> subclassed to include a 'loadFromUrl' or an
> 'updateFromUrlWhenThatSelectWidgetChanges' parameter =).
And (thanks to Jason) there is even a patch to make this possible :
http://trac.turbogears.org/turbogears/ticket/204
Ciao
Michele
Ian Bicking
> On 12/19/05, *Steven Kryskalla* <skrys...@gmail.com
>
> This seems like the best possible outcome for the two projects, but it
> will need some momentum and approval from Kevin.
>
> Why not just start creating patches and tickets? Anything that doesn't
> fundamentally change TG would probably be easily accepted.
I think it's only fair for Subway developers to get a bit more
consideration and some more definitive decisions than just submitting
another set of patches in a tracker. The contributions are concrete and
be discussed in much more detail than mere API experimentations. They
represent ideas that have gone through several iterations already, and
while those ideas have been developed in a slightly different context,
it's only *slightly* different.
Also, if Subway is going to "close up shop" so to speak, that's
disheartening if its ideas live in some sort of limbo (out of which they
may or may not ever emerge) in the form of TG patches. It will be much
more pleasant if Subway's pieces can either be thrown out for good (in a
kind of cathartic cleaning) or merged into something else (TG or perhaps
new projects; for instance, Crack Ajax would be a good candidate for an
entirely new package).
--
Ian Bicking / ia...@colorstudy.com / http://blog.ianbicking.org
David Stanek
I think it's only fair for Subway developers to get a bit more
consideration and some more definitive decisions than just submitting
another set of patches in a tracker. The contributions are concrete and
be discussed in much more detail than mere API experimentations. They
represent ideas that have gone through several iterations already, and
while those ideas have been developed in a slightly different context,
it's only *slightly* different.
I have heard lots of people saying what a good idea this would be, but I have not really heard much about the differences. I am anxious to see patches, tickets and mailing list posts related to the integration.
-- David
_max
I ve tried TG, i really like the integration with cherrypy/sqlobject ,
love the toolbox idea and everything around it, but Kid is what keeps
me away from going further with this.
Kid feels bloated, lots of features which are imho useless and/or costs
too much in terms of performance , most of the time i end up hacking
around kid to avoid its issues. I am one of those who think a template
language has to stay simple (i think it s also django approach).
I like the idea behind Kid (xsl/python mix) but not at such a
performance cost, i'd rather have controllers serializing return
dict(...) in XML and using XSL.
And there's no proper cheetah support so far in TG(well there's
http://trac.turbogears.org/turbogears/ticket/214 but looks like it
breaks i18n support).
Cheetah feels like an improvement for a lot of people, i am sure it
would bring some new ppl to TG . It s rock solid/stable, has some
really nice features Kid lacks (powerefull caching, oo, no hassle with
well-formedness/entities, document output format).
Not to mention all the cheetah+framework "X" web apps which could be
converted to TG faster.
my 2 cents
Steve Bergman
assured that the html documents I am sending out are valid. (With
certain exceptions, of course.) IMO, this is the *right* way to do
things. Web validators are fine, but an afterthought. The tool should
guarantee compliance with the document standard. Do you run your OOo or
Word or Excel or Gnumeric documents through a validator? I don't. And
if I did have an application that generated documents that allowed
invalid documents to be generated and shunted the responsibility for
making sure they are valid to me, I would consider it to be quite broken.
I am not very familiar with Cheetah, but I have never heard that it had
this feature.
Other than that, I'm not really married to Kid. Though that should be
taken in the context of me being someone who is familiar with Kid
because I have been using it with TG, and who has never used Cheetah.
-Steve
Kevin Dangoor
> Kid feels bloated, lots of features which are imho useless and/or costs
> too much in terms of performance , most of the time i end up hacking
> around kid to avoid its issues. I am one of those who think a template
> language has to stay simple (i think it s also django approach).
I'd be interested in examples here. I don't find Kid to be a
particularly complex template system.
> I like the idea behind Kid (xsl/python mix) but not at such a
> performance cost, i'd rather have controllers serializing return
> dict(...) in XML and using XSL.
Performance issues can be dealt with (and David Stanek has looked at
this some). XSL is only performant because of work put in on the
individual implementations to make it so. Likewise, Kid is a good
language to work with and there are many ways to address performance
issues in Python.
> Cheetah feels like an improvement for a lot of people, i am sure it
> would bring some new ppl to TG . It s rock solid/stable, has some
> really nice features Kid lacks (powerefull caching, oo, no hassle with
> well-formedness/entities, document output format).
"no hassle with well-formedness"? Ick. Especially as the migration
gradually occurs to XHTML, having well-formed documents and a system
that supports that will be a big bonus. I'm not sure what you mean by
"document output format"?
I'm also not certain that it's the template tool's job to do caching.
There are many places were one can conceivably do caching.
> Not to mention all the cheetah+framework "X" web apps which could be
> converted to TG faster.
This is actually a real use case that I can get behind. In "What
TurboGears Is Not" [1], I state that having two ways of doing
something is fine as long as people know very clearly when to use one
or the other. Making it possible to easily send data to a Cheetah
template as a temporary compatibility measure while migrating to the
whole framework is fine. But trying to fully integrate another
template language (i18n, Toolbox, widgets, etc.) is not in the cards.
TurboGears will not stand in the way of people using Cheetah, and can
go so far as allowing Cheetah templates to receive data via
turbogears.expose. But, going beyond that will just make things messy.
[1] http://www.blueskyonmars.com/2005/12/20/what-is-turbogears-not/
Ian Bicking
>>Kid feels bloated, lots of features which are imho useless and/or costs
>>too much in terms of performance , most of the time i end up hacking
>>around kid to avoid its issues. I am one of those who think a template
>>language has to stay simple (i think it s also django approach).
>
>
> I'd be interested in examples here. I don't find Kid to be a
> particularly complex template system.
In my experience with ZPT I've found it rather difficult for
non-programmers to understand. I think, if anything, that would be more
true for Kid -- ZPT macros aren't easy (nothing on that level is easy),
but Kid's matching is difficult. OTOH, it is true that a certain class
of errors (well formedness) is eliminated. But constantly validating
during development is not unreasonable (Paste even has a middleware for
this, of course ;).
OTOH, for programmers a markup based language does get you in the mind
of thinking of the structure of the page, not just the text. That's a
helpful mindset for working with Javascript. I wonder if it means
anything that Rails people primarily use innerHTML, and their templating
language is text based?
Anyway, while there's arguments back and forth, in my concrete
experience markup languages are harder.
Cheetah (like Django and ZPT) also has loose expressions which conflate
attributes, dictionaries, and methods; this is also useful for
non-programmers. Cheetah goes further than others by making those
expressions reasonably powerful as well (ZPT has no 'and' operator
without going into straight Python syntax, bah). This can add
complexity as well, so it's not a complete win.
OTOH, I've seen particular interest in quite a few programmers in TG
specifically because of Kid, or at least towards a markup-based
templating language. So it's not a bad choice, but it's catering to
programmers from what I have seen.
Ultimately, both Kid and Cheetah are good languages, this isn't
necessarily about N different templating languages. If another language
comes along with some good feature, one or the other of these two
languages can adopt that feature given some effort. But they both
represent two very different camps, and people have a certain emotional
reaction for or against them.
>>I like the idea behind Kid (xsl/python mix) but not at such a
>>performance cost, i'd rather have controllers serializing return
>>dict(...) in XML and using XSL.
>
>
> Performance issues can be dealt with (and David Stanek has looked at
> this some). XSL is only performant because of work put in on the
> individual implementations to make it so. Likewise, Kid is a good
> language to work with and there are many ways to address performance
> issues in Python.
>
>
>>Cheetah feels like an improvement for a lot of people, i am sure it
>>would bring some new ppl to TG . It s rock solid/stable, has some
>>really nice features Kid lacks (powerefull caching, oo, no hassle with
>>well-formedness/entities, document output format).
>
>
> "no hassle with well-formedness"? Ick. Especially as the migration
> gradually occurs to XHTML, having well-formed documents and a system
> that supports that will be a big bonus. I'm not sure what you mean by
> "document output format"?
I personally think HTML is a perfectly good markup language, and XHTML
doesn't offer any compelling advantages for humans. But then ZPT
handles HTML just fine so I don't deal with this. It could potentially
be useful to extract whatever code does this from ZPT (at the
ElementTree level, I suppose -- it would be quite nice if ElementTree
had better HTML parsing support). Extracting from ZPT shouldn't be that
hard -- ZPT's code is not that scary! (It was even originally written
by Guido, so a nice lineage)
> I'm also not certain that it's the template tool's job to do caching.
> There are many places were one can conceivably do caching.
Granular output caching is probably best done in the template. OTOH,
Kid already has some structures which would probably facilitate this
reasonably.
>>Not to mention all the cheetah+framework "X" web apps which could be
>>converted to TG faster.
>
>
> This is actually a real use case that I can get behind. In "What
> TurboGears Is Not" [1], I state that having two ways of doing
> something is fine as long as people know very clearly when to use one
> or the other.
Incidentally Cheetah support would also solve the how-to-generate-text
issue. I think there's some other possible solutions for things like
email, but there's still cases when it's a useful function. Cheetah,
for instance, is a much better fit for generating Python source.
There's also been recent additions to it that may (I'm a little unclear)
make it appropriate for untrusted templates as well.
_max
mostly, the validation of the template) are imho not that imporant to a
template language when it deals with python behind (I don't generate
onyl xhtml/xml/html documents with my templates, i'd like to be able to
generate mail/csv/latex without too much workarounds).
"XSL is only performant because of work put in on the individual
implementations to make it so."
Yes just like Cheetah, there s been a huge amout of work put into this
project , it s a bit sad not to do take advantage of this. If i was
about to bring the best-of-breed i d use Cheetah or XSL (but Cheetah
is more friendly to newcomers in a python based framework) , but then
again it s a matter of personal taste.
I began to use cheetah a few days ago so i am not 100% confident with
it yet but i liked it so far (i am no kid expert either, but i ve
played with most of its functionalities).
"TurboGears will not stand in the way of people using Cheetah, and can
go so far as allowing Cheetah templates to receive data via
turbogears.expose. "
Yes, looking foward to use some of the great features from the Toolbox,
i guess i am just sad having to give up on widgets & i18n for now.
"But, going beyond that will just make things messy"
Yes certainly, i didn't think of all the implications for sure (haven't
tried widgets yet, maybe kid got improvements in terms of performance
lately too).
Sorry for the spelling mistakes, it not my native language.
Kevin Dangoor
> mostly, the validation of the template) are imho not that imporant to a
> template language when it deals with python behind (I don't generate
> onyl xhtml/xml/html documents with my templates, i'd like to be able to
> generate mail/csv/latex without too much workarounds).
I think that match is one of Kid's coolest features (and the overhead
of match is surprisingly less than you'd expect). The great thing
about match is that it allows you to create templates that are fully
viewable in a browser on their own *and* have app-wide styling applied
to them at runtime.
Kid provides a great collection of ways to structure your templates so
that it makes sense for your application style.
Current versions of Kid can produce plain text output. Admittedly, Kid
is not as good at plain text as Cheetah, but Kid works great for
HTML/XML which is a large portion of a webapp's output. Rather than
optimizing for the less common case, I thought it best to optimize for
the most common case.
> "XSL is only performant because of work put in on the individual
> implementations to make it so."
>
> Yes just like Cheetah, there s been a huge amout of work put into this
> project , it s a bit sad not to do take advantage of this. If i was
> about to bring the best-of-breed i d use Cheetah or XSL (but Cheetah
> is more friendly to newcomers in a python based framework) , but then
> again it s a matter of personal taste.
True, this is a matter of taste. I would say that Cheetah *is* the
best-of-breed template language for things other than XML/HTML.
> I began to use cheetah a few days ago so i am not 100% confident with
> it yet but i liked it so far (i am no kid expert either, but i ve
> played with most of its functionalities).
I've used Cheetah quite a bit, and I should be clear that I'm not
trying to sound negative about Cheetah. Cheetah is good at what it
does. I just think that Kid is better at doing an important and common
webapp task (generating HTML output).
> "TurboGears will not stand in the way of people using Cheetah, and can
> go so far as allowing Cheetah templates to receive data via
> turbogears.expose. "
>
> Yes, looking foward to use some of the great features from the Toolbox,
> i guess i am just sad having to give up on widgets & i18n for now.
>
>
> "But, going beyond that will just make things messy"
>
> Yes certainly, i didn't think of all the implications for sure (haven't
> tried widgets yet, maybe kid got improvements in terms of performance
> lately too).
I honestly don't know if Kid has had performance improvements applied,
I just know that some looking into it was going on. I do believe that
any performance problems can be addressed through the many means
possible in Python.
> Sorry for the spelling mistakes, it not my native language.
Your message seemed quite clear to me! Thanks for taking the time! I
know it is more difficult to write in another language.
Kevin
Peter Hunt
I think combining Subway and TG under the TG name would end the web
framework wars. As of right now (I haven't talked to anyone related to
TG about these ideas), I would propose the following:
- 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.
- 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.
- CherryFlow would be a quick addition to TG that wouldn't require much
else other than some refactoring and some documentation.
- 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.
- 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.
- 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.
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!
Peter Hunt
Ian Bicking
> - 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.
Jorge Godoy
> - 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 <jgo...@gmail.com>
Jorge Godoy
> 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 was looking at Paste's website... Where can I find more "Paste is good for
this and that and you can use it like this" docs?
--
Jorge Godoy <jgo...@gmail.com>
Ian Bicking
Well, I've always had a problem explaining what it is. Maybe this more
recent blog entry is the best description of it at the moment:
http://blog.ianbicking.org/what-is-paste-yet-again.html
There's a couple more recent things in Paste; Clark Evans added some
identification/authentication code, and Ben Bangert just added some
rough OpenID code. Last night I just committed two new paster commands
for installing and setting up applications; they are rough but
more-or-less extractions of what I'm using at work. But it's mostly
what's listed there.
Actually using these bits in the context of TG is the open question. I
don't want Paste to be leaky abstraction (or rather, Paste shouldn't
leak into the abstractions a framework provides), but that means that it
relies on a framework to do some integration work (you can't really have
both).
Peter Hunt
point...more of a "pie in the sky" type of deal.
Ian: I've got commit in the CP core. What exactly needs fixing? Shoot
me an email.
Peter Hunt
Kevin Dangoor
On 12/20/05, Peter Hunt <floyd...@gmail.com> wrote:
> I think combining Subway and TG under the TG name would end the web
> framework wars. As of right now (I haven't talked to anyone related to
> TG about these ideas), I would propose the following:
Thanks for the detailed proposal! This email was exactly what I was
looking for to see how we can forge ahead.
In order to keep the discussion focused, I'm going to respond to the
individual bullets in separate messages.
Kevin
Kevin Dangoor
> 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.
I'm sure Cheetah (only with a compiled namemapper) currently (and
likely in the future) outperforms Kid. Kid's performance can, and
doubtless will, be improved. I don't think Cheetah is more extensible
than Kid. Kid has an exceptional collection of mechanisms for
composing templates.
Kid can now do plaintext, but it's certainly not as elegant as Cheetah for that.
> 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.
Agreed.
As I alluded earlier in the thread, I *do* plan to have a way to plug
in a different template system, but primarily for the purpose of
backwards compatibility and easier transition to TurboGears.
Kevin
Sylvain Hellegouarch
>
> As I alluded earlier in the thread, I *do* plan to have a way to plug
> in a different template system, but primarily for the purpose of
> backwards compatibility and easier transition to TurboGears.
I like the sound of that idea since it has been the core idea of CherryPy itself
since the very beginning. Being able to plug and play what fits your needs. I'd
like for instance replace Kid by XSLT for my personnal use.
- Sylvain
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
Kevin Dangoor
> 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.
This is funny, in a way. Cheetah is a more programmer-centric template
system than Kid. So, it's hard to say which is more designer friendly:
widgets with individual templates, or Cheetah+htmlfill.
Widgets *do* actually have a way to be completely designer friendly
via the "source" view of a widget. Basically, the workflow is that the
programmer creates the form object with the appropriate
fields/validators (or automatically using a utility function) and the
widgets spit out the Kid template for the whole form, ready to drop
into a template. The idea is that the form would function the same as
a generated form, but is fully customizable, even with WYSIWYG tools
(that are XHTML capable).
The basis for this is there, but it'll take more tools to make it
slick and very usable.
Kevin
Kevin Dangoor
> > As I alluded earlier in the thread, I *do* plan to have a way to plug
> > in a different template system, but primarily for the purpose of
> > backwards compatibility and easier transition to TurboGears.
>
> I like the sound of that idea since it has been the core idea of CherryPy itself
> since the very beginning. Being able to plug and play what fits your needs. I'd
> like for instance replace Kid by XSLT for my personnal use.
Keep in mind, though, that you'll likely miss out on the other cool
stuff like widgets i18n.
Kevin
Sylvain Hellegouarch
> Keep in mind, though, that you'll likely miss out on the other cool
> stuff like widgets i18n.
The ultimate experience would to be able to switch any layer of TG to replace by
another that respects the same API :)
What I'm dreaming?
Peter Hunt
about consistency and One Way to Do It. By encouraging pluggable
components, this concept would be ruined, IMO.
Sounds like you want to write a CherryPy generic template API.
Peter Hunt
Kevin Dangoor
Kevin
Mike Orr
>
> >
> > As I alluded earlier in the thread, I *do* plan to have a way to plug
> > in a different template system, but primarily for the purpose of
> > backwards compatibility and easier transition to TurboGears.
>
> I like the sound of that idea since it has been the core idea of CherryPy itself
> since the very beginning. Being able to plug and play what fits your needs. I'd
> like for instance replace Kid by XSLT for my personnal use.
>
> - Sylvain
Case in point. I have three Quixote applications using Cheetah and a
homegrown SQL generator. I see TG and like its clean controller
design, forward-compatibility for Ajax, SQLObject which has stablized
since last year, and an active development community that has many
more features almost done.
But I'm not too happy about Kid. Yes, my *output tags* have to be
valid HTML, but why should my control structures be
(#for/#if/#def/#extends). The significant word (py:for) is buried in
a tag attribute where it's easy to miss. I'll have to put comments
around every for-block and if-block to make them stand out. And Kid
doesn't have if/else!
Now, if TG had a simple way for me to plug in a Cheetah engine, yoo
hoo! Even if it didn't ship with TG for philosophical reasons, that
would be fine. I do believe in "one way of doing things". I just
don't believe in adding artificial barriers to prevent people from
doing other things. Right now you have to completely rewrite @expose
or push your own template.