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.view() into TG: not cool. I've added a
plugin architecture outline to the Cheetah ticket (#214). Unless I'm
mistaken, it's dirt simple to port the existing Kid code to this, and
then people can also write drivers for any other template system they
like. TG wins because it's fundamental goal hasn't been violated: a
"one way to do it" that works out of the box. But TG also wins again
because a secondary userbase will come to it, those who absolutely
refuse to use Kid.
Otherwise users have two choices. Suck it up and use Kid, or port all
of TG's other interesting features to <Other Framework>. That's
really what "Don't use TG if you don't like Kid" means.
I'd like to see this plugin philosophy extended to any other major
areas of controversy that come up. I don't see the SQLObject
dependency as significant at this point: there is no clear
alternative. But it could be an issue in the future. The other
potential areas are things that haven't stablized yet: forms,
identity, sessions, etc. Hopefully the final contenders will be
flexible enough to work for everybody, but if not, people need an easy
way to substitute their own, and this should be documented with
examples.
--
Mike Orr <slugg...@gmail.com>
(m...@oz.net address is semi-reliable)
Mike Orr
> > Keep in mind, though, that you'll likely miss out on the other cool
> > stuff like widgets i18n.
That's the tradeoff. Use Kid or port these extra features yourself.
Or maybe a third-party maintainer will arise to do it for everybody.
> 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?
That may be unfeasable in this case. But if you can think of a way to
do it, it's certainly worth making a proposal.
The interface between all these "extras" and Kid seems to be an
ElementTree node. The extra thingy generates it, and Kid knows how to
interpret it. So maybe if Cheetah knew how to interpret it too,
everything would be hunky-dory. (My, I'm using a lot of corny slang
today. It must mean I'm very tired.) Actually, if the thingy has a
suitable .__str__() method that produces the appropriate HTML, the
work would already be done. Oh, but ElementTree produces XML not
HTML, darn. A Cheetah filter would have to do the conversion. Well,
that's not an insurmountable task.
Mike Orr
> The other
> potential areas are things that haven't stablized yet: forms,
> identity, sessions, etc. Hopefully the final contenders will be
> flexible enough to work for everybody, but if not, people need an easy
> way to substitute their own,
For forms, the issue is whether @expose has has extra keywords to
specify the form, validators, etc. If so, these should call a limited
intermediate API rather looking deeply into the form object itself.
This would allow an alternative form library to add just one object or
set of methods to make itself @expose-compatible.
Simon Belak
> The interface between all these "extras" and Kid seems to be an
> ElementTree node. The extra thingy generates it, and Kid knows how to
> interpret it. So maybe if Cheetah knew how to interpret it too,
> everything would be hunky-dory. (My, I'm using a lot of corny slang
> today. It must mean I'm very tired.) Actually, if the thingy has a
> suitable .__str__() method that produces the appropriate HTML, the
> work would already be done. Oh, but ElementTree produces XML not
> HTML, darn. A Cheetah filter would have to do the conversion. Well,
> that's not an insurmountable task.
>
In regard to HTML serialisation, maybe Ian would contribute his patch to
ElementTree [1] as used for Commentary?
[1] http://blog.ianbicking.org/xml-processing.html#comments
Simon
Sylvain Hellegouarch
>
> Actually, I think that's a bad idea. Front-to-back frameworks are all
> about consistency and One Way to Do It.
That doesn't imply either we talk about the implementation or the design. WSGI
is a not about the implementation but the design, still it's 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.
Nope, but CherryPy core idea is to stay out of the way of the developer as much
as possible. If people keep writing new web frameworks, it's exactly because at
one point you try many of them and you think "damn it no let me work the way I
want. Screw it I'll write my own".
If you make sure people can use their template of choice, their backend of
choice, etc. then you make sure people are happy because they don't have to
learn a new framework all over again each time.
But fair enough, Kevin said it was not his priority and I respect that (and I
respect your POV of course), I just think that sooner or later someone will
write a TG killer framework because he work the way he wanted with TG.
Sylvain Hellegouarch
awake. My gosh all those mistakes I made. *sigh*
/me gets some orange juice
Selon Sylvain Hellegouarch <s...@defuze.org>:
Ian Bicking
What I wrote is just what Kid already has -- writing HTML. ElementTidy
is what parses the HTML, but tidying source is not at all appropriate
for a template. Parsing actual HTML for a template should be more
strict and predictable. So again, I'd recommend looking at the parser
in ZPT:
http://svn.zope.org/Zope3/trunk/src/zope/tal/htmltalparser.py?rev=30078&view=markup
--
Ian Bicking | ia...@colorstudy.com | http://blog.ianbicking.org
Marek Baczynski
> 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!
Exactly. People with a strong PHP background absolutely love Cheetah
for being Smarty, but much, much better. Kid, on the other hand,
strikes me as software-that-knows-better -- and I say, don't worry
about me producing invalid HTML, I sometimes want exactly that (on very
rare occasions, but still.) All visibility arguments are also valid.
(You'll probably think that I just don't like Kid; and you're right :))
I understand the strong push for having a single templating engine, but
IMHO Kid is just not flexible enough. If I could do something like this
at the beginning of the template file:
# shebang, emacs and python inspired: -*- template: cheetah -*-
<cheetah code here>
I'd be more than happy.
Peter Hunt
knowledge) the first framework to use attribute-based templating, needs
to break down and use DTML to generate other document formats such as
CSS.
It seems to me like it is too late to switch templating languages,
unfortunately. This is Kevin Dangoor's framework, let him decide :)
Peter Hunt
pan...@gmail.com
pan...@gmail.com
IMO there are two disatvanatages in TG:
1) lack of chosing template language (which is kind of religion)
2) lack of url-name mapper
I heard second will be fixed using routes.
Fixing first issue would be big step towards users - eg. I have big
template library in cheetah and dont want to rewrite them.
Maybe additional value for decorator (tmpl_language = "KID") would do?
I think i could code decorator to use cheetah template, but heard that
tg uses incremental sending - kid sends rendered part of template,
what couldnt be done in cheetah.
What do you think?
2005/12/22, pan...@gmail.com <pan...@gmail.com>:
_max
Yes, maybe TurboGears should do it RoRs way here: no default (real)
template language.
It's too late to switch templating languages, but maybe its possible to
make widgets and other template sensitive parts of TG "template
independant" like RoR, wich is not the same thing as supporting Kid &
Cheetah everywhere, less hassle, and that would please everyone (i
think).
Kevin Dangoor
The danger of this is that if we stop making assumptions about a
template language to use, we miss out on some features that we get by
making the assumption. (Examples: i18n has a Kid filter that makes it
easier to provide the correct text, and the widgets allow you to use
the same templates you use for the main code... which is a bonus.)
One good thing I'll say about this thread: most people are asking for
Cheetah specifically. In some ways, that's better than having a bunch
of messages where people say "yeah! and I want Myghty" and others say
"I want PSP". And let's throw in XSLT for Sylvain while we're at it :)
There are actually interesting ways that changes on the parser end
could make Kid more attractive to the people who like Cheetah without
making it less attractive to the people who like Kid. David Stanek
mentioned to me the idea of using a more liberal HTML parser (which
would take somewhat cruddy HTML input and produce nice HTML output on
the other end). Anything that can ultimately end up as Elements (and
then serialized to plain text or HTML or XML or whatever) is fair game
to be mixed and matched with the rest of Kid output. That's one nice
thing about Kid's architecture: if you hand it an Element to render,
it just drops it into the tree, ready for serialization.
I do think some people dismiss Kid a little too readily. And py:match
is addictive when you use it (and, as far as I know, Cheetah has
nothing like it).
Kevin
Jarek Zgoda
> Exactly. People with a strong PHP background absolutely love Cheetah
> for being Smarty, but much, much better. Kid, on the other hand,
> strikes me as software-that-knows-better -- and I say, don't worry
> about me producing invalid HTML, I sometimes want exactly that (on very
> rare occasions, but still.) All visibility arguments are also valid.
> (You'll probably think that I just don't like Kid; and you're right :))
In my daily work I use HTMLTemplate, so I am more than happy with Kid.
This makes me suspicious that you can learn to love Kid if you get
exposed to other types of templating engines. How do you like Xist from
LivingLogic?
> I understand the strong push for having a single templating engine, but
> IMHO Kid is just not flexible enough.
Too much flexibility kills simplicity. That's why we all love Perl. No,
really. ;)
--
Jarek Zgoda
http://jpa.berlios.de/
Kevin Dangoor
>
> sorry, clicked "enter" unintenionaly:
>
> IMO there are two disatvanatages in TG:
> 1) lack of chosing template language (which is kind of religion)
> 2) lack of url-name mapper
>
> I heard second will be fixed using routes.
Probably so. I'm interested in hearing your use case for #2...
CherryPy is pretty flexible when it comes to URLs. (Compatibility with
existing URLs is a use case that I do agree a mapper will help out
with).
> Fixing first issue would be big step towards users - eg. I have big
> template library in cheetah and dont want to rewrite them.
Yep. I agree that this is a valid use case for providing the ability
to plugin a different template language.
>
> Maybe additional value for decorator (tmpl_language = "KID") would do?
>
> I think i could code decorator to use cheetah template, but heard that
> tg uses incremental sending - kid sends rendered part of template,
> what couldnt be done in cheetah.
I've already seen a decorator for using Cheetah. It's not hard,
because you can just return a string and CherryPy will send it along.
A plugin would be more graceful.
Kevin
Mike Orr
> There are actually interesting ways that changes on the parser end
> could make Kid more attractive to the people who like Cheetah without
> making it less attractive to the people who like Kid. David Stanek
> mentioned to me the idea of using a more liberal HTML parser (which
> would take somewhat cruddy HTML input and produce nice HTML output on
> the other end). Anything that can ultimately end up as Elements (and
> then serialized to plain text or HTML or XML or whatever) is fair game
> to be mixed and matched with the rest of Kid output. That's one nice
> thing about Kid's architecture: if you hand it an Element to render,
> it just drops it into the tree, ready for serialization.
I'm fine with optional Kid preprocessors that cover over some of the annoyances:
#####
<FOR expr="r in records" attr="value"> =>
<div py:for="r in records" attr="value">
#####
<FOR expr="r in records" tag="span" attr="value"> =>
<span py:for="r in records" attr="value">
#####
<?python <![CDATA[
is_insufficient = level < 100
]]> python> =>
<?python
is_insufficient = level & 100
?>
Although a more pleasant spelling for <
Bob Ippolito
> knowledge) the first framework to use attribute-based templating, needs
> to break down and use DTML to generate other document formats such as
> CSS.
It's a pretty bad idea to generate CSS or JavaScript anyway. Why would
you ever need to? Especially because you probably wouldn't end up doing
it correctly if you tried, because all these langauges have different
escaping rules.
-bob
Karl Guertin
> It's a pretty bad idea to generate CSS or JavaScript anyway. Why would
> you ever need to?
I don't know about you, but I regularly wish I could set variables in
CSS, mostly for colors. Inman has a php package that does this and
I've seen it mentioned in several places besides just on his site.
Ville
> I've already seen a decorator for using Cheetah. It's not hard,
> because you can just return a string and CherryPy will send it along.
> A plugin would be more graceful.
I don't know, all that seems necessary is IMO a simple "howto" bullet
point on how to use different template types easily (while retaining
Kid as the default/official/supported one). How much simpler does it
need to get? If much simplification is needed, it should be provided by
the projects that deliver the template engines.
That said, I don't understand all the hoopla around Cheetah. I've been
using EmPy (for non-web applications) and it seems to be much simpler
("@" is the only special character) without sacrificing the power or
ease. I'd need to see some benchmarks to draw a definite conclusion,
but I suppose a template that is "bytecompiled" to some intermediate
form (or even just having the "special" byte positions in a table)
could be the fastest one, and would benefit from a framework that
provides the precompilation machinery...
Perhaps TurboGears could have support for "pluggable" templating
engines as described in:
http://peak.telecommunity.com/DevCenter/setuptools#dynamic-discovery-of-services-and-plugins
Fictional example:
setup(
# ...
entry_points = {'turbogears.template_engine': '.em =
empy.tg_entrypoint'}
)
Kevin Dangoor
> Perhaps TurboGears could have support for "pluggable" templating
> engines as described in:
>
> http://peak.telecommunity.com/DevCenter/setuptools#dynamic-discovery-of-services-and-plugins
>
> Fictional example:
>
> setup(
> # ...
> entry_points = {'turbogears.template_engine': '.em =
> empy.tg_entrypoint'}
> )
This is exactly what I meant by plugins for template engines.
Kevin Dangoor
> I'm fine with optional Kid preprocessors that cover over some of the annoyances:
>
> #####
> <FOR expr="r in records" attr="value"> =>
> <div py:for="r in records" attr="value">
>
> #####
> <FOR expr="r in records" tag="span" attr="value"> =>
> <span py:for="r in records" attr="value">
>
> #####
> <?python <![CDATA[
> is_insufficient = level < 100
> ]]> python> =>
> <?python
> is_insufficient = level & 100
> ?>
> Although a more pleasant spelling for <![CDATA[ would
> be nice. Maybe <?python-cdata ... ?>
A preprocessor that is not doing XML could look entirely different
(even Cheetah-like). But, something like what you're proposing would
likely be far easier to implement.
> #####
> That py:layout feature.
> http://lesscode.org/projects/kid/ticket/105
You can basically do that today using py:def.
http://lesscode.org/projects/kid/wiki/DefBasedLayoutTemplateRecipe
But, the syntax suggested in the ticket is a bit cleaner and easier
for that style of layout.
>
> #####
> Some kind of if/else. I can't think of a fesasble way without two
> child elements though, and this may be worse than the original
> problem.
>
> <IFELSE expr="records">
> <THEN>
> # Draw table.
> </THEN>
> <ELSE>
> <div><em>No records.</em></div>
> </ELSE>
> </IFELSE> =>
>
> <div py:if="records">
> # Draw table
> </div>
> <div py:if="not (records)">
> <div><em>No records.</em></div>
> </div>
I agree that if/else is tricky with an XML-ish syntax.
>
>
> > And py:match
> > is addictive when you use it (and, as far as I know, Cheetah has
> > nothing like it).
>
> No, but nobody has asked for it either.
I doubt anyone would ask for it... Cheetah knows nothing about
document structure, so it has nothing to match on. (Thus implementing
something like py:match for Cheetah would be difficult and go against
Cheetah's grain of just working with unstructured text) It's still a
useful feature!
py:match lets you do things like that py:layout feature without
putting *any* special markup in the individual pages (other than the
reference to the layout template, of course).
Kevin
Mike Orr
> point on how to use different template types easily
Yes, but first TG's architecture has to be changed slightly.
Currently you have to rewrite @expose, which is what the Cheetah patch
does. Writing decorators with arguments befuddles even good Python
programmers; it can't be made "simple", and you have to reimplement
parts of TG you didn't intend to change. But when @expose is taught
to discover the locally-supported template system(s) via a
configuration setting, list of functions, or egg entry points, it will
be easy.
Mike Orr
>
> On 12/22/05, Mike Orr <slugg...@gmail.com> wrote:
> > I'm fine with optional Kid preprocessors that cover over some of the annoyances:
> >
> > <div py:for="r in records" attr="value">
> >
There are a lot of possibilities. The XML-compliant ones can maybe be
done as Kid filters. The non-compliant ones can convert string to
string before Kid sees it. Going from String to ElementTree is also
intriguing, although I think Kid would accept that only for
placeholder values and not the entire template.
I'll make tickets for the more promising proposals. I don't think
this has to hold up 0.9, however. The multitemplate plugin is more
important, even if the API is marked experimental.
The <FOR> proposal is XML compliant except that we've defined the
default namespace as XHTML. If the parser can ignore that, we're
fine. Or we can define an XHTML+extras DTD, which a later stage
changes to XHTML.
A preprocessor that puts a complete document around a <body> or <div
class="page_content"> tag would also be desirable. I like my page
templates to contain just their unique content, not several lines of
boilerplate tags around them. Yes, the raw template shows up wrongly
in the browser but it does show up. I think this is what py:layout
was designed for.
Bob Ippolito
When was the last time you wanted to do this? What was the use case? If
there are just a few different colors, you can always use separate css
files (either just copies, or three files.. a base file and two with
@imports and the custom colors).
If it's really dynamic every page load then the css declarations are
probably better off ending up in the html anyway. That way you can cache
the static parts of the css and the dynamic parts definitely won't get
cached since they're not in a separate file.
-bob
Kevin Dangoor
> A preprocessor that puts a complete document around a <body> or <div
> class="page_content"> tag would also be desirable. I like my page
> templates to contain just their unique content, not several lines of
> boilerplate tags around them. Yes, the raw template shows up wrongly
> in the browser but it does show up. I think this is what py:layout
> was designed for.
Actually, Kid 0.8 already provides a way to have a template just
define the content section and get marked up by a surrounding
template. AFAIK, the only doc I saw on this was a Kid ticket :(
Kevin
Karl Guertin
> > I don't know about you, but I regularly wish I could set variables in
> > CSS, mostly for colors. Inman has a php package that does this and
> > I've seen it mentioned in several places besides just on his site.
>
> When was the last time you wanted to do this? What was the use case? If
> there are just a few different colors, you can always use separate css
> files (either just copies, or three files.. a base file and two with
> @imports and the custom colors).
I have had 800-1k line css files using four or five colors. I don't
want variables so much as constants so I don't have to go through the
entire file changing colors. You can't always just do a search and
replace (unless you confirm every step, and that can get tedious).
It's the same principle as #defining a constant in a C file.
Bob Ippolito
I'm sure you could do this statically rather easily if you simply used
more than one class in the document, or used more advanced features of
CSS.
-bob
Karl Guertin
It's not so much about doable as it is about convenient. I know a
couple ways to work around the issue, but they all have drawbacks
bigger than the inconvenience of search/replacing color values. You
asked for a scenario where you'd want to do templated CSS or JS and I
gave an example along with a tool ([1] though I didn't link it the
first time) that designers actually use.
Bob Ippolito
I'd disagree, and I've never seen any designer use that (or any similar)
tool.
-bob
David Stanek
It's not so much about doable as it is about convenient. I know a
couple ways to work around the issue, but they all have drawbacks
bigger than the inconvenience of search/replacing color values.
Some would not consider splitting up CSS declarations into multiple files a work around. I consider it an appropriate use of the technology. It is trivial to split of things that change (i.e. colors) into separate files.
Ron Stephens
Martelli:
UrsusMaxi...@gmail.com
Dec 25, 7:53 pm show options
On December 15, Alex Martelli wrote:
>Alternatively, counting Google hits:
>rails python django 112,000
>rails python subway 81,600
>rails python turbogears 32,000
>This isn't exactly "buzz", of course, but it's SOME measure of "critical
>mass" -- and with django about equal to subway+turbogears, it does not
>appear to show any emerging dominance. A significant measure of "buzz"
>might be obtained by redoing the same search in, say, two weeks, and
>noticing the deltas...
>Alex
Hmm, on December 25, I re-did the numbers using google:
rails python django 138,000
rails python subway 66,000
rails python turbogears 46,000
Now, I coudln't resist doing it this way too:
python django 360,000
python subway 690,000
python turbogears 127,000
Unfortunately, no compelling trend emerges. This is the problem, I
think, no, trend, no clear winner (other than Rails;-)))
Python web frameworks, for the love of God, UNITE!!!!
This will work, I think, if and only if the "Consolidating" framework,
the one to be used to absorb the other(s) best aspects, makes immediate
and up-front, highly visible concession(s) so as to clearly
communicate a win-win scenario.
Ron Stephens
If this is to work, in my opinion, (and by "work" I mean be successful
enough to challenge Rails), then Cheetah must be enabled as an equal
templating language to Kid (at least). Kevin, you don't know me, but I
dare make this post for the good of Python. Kid may be technically
superior in every way to Cheetah (I don't know), but is the least
popular choice you made for TurboGears. Cheetah is a lot more popular.
You obviously love Kid; I suspect you think it is the best choice you
made in creating TurboGears.
But if you give in on this, you will be amply rewarded, but on the
other hand, I do not believe a Kid-centric TurboGears will compete
effectively with Rails, for it will signal continuing division and in
Python land.
Ron Stephens
fumanchu
because you believe some of your end-to-end integration will be lost if
you can't guarantee one of the components). I've found that it isn't
the truism I thought it was. I recently put a lot of work into CherryPy
and Dejavu (to name a couple of my larger projects), allowing options
where there used to be One Way. I've found time and again that if I
rephrase the issue from "I'm going to lose functionality if I break
this up" to "those users who choose a different component will pay the
[performance|development|maintenance] penalty for their own choice", I
sleep much better at night.
For example, I support using "shelve" as a data store with Dejavu. For
simple queries and small stores, it beats the pants off RDBMS's. But
because it is a builtin StorageManager, it has to support the full
interface, including multirecall (both INNER and OUTER JOINs). Now that
part is SO much slower than with DB's, that it's only usable with toy,
demo datasets. But I have no problem with that, because it's a choice I
leave to the deployer; they may decide their app has few enough
multirecall's to make the tradeoff worthwhile.
Perhaps it's something about Python itself, or perhaps my design skills
have improved, or my sensibilities changed. But I should think you
could find a way to say, "fine, use Cheetah; if you don't use Kid, you
don't get this nice i18n tool (unless you port it! ;). Your choice."
My 2 cents.
Robert Brewer
System Architect
Amor Ministries
fuma...@amor.org
Bob Ippolito
> Perhaps it's something about Python itself, or perhaps my design
> skills
> have improved, or my sensibilities changed. But I should think you
> could find a way to say, "fine, use Cheetah; if you don't use Kid, you
> don't get this nice i18n tool (unless you port it! ;). Your choice."
I think it's worthwhile to make it easy to use Cheetah as an
alternative... if for no other reason than it would give a lot of
people a good reason to shut up. All of the ranting and raving for
and against Cheetah makes me ill.
Personally I find Cheetah to be a really gnarly choice for an HTML/
XML template language, but it seems like an OK choice for other
content if you really can't get along with just string
interpolation. I just don't find myself in that situation very often.
However, I'm not writing other users' web apps, so I couldn't care
less how funky their templates are. All I'm concerned with is that
Kid (or something of similar design) is what's used in the core for
doing HTML and XML.
-bob
David Stanek
Now, I will just add this (here only):
If this is to work, in my opinion, (and by "work" I mean be successful
enough to challenge Rails), then Cheetah must be enabled as an equal
templating language to Kid (at least). Kevin, you don't know me, but I
dare make this post for the good of Python. Kid may be technically
superior in every way to Cheetah (I don't know), but is the least
popular choice you made for TurboGears. Cheetah is a lot more popular.
You obviously love Kid; I suspect you think it is the best choice you
made in creating TurboGears.
While I agree that there needs to be a good way to use any template engine, I know switching is the wrong thing to do right now. There is way too much invested. I think Kevin is an the right track in how he is dealing with this issue.
It is quite possible that the end templating system maybe something completely different or some wierd marriage between Kid and Cheetah. It might be wise to create a KidVsCheetah? wiki page in trac that has all of the complaints. Once all this information is in one place we can effectively make decisions.
But if you give in on this, you will be amply rewarded, but on the
other hand, I do not believe a Kid-centric TurboGears will compete
effectively with Rails, for it will signal continuing division and in
Python land.
What will happen when the next great template language comes along? Or when TG tries to merge with another framework that has yet another template language?
-- David
Mark Ramm
> alternative... if for no other reason than it would give a lot of
> people a good reason to shut up.
This is exactly why the Ubuntu team created Kubuntu. One of the most
common questions they got was why did you choose Gnome over KDE. And
it wasn't enough that they had good reasons, and it was clearly be
best default for them (they were aiming at computer novices who would
be bewildered by many of the configuration options in KDE) it wasn't
the best choice for everybody. So now there is a Kubuntu project,
and it gets significant funding, and has become a popular choice for
KDE people.
But, it was also initially designed and supported by developers
outside the core, because the core needed to focus on making the gnome
based version rock. If Ubuntu came out with two "OK, not great"
versions to start, nobody ever asked for a KDE based Ubuntu.
I think there is a lesson to be learned here, and I am convinced that
if somebody can add really good Cheetah support that's easy to use, to
TurboGears, and make it play nice and leave Kid as the default, I
think that will make everybody happy. But I'm also convinced that we
have other fish to fry, and we shouldn't loose focus on CRUD, and
other 1.0 blocking features.
Anyway, from the looks of things over at CherryPy, that might be a
little bit easier than it was a week ago. (
http://projects.dowski.com/projects/buffet )
--Mark Ramm
Kevin Dangoor
These numbers, in my opinion, are almost completely useless. I
realized this soon after TurboGears was released. Before release, a
Google search for TurboGears yielded ~60 results. Within a week of
release, a search yielded more than 100,000 hits. I'm certain that one
would be very hard pressed to truly find 100,000 pages referring to
TurboGears a week after release.
That's why I've been paying a lot more attention to what's visible in
front of me: how many people are members of the google group, how
active are they, how many people are contributing patches, how many
people are looking at the site and the screencasts, how many
downloads? And, probably most importantly, what are people doing with
it?
Any of these things taken by themselves are not very compelling as a
statistic. Taken together, you can see that things are moving and
moving fast with TurboGears. (That may be true of Django, as well, but
the stuff I really know about is TurboGears.)
Here's some of the qualitative stuff that I get out of reading the
mailing list and talking with users directly: businesses are using
TurboGears (for internal apps *and* for products), people are moving
to TurboGears from Java and PHP, publishers are interested in
publishing TurboGears-related material (even if O'Reilly isn't!).
> Python web frameworks, for the love of God, UNITE!!!!
"For God's sake, think of the children!"
Luckily, I've already responded to this. Ruby on Rails (and Ruby by
association) have *not* been growing because Python has too many
frameworks. Rails was a distinctly better product with better
marketing.
http://www.blueskyonmars.com/2005/12/20/python-and-the-one-web-framework/
> This will work, I think, if and only if the "Consolidating" framework,
> the one to be used to absorb the other(s) best aspects, makes immediate
>
> and up-front, highly visible concession(s) so as to clearly
> communicate a win-win scenario.
I disagree. It will work if and only if the best parts are chosen. Of
course, "best" is subjective, but ultimately *someone* has to decide.
If you try to take everything in or opt for a less ideal way of doing
things as a "concession", the whole becomes weaker. That is a path to
mediocrity or worse.
> If this is to work, in my opinion, (and by "work" I mean be successful
> enough to challenge Rails), then Cheetah must be enabled as an equal
> templating language to Kid (at least). Kevin, you don't know me, but I
> dare make this post for the good of Python. Kid may be technically
> superior in every way to Cheetah (I don't know), but is the least
> popular choice you made for TurboGears. Cheetah is a lot more popular.
> You obviously love Kid; I suspect you think it is the best choice you
> made in creating TurboGears.
Again, I think "for the good of Python" is an invalid argument. "For
the good of Python" is a web framework that provides a great user
experience with a clear path to getting things done, instead of
unnecessary choices at every turn. I also think that "Cheetah is a lot
more popular" is not a very good argument. I could turn around and use
the ridiculous sort of statement that they use on the news: "Kid's
growth in popularity over the last three months has dwarfed that of
Cheetah". With that kind of phrasing, it would sound like Cheetah is
an also-ran, no?
Back to Cheetah, though: as I've said earlier in the thread, I've used
Cheetah quite a bit and it's a very good package. The place where
"Cheetah is a lot more popular" *does* have important meaning is the
use case of providing some Cheetah support to make it easier for
people to migrate their apps. That was a use case I've been planning
to support since before this discussion began (and it's also worth
noting that there are people using Cheetah with TurboGears today).
But, there is a big difference between making it easy for people to
use Cheetah and making Cheetah a core part of TurboGears. I think
David Stanek's suggestion of starting a KidVsCheetah page on the wiki
is a good one. It will allow us to put together a solid picture of the
differences between the two.
> But if you give in on this, you will be amply rewarded, but on the
> other hand, I do not believe a Kid-centric TurboGears will compete
> effectively with Rails, for it will signal continuing division and in
> Python land.
"Continuing division in Python land" has little to do with competing
with Rails. TurboGears with Kid will only have problems competing with
Rails if it provides a lesser user experience. I think Kid provides a
better user experience for HTML/XML.
Kevin Dangoor
> I think there is a lesson to be learned here, and I am convinced that
> if somebody can add really good Cheetah support that's easy to use, to
> TurboGears, and make it play nice and leave Kid as the default, I
> think that will make everybody happy. But I'm also convinced that we
> have other fish to fry, and we shouldn't loose focus on CRUD, and
> other 1.0 blocking features.
>
> Anyway, from the looks of things over at CherryPy, that might be a
> little bit easier than it was a week ago. (
> http://projects.dowski.com/projects/buffet )
Adding some decent Cheetah support is not hard (I've received two
different patches already). My intention is to do it plugin-style
(using an EntryPoint), which should be pretty easy as well and allow
people to plugin whatever template language they wish.
Lethalman
>
> On 12/26/05, Mark Ramm <mark.mch...@gmail.com> wrote:
> > I think there is a lesson to be learned here, and I am convinced that
> > if somebody can add really good Cheetah support that's easy to use, to
> > TurboGears, and make it play nice and leave Kid as the default, I
> > think that will make everybody happy. But I'm also convinced that we
> > have other fish to fry, and we shouldn't loose focus on CRUD, and
> > other 1.0 blocking features.
> >
> > Anyway, from the looks of things over at CherryPy, that might be a
> > little bit easier than it was a week ago. (
> > http://projects.dowski.com/projects/buffet )
>
> Adding some decent Cheetah support is not hard (I've received two
> different patches already). My intention is to do it plugin-style
> (using an EntryPoint), which should be pretty easy as well and allow
> people to plugin whatever template language they wish.
>
> Kevin
>
Hi,
maybe i forgot some discussion, finally would be this union be made or not?
--
www.italianpug.org - Italian Python User Group Founder
www.lethalman.net - Thoughts about computer technologies
jorge....@gmail.com
For what I see people wanting Cheetah have this points:
1 - I need to output <format> and kid doesn't lets me
2 - I just like it better
3 - We should let people decide
for 1 and I think this is the most important part, why don't we made
kid default for XML, XHTML and whatever it implements, and Chettah for
everything else?
for 2 I just say from the quick look I took at Cheetah went this thread
started, that most people complaining about kid are your lazy to try
it, because Cheetah seems easier at first, and I have exactly the same
complains to Chettah as you have for kid, so it's a matter of style.
for 3 Many people have address this so I won't.
3-
Jeff Watkins
for 2 I just say from the quick look I took at Cheetah went this thread
started, that most people complaining about kid are your lazy to try
it, because Cheetah seems easier at first, and I have exactly the same
complains to Chettah as you have for kid, so it's a matter of style.
--
Jeff Watkins
Computers, they're just a fad.
Kevin Dangoor
> Again, I don't usually get involved in arguments like this because I simply
> don't use the templates (my pages are static HTML with Ajax calls), but one
> of my initial complaints with Kid is that it *changes* my code.
>
> If I write in XHTML, I expect it to *stay* XHTML not be translated into HTML
> 4.0.
To me, it's an important feature that I can author in a reliable,
parsable format like XHTML and get browser-friendly HTML 4.0 on the
output.
Besides, ultimately *all* template engines are about changing whatever
the input looks like into whatever the output is supposed to be. Kid
takes advantage of the fact that XML has well-defined syntax rules.
> And if I specify XHTML in the config file, I expect it to look the way
> I wrote it, complete with closing script tags instead of autoclosed script
> tags (<script src="..."></script> instead of <script src="..."/>).
Those are both legal XHTML. If you're really trying to do XHTML, it
makes *no difference* which form you get. The trouble is that you're
probably trying to use it in a real-life browser that doesn't actually
understand XHTML. Which is why Kid translates to HTML 4.0.
> I *really* hate anything that changes my code, because chances are I know
> what I'm doing. And if I don't, I won't learn unless it breaks.
>
> I won't use Kid until it quits screwing with my code.
Personally, I think Kid works fine in these instances. It provides
serializers that understand real world browser (HTML 4.0) and what
we'd really like when the support arrives (XHTML), and they both work
from the same, unambiguous source format.
Kevin
David Stanek
If I write in XHTML, I expect it to *stay* XHTML not be translated into HTML 4.0. And if I specify XHTML in the config file, I expect it to look the way I wrote it, complete with closing script tags instead of autoclosed script tags (<script src="..."></script> instead of <script src="..."/>).
-- David
Ron Stephens
Jorge Vargas wrote:
>For what I see people wanting Cheetah have this points:
>1 - I need to output <format> and kid doesn't lets me
>2 - I just like it better
>3 - We should let people decide
>for 1 and I think this is the most important part, why don't we made
>kid default for XML, XHTML and whatever it implements, and Chettah for
>everything else?
I really like this idea. Anyway, it seems to me that ...
1. Cheetah is very popular, probably the most popular solution of its
kind amongst Pythonistas (certainly more popular than Kid).
2. Cheetah is percieved as being easy by a lot of Pythonistas who do
web programming. Whether this is a mis-conception or not, perceptions
do matter.
3. This leads me to believe that not using Cheetah will be a major
reason why many people don't choose TurboGears.
4. The better support for Cheetah you offer, the more people will
choose to use TurboGears. The more vocal you are about supporting
Cheetah, the better. If Cheetah support is offered grudgingly, this is
not much better than not suppoorting it at all.
Anyway, I will shut up now. Sorry to be a pain.
Jorge Godoy
> On 12/29/05, Jeff Watkins <je...@newburyportion.com> wrote:
> > Again, I don't usually get involved in arguments like this because I simply
> > don't use the templates (my pages are static HTML with Ajax calls), but one
> > of my initial complaints with Kid is that it *changes* my code.
> >
> > If I write in XHTML, I expect it to *stay* XHTML not be translated into HTML
> > 4.0.
>
> To me, it's an important feature that I can author in a reliable,
> parsable format like XHTML and get browser-friendly HTML 4.0 on the
> output.
Anyway, defining kid.outputformat="xhtml-strict" will make Strict XHTML.
Removing the strict will give you transitional XHTML.
--
Jorge Godoy <jgo...@gmail.com>
fre...@pythonware.com
> know what I'm doing.
well, judging from your post, it's not all that obvious that
you do know what you're doing, at least wrt XML and XHTML.
I suggest reading this before proceeding:
http://www.hixie.ch/advocacy/xhtml
(start with the executive summary)
reading the XML infoset specification may also help. XML (and
XHTML) is an information model, not a wire format. if you're
thinking in wire terms, you're completely missing the point.
</F>
Jeff Watkins
not relevant to me. If I write a document that contains:
<script src="..."></script>
I don't want my template processor to change that to:
<script src="..."/>
While I'm well aware that both forms are legal XHTML and are basically
the same, one works in all browsers and one doesn't.
So suggesting that I change the kid.outputformat to xhtml-strict
doesn't change the fact that KID will change my file for no good reason
and will therefore make it *not* work with all browsers. Whereas it
would have worked prior to processing (exempting the processing stuff).
Thanks for suggesting Hickson's article. I've read it, and while I
appreciate his concerns and look forward to the day when UAs actually
support XHTML instead of HTML4 with clever hacks, I don't need to make
a stand and refuse to publish anything as XHTML until they do. I'll
leave the ideology of the issue for others to worry about.
I actually agree with Kevin: it's a nice feature that Kid is able to
translate from XHTML to HTML4. It's just not a feature that I'm
interested in using. And naturally I expect a template processor to
modify the parts of my file that require processing -- that's what they
do. I just don't like it when it changes the parts that *don't* require
processing.
(Apparently, either Google is not delivering messages from this list or
my mail server is ignoring them. So if there are other messages which
are waiting for a response from me, I'll try to get to them as I can.)
fre...@pythonware.com
> the same, one works in all browsers and one doesn't.
what part of "not all browsers support XHTML" in Hixie's article did
you
miss? I still don't think you understand this issue, at all.
</F>
David Stanek
I understand the difference between wire and infoset, but they're just
not relevant to me.
They somewhat are relevant because Kid stands true to the infoset and not the wire format.
If I write a document that contains:
<script src="..."></script>
I don't want my template processor to change that to:
<script src="..."/>
While I'm well aware that both forms are legal XHTML and are basically
the same, one works in all browsers and one doesn't.
So suggesting that I change the kid.outputformat to xhtml-strict
doesn't change the fact that KID will change my file for no good reason
and will therefore make it *not* work with all browsers. Whereas it
would have worked prior to processing (exempting the processing stuff).
I think you should probably serialize as html and not xhtml. Is there any reason that this won't work for you? Does it lack some features you are using?
Part of the reason Kid is so powerful is the fact that it takes a template input and stores it as a series of ElementTree.Element objects. This is also the reason the output does not look quite like the input.
-- David
Jorge Godoy
> I understand the difference between wire and infoset, but they're just
> not relevant to me. If I write a document that contains:
>
> <script src="..."></script>
>
> I don't want my template processor to change that to:
>
> <script src="..."/>
It doesn't happen here:
<script src="/tg_widgets/turbogears.widgets/calendar.js" language="JavaScript"> </script>
<script src="/tg_widgets/turbogears.widgets/lang/calendar-pt-utf8.js" language="JavaScript"> </script>
<script src="/tg_widgets/turbogears.widgets/calendar-setup.js" language="JavaScript"> </script>
This is the code I view in Firefox, for the following template:
<script language="JavaScript" src="/tg_widgets/turbogears.widgets/calendar.js"> </script>
<script language="JavaScript" src="/tg_widgets/turbogears.widgets/lang/calendar-pt-utf8.js"> </script>
<script language="JavaScript" src="/tg_widgets/turbogears.widgets/calendar-setup.js"> </script>
My dev.cfg specifies xhtml-strict as output for Kid.
--
Jorge Godoy <jgo...@gmail.com>
Elvelind Grandin
--
cheers
elvelind grandin
Karl Guertin
<script src="foo.js"></script>
and
<script src="foo.js"> </script>
Are not the same. The latter has a text node inside the script element
consisting of a single space (unless I'm remembering my xml
incorrectly).
David Stanek
The truth of the matter is that unless you are using a Content-type of application/xhtml+xml you are not truely getting XHTML behavior. See the first line of http://www.w3.org/TR/xhtml-media-types/#text-html and all of http://www.w3.org/TR/xhtml-media-types/#text-html.
-- David
Jorge Godoy
You are correct. But both my input and output have a space. :-) I read
somewhere that IE gets lost without it and I got used to adding this single
space...
--
Jorge Godoy <jgo...@gmail.com>
Bob Ippolito
On Dec 29, 2005, at 2:14 PM, Jorge Godoy wrote:
>
> "Jeff Watkins" <jw-l...@newburyportion.com> writes:
>
>> I understand the difference between wire and infoset, but they're
>> just
>> not relevant to me. If I write a document that contains:
>>
>> <script src="..."></script>
>>
>> I don't want my template processor to change that to:
>>
>> <script src="..."/>
>
> It doesn't happen here:
>
> <script src="/tg_widgets/turbogears.widgets/calendar.js"
> language="JavaScript"> </script>
> <script src="/tg_widgets/turbogears.widgets/lang/calendar-pt-
> utf8.js" language="JavaScript"> </script>
> <script src="/tg_widgets/turbogears.widgets/calendar-setup.js"
> language="JavaScript"> </script>
>
> This is the code I view in Firefox, for the following template:
>
> <script language="JavaScript" src="/tg_widgets/
> turbogears.widgets/calendar.js"> </script>
> <script language="JavaScript" src="/tg_widgets/
> turbogears.widgets/lang/calendar-pt-utf8.js"> </script>
> <script language="JavaScript" src="/tg_widgets/
> turbogears.widgets/calendar-setup.js"> </script>
>
> My dev.cfg specifies xhtml-strict as output for Kid.
It looks like you have a space between the opening and closing script
tags, which it is probably preserving.
-bob
Karl Guertin
> You are correct. But both my input and output have a space. :-) I read
> somewhere that IE gets lost without it and I got used to adding this single
> space...
IE actually gets confused on the <script src="foo.js" /> syntax, hence
Jeff's complaints. Adding the space removes the
<script></script>::<script/> equivalence and prevents this.
Jeff Watkins
make. Or more accurately: I don't care. Remember, it's advocacy. Not
gospel.
All browsers will read XHTML served with the content-type text/html and
will *at least* render correct HTML. I simply couldn't care less
whether they complain about invalid XHTML.
Additionally, because the file is well-formed XML, it can be parsed
easily by any number of existing tools.
Maybe I'm just being grumpy because I haven't had any sleep, but I
really hate template processors that modify anything I didn't ask them
to modify. In addition to fiddling with my tags when I didn't ask it
to, it uppercases everything. Ick.
(This is also one of the things I dislike about SQLObject. I
instantiated a RelatedJoin, where did it go and what's this property
doing in it's place? Especially because there's nothing I can do with
the property: it's brain-dead. I can't ask it what the joinColumn is. I
can't ask it anything about the target class. Oh, I can get this
information, I just have to jump through silly hoops to get it.)
Jeff Watkins
to try using xhtml again.
Jeff Watkins
a newline between the open and close script tags. But that's merely a
nit.
I'm also pleased to see it leaves the case of attributes alone. My
JavaScript binding framework (think Apple's Cocoa Bindings for Web
applications) uses custom attributes to do its trick. At some point,
these will be converted to use a namespace, but I haven't had the time.