Webware for Python

at ipc9, talking to the webware developers its seems that the most common 
development strategy for webware is to define a sitepage with common element 
fragments and have the servlets generate dynamic content in the well (center 
of the page). 

i think this strategy is fine for a great many sites, however i think it has 
problems for most commercial development that i taken part in (aside from 
intranets). the problem being most of the time you're working with graphic 
designers and html/jscript coders who produce the templates, generally with 
some graphical tool. having them edit page fragments is a pain in the ass, as 
is slowing down development to roundtrip templates back and forth between 
developers and designers.

a lot of web platforms are moving away from this style of development to one 
that supports using well-formed documents as the basis for content generation 
(zope, enhydra, arsdigita's acs) to name a few. granted this is a problem for 
most 

i took a quick looksy through the webkit and code and noticed some support 
for a paradigm that i think people could use to implement this style of 
development in webware as well supporting general publishing frameworks (ala 
apache cocoon). one key is the servlet chaining option already builtin into 
webware. the other key, which i don't see and which i' surmise doesn't exist 
from reading through the ipc9 paper, is the ability to map servlets not to 
just file extensions but to whole directory structures (including the root 
directory). 

it looks like the current webware implementation uses the application to 
preform request handling soley on the basis of a file xtension -> servlet 
mapping.

dug a little deeper into Application.py and noticed there is a special case 
that can be used to mimic the behavior i want, but its kinda of degenerate to 
use it this way since i'll be overiding what i think might be a common 
assumption in the code about servletFactories mapping to extensions. i'd like 
to create servletFactories which don't have any exts, and to create one which 
maps to .* (apparently the catchall). does anyone see a possible problem with 
this approach?

the basic idea is to create a request handler servlet which maps all incoming 
requests into other servlets, using a single servlet to present templates 
(created by the designer with some special xml encoding that their design 
tools will ignore) and using other servlets to generate dynamic content for 
insertion into the templates. i suppose this could also be a good point to 
override the caching option in the application and institute per template 
caching. does this sound like a valid approach or will i be hitting any 
hidden land  mines (it used to happen to me so often in zope, i've gotten 
into the habit of checking first).

cheers

kapil

Re: [Webware-discuss] content generation From: Geoff Talvola <gtalvola@na...> - 2001-03-09 21:20 ender wrote: > at ipc9, talking to the webware developers its seems that the most common > development strategy for webware is to define a sitepage with common element > fragments and have the servlets generate dynamic content in the well (center > of the page). > > i think this strategy is fine for a great many sites, however i think it has > problems for most commercial development that i taken part in (aside from > intranets). the problem being most of the time you're working with graphic > designers and html/jscript coders who produce the templates, generally with > some graphical tool. having them edit page fragments is a pain in the ass, as > is slowing down development to roundtrip templates back and forth between > developers and designers. > > a lot of web platforms are moving away from this style of development to one > that supports using well-formed documents as the basis for content generation > (zope, enhydra, arsdigita's acs) to name a few. granted this is a problem for > most What is wrong with the strategy of having your graphic designers work with PSP's that make up well-formed documents? The writeHeader/writeSidebar/writeBody/writeFooter stuff is one way to do it, but there's also nothing wrong with having the PSP override writeHTML if you want the PSP to make up the entire web page. You can still inherit from base classes within your PSP, to give you access to functionality shared across all pages... If you don't like PSP syntax, the same idea applies to whatever templating syntax you invent yourself -- just write a ServletFactory for your favorite syntax. > i took a quick looksy through the webkit and code and noticed some support > for a paradigm that i think people could use to implement this style of > development in webware as well supporting general publishing frameworks (ala > apache cocoon). one key is the servlet chaining option already builtin into > webware. the other key, which i don't see and which i' surmise doesn't exist > from reading through the ipc9 paper, is the ability to map servlets not to > just file extensions but to whole directory structures (including the root > directory). Can you elaborate a bit on why you want to have a single servlet map to a whole directory? I guess I'm just not getting what you're trying to do. It sounds like you might be interested in the "ExtraPathInfo" config option also -- it allows you to have a servlet handle all requests that start with http://localhost/MyServlet/foo/bar (for example) and the additional path information after MyServlet becomes accessible through self.request().extraURLPath() -- in this case "/foo/bar". This may be a way to achieve your goal of having a servlet handle all requests for an entire directory. see http://webware.sourceforge.net/Webware/WebKit/Docs/UsersGuide.html#Config_Application > it looks like the current webware implementation uses the application to > preform request handling soley on the basis of a file xtension -> servlet > mapping. > > dug a little deeper into Application.py and noticed there is a special case > that can be used to mimic the behavior i want, but its kinda of degenerate to > use it this way since i'll be overiding what i think might be a common > assumption in the code about servletFactories mapping to extensions. i'd like > to create servletFactories which don't have any exts, and to create one which > maps to .* (apparently the catchall). does anyone see a possible problem with > this approach? Why not just give them the same extension? If you're inventing a new template syntax, let's call it KTL (Kapil's Templating Language), why not give your files the extension .ktl? And have a servlet factory for that extension. > the basic idea is to create a request handler servlet which maps all incoming > requests into other servlets, using a single servlet to present templates > (created by the designer with some special xml encoding that their design > tools will ignore) and using other servlets to generate dynamic content for > insertion into the templates. i suppose this could also be a good point to > override the caching option in the application and institute per template > caching. does this sound like a valid approach or will i be hitting any > hidden land mines (it used to happen to me so often in zope, i've gotten > into the habit of checking first). I'm not sure exactly what you're talking about so I can't tell if there would be any killer problems :-) but I would just say, consider whether what you're trying to do can be achieved with the "standard" Webware techniques of Servlets and Servlet Factories, and inheritance. -- - Geoff Talvola Parlance Corporation gtalvola@...

