[TurboGears] Re: Combine TG and Subway?
Mike Orr wrote: Having minimal Cheetah integration so you can at least use a .tmpl file for output seems like a good start. This will pacify the large number of people who will not use TG without Cheetah. No, it's not about market share. It's about using the best tool for the job, and if we think TG is the best framework for many jobs, we shouldn't arbitrarily hinder people from using it just because we're dogmatic about templating. Maybe they'll warm up to Kid gradually if it's not shoved down their throat at the beginning. +1 I think TG should continue using kid as it's native template language (ie. widgets, i18n, etc...) but support cheetah as it currently does for easy migration of other subway/cherrypy sites and having an alternative for jobs where it performs better or it's easier to set up.. I'm currently working on a site and using cheetah for mail and system configuation templates. (generating Bind zone files, Apache vhost config files, etc...). It used to be only cheetah based (via, now obsolte, http://trac.turbogears.org/turbogears/ticket/214 hack that i wrote), but it's been quite easy to port all form-generating templates to kid for integration with the widgets/fastdata subsystem. I really think TG must still support cheetah, and other template languages that people care to implement as plugins (BTW, thanks kevin for the cheetah plugin, it's feels much better not branching too much from the trunk by using my ugly patch). Mainly because they're not too hard to implement and can only be good. Anyway, Kid should continue as official main language for core functionality (widgets et al.). It's easy to have a mixed templating system running (i do), just make sure you stick with kid if youre using widgets or i18n in the template. (I believe that if you render the widget instead of insert it you can still have widgets in a cheetah template, though no automatic insertion of css/js in the head will take place) As Mike said: It's about using the best tool for the job Alberto.
[TurboGears] Re: Combine TG and Subway?
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. 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=""/).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.On 28 Dec, 2005, at 10:18 pm, [EMAIL PROTECTED] wrote: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 Watkinshttp://newburyportion.com/Computers, they're just a fad.
[TurboGears] Re: Combine TG and Subway?
On 12/29/05, Jeff Watkins [EMAIL PROTECTED] 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. 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
[TurboGears] Re: Combine TG and Subway?
On 12/29/05, Jeff Watkins [EMAIL PROTECTED] wrote: 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="" instead of script src=""> Are you actually writing XHTML? Probably not, see http://www.hixie.ch/advocacy/xhtml. Like Kevin said both script src="" and script src="" are correct XHTML and will be evaluated exactly the some by applications that understand XHTML. -- David
[TurboGears] Re: Combine TG and Subway?
Hello Kevin 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.
[TurboGears] Re: Combine TG and Subway?
I *really* hate anything that changes my code, because chances are I 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
[TurboGears] Re: Combine TG and Subway?
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=.../ 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.)
[TurboGears] Re: Combine TG and Subway?
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. 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
[TurboGears] Re: Combine TG and Subway?
On 12/29/05, Jeff Watkins [EMAIL PROTECTED] wrote: I understand the difference between wire and infoset, but they're justnot 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="" 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 basicallythe same, one works in all browsers and one doesn't. So suggesting that I change the kid.outputformat to xhtml-strictdoesn't change the fact that KID will change my file for no good reasonand 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
[TurboGears] Re: Combine TG and Subway?
Jeff Watkins [EMAIL PROTECTED] 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. -- Jorge Godoy [EMAIL PROTECTED]
[TurboGears] Re: Combine TG and Subway?
I belive they fixed the script / problem in the latest version of kid. On 29 Dec 2005 17:14:21 -0200, Jorge Godoy [EMAIL PROTECTED] wrote: Jeff Watkins [EMAIL PROTECTED] 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. -- Jorge Godoy [EMAIL PROTECTED] -- cheers elvelind grandin
[TurboGears] Re: Combine TG and Subway?
On 29 Dec 2005 17:14:21 -0200, Jorge Godoy [EMAIL PROTECTED] wrote: It doesn't happen here: 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).
[TurboGears] Re: Combine TG and Subway?
The interesting thing about all of this is that users think they are using XHTML when they a really using a fudgy form of HTML. There is nothing wrong with serializing as HTML and I am not sure why so many people want XHTML other than to add another buzz word to their resume. 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
[TurboGears] Re: Combine TG and Subway?
Karl Guertin [EMAIL PROTECTED] writes: On 29 Dec 2005 17:14:21 -0200, Jorge Godoy [EMAIL PROTECTED] wrote: It doesn't happen here: 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). 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 [EMAIL PROTECTED]
[TurboGears] Re: Combine TG and Subway?
On Dec 29, 2005, at 2:14 PM, Jorge Godoy wrote: Jeff Watkins [EMAIL PROTECTED] 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
[TurboGears] Re: Combine TG and Subway?
On 29 Dec 2005 17:27:44 -0200, Jorge Godoy [EMAIL PROTECTED] wrote: 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.
[TurboGears] Re: Combine TG and Subway?
Fredrik, I don't understand the ideological point Hickson is trying to 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.)
[TurboGears] Re: Combine TG and Subway?
Elvelind, thanks! I didn't notice that this had been fixed. I'll have to try using xhtml again.
[TurboGears] Re: Combine TG and Subway?
Thanks again! That worked a treat. A small nit to pick: Kid introduces 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.
[TurboGears] Re: Combine TG and Subway?
On Dec 29, 2005, at 2:35 PM, Jeff Watkins wrote:
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.
The thing is that it's not a tool for handing text, it only
understands XML. By the time it parses the document, all of your
entities will be translated to unicode, attribute order is made
irrelevant, and empty tags are empty tags. It's *not* changing your
document with regard to the XML format.
If this was Python, you'd be asking for print {c: 'd', a:
r'b'} to look the same as the input expression, where Python's dict
hashing algorithm and string repr rules happen to print out something
quite different but absolutely equivalent.
-bob
[TurboGears] Re: Combine TG and Subway?
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. What's the point of serving XHTML as text/html apart from confusing the browser? You might not care but user agents might. - Sylvain
[TurboGears] Re: Combine TG and Subway?
Hello, 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. I'm not sure to see the point of serving XHTML as text/html apart from messing up with the user agent expectations. You might not care but user agents do. - Sylvain
[TurboGears] Re: Combine TG and Subway?
On 12/29/05, Jeff Watkins [EMAIL PROTECTED] wrote: In addition to fiddling with my tags when I didn't ask itto, it uppercases everything. Ick. This can be controlled easily be setting serializer.transpose = None where serializer is an instance of HTMLSerializer. I am not sure how easy this is to do within TurboGears. -- David
[TurboGears] Re: Combine TG and Subway?
On 12/29/05, David Stanek [EMAIL PROTECTED] wrote: On 12/29/05, Jeff Watkins [EMAIL PROTECTED] wrote: In addition to fiddling with my tags when I didn't ask it to, it uppercases everything. Ick. This can be controlled easily be setting serializer.transpose = None where serializer is an instance of HTMLSerializer. I am not sure how easy this is to do within TurboGears. -- David It's not easy at this point. but perhaps we should add an option to make it easy? -- cheers elvelind grandin
[TurboGears] Re: Combine TG and Subway?
On 12/29/05, Elvelind Grandin [EMAIL PROTECTED] wrote: It's not easy at this point. but perhaps we should add an option to make it easy? You should just lowercase by default. I haven't seen any handwritten html in the last 5 years that uses uppercase tags. It doesn't matter to the UAs but it does to the designers. I agree with jeff: ick.
[TurboGears] Re: Combine TG and Subway?
On 12/29/05, Karl Guertin [EMAIL PROTECTED] wrote: On 12/29/05, Elvelind Grandin [EMAIL PROTECTED] wrote: It's not easy at this point. but perhaps we should add an option to make it easy?You should just lowercase by default. I haven't seen any handwritten html in the last 5 years that uses uppercase tags. It doesn't matterto the UAs but it does to the designers.I agree with jeff: ick.To my knowledge there has not been any complaints about this, but I too thought it to be odd. But I never really thought about it because only the browser typically sees the output not me. TG can be changed to fix this issue if that is what is desired. -- David
[TurboGears] Re: Combine TG and Subway?
On 12/29/05, David Stanek [EMAIL PROTECTED] wrote: You should just lowercase by default. I haven't seen any handwritten html in the last 5 years that uses uppercase tags. It doesn't matter to the UAs but it does to the designers. I agree with jeff: ick. To my knowledge there has not been any complaints about this, but I too thought it to be odd. But I never really thought about it because only the browser typically sees the output not me. TG can be changed to fix this issue if that is what is desired. Odd as it may seem, apparently the HTML 4.0 standard recommends upper case tags. IIRC, that's what Ryan had told me was the reason for the uppercasing of tags. Kevin -- Kevin Dangoor Author of the Zesty News RSS newsreader email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com
[TurboGears] Re: Combine TG and Subway?
On 12/29/05, Ron Stephens [EMAIL PROTECTED] wrote: Hello Kevin 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. Um, what non-HTML format is there that TG should support out of the box? (And I'm a Cheetah fan, sheesh.) And doesn't the new Cheetah-friendly template handler cover those cases? (I haven't tried it yet.) My main complaint about the template plugin is wiki20.templates.main.tmpl mixes module syntax with filename extensions in a schizophrenic way. Perhaps a scheme identifier at the front instead? cheetah:wiki20.templates.main. 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. This turns on what Cheetah support means. Having full Cheetah integration is incompatible with other parts of TG depending on Kid's side features: mainly its ability to convert XML templates to an object model that can be transformed a la XSLT (py:match et al), and into which you can inject XML elements (e.g., widgets). One can imagine an abstract API that genericizes this for all template types, but it would be a heckuv a lot of work. Having minimal Cheetah integration so you can at least use a .tmpl file for output seems like a good start. This will pacify the large number of people who will not use TG without Cheetah. No, it's not about market share. It's about using the best tool for the job, and if we think TG is the best framework for many jobs, we shouldn't arbitrarily hinder people from using it just because we're dogmatic about templating. Maybe they'll warm up to Kid gradually if it's not shoved down their throat at the beginning. Somehow, Cheetah support will have to be advertised with TG. Right now it's buried under template plugins on the docs page. http://www.turbogears.org/docs/ That could be: templat eplugins (Cheetah) template plugins (Cheetah, etc) Cheetah and other template plugins Also, TG is really marketing itself to two different audiences, and maybe that should be reflected in a second About page. 1) Some people just want an integrated solution, and don't want to hear about a second template system. The current About page handles this. 2) Experienced Python users often have specific ideas about what kinds of tools they prefer. So the second page would highlight TG's flexibility. This is where the tradeoffs of Cheetah could be discussed. -- Mike Orr [EMAIL PROTECTED] ([EMAIL PROTECTED] address is semi-reliable)
[TurboGears] Re: Combine TG and Subway?
On 12/29/05, Mike Orr [EMAIL PROTECTED] wrote: Um, what non-HTML format is there that TG should support out of the box? (And I'm a Cheetah fan, sheesh.) And doesn't the new Cheetah-friendly template handler cover those cases? (I haven't tried it yet.) Ideally, it would be easy to do simple substitutions and such for non-XML formats (CSS and JS) using Kid as well. My main complaint about the template plugin is wiki20.templates.main.tmpl mixes module syntax with filename extensions in a schizophrenic way. Perhaps a scheme identifier at the front instead? cheetah:wiki20.templates.main. Yeah, that smelled funny to me, too. The scheme identifier seems like a good way to go. Good thing this is alpha, so I'm allowed to make changes. (Plus, afaik, I'm the only one who's written a template plugin :) 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. This turns on what Cheetah support means. Having full Cheetah integration is incompatible with other parts of TG depending on Kid's side features: mainly its ability to convert XML templates to an object model that can be transformed a la XSLT (py:match et al), and into which you can inject XML elements (e.g., widgets). One can imagine an abstract API that genericizes this for all template types, but it would be a heckuv a lot of work. No kidding. Also, TG is really marketing itself to two different audiences, and maybe that should be reflected in a second About page. 1) Some people just want an integrated solution, and don't want to hear about a second template system. The current About page handles this. 2) Experienced Python users often have specific ideas about what kinds of tools they prefer. So the second page would highlight TG's flexibility. This is where the tradeoffs of Cheetah could be discussed. This is a good point, and I think that having a page (or several) devoted to Python people coming in from other places would be a good thing. Kevin
[TurboGears] Re: Combine TG and Subway?
Fredrik, I don't understand the ideological point Hickson is trying to make. Or more accurately: I don't care. Remember, it's advocacy. No, it's a simple observation of the fact that Internet Explorer don't under- stand XHTML. It's IE that doesn't care about what you're doing; you think you send XHTML, IE says sorry, Jeff, this is crap, so I'm going to treat it as tag soup. If you think in XHTML infoset terms instead, and ignore the wire, TG will make sure that the info model inside IE matches the info model in your template. Maybe I'm just being grumpy because I haven't had any sleep I suggest sleeping, and rereading the Hixie article a couple of times when you feel better. /F
[TurboGears] Re: Combine TG and Subway?
Kevin Dangoor, el jueves 29 de diciembre a las 15:50 me escribiste: On 12/29/05, David Stanek [EMAIL PROTECTED] wrote: You should just lowercase by default. I haven't seen any handwritten html in the last 5 years that uses uppercase tags. It doesn't matter to the UAs but it does to the designers. I agree with jeff: ick. To my knowledge there has not been any complaints about this, but I too thought it to be odd. But I never really thought about it because only the browser typically sees the output not me. TG can be changed to fix this issue if that is what is desired. Odd as it may seem, apparently the HTML 4.0 standard recommends upper case tags. IIRC, that's what Ryan had told me was the reason for the uppercasing of tags. It's a way to easily distinguish between HTML and XHTML... -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ., \ GPG: 5F5A8D05 // F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05 / '' Es mas posible, que un elefante maneje un cero km a que un camello habite un departamento de un ambiente. -- Peperino Pómoro
[TurboGears] Re: Combine TG and Subway?
Ì'm sorry i was away for a while and just catch up with the thread. 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-
[TurboGears] Re: Combine TG and Subway?
On 12/25/05, Ron Stephens [EMAIL PROTECTED] wrote: I posted this on Python newsgroup just now, in response to Alex Martelli: [EMAIL PROTECTED] 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 django360,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;-))) 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
[TurboGears] Re: Combine TG and Subway?
On 12/26/05, Mark Ramm [EMAIL PROTECTED] 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 -- Kevin Dangoor Author of the Zesty News RSS newsreader email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com
[TurboGears] Re: Combine TG and Subway?
On Dec 26, 2005, at 12:00 AM, fumanchu wrote: 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
[TurboGears] Re: Combine TG and Subway?
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. 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
[TurboGears] Re: Combine TG and Subway?
Kevin Dangoor wrote:
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'}
)
[TurboGears] Re: Combine TG and Subway?
On 12/23/05, Ville [EMAIL PROTECTED] wrote:
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
--
Kevin Dangoor
Author of the Zesty News RSS newsreader
email: [EMAIL PROTECTED]
company: http://www.BlazingThings.com
blog: http://www.BlueSkyOnMars.com
[TurboGears] Re: Combine TG and Subway?
On 12/22/05, Mike Orr [EMAIL PROTECTED] wrote: 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 amp; 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 divemNo records./em/div /ELSE /IFELSE = div py:if=records # Draw table /div div py:if=not (records) divemNo 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
[TurboGears] Re: Combine TG and Subway?
On 12/23/05, Ville [EMAIL PROTECTED] wrote: I don't know, all that seems necessary is IMO a simple howto bullet 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 [EMAIL PROTECTED] ([EMAIL PROTECTED] address is semi-reliable)
[TurboGears] Re: Combine TG and Subway?
On 12/23/05, Kevin Dangoor [EMAIL PROTECTED] wrote: On 12/22/05, Mike Orr [EMAIL PROTECTED] wrote: 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 ?python ![CDATA[ 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. -- Mike Orr [EMAIL PROTECTED] ([EMAIL PROTECTED] address is semi-reliable)
[TurboGears] Re: Combine TG and Subway?
On 12/22/05, Bob Ippolito [EMAIL PROTECTED] wrote: 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. 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
[TurboGears] Re: Combine TG and Subway?
On 12/23/05, Mike Orr [EMAIL PROTECTED] wrote: 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
[TurboGears] Re: Combine TG and Subway?
On 12/23/05, Bob Ippolito [EMAIL PROTECTED] wrote: 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.
[TurboGears] Re: Combine TG and Subway?
On 12/23/05, Bob Ippolito [EMAIL PROTECTED] wrote: 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. 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. [1] http://www.shauninman.com/plete/2005/08/css-constants
[TurboGears] Re: Combine TG and Subway?
Mike Orr wrote: 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
[TurboGears] Re: Combine TG and Subway?
Hi Peter, 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 This message was sent using IMP, the Internet Messaging Program.
[TurboGears] Re: Combine TG and Subway?
I realise people should not be allowed to write messages when they are not awake. My gosh all those mistakes I made. *sigh* /me gets some orange juice Selon Sylvain Hellegouarch [EMAIL PROTECTED]: Hi Peter, 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 This message was sent using IMP, the Internet Messaging Program. This message was sent using IMP, the Internet Messaging Program.
[TurboGears] Re: Combine TG and Subway?
Simon Belak wrote: 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 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=30078view=markup -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
[TurboGears] Re: Combine TG and Subway?
Mike Orr napisal(a): 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.
[TurboGears] Re: Combine TG and Subway?
Not to mention that Kid can't do CSS. Even Zope, which was (to my 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
[TurboGears] Re: Combine TG and Subway?
IMO there are two disatvanatages in TG: 1 2005/12/22, Peter Hunt [EMAIL PROTECTED]: Not to mention that Kid can't do CSS. Even Zope, which was (to my 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
[TurboGears] Re: Combine TG and Subway?
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. 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, [EMAIL PROTECTED] [EMAIL PROTECTED]: IMO there are two disatvanatages in TG: 1 2005/12/22, Peter Hunt [EMAIL PROTECTED]: Not to mention that Kid can't do CSS. Even Zope, which was (to my 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
[TurboGears] Re: Combine TG and Subway?
1) lack of chosing template language (which is kind of religion) 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).
[TurboGears] Re: Combine TG and Subway?
On 12/22/05, _max [EMAIL PROTECTED] wrote: 1) lack of chosing template language (which is kind of religion) 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). 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 -- Kevin Dangoor Author of the Zesty News RSS newsreader email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com
[TurboGears] Re: Combine TG and Subway?
Marek Baczynski napisał(a): 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/
[TurboGears] Re: Combine TG and Subway?
On 12/22/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: 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
[TurboGears] Re: Combine TG and Subway?
On 12/22/05, Kevin Dangoor [EMAIL PROTECTED] wrote: 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 amp; 100 ? Although a more pleasant spelling for ![CDATA[ would be nice. Maybe ?python-cdata ... ? # That py:layout feature. http://lesscode.org/projects/kid/ticket/105 # 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 divemNo records./em/div /ELSE /IFELSE = div py:if=records # Draw table /div div py:if=not (records) divemNo records./em/div /div 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. For functional uses (like the greeting example in section 7.8.1 of the Kid Language Specification), people would just use methods. For overloading the title tag and other header stuff, either the parent or subclass template would have the actual tag with placeholders for the varying stuff, and the other template would have #def's or #attr's to specify the varying stuff. #block may also be useful. I don't think #match is feasable in Cheetah; how would it know which sections of the template to replace? -- Mike Orr [EMAIL PROTECTED] ([EMAIL PROTECTED] address is semi-reliable)
[TurboGears] Re: Combine TG and Subway?
On 12/22/05, Kevin Dangoor [EMAIL PROTECTED] wrote: On 12/22/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: 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... More important is a solution to the RESTful URL problem. Is there a way to handle /articles/1234/edit without an if-switch in a default method? Is that Resource URL class (can't find it now) going to be accepted? -- Mike Orr [EMAIL PROTECTED] ([EMAIL PROTECTED] address is semi-reliable)
[TurboGears] Re: Combine TG and Subway?
Jarek Zgoda napisal(a): 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? HTMLTemplate looks like nevow's XML template, and I didn't really like it when I tried it (nevow wasn't even 0.3 back then; it's 0.7 now, maybe some things changed. BTW, that's where my anti-Kid-like prejudice comes from.) Xist looks like nevow's Stan - a very good idea, but Stan is much, much simpler (or so it looks :)) PS. I consider Nevow the definition of 'innovative' in the Python Web world, even if only because it had Ajax support when nobody even knew it's going to be called like that (and it didn't even require writing Javascript.) Too bad Twisted is so much inside-out it hurts your brain.
[TurboGears] Re: Combine TG and Subway?
Though I'm against supporing too many templating langauges, I do love Cheetah a lot. Kid and Cheetah both have import hooks, to my knowledge. It would be possible to just install them both and determine which language to use just by file extension, right? Peter Hunt
[TurboGears] Re: Combine TG and Subway?
Marek Baczynski napisał(a): 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? HTMLTemplate looks like nevow's XML template, and I didn't really like it when I tried it (nevow wasn't even 0.3 back then; it's 0.7 now, maybe some things changed. BTW, that's where my anti-Kid-like prejudice comes from.) Xist looks like nevow's Stan - a very good idea, but Stan is much, much simpler (or so it looks :)) For me, it's a right way to do XML (so XHTML qualifies here) from Python, so I wouldn't argue. I don't know PHP's Smarty, the only templating engine I know is Apache's Velocity and I hate all these directives (like #foreach, #if, etc.) they put in template, I saw it elsewhere many times. I prefer clean Python code. Kid somehow has it (although it has directives also), HTMLTemplate has it, Xist *is* it. Sure, I'd like to have Xist in TG, but it's not feasible. We do not need anything like that to generate proper output. -- Jarek Zgoda http://jpa.berlios.de/
[TurboGears] Re: Combine TG and Subway?
Not to mention that Kid can't do CSS. Even Zope, which was (to my 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
[TurboGears] Re: Combine TG and Subway?
Hi Peter, On 12/20/05, Peter Hunt [EMAIL PROTECTED] 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
[TurboGears] Re: Combine TG and Subway?
On 12/20/05, Peter Hunt [EMAIL PROTECTED] wrote: - 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. 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
[TurboGears] Re: Combine TG and Subway?
Hi Kevin, 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.
[TurboGears] Re: Combine TG and Subway?
On 12/20/05, Ian Bicking [EMAIL PROTECTED] wrote: 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
[TurboGears] Re: Combine TG and Subway?
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? - Sylvain This message was sent using IMP, the Internet Messaging Program.
[TurboGears] Re: Combine TG and Subway?
Actually, I think that's a bad idea. Front-to-back frameworks are all 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
[TurboGears] Re: Combine TG and Subway?
Right on. Kevin On 12/21/05, Peter Hunt [EMAIL PROTECTED] wrote: Actually, I think that's a bad idea. Front-to-back frameworks are all 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 Author of the Zesty News RSS newsreader email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com
[TurboGears] Re: Combine TG and Subway?
On 12/21/05, Sylvain Hellegouarch [EMAIL PROTECTED] wrote: Kevin Dangoor wrote: 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 [EMAIL PROTECTED] ([EMAIL PROTECTED] address is semi-reliable)
[TurboGears] Re: Combine TG and Subway?
On 12/21/05, Mike Orr [EMAIL PROTECTED] wrote: 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. -- Mike Orr [EMAIL PROTECTED] ([EMAIL PROTECTED] address is semi-reliable)
[TurboGears] Re: Combine TG and Subway?
On 12/21/05, Sylvain Hellegouarch [EMAIL PROTECTED] wrote: Hi Kevin, 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 [EMAIL PROTECTED] ([EMAIL PROTECTED] address is semi-reliable)
[TurboGears] Re: Combine TG and Subway?
My _personnal_ opinion : 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
[TurboGears] Re: Combine TG and Subway?
One feature that I really feel strongly about wrt Kid is that I am 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
[TurboGears] Re: Combine TG and Subway?
On 12/20/05, _max [EMAIL PROTECTED] wrote: 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/
[TurboGears] Re: Combine TG and Subway?
Kevin Dangoor wrote: 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. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
[TurboGears] Re: Combine TG and Subway?
I didnt mean complex by that, but all the xsl like features (match 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.
[TurboGears] Re: Combine TG and Subway?
Hi all, 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
[TurboGears] Re: Combine TG and Subway?
Peter Hunt wrote: - Integrate Subway's form handling. I think Subway's form handling system is innovative and a very productive way of validating forms. TG seems to be a bit lacking in form validation, anyway, so I think this won't be too controversial. My impression is that TG has already been going down the same development path that Subway went down with respect to validation; Subway is a couple iterations further, but they feel similar. Also, htmlfill_schemabuilder (which came from Peter) is already in TG (by way of FormEncode), it's just a matter of using it. I think htmlfill and the schemabuilder have a distinct set of use cases from widgets, and that it's worth supporting that well. Again, it has something to do with work flow -- htmlfill is written with designers in mind, while widgets are more programmer-centric. There should be room for both techniques, without trying to encorporate both cases into the same interface. - Full integration with Python Paste could be a good idea, too. Subway used to do it, but Paste was changing too quickly for us to keep up, and we haven't had support for it for a while. I would certainly welcome that. When Subway tried to use Paste I was still trying to figure out how plugins should work, and it was pretty messy -- since then I've been using eggs and entry points and everything stabalized quickly. Paste interfaces have been stable for some time now. I also think TG should consider using other pieces of Paste besides the creation templates. People who use the evaluating exception handler (myself included, of course) have found it very useful. And if Kid adopts some of the conventions I've suggested for mapping exceptions to source positions, Paste is also set up to display those well (and those conventions are substantially better than other conventions I've seen used in templates). To make TG more Paste friendly really means two things -- first, I believe there are still some outstanding issues with CherryPy, and how well it isolates requests, and how well it respects the meaning of SCRIPT_NAME and PATH_INFO. I doubt these are big issues, but they require someone in the core of CherryPy to actually fix them all. I'm not sure about the details, but I'm willing to look into it all more closely from my perspective if someone from the CherryPy side is ready to follow up on this stuff. The second is configuration and making it possible/easier to set up WSGI stacks. Paste Deploy offers one model using configuration files, but I'm actually more interested in what it uses underneath -- namely, simple function calls with configuration expressed as keyword parameters. If a CherryPy or TG app can consume those functions, then that's great; if there's just an easy way to wrap the entirety of a CherryPy app in a WSGI wrapper, then that's fine too. I'm happy to discuss more of the particulars and look into it more closely, again if there's someone on the other side who wants to follow up on that from the other side. So... after going into that, I'll note that another thing Paste offers is the potential for a really good deployment story. This isn't complete in Paste, but it's well along in progress, and many of the issues with Paste support are just about formalizing what the boundary of the application looks like, and that's simply what's necessary for making a good deployment situation. Also, it makes nesting of applications a real possibility -- I know non-TG users are interested in CatWalk (and no doubt lots of the other toolbox apps coming up), and I expect we'll see other apps like Tasty that are just asking to be embedded. I think it will be good for TG if people get a taste of it by way of using things built in it, just like people often get used to PHP by installing and tweaking PHP apps. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
[TurboGears] Re: Combine TG and Subway?
Jorge Godoy wrote: Ian Bicking [EMAIL PROTECTED] writes: 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? 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). -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
[TurboGears] Re: Combine TG and Subway?
I think Paste integration is the least of our concerns at this 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
[TurboGears] Re: Combine TG and Subway?
Important ? that's the understatement of the year. What is your position Kevin ? Martin
[TurboGears] Re: Combine TG and Subway?
What you guys mean by Combine? I mean would it be a simple interopability or a full integration of both products? - Sylvain Selon [EMAIL PROTECTED] [EMAIL PROTECTED]: Important ? that's the understatement of the year. What is your position Kevin ? Martin This message was sent using IMP, the Internet Messaging Program.
[TurboGears] Re: Combine TG and Subway?
Sylvain Hellegouarch wrote: 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
[TurboGears] Re: Combine TG and Subway?
What Subway features stand out over TurboGears? On 12/19/05, Steven Kryskalla [EMAIL PROTECTED] wrote: Sylvain Hellegouarch wrote: 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 -- [EMAIL PROTECTED]
[TurboGears] Re: Combine TG and Subway?
some random stuf i got from a quick look at their site. - 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
[TurboGears] Re: Combine TG and Subway?
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. 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
[TurboGears] Re: Combine TG and Subway?
Jared Kuolt wrote: 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
[TurboGears] Re: Combine TG and Subway?
Just so people know, I am definitely aware of this thread, and Peter 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 On 12/19/05, paron [EMAIL PROTECTED] wrote: In 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 -- Kevin Dangoor Author of the Zesty News RSS newsreader email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com
[TurboGears] Re: Combine TG and Subway?
Jorge Godoy wrote: Steven Kryskalla [EMAIL PROTECTED] writes: 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. :-) 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
[TurboGears] Re: Combine TG and Subway?
Michele Cella wrote: 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
[TurboGears] Re: Combine TG and Subway?
I hate to post a me-too, but hell, me too =) -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 =). On Dec 19, 2005, at 10:22 PM, Richard (koorb) wrote: Michele Cella wrote: 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 mail: ronald AT checkandshare DOT com blog: http://www.checkandshare.com/blog
[TurboGears] Re: Combine TG and Subway?
Ronald Jaramillo wrote: 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 On Dec 19, 2005, at 10:22 PM, Richard (koorb) wrote: Michele Cella wrote: 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 mail: ronald AT checkandshare DOT com blog: http://www.checkandshare.com/blog
[TurboGears] Re: Combine TG and Subway?
On 12/19/05, Ian Bicking [EMAIL PROTECTED] wrote: I think it's only fair for Subway developers to get a bit moreconsideration and some more definitive decisions than just submitting another set of patches in a tracker.The contributions are concrete andbe discussed in much more detail than mere API experimentations.Theyrepresent 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 am not trying to trivialize the Subway project. I was merely trying to point out that there are steps that can be taken before there is official word from the TurboGears folks. 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
