pycs-devel Mailing List for Python Community Server (Page 18)
Status: Alpha
Brought to you by:
myelin
Menu
▾
▴
pycs-devel — Python Community Server development/chat
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
(3) |
Oct
(1) |
Nov
(70) |
Dec
(41) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(20) |
Feb
(9) |
Mar
(36) |
Apr
(11) |
May
(3) |
Jun
(6) |
Jul
(3) |
Aug
(13) |
Sep
(2) |
Oct
(32) |
Nov
(4) |
Dec
(7) |
| 2004 |
Jan
(14) |
Feb
(16) |
Mar
(3) |
Apr
(12) |
May
(1) |
Jun
(4) |
Jul
(13) |
Aug
(1) |
Sep
(2) |
Oct
(1) |
Nov
(2) |
Dec
(3) |
| 2005 |
Jan
(7) |
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
(2) |
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
(2) |
Dec
(1) |
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
(2) |
Oct
(7) |
Nov
(18) |
Dec
(22) |
| 2007 |
Jan
(10) |
Feb
(11) |
Mar
(1) |
Apr
(6) |
May
(5) |
Jun
(5) |
Jul
(14) |
Aug
(28) |
Sep
(4) |
Oct
(6) |
Nov
(9) |
Dec
(8) |
| 2008 |
Jan
(10) |
Feb
(19) |
Mar
(38) |
Apr
(17) |
May
(13) |
Jun
(7) |
Jul
(36) |
Aug
(15) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
|
From: Georg B. <gb...@mu...> - 2003-01-10 22:35:17
|
Hi! Just thought I first tell you here, as it might be something of interest for you. What happened? I hacked the last days quite heavy. Didn't do much PyCS work, though, but instead PyDS. Yep, PyDS :-) As a supplement to the Python Community Server, now there is a Python Desktop Server. It's actually mostly an implementation of an application much like Radio Userland, but in Python. And for Posix systems. It's still alpha, but it is useable, as you can see at http://muensterland.org/users/0000006/ The page is german, an english one is at http://pyds.muensterland.org/, but that was done earlier today and so uses an older version of PyDS and has maybe some broken links. At that site you can download the current version. Usually it's a daily snapshot, but I just made it current. What is implemented: - weblog editing, categories, rendering, upstreaming (in the background) - preferences and preferences-hooks for tools - dynamic userdefined macros - online documentation of tool API - templating using Cheetah templates - theoretically themeable, although currently done by hand - dynamically installed tools - eventlog - full translations for english and german - almost but not fully without documentation :-) I currently still use Radio for now, but that's just for now - I don't have stories implemented yet, and I would need them to transfer all my stuff to PyDS. And the News Aggregator isn't implemented yet, but there one can use AmphetaDesk (and make a little patch to the template of AmphetaDesk to post to PyDS). Would be fun if some of you using Posix systems (some BSD flavor, Linux or Mac OS X - actually I am developing both on Mac OS X and Linux) would try it out. Installation instructions are given in the Archive. When there is enough to discuss I can set up a mailing list for it, so we don't flood Phils pycs-devel, but I thought you to be a good targeted audience for first experiments :-) Comments? bye, Georg |
|
From: Georg B. <gb...@mu...> - 2003-01-01 23:45:27
|
Hi! > testing (Rogers - if you're reading this, keep using the comment > monitor for > the moment - it makes much smaller RSS!). It also appears broken in Yep, maybe an option to leave out the description? So it only transfers title and link? And I think the timelimit should be implemented, too. Maybe with a quite large timeframe, 14 days or something like that. > Internet Explorer; there's something dodgy in the XML somewhere ... Hmm. Looks like some char-problem again. I thought I can just use your comment feed stuff, as it uses CDATA[[]] to encapsulate body information, but it looks like that isn't enough to keep XML parsers happy. It's a chr(0xa0) in a comment. It will go away as soon as I put the iso-8859-1 header in there. That wasn't in the comments/rss.py - looks like it works after that addition (at least with my - umlaut-infested - feed). Ok, the following changes are checked in: - full=1 delivers now a feed with shortened description elements (only first 40 bytes) - full=2 delivers now a feed with full description elements - full=3 delivers the same as full=2, but delivers _all_ comments. the lower levels only deliver the last 14 days of comments When you update your server, we can look how that works with Rogers feed. full=1 should be highly reduced, I think. bye, Georg |
|
From: Phillip P. <ph...@my...> - 2003-01-01 22:59:26
|
Great! I've updated pycs.net to use the latest code. Looks good. Rogers Cadenhead's comment feed is a bit long; it might be useful for testing (Rogers - if you're reading this, keep using the comment monitor for the moment - it makes much smaller RSS!). It also appears broken in Internet Explorer; there's something dodgy in the XML somewhere ... http://www.pycs.net/system/comments.py?u=0000001&format=rss&full=1 Cheers, Phil :) |
|
From: Georg B. <gb...@mu...> - 2003-01-01 14:32:09
|
Hi! I just checked in a change to comments.py and the related comments/*.py files so that comments.py now can return a full feed for all comments for a usernumber. The URL format is as follows: http://muensterland.org/system/comments.py?u=0000001&format=rss&full=1 This returns an rss feed for this weblog with all comments attached. Comments are ordered by date, newest first. I did this because this way we can return more data in the comment - this comment has more flesh in the title (the author name, the date when it was posted) and carries the actual comment in the body. I think there should be a way to limit posts to "last X days" or "newest X comments", but since I don't have much comments on my site, I didn't implement it now. Might ponder a bit over that - maybe a "new comments since my last run with new comments" and a user preference would be an alternative, I can't say at the moment. Since this feed would be used to monitor your comments to be able to weed out bad stuff, I think it should guarantee as best as it could that you don't miss on comments (just because you were flooded by comments and so it broke the limit or just because you didn't check for some weeks and so miss some old comments). To enable this I implemented a commentfeed formatter rssfull.py (new module in comments/) and made some small changes to the system. Since my MacReporterForge beta expired again, I can't check it with that tool, but the feed looks ok, so I think it's useable. I hope I didn't break anything with normal posting-related comment feeds. bye, Georg |
|
From: Georg B. <gb...@mu...> - 2002-12-30 19:21:36
|
Hi! > The translations are not complete, but the make_msgs.py utility has an > easy upgrade mechanism, so you can start now and just fill in when there > are new translations to be made. Ok, I think they are complete now. Might be I overlooked some stuff, but that can only be quite rare strings. bye, Georg |
|
From: Georg B. <gb...@mu...> - 2002-12-30 12:55:12
|
Hi!
> But please don't start yet, as the first version is very crude and
Ok, you now can start to produce other translations, if you want to. I did
some more changes today, as are:
modules/system/*.py - those with translations were cleaned up a bit
comments/html.py - added translations for the comment form
pycs_translation.py - small fix
and the most important ones:
make_msgs.py - scans all .py files and produces a catalog
TRANSLATIONHOWTO - a small documentation for the above script
Phil: even if you won't do the translations, you might read the file, as
it contains some hints on the format the scanner expects. Especially the
translated strings should be written as _("...") or _('...'), not with
your usual _( "..." ) format, as the latter would break make_msgs.py.
Others: fetch the newest CVS stuff, read TRANSLATIONHOWTO, create your own
translation file for your favorite language and start hacking :-)
Maybe it might be a good idea to ask on this list before starting, to make
sure that no two developers are translating to the same language.
The translations are not complete, but the make_msgs.py utility has an
easy upgrade mechanism, so you can start now and just fill in when there
are new translations to be made.
German translation is already in CVS and will be maintained by me.
bye, Georg
|
|
From: Georg B. <gb...@mu...> - 2002-12-28 15:44:22
|
Hi! Just thought to share this with you, it's not directly PyCS related, but at least RSS related (and written in python) :-) At http://kenny.gws-online.de/~gb/searchebay.py you can download a short python script that does a search at ebay for given search words and creates an RSS feed out of the results. Usage: python searchebay.py +contax +zeiss -ikon -o=contax searches for combinations of contax and zeiss, weeds out ikon and stores it in $HOME/public_html/contax.xml I run that one regularily on a server of mine and create watchlists for stuff I am looking for (contax lenses, mamiya press rollfilm backs and rollei 6008 stuff :-) ). Quite handy. And you can subscribe to that RSS feed with MacReporter and see it "life" on your desktop when something changes. See it as a late christmas present, or a temporary hack until eBay implements web services :-) The "official" announcement (in german) is at http://hugo.muensterland.org/categories/programmierung/2002/12/27.html#a175 bye, Georg |
|
From: Phillip P. <ph...@my...> - 2002-12-26 21:26:24
|
> If we run it at the same place, we can use sourceforge, I'd say. Or you > set up an A record for lists.pycs.net and host a mailman instance (or > point that over at one of my servers and I run the mailman instance > there). At least it's a list manager written in python ;-) True :-) Let's use SF for the moment then. I've got a bit on at the moment, but will hopefully have some time over the next few days to set it up. Cheers, Phil |
|
From: Georg B. <gb...@mu...> - 2002-12-26 12:53:40
|
Hi! > To keep things in the right place (I agree - that's a good way to do > it), we should host pycs-users at sourceforge and have the archives on > pycs.net. An alternative would be to use eGroups (groups.yahoo.com) > like Radio, Blogger, the syndication guys, etc. Ugh, no, please not yahoogroups. I really can't stand them, butt ugly user interface, advertising all over the place and they change settings from time to time without your knowledge, especially if you migrated several egroups/onelist/yahoogroups accounts to one central yahoo acount. Lost about half my mailinglist posting abilities due to that problem (of course I still get the lists, but can't post there any more, because I am not subscribed with the "right" address - of course I am not, as they dumped the "right" address). If we run it at the same place, we can use sourceforge, I'd say. Or you set up an A record for lists.pycs.net and host a mailman instance (or point that over at one of my servers and I run the mailman instance there). At least it's a list manager written in python ;-) > Sounds like fun :-) Yeah, I recovered most of it today, but still have a large platter of cake, some staples of cookies, a pot of dessert and some potato salad left to eat. Christmas is _not_ good for you health ;-) bye, Georg |
|
From: Phillip P. <pp...@my...> - 2002-12-26 03:50:49
|
> Ok, it's actually better (I think) when all pycs related lists are in > one place, so we host them at your site (except if you have problems > with that). To keep things in the right place (I agree - that's a good way to do it), we should host pycs-users at sourceforge and have the archives on pycs.net. An alternative would be to use eGroups (groups.yahoo.com) like Radio, Blogger, the syndication guys, etc. > Actually I don't know how long I will take to recover from > _this_ particular christmas: had family-visit from Hamburg for 24th, but > due to bad weather conditions, trains didn't go back to hamburg, so they > had to stay at our site. It's now 25th, 6:30 in the morning, my birthday > (I got a Manfrotto Monopod as a present :-) ), and I only had 1-2 hours > of sleep. And in some hours the usual christmas-heavy-food-marathon > starts ... Sounds like fun :-) Cheers, Phil |
|
From: Georg B. <gb...@mu...> - 2002-12-25 05:37:29
|
Hi! > Heh, sure. Will set that up soon (once Xmas dinner etc is over). Ok, it's actually better (I think) when all pycs related lists are in one place, so we host them at your site (except if you have problems with that). Actually I don't know how long I will take to recover from _this_ particular christmas: had family-visit from Hamburg for 24th, but due to bad weather conditions, trains didn't go back to hamburg, so they had to stay at our site. It's now 25th, 6:30 in the morning, my birthday (I got a Manfrotto Monopod as a present :-) ), and I only had 1-2 hours of sleep. And in some hours the usual christmas-heavy-food-marathon starts ... So don't count on anything I say today, as I am surely out of my (usualy a bit less fragile) mind ;-) bye, Georg |
|
From: Phillip P. <pp...@my...> - 2002-12-24 22:33:57
|
> Just thought about it, I think we should have them. Phil: with your > mailing-list-to-blog gateway and a patched comments.py that gates > comments back to the mailing list, we should be able to get the dual > feed technology that radio has with only minor hassles. I think it would > be good to have them both and to change the defaults in xmlStorageSystem > to our own lists. Good idea! > So my proposal would be to set up pycs-users as a mailing list, gate > that into a blog and gate comments back into the list. And maybe we > could set up two of them, so we can have one in english and one in > german? ;-) Heh, sure. Will set that up soon (once Xmas dinner etc is over). > Or tell me what is needed for the gateway stuff, and I set them up at my > system (list software is already available, so it wouldn't be a problem > to run it). But I think we should get users to ask on our own forum > first, as that would enable us to filter out stuff that's more a pycs > problem than a rcs/radio problem. We can still point them over to the > radio list if we think it's something we can't handle/solve. All that's needed for the gateway is a copy of bzero. Install, create a new blog on pycs.net (tell me the usernum and I'll make it pycs.net/users or something), and call bzero postmsg with each message as it arrives. Here's the Python code I use to do it for this list: open( '/tmp/pycs-devel.msg.tmp', 'w' ).write( msgtext ) os.system( 'bz postmsg pycs-devel-archive /tmp/pycs-devel.msg.tmp' ) os.system( 'bz send pycs-devel-archive' ) > Oh, and a merry christmas to all here on the list! Yup - Merry Christmas to everyone! Cheers, Phil :) |
|
From: Georg B. <gb...@mu...> - 2002-12-24 11:44:30
|
Hi! Just thought about it, I think we should have them. Phil: with your mailing-list-to-blog gateway and a patched comments.py that gates comments back to the mailing list, we should be able to get the dual feed technology that radio has with only minor hassles. I think it would be good to have them both and to change the defaults in xmlStorageSystem to our own lists. So my proposal would be to set up pycs-users as a mailing list, gate that into a blog and gate comments back into the list. And maybe we could set up two of them, so we can have one in english and one in german? ;-) Or tell me what is needed for the gateway stuff, and I set them up at my system (list software is already available, so it wouldn't be a problem to run it). But I think we should get users to ask on our own forum first, as that would enable us to filter out stuff that's more a pycs problem than a rcs/radio problem. We can still point them over to the radio list if we think it's something we can't handle/solve. Oh, and a merry christmas to all here on the list! bye, Georg |
|
From: Georg B. <gb...@mu...> - 2002-12-23 16:50:45
|
Hi! I just commited some changes that enable us to use gettext (the python module, not the GNU library!) to translate strings to different languages. What I changed: pycs_setting.py now has a Language method to deliver the configured language (option language) or 'en' as a default. The language setting is documented in the pycs.conf.default. If you don't enable language support, a NullTranslations stub will be used and everything should work as before pycs_translation.py (new module) has support for the message files. Those are named pycs-XX.msgs with XX currently only being "de" (as that's my native language). pycs.py initializes the translation engine and installs the "_" function as the translation function for the configured language. This translation function returns either a translation or the original message if no translation can be found. modules/system/rankings.py, weblogUpdates.py, searches.py, referers.py are all changed to now use this new feature. You can see them in action at http://muensterland.org/ To enable us to collect missing translations (or new translations for stuff that has changed), missing translations are written to a failedmsg.log file in the log directory. Be sure to rotate that in the same way as you rotate other logfiles. I will go through the whole source and use translation on those parts where it is needed. Mostly this is the modules, but some internals, too. So there will be a first message catalog for german language. It would be nice if others would pick up from here and take the pycs-de.msgs as a starting point to build their own message catalog for other languages. But please don't start yet, as the first version is very crude and especially includes very ugly strings, as formatting is still in there. I will first go through all modules and change their source in a way that enables me to split between templating code and actual strings, so the strings in the message catalog will become shorter. Comments? bye, Georg |
|
From: Georg B. <gb...@mu...> - 2002-12-18 22:57:32
|
Hi! > There some logic behind it ... basically, anything that doesn't need > to change once it's on the server is rendered by the client and > uploaded Yeah, sure, but it sometimes is a _bit_ irritating, especially if they pull their "use javascript that dynamically rewrites document source" trick :-) > It shouldn't be too hard. All you need to do is: Oh, that's not the problem, I only hoped it might be easier. It's not really important, it's just that Jutta would like a link directory for her pages. I already did a little RSS-to-HTML-via-XSLT tool for her to render dynamically her RSS feeds on the other server. I am actually thinking about some way to integrate 4Suite into PyCS to enable dynamic rendering of XML into HTML with XSLT. XSLT isn't the best way to work with XML, but it's one where you have lots of documentation for people to read and use. And since Radio (and bzero) already produce XML files, it would fit nicely into the grand scheme. bye, Georg |
|
From: Phillip P. <pp...@my...> - 2002-12-18 22:44:22
|
> >Check out the HTML source of linksammlung.html - it looks like there's > >an app running on subhonker6 that downloads .opml files and generates > >HTML directories out of them. Here's the URL to do it for your page: > > Aaarghl. Those Userland-programmers are driving me crazy with their > linking/fetching/transforming/stuffing/distributing stuff. Can't they > decide on what system to run their code? :-) Heh :-) There some logic behind it ... basically, anything that doesn't need to change once it's on the server is rendered by the client and uploaded. Anything that needs to be more dynamic is done on the server. In this case, your OPML could be generated by the client but the HTML had to be done by the server. > Ok, so that's not so easy to hack up, this calls for a bit more action. > Hmm. It shouldn't be too hard. All you need to do is: - fetch the OPML file (check authentication, validate filename, read file) - parse OPML into a tree - figure out which branch to display - display branch, putting in links as required Cheers, Phil :) |
|
From: Georg B. <gb...@mu...> - 2002-12-18 22:12:14
|
Hi! > Check out the HTML source of linksammlung.html - it looks like there's > an app running on subhonker6 that downloads .opml files and generates > HTML directories out of them. Here's the URL to do it for your page: Aaarghl. Those Userland-programmers are driving me crazy with their linking/fetching/transforming/stuffing/distributing stuff. Can't they decide on what system to run their code? :-) Ok, so that's not so easy to hack up, this calls for a bit more action. Hmm. bye, Georg |
|
From: Phillip P. <pp...@my...> - 2002-12-18 21:56:08
|
Georg: > I created a little directory at > http://hugo.muensterland.org/stories/2002/12/18/linksammlung.html > > There you can see the problem: it references subhonker and not PyCS. So > the spontanous question arises, would it be possible to hack this to use > a different Community Server? Maybe some of you already used this > feature and know about it? Hi, Check out the HTML source of linksammlung.html - it looks like there's an app running on subhonker6 that downloads .opml files and generates HTML directories out of them. Here's the URL to do it for your page: http://subhonker6.userland.com/rcsPublic/viewDirectory/?flIcons=true&flLinkText=false&flMinimalTemplate=false&flXmlButton=true&remoteInclude=true&url=http%3A%2F%2Fhugo.muensterland.org%2Fgems%2FMeineLinks.opml You could code up a replacement for viewDirectory inside PyCS if you like, although fetching remote URLs without blocking is a little trickier inside Medusa than it is under multi-threaded Frontier or multi-process Apache. If you restrict it to local files (then, say, call it with something like http://foo/system/viewDirectory.py?usernum=0000001&path=/gems/MeineLinks.opml) it wouldn't be too hard though... all you need to do is parse OPML and create HTML. Rick at techno-weenie.com might have done something about this; I remember he was hacking some PHP outline stuff a while ago. Cheers, Phil :) |
|
From: Georg B. <gb...@mu...> - 2002-12-18 19:46:14
|
Hi! Radio Userland allows rendering Outliners as HTML Link Directories. A description is at http://radio.outliners.com/directoryOutliner I created a little directory at http://hugo.muensterland.org/stories/2002/12/18/linksammlung.html There you can see the problem: it references subhonker and not PyCS. So the spontanous question arises, would it be possible to hack this to use a different Community Server? Maybe some of you already used this feature and know about it? And if it can be hacked, does it use server capabilities we would have to implement? Especially the link suggestion would be nice. bye, Georg |
|
From: Georg B. <gb...@mu...> - 2002-12-18 18:41:30
|
Hi!
> ZOpen-X blog. That looks pretty good, and has a standalone version
> ("Catalog") that might be able to be plugged in. It adds some
> overhead (requires the ZODB) but this is to be expected when you have
> a search DB.
Hmm. ZODB might not be really that bad - we could use that as base DB,
instead of Metakit and so get the Unicode stuff up and running, as ZODB
is fully Unicode compliant, if I recall correctly.
But ZODB has one rather big disadvantage: ZODB never shrinks. It only
grows. Write new records and it grows. Store new objects and it grows.
Change Attributes and it grows.
To shrink you have to call an special maintenance code that actually
copies out all active objects into a new ZODB and then switches DB files
underneath the running server. That's something that always has bothered
me a bit with our production environment (we make extensive use of
ZODB). But it is quite stable, so this problem is more one of style and
not function ;-)
bye, Georg
|
|
From: Phillip P. <pp...@my...> - 2002-12-18 10:44:20
|
Hello all,
Here's a note (for the ppl who haven't been following scripting news &
zopenx) about stuff that's been going on off the list over the last
few days, mainly to do with search engines.
I'm hosting a (private) community server for RealWorld Systems (in
Canada) and they need a search engine. This is a good opportunity to
plug a decent search interface into PyCS.
There are loads of possibilities ... I've tried standalone packages
(mnoGoSearch and ht://Dig) and ht://Dig looks quite good. Now I want
to hack something together to get the search playing nicely with the
page viewing permissions. Someone who can only see one or two blogs
shouldn't see search results outside those.
The obvious way (and probably the quickest) to do this would be to
turn ht://Dig's 'htsearch' module into a Python extension, and to
create a system/search.py that would call back into that and only
display matches that are valid for the current user.
The disadvantage here is that ht://Dig is GPL, so this would have to
be a separate plugin for PyCS rather than an integral part of it.
(I'd make an 'opt' directory in the CVS for optional things like
this). Including it would make the GPL cover your copy of PyCS, which
doesn't worry me, but I don't want it becoming the default license for
things.
Robert Barksdale pointed out the very cool ZCatalog module on his
ZOpen-X blog. That looks pretty good, and has a standalone version
("Catalog") that might be able to be plugged in. It adds some
overhead (requires the ZODB) but this is to be expected when you have
a search DB.
My plan of attack at the moment (as speed is a priority) is to do the
ht://Dig option, but I would prefer to use Catalog in future as it
will fit in much better with the system.
Comments?
If you feel like reading more, I've written a whole heap (on Second
p0st) about this over the last couple of days:
Search engines:
http://blogs.salon.com/0000002/2002/12/17/#200212172
mnoGoSearch on FreeBSD:
http://blogs.salon.com/0000002/2002/12/17/mnogosearch_on_freebsd.html
Building a search engine for PyCS:
http://blogs.salon.com/0000002/2002/12/17/search_engine_in_python.html
Adapting existing code:
http://blogs.salon.com/0000002/2002/12/18/adapting_other_search_engines.html
ht://Dig on FreeBSD:
http://blogs.salon.com/0000002/2002/12/18/htdig_on_freebsd.html
Cheers,
Phillip :-)
|
|
From: Georg B. <gb...@mu...> - 2002-12-14 22:37:25
|
Hi! > Would anyone care to elaborate on the objectives of the template > system? Will the templates see the light of day on the client-side > like Radio's templates are exposed? If so, there should be a way for > designers and content owners see what is going on, correct? Hmm. At current time I think the biggest value would come out of using the templates for the programming part of PyCS - to allow Phil and me and others to easily write up modules with dynamic content and separate programming and designing. And I think I would like to use them to build administrative interfaces - the first round will mostly concentrate on the usual sysadmin stuff. There might be a second stage when I find a good and easy way to build Python "sandboxes" to evaluate code, because then I can integrate them directly into medusa via a template handler - this would enable us to use template functionality on the server via Radio templates. This would actually be quite weird, as you would write Radio templates to create HTML files that use Cheetah template code to evaluate on the server. It would be quite cool, as it would break one limit Radio currently has, that it only can export static content and has to rely on Javascript and pulled-in modules for dynamicity. Look at the hacks done for the Radio Nuggets - that's really cool JavaScript hackery, but it is hackery nontheless, and would be far easier and stable if not using JavaScript. (For a stability example: ActiveRenderer doesn't work with Opera on Linux and some versions of IE - that's always a problem with JavaScript, the little differences). To use it on the client side directly, you would have to run something build in python. So it might be a nice fit for Phil's bzero, where it could give you the same functionality as the templates in Radio. But that's up to Phil, as bzero is not open source :-) bye, Georg |
|
From: Robert B. <rba...@ma...> - 2002-12-14 20:01:53
|
Cool! Thanks for taking the time for writing this up, Georg. Your insights are appreciated. Your points make things clearer for me. Would anyone care to elaborate on the objectives of the template system? Will the templates see the light of day on the client-side like Radio's templates are exposed? If so, there should be a way for designers and content owners see what is going on, correct? I ask these questions because the folks at evectors.it have a little Radio tool that evaluates the Radio template and provides a way of editing a template in a WYSIWYG editor. I wondering, out loud, what would be involved in doing the same thing using Cheetah's Template language. It will be interesting to see Phil's GUI and how this will all mesh together. Regards, Robert On Friday, Dec 13, 2002, at 07:21 US/Central, Georg Bauer wrote: > Hi! > >> straight forward. I would be interested to learn how it would >> interact >> with tools like Mozilla's Editor, Dreamweaver or GoLive. Having the > > It is mostly ignorant of those tools, but won't break too much. There > are > several ideas on integrating Script with HTML: > > 1) invent your own tags (DTML) > > This has the problem that most GUI tools don't support those and so > they > are a PITA to use. You are usually forced to switch to HTML source > view. > And without clear visual distinction between html and script, code > often > is hard to read. Syntax coloring editors can sometimes help by coloring > script tags differently from standard tags, but it is not often > implemented. > > 2) invent your own attributes and use existing tags (ZPT) > > These are more resistent to GUI tools, as they usually just fit in if > the > tool supports user defined attributes to tags (like Dreamweaver does). > If > your GUI tool doesn't support user defined attributes, and possibly > rewrites code to it's own likening, you are doomed. And another > problem: > since you have to put your attributes in available tags, you are > forced to > build your script in the same structure as your HTML. This sucks for > bigger tasks. It does allow you to do nice "example" coding and later > overwriting automatically your example data with real data, though - > that's the one big advantage of ZPT. Distinction of html and script is > even worse than with number 1. And syntax coloring editors usually get > lost, as they don't know which attributes to color this way and another > way. > > 3) use ASP taglike structures (many do that, you recognize them by <% > %>) > > The same problems as with defining your own tags, as most GUI tools > process ASP tags as some obscure tags. Often they reformat stuff and it > breaks, especially if your stuff is whitespace sensitive. But the nice > thing is that if your template language is compatible with ASP, you > might > find tools that support it natively. Visual distinction of html and > script > is better, but since the script looks much like html comments, it might > get bad if you comment heavily. But syntax coloring editors can help a > lot > here. > > 4) invent your own language (like almost the rest does) > > This has the big drawback that you have to learn the language. But it > has > the big adavantage that you can design your language near enough to a > real > language. Cheetah designs it's language conceptually (not in syntax, > but > in semantic) like Python. So it can compile templates directly to > python > and mix Python classes and Template classes freely. The big advantage > of > inventing your own language is, you can design the language in the way > that you need, not anything forced by structures outside the > programming > domain. And usually you see your sourcecode in the GUI tool as simple > textual content, this helps with debugging. But there will always be > some > (sometimes obscure) areas where the script language will break GUI tool > usage. Often you can get around that problem, but sometimes it's quite > hard to see a way and you have to go back to the source code. Visual > distinction of html and script is often quite good, as script looks > very > differently than script code is regarded as simple text, so stands out > even in GUI tools. > > So if GUI tool interoperability is highest priority, an approach like > ZPT > would be best. If programming is hightes priority (and since that is > what > I do most of my daylife ;-) ) you have to go for something like > Cheetah, > as you get a full fledged language that is easily integrated with the > server software. Programmers usually use more syntax coloring editors > than > GUI editors. > > I prefer the programmer approach :-) > > bye, Georg > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: > With Great Power, Comes Great Responsibility > Learn to use your power at OSDN's High Performance Computing Channel > http://hpc.devchannel.org/ > _______________________________________________ > PyCS-devel mailing list > PyC...@li... > https://lists.sourceforge.net/lists/listinfo/pycs-devel |
|
From: Georg B. <gb...@mu...> - 2002-12-13 13:27:09
|
Hi! > straight forward. I would be interested to learn how it would interact > with tools like Mozilla's Editor, Dreamweaver or GoLive. Having the It is mostly ignorant of those tools, but won't break too much. There are several ideas on integrating Script with HTML: 1) invent your own tags (DTML) This has the problem that most GUI tools don't support those and so they are a PITA to use. You are usually forced to switch to HTML source view. And without clear visual distinction between html and script, code often is hard to read. Syntax coloring editors can sometimes help by coloring script tags differently from standard tags, but it is not often implemented. 2) invent your own attributes and use existing tags (ZPT) These are more resistent to GUI tools, as they usually just fit in if the tool supports user defined attributes to tags (like Dreamweaver does). If your GUI tool doesn't support user defined attributes, and possibly rewrites code to it's own likening, you are doomed. And another problem: since you have to put your attributes in available tags, you are forced to build your script in the same structure as your HTML. This sucks for bigger tasks. It does allow you to do nice "example" coding and later overwriting automatically your example data with real data, though - that's the one big advantage of ZPT. Distinction of html and script is even worse than with number 1. And syntax coloring editors usually get lost, as they don't know which attributes to color this way and another way. 3) use ASP taglike structures (many do that, you recognize them by <% %>) The same problems as with defining your own tags, as most GUI tools process ASP tags as some obscure tags. Often they reformat stuff and it breaks, especially if your stuff is whitespace sensitive. But the nice thing is that if your template language is compatible with ASP, you might find tools that support it natively. Visual distinction of html and script is better, but since the script looks much like html comments, it might get bad if you comment heavily. But syntax coloring editors can help a lot here. 4) invent your own language (like almost the rest does) This has the big drawback that you have to learn the language. But it has the big adavantage that you can design your language near enough to a real language. Cheetah designs it's language conceptually (not in syntax, but in semantic) like Python. So it can compile templates directly to python and mix Python classes and Template classes freely. The big advantage of inventing your own language is, you can design the language in the way that you need, not anything forced by structures outside the programming domain. And usually you see your sourcecode in the GUI tool as simple textual content, this helps with debugging. But there will always be some (sometimes obscure) areas where the script language will break GUI tool usage. Often you can get around that problem, but sometimes it's quite hard to see a way and you have to go back to the source code. Visual distinction of html and script is often quite good, as script looks very differently than script code is regarded as simple text, so stands out even in GUI tools. So if GUI tool interoperability is highest priority, an approach like ZPT would be best. If programming is hightes priority (and since that is what I do most of my daylife ;-) ) you have to go for something like Cheetah, as you get a full fledged language that is easily integrated with the server software. Programmers usually use more syntax coloring editors than GUI editors. I prefer the programmer approach :-) bye, Georg |
|
From: Robert B. <rba...@ma...> - 2002-12-13 12:53:55
|
On Friday, Dec 13, 2002, at 04:25 US/Central, Georg Bauer wrote: > Does the non-existence of replies say you all don't care, you all > object > or you all agree? :-) > > I really would like to get some feedback, because using Cheetah would > add > to the prerequisites of PyCS. So even if you don't care, please just > say > that you don't care, so I know about it. Sorry, Georg for not replying to the list.... From a neophyte's perspective Cheetah appears to be something I could handle. I looked over the User's guide and it appears to be a pretty straight forward. I would be interested to learn how it would interact with tools like Mozilla's Editor, Dreamweaver or GoLive. Having the capability of extending these tools to handle template design and modification would be idea for the whole PyCS design and development process. Regards, Robert |
125 messages has been excluded from this view by a project administrator.