Re: [Webware-discuss] content generation From: ender <kthangavelu@ea...> - 2001-03-09 23:04 On Friday 09 March 2001 13:29, Geoff Talvola wrote: >>ender wrote: >>> at ipc9, talking to the webware developers its seems that the most common >>> development strategy for webware is to define a sitepage with common >>> element fragments and have the servlets generate dynamic content in the >>> well (center of the page). >>> >>> i think this strategy is fine for a great many sites, however i think it >>> has problems for most commercial development that i taken part in (aside >>> from intranets). the problem being most of the time you're working with >>> graphic designers and html/jscript coders who produce the templates, >>> generally with some graphical tool. having them edit page fragments is a >>> pain in the ass, as is slowing down development to roundtrip templates >>> back and forth between developers and designers. >>> >>> a lot of web platforms are moving away from this style of development to >>> one that supports using well-formed documents as the basis for content >>> generation (zope, enhydra, arsdigita's acs) to name a few. granted this >>> is a problem for most >> >>What is wrong with the strategy of having your graphic designers work with >> PSP's that make up well-formed documents? The >> writeHeader/writeSidebar/writeBody/writeFooter stuff is one way to do it, >> but there's also nothing wrong with having the PSP override writeHTML if >> you want the PSP to make up the entire web page. You can still inherit >> from base classes within your PSP, to give you access to functionality >> shared across all pages... the main issue for me is separation of content and logic. the unfinished sentence from above was going to be. granted this is a problem for most templating languages. support for templating languages in graphical design tools is sketchy at best (some ignore them, some complain, some die, some just remove the offending tags when saving), on top of which without the interpretation of the template by the server system they generally come out looking like shite, which makes them difficult for a graphics designer to work with. one solution, which the platforms i cited above are moving towards is basically using html tag attributes as a rendering system or using xml-> xslt transformations. (the latter having the added benefit of being almost complete separation of content and presentation to the point that switching from html to wap can be as easy as changing your xslt (presentation). ) >>If you don't like PSP syntax, the same idea applies to whatever templating >> syntax you invent yourself -- just write a ServletFactory for your >> favorite syntax. technically your right, i can do some of the above in a servlet factory interface, but i want more than just a page renderer. i want to build a publishing framework with various resources and transformations engines and its own custom caching serving up a variety of file types. >>> i took a quick looksy through the webkit and code and noticed some >>> support for a paradigm that i think people could use to implement this >>> style of development in webware as well supporting general publishing >>> frameworks (ala apache cocoon). one key is the servlet chaining option >>> already builtin into webware. the other key, which i don't see and which >>> i' surmise doesn't exist from reading through the ipc9 paper, is the >>> ability to map servlets not to just file extensions but to whole >>> directory structures (including the root directory). >> >>Can you elaborate a bit on why you want to have a single servlet map to a >> whole directory? I guess I'm just not getting what you're trying to do. in a word, i want flexibility. a trivial example would be a servlet that maps to a directory of various file types and performs transformations on them, such as encoding html, txt, docbook into pdf via reportlab on the fly. more complex examples might include getting external connections as datasources for any files that need to be rendered in a directory and passing these resources on to the servlets that will perform the extension specific rendering (like grabbing a corba or snmp connection for ), but say if they weren't in that directory i don't need those connections. the list of possible examples could go on. maybe these things are possible with the current ideology but, to me a centralized servlet handler is the most natural design. in the above external connection example i could implement a lot of location specific garbage code to perform the connections in several different servlets, but i lose out in terms of code resuse vs just checking for an existing resource. >>It sounds like you might be interested in the "ExtraPathInfo" config option >> also -- it allows you to have a servlet handle all requests that start >> with http://localhost/MyServlet/foo/bar (for example) and the additional >> path information after MyServlet becomes accessible through >> self.request().extraURLPath() -- in this case "/foo/bar". This may be a >> way to achieve your goal of having a servlet handle all requests for an >> entire directory. very interesting, very cool. i vaguely remembering seeing this being discussed on the webware lists a few months ago. although this doesn't satisfy my requirements for directory handling of file extents, it does make a ZODB servlet a very real possiblity. i'm really beg. to like webware. >>see >> http://webware.sourceforge.net/Webware/WebKit/Docs/UsersGuide.html#Config_ >>Application >> >>> it looks like the current webware implementation uses the application to >>> preform request handling soley on the basis of a file xtension -> servlet >>> mapping. >>> >>> dug a little deeper into Application.py and noticed there is a special >>> case that can be used to mimic the behavior i want, but its kinda of >>> degenerate to use it this way since i'll be overiding what i think might >>> be a common assumption in the code about servletFactories mapping to >>> extensions. i'd like to create servletFactories which don't have any >>> exts, and to create one which maps to .* (apparently the catchall). does >>> anyone see a possible problem with this approach? >> >>Why not just give them the same extension? If you're inventing a new >> template syntax, let's call it KTL (Kapil's Templating Language), why not >> give your files the extension .ktl? And have a servlet factory for that >> extension. sigh, i hope the above answered this question, if i really wanted my own templating language i could just as easily port dtml over to webware (ignoring licensing issues, its not nesc a bad idea since dtml is precompiled into callable objects which is speed up by being a c extension.). the only thing that needs to be done is constructing a variable namespace. but i'm not interested in YATL (yet another templating language), i want flexibility in publishing. >>> the basic idea is to create a request handler servlet which maps all >>> incoming requests into other servlets, using a single servlet to present >>> templates (created by the designer with some special xml encoding that >>> their design tools will ignore) and using other servlets to generate >>> dynamic content for insertion into the templates. i suppose this could >>> also be a good point to override the caching option in the application >>> and institute per template caching. does this sound like a valid approach >>> or will i be hitting any hidden land mines (it used to happen to me so >>> often in zope, i've gotten into the habit of checking first). >> >>I'm not sure exactly what you're talking about so I can't tell if there >> would be any killer problems :-) but I would just say, consider whether >> what you're trying to do can be achieved with the "standard" Webware >> techniques of Servlets and Servlet Factories, and inheritance. "standard" is as "standard" does. the question is how easily webware can support my non "standard" desires. its not a matter of immeadiate solutions but what architectures can the system support. cheers kapil

