> 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.
> >> http://webware.sourceforge.net/Webware/WebKit/Docs/UsersGuide.html#Config_
> >>> 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
> >>> 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