Re: [Webware-discuss] content generation From: Geoff Talvola <gtalvola@na...> - 2001-03-09 23:22 ender wrote: > On Friday 09 March 2001 13:29, Geoff Talvola wrote: > >>ender wrote: > >>> at ipc9, talking to the webware developers its seems that the most common > >>> development strategy for webware is to define a sitepage with common > >>> element fragments and have the servlets generate dynamic content in the > >>> well (center of the page). > >>> > >>> i think this strategy is fine for a great many sites, however i think it > >>> has problems for most commercial development that i taken part in (aside > >>> from intranets). the problem being most of the time you're working with > >>> graphic designers and html/jscript coders who produce the templates, > >>> generally with some graphical tool. having them edit page fragments is a > >>> pain in the ass, as is slowing down development to roundtrip templates > >>> back and forth between developers and designers. > >>> > >>> a lot of web platforms are moving away from this style of development to > >>> one that supports using well-formed documents as the basis for content > >>> generation (zope, enhydra, arsdigita's acs) to name a few. granted this > >>> is a problem for most > >> > >>What is wrong with the strategy of having your graphic designers work with > >> PSP's that make up well-formed documents? The > >> writeHeader/writeSidebar/writeBody/writeFooter stuff is one way to do it, > >> but there's also nothing wrong with having the PSP override writeHTML if > >> you want the PSP to make up the entire web page. You can still inherit > >> from base classes within your PSP, to give you access to functionality > >> shared across all pages... > > the main issue for me is separation of content and logic. the unfinished > sentence from above was going to be. > > granted this is a problem for most templating languages. > > support for templating languages in graphical design tools is sketchy at best > (some ignore them, some complain, some die, some just remove the offending > tags when saving), on top of which without the interpretation of the template > by the server system they generally come out looking like shite, which makes > them difficult for a graphics designer to work with. > > one solution, which the platforms i cited above are moving towards is > basically using html tag attributes as a rendering system or using xml-> xslt > transformations. (the latter having the added benefit of being almost > complete separation of content and presentation to the point that switching > from html to wap can be as easy as changing your xslt (presentation). ) I would think that HTML designers are going to have a tough time writing xslt :-) But I do agree with your point. I've often wished for a framework where I could produce nicely formatted PDF for printing, as well as HTML optimized for browsing, from the same code base. Given the right xslt, I could produce an intermediate xml format, then translate to html or pdf as needed. Ultimately this turned out to be too much work, so I'm concentrating on browsability and hoping that the resulting documents don't look too bad when printed. Note that none of the commercial report writers that I'm aware of do a good job of solving this problem, either -- when you choose to view a report as HTML, they take a page-centric view and always include page breaks in the HTML. When I'm browsing a report online, I don't want page breaks! > >>If you don't like PSP syntax, the same idea applies to whatever templating > >> syntax you invent yourself -- just write a ServletFactory for your > >> favorite syntax. > > technically your right, i can do some of the above in a servlet factory > interface, but i want more than just a page renderer. i want to build a > publishing framework with various resources and transformations engines and > its own custom caching serving up a variety of file types. > >>> i took a quick looksy through the webkit and code and noticed some > >>> support for a paradigm that i think people could use to implement this > >>> style of development in webware as well supporting general publishing > >>> frameworks (ala apache cocoon). one key is the servlet chaining option > >>> already builtin into webware. the other key, which i don't see and which > >>> i' surmise doesn't exist from reading through the ipc9 paper, is the > >>> ability to map servlets not to just file extensions but to whole > >>> directory structures (including the root directory). > >> > >>Can you elaborate a bit on why you want to have a single servlet map to a > >> whole directory? I guess I'm just not getting what you're trying to do. > > in a word, i want flexibility. a trivial example would be a servlet that maps > to a directory of various file types and performs transformations on them, > such as encoding html, txt, docbook into pdf via reportlab on the fly. more > complex examples might include getting external connections as datasources > for any files that need to be rendered in a directory and passing these > resources on to the servlets that will perform the extension specific > rendering (like grabbing a corba or snmp connection for ), but say if they > weren't in that directory i don't need those connections. the list of > possible examples could go on. > > maybe these things are possible with the current ideology but, to me a > centralized servlet handler is the most natural design. in the above external > connection example i could implement a lot of location specific garbage code > to perform the connections in several different servlets, but i lose out in > terms of code resuse vs just checking for an existing resource. > > >>It sounds like you might be interested in the "ExtraPathInfo" config option > >> also -- it allows you to have a servlet handle all requests that start > >> with http://localhost/MyServlet/foo/bar (for example) and the additional > >> path information after MyServlet becomes accessible through > >> self.request().extraURLPath() -- in this case "/foo/bar". This may be a > >> way to achieve your goal of having a servlet handle all requests for an > >> entire directory. > > very interesting, very cool. i vaguely remembering seeing this being > discussed on the webware lists a few months ago. although this doesn't > satisfy my requirements for directory handling of file extents, it does make > a ZODB servlet a very real possiblity. i'm really beg. to like webware. > > >>see > >> http://webware.sourceforge.net/Webware/WebKit/Docs/UsersGuide.html#Config_ > >>Application > >> > >>> it looks like the current webware implementation uses the application to > >>> preform request handling soley on the basis of a file xtension -> servlet > >>> mapping. > >>> > >>> dug a little deeper into Application.py and noticed there is a special > >>> case that can be used to mimic the behavior i want, but its kinda of > >>> degenerate to use it this way since i'll be overiding what i think might > >>> be a common assumption in the code about servletFactories mapping to > >>> extensions. i'd like to create servletFactories which don't have any > >>> exts, and to create one which maps to .* (apparently the catchall). does > >>> anyone see a possible problem with this approach? > >> > >>Why not just give them the same extension? If you're inventing a new > >> template syntax, let's call it KTL (Kapil's Templating Language), why not > >> give your files the extension .ktl? And have a servlet factory for that > >> extension. > > sigh, i hope the above answered this question, if i really wanted my own > templating language i could just as easily port dtml over to webware > (ignoring licensing issues, its not nesc a bad idea since dtml is precompiled > into callable objects which is speed up by being a c extension.). the only > thing that needs to be done is constructing a variable namespace. but i'm not > interested in YATL (yet another templating language), i want flexibility in > publishing. > > >>> the basic idea is to create a request handler servlet which maps all > >>> incoming requests into other servlets, using a single servlet to present > >>> templates (created by the designer with some special xml encoding that > >>> their design tools will ignore) and using other servlets to generate > >>> dynamic content for insertion into the templates. i suppose this could > >>> also be a good point to override the caching option in the application > >>> and institute per template caching. does this sound like a valid approach > >>> or will i be hitting any hidden land mines (it used to happen to me so > >>> often in zope, i've gotten into the habit of checking first). > >> > >>I'm not sure exactly what you're talking about so I can't tell if there > >> would be any killer problems :-) but I would just say, consider whether > >> what you're trying to do can be achieved with the "standard" Webware > >> techniques of Servlets and Servlet Factories, and inheritance. > > "standard" is as "standard" does. > > the question is how easily webware can support my non "standard" desires. > > its not a matter of immeadiate solutions but what architectures can the > system support. I think the system will support just about anything you want to do with it. The farther you deviate from the "standard" webware way of doing things, the more work you'll have to do and the deeper you'll have to reach into the guts of WebKit. But the great thing is, webware is pretty modular, and the code is reasonably well documented and easy to understand. My gut feeling is that you ought to be able to do what you want by hooking into Servlet Factory and/or subclassing Application. -- - Geoff Talvola Parlance Corporation gtalvola@...

Re: [Webware-discuss] content generation From: Ian Bicking <ianb@co...> - 2001-03-10 07:05 ender <kthangavelu@...> wrote: > the main issue for me is separation of content and logic. the unfinished > sentence from above was going to be. > > granted this is a problem for most templating languages. > > support for templating languages in graphical design tools is > sketchy at best (some ignore them, some complain, some die, some > just remove the offending tags when saving), on top of which without > the interpretation of the template by the server system they > generally come out looking like shite, which makes them difficult > for a graphics designer to work with. Why not give up and follow what the GUI tools want? Allow a diversity of templates -- every GUI tool must have some notion of a template. I know Dreamweaver uses comments to delimit named template fields, and is easy enough to parse. I think named fields must be pretty universal. It would probably be quite easy to support the various template forms. This lowest-common-denominator will generally only allow named fields to be replaced, and generally not support any sort of repeating or other complexities. I don't see any simple way on a GUI level that someone would show that rows in a table should be repeated, for instance -- the table structure is fairly opaque on the graphic level. This isn't the perfect solution, but to me it seems like a very simple solution. Look for the generator tag, create some parser that works for the associated template format, and substitute values. Anything more complicated needs to be done with real programming (even if in a simplified template language), on the HTML level, and should probably be done by someone who knows HTML, which may or may not describe the graphic designer. Otherwise it can be done by example, which isn't too hard since the examples will be isolated and most of the template will be reusable as-is. (And, in most cases, the designer won't need to be involved -- doing repeated lines with <br> tags doesn't take a lot of thought). Anyway, a thought. It lacks any ability to abstract the template, create sub-templates, etc. But there's no perfect solution. Templates are abstract, WYSIWYG is absolutely *not* abstract. Maybe a GUI tool running *on* the server, rendering the template on the fly, would break down some of that. As I think about it, that technique has many of the same barriers that WYSIWYG word processing had -- performance, latency, interface... but when people got used to it, they realized the word processor would wrap the words for them, paginate for them, etc., and they understood that there was an abstract model underneith the WYSIWYG aspect (one where paragraph breaks exist as a character, for instance). Hmm... I had never really thought about it that way. I need to think about this more... -- Ian Bicking 4869 N. Talman Ave., Chicago, IL 60625 (773) 275-7241 ianb@... http://www.colorstudy.com/ianb

Re: [Webware-discuss] content generation From: Chuck Esterbrook <echuck@mi...> - 2001-03-11 06:13 At 06:31 PM 3/9/2001 -0500, Geoff Talvola wrote: >I think the system will support just about anything you want to do with >it. The farther you deviate from the "standard" webware way of doing >things, the more work you'll have to do and the deeper you'll have to >reach into the guts of WebKit. But the great thing is, webware is pretty >modular, and the code is reasonably well documented and easy to >understand. My gut feeling is that you ought to be able to do what you >want by hooking into Servlet Factory and/or subclassing Application. Also, someone (Terrel?) had an interesting URLDecoder/Encoder enhancement that allowed for a different kind of hook into URLs. -Chuck

Re: [Webware-discuss] content generation From: Chuck Esterbrook <echuck@mi...> - 2001-03-11 07:08 At 07:27 AM 3/9/2001 -0800, ender wrote: >technically your right, i can do some of the above in a servlet factory >interface, but i want more than just a page renderer. i want to build a >publishing framework with various resources and transformations engines and >its own custom caching serving up a variety of file types. I still don't see why you couldn't do this with the current WebKit facilities. If you have 3 or 4 extensions such as .xhtml, .xml, .xthis and .xthat, you can provide servlet factories and custom servlet classes for each of them. If they have things in common, you can provide an abstract servlet class to capture that. Regarding resources, if you need to access related files, such as a configuration file expected in the same directory, you can use the serverSidePath() method of the request, which let's you quickly build relative pathnames by passing in a path name to os.join() with: filename = request.serverSidePath('config.dict') Regarding custom caching, I believe Jay proved that this is doable when he did so with PSP, although I don't think we have any docs on the topic. Perhaps he can provide a few pointers. > >>> i took a quick looksy through the webkit and code and noticed some > >>> support for a paradigm that i think people could use to implement this > >>> style of development in webware as well supporting general publishing > >>> frameworks (ala apache cocoon). one key is the servlet chaining option > >>> already builtin into webware. the other key, which i don't see and which > >>> i' surmise doesn't exist from reading through the ipc9 paper, is the > >>> ability to map servlets not to just file extensions but to whole > >>> directory structures (including the root directory). > >> > >>Can you elaborate a bit on why you want to have a single servlet map to a > >> whole directory? I guess I'm just not getting what you're trying to do. > >in a word, i want flexibility. a trivial example would be a servlet that maps >to a directory of various file types and performs transformations on them, >such as encoding html, txt, docbook into pdf via reportlab on the fly. more That particular example can be done by turning ExtraPathInfo on, creating a directory "foo" with a "Main.py" and putting the files in a subdir called "resources/". Now when you get a URL like http://host.com/foo/baz, then your Main.py can grab "baz" out of "resources/" and do what it likes with it. Hmmm, if you wanted this to happen in your root, such as http://host.com/baz, I'm not sure how you'd pull that off. I think you could have a Main.py that forwards the request to a servlet in a subdir. I'll consider the idea of a servlet handler for a given URL that takes precedence over files in that directory. There are questions, like how do we indicate that? Does it go "deep" into further URLs? etc. Kapil, if you really want this, you should write a WEP. Basically, WebKit's extension provisions are powerful, flexible and mature enough that changes to them are going to be weighed carefully before proceeding. Kind of like modifying Python. It already works great, so changes have to be scrutinized. >maybe these things are possible with the current ideology but, to me a >centralized servlet handler is the most natural design. in the above external >connection example i could implement a lot of location specific garbage code >to perform the connections in several different servlets, but i lose out in >terms of code resuse vs just checking for an existing resource. As I mentioned above, having a "Main.py" by itself in a subdirectory gives you a "servlet handler". You just have to put the other files in a subdir. >very interesting, very cool. i vaguely remembering seeing this being >discussed on the webware lists a few months ago. although this doesn't >satisfy my requirements for directory handling of file extents, it does make >a ZODB servlet a very real possiblity. i'm really beg. to like webware. Well, it's about time! :-) >sigh, i hope the above answered this question, if i really wanted my own >templating language i could just as easily port dtml over to webware >(ignoring licensing issues, its not nesc a bad idea since dtml is precompiled >into callable objects which is speed up by being a c extension.). the only >thing that needs to be done is constructing a variable namespace. but i'm not >interested in YATL (yet another templating language), i want flexibility in >publishing. Actually, a DTML language that used [] instead of <> wouldn't be such a bad idea. My graphic design clients already use a custom templating language somewhat akin to DTML and love it. Their biggest gripe is that like DTML, their language uses <> so when they preview in Netscape they can't see what's going on. Other than that, they are very happy. I'm not really a fan of YATL either, but I do realize that non-Pythonic people need _something_. Whether or not that is DTML-like or XHMTL-attribute-based is something I haven't figured out yet. Note that with the [] delimited syntax there is _no_ issue of "such and such tool won't view these files" or "such and such tool clobbers these tokens". >"standard" is as "standard" does. > >the question is how easily webware can support my non "standard" desires. > >its not a matter of immeadiate solutions but what architectures can the >system support. Well, we do our best, but every architecture has its pros and cons. At this point, if you wanna push the directory-handler idea, a WEP is the way to go. The idea seems powerful and interesting, but it's not on my list of things to champion in the near future. -Chuck

Re: [Webware-discuss] content generation From: Tripp Lilley <tlilley@pe...> - 2001-03-11 16:40 On Sat, 10 Mar 2001, Chuck Esterbrook wrote: > I'm not really a fan of YATL either, but I do realize that non-Pythonic > people need _something_. Whether or not that is DTML-like or > XHMTL-attribute-based is something I haven't figured out yet. > > Note that with the [] delimited syntax there is _no_ issue of "such and > such tool won't view these files" or "such and such tool clobbers these > tokens". Perl's Text::Template allows you to set the delimiters dynamically, so you're not bound to a particular set and can tailor them for each application, or even each file. This doesn't address the issue of defining "tags" to inline, in the "XML" sense, but it does give a little more flexibility for tailoring your site's templates to the tools you use (ie: previewing in netscape). As a trivial example, I made Text::Template regard "<tx>" and "</tx>" as the delimiters so that emacs would properly indent my inlined code :) -- Joy-Loving * Tripp Lilley * http://stargate.eheart.sg505.net/~tlilley/ ------------------------------------------------------------------------------ "Fiber makes you poop." -- From <http://www.pvponline.com/bts_studio.php3>

Re: [Webware-discuss] content generation From: ender <kthangavelu@ea...> - 2001-03-11 18:52 On Friday 09 March 2001 15:31, Geoff Talvola wrote: >>ender wrote: >>> On Friday 09 March 2001 13:29, Geoff Talvola wrote: <snip><snip><snap> >>> >>What is wrong with the strategy of having your graphic designers work >>> >> with PSP's that make up well-formed documents? The >>> >> writeHeader/writeSidebar/writeBody/writeFooter stuff is one way to do >>> >> it, but there's also nothing wrong with having the PSP override >>> >> writeHTML if you want the PSP to make up the entire web page. You can >>> >> still inherit from base classes within your PSP, to give you access to >>> >> functionality shared across all pages... >>> >>> the main issue for me is separation of content and logic. the unfinished >>> sentence from above was going to be. >>> >>> granted this is a problem for most templating languages. >>> >>> support for templating languages in graphical design tools is sketchy at >>> best (some ignore them, some complain, some die, some just remove the >>> offending tags when saving), on top of which without the interpretation >>> of the template by the server system they generally come out looking like >>> shite, which makes them difficult for a graphics designer to work with. >>> >>> one solution, which the platforms i cited above are moving towards is >>> basically using html tag attributes as a rendering system or using xml-> >>> xslt transformations. (the latter having the added benefit of being >>> almost complete separation of content and presentation to the point that >>> switching from html to wap can be as easy as changing your xslt >>> (presentation). ) >> >>I would think that HTML designers are going to have a tough time writing >> xslt :-) But I do agree with your point. I've often wished for a >> framework where I could produce nicely formatted PDF for printing, as well >> as HTML optimized for browsing, from the same code base. Given the right >> xslt, I could produce an intermediate xml format, then translate to html >> or pdf as needed. Ultimately this turned out to be too much work, so I'm >> concentrating on browsability and hoping that the resulting documents don >> t look too bad when printed. Note that none of the commercial report >> writers that I'm aware of do a good job of solving this problem, either -- >> when you choose to view a report as HTML, they take a page-centric view >> and always include page breaks in the HTML. When I'm browsing a report >> online, I don't want page breaks! the solution i was referring to are actually two different approaches that attempt to solve the problem of content / logic separation. two are designer friendly, namely enhydra's xmlc http://xmlc.enhydra.org xmlc is competely designer friendly and usable in existing tools, it relies only on the id attribute which is part of HTML, and uses that as the key for insertion of dynamic data. but its kinda of non-pythonic in the sense of how strict is, all your logic goes into a separate file, because you're documents are valid HTML/XML/etc. which means that it works for any designer's tools. Zope's embryonic Presentation Templates http://www.zope.org/Wikis/DevSite/Projects/ZPT which is a bit more pythonic, but adds the notion of presentation logic which should be in templates. its a bit more sophisiticated in its use of html (xhtml), and it uses xml namespaces to add in three separate kinds of insertion/presentation logic. sadly this solution isn't entirely compatible with all gui design tools, but it is a nice step in this direction for zope/python. (the bad tool in question is dreamweaver, another which works properly is adobe go live). the other kind of solution to the content/logic separation is more technically friendly, such as a publishing framework (of which the most popular is XSLT/XML). having a desinger use these things would generally produce only amusement and maybe a lost designer. but these solutions also offer powerful translation to vastly different kinds of presentation formats from the same data. i think this dicussion has deviated a bit, i'm not suggesting the inclusion of any these technologies, just trying to get people thinking about the content generation problem in a webware context. <snap> <snap> <snip> >>> >>Can you elaborate a bit on why you want to have a single servlet map to >>> >> a whole directory? I guess I'm just not getting what you're trying to >>> >> do. >>> >>> in a word, i want flexibility. a trivial example would be a servlet that >>> maps to a directory of various file types and performs transformations on >>> them, such as encoding html, txt, docbook into pdf via reportlab on the >>> fly. more complex examples might include getting external connections as >>> datasources for any files that need to be rendered in a directory and >>> passing these resources on to the servlets that will perform the >>> extension specific rendering (like grabbing a corba or snmp connection >>> for ), but say if they weren't in that directory i don't need those >>> connections. the list of possible examples could go on. >>> >>> maybe these things are possible with the current ideology but, to me a >>> centralized servlet handler is the most natural design. in the above >>> external connection example i could implement a lot of location specific >>> garbage code to perform the connections in several different servlets, >>> but i lose out in terms of code resuse vs just checking for an existing >>> resource. i should also add that this type of functionality is also present in every other webserver i've used (aolserver, apache, orionserver, tomcat, and zope). i think of this as pretty basic stuff, that should be in the core (notice two of the above servers are serlvet frameworks, if that means anything). <snip ExtraPathInfo stuff> >>> >>I'm not sure exactly what you're talking about so I can't tell if there >>> >> would be any killer problems :-) but I would just say, consider >>> >> whether what you're trying to do can be achieved with the "standard" >>> >> Webware techniques of Servlets and Servlet Factories, and inheritance. >>> >>> "standard" is as "standard" does. >>> >>> the question is how easily webware can support my non "standard" desires. >>> >>> its not a matter of immeadiate solutions but what architectures can the >>> system support. >> >>I think the system will support just about anything you want to do with it. >> The farther you deviate from the "standard" webware way of doing things, >> the more work you'll have to do and the deeper you'll have to reach into >> the guts of WebKit. But the great thing is, webware is pretty modular, >> and the code is reasonably well documented and easy to understand. My gut >> feeling is that you ought to be able to do what you want by hooking into >> Servlet Factory and/or subclassing Application. >>- Geoff Talvola >> Parlance Corporation >> gtalvola@...

Re: [Webware-discuss] content generation From: Terrel Shumway <tshumway@tr...> - 2001-03-12 18:39 ender wrote: > > i'm against altering the operation of the base distribution because i want to > be able to give back what i build to the community, and i strongly feel that > at least the concept of directory handlers (or maybe just regex'd handlers) > should be in the core. > In progress. I did most of the work about a month ago, but I never finished the Unit tests. In about 20 minutes (11:00 PST (UTC-8:00)), checkout http://www.ics.uci.edu/~tshumway/webware/urldecode.html > > on a side note i'm also a bigger fan of composition over inheritance as a > means of code reuse. much easier to unit test, and much more likely to be > resusable (ie glue togther quickly exisiting components), esp. because python > allows multiple inheritance, not that this seems to be used abusively in > Webware, which is a good thing, just a personal preference. Me too.

1 message has been excluded from this view by a project administrator.