Chuck, these are all very good points. The main issue to me, though, is that I, the programmer, want to be able to write possibly tricky and involved code and logic in a WebKit class in pure Python, but have my web designer use PSP with minimal Python code to present the results. So, can PSP be used as a presentation mechanism for data generated within a WebKit class? If it isn't possible right now, it shouldn't be hard to do, I would assume.
Now, as Jay suggests, I realize that if I actually took the time to look at the source in CVS, I might already know the answer. So before I make any more comments or suggestions to this list, I'm going to grab the latest snapshot from CVS and actually look at what's there...
Chuck Esterbrook wrote:
> Wow, I've invented a term: *SP.
>
> My thoughts:
>
> [1] This reminds me very much of DTML in Zope to the point of wondering why you don't use that system if this is what you're looking for. DTML's options for displaying data and looping looked extremely mature to me (except for one little quirk that eludes my memory right now).
>
> [2] Your system works with lists and dictionaries and nested versions of them, but doesen't mention objects. Your example pulls data from the database and works with it directly. -- In terms of an OO approach, I would think you'd want to deal with objects whose methods may cover for data or may be calculations, etc. Certainly users would still be able to work with "naked" data structures and have that choice, but you could easily tweak your system to invoke methods instead.
>
> I have a class called "KeyValueAccess" in Webware that lets you say valueForName("x.y.z") and it can follow the keys regardless of whether you're traversing through objects or dictionaries. It goes for public methods first, then public attributes, then private methods (_foo()), then private attrs (_foo). You're welcome to look at it if you like.
>
> [3] My concern with mini-languages is that inevitably they give out on you, while with a *SP approach you have everything that Python can give. This can be useful because
> * you get a large "vocabulary" to work with
> * you can do something that's outright hacky but saves your ass in the nick of time when you need to
> * you can more easily experiment with different approaches
> Of course, this can be abused more, but generally prefer to have more slack rather than less.
>
> I certainly agree that item (A) is a bad choice.
>
> I'm not yet convinced that YAML (yet another mini-language) is the way to go.
>
> Ben, you might also want to look at Latte, whose mini-language allows you to define funcs in the document mostly to make life easier and reduce typing. For a mini-language approach, it's not bad. http://www.zanshin.com/latte/home.html
>
> -Chuck
>
> Benjamin Saller Bender wrote:
> >
> > I find myself looking at and questioning the *SP model (ASP, PHP, etc), as
> > it was recently coined. The problem, as I am sure you are all aware is the
> > presence of code scattered throughout what is effectively the user
> > interface.
> >
> > Web customers are a fickle lot. Most web sites will undergo at least one
> > full UI revamping in there life time, but in most cases all the core
> > functionality survives. This means that the containment vehicle for the
> > functional code will evolve and change, often at a different rate than the
> > functionality itself.
> >
> > Now when developing *SP styled applications you can do it a few
> > options.
> > A) You litter the application with code. You find the code that
> > generates content at the respective place in the *SP file.
> >
> > B) You encapsulate everything, including the bulk of the code and
> > the work in the front of the file and only put presentation
> > oriented code anywhere in the UI proper.
> >
> > C) Like B except that you only things like the single __str__
> > method of an object to render complex presentation at any given
> > point in a document.
> >
> > I am sure there are other common modes of delivering dynamic content
> > using the *SP model, but these are the ones I have seen done
> > most. The problems that I see with (A) is that it is inherently
> > fragile. The approach can (but doesn't always) lead to very procedural
> > programming. Without heavy reliance on a framework to do all the work
> > scatter throughout your document you create a rigid piece of code, tightly
> > bound to the physical data model of the back-end database and little
> > opportunity to change it. Changes are more likely to ripple from one
> > section of you application to another and it becomes difficult to enforce
> > any uniformity. While (A) is popular on small sites most *SP programmers
> > lean towards something more like (B) or (C).
> >
> > (B) and (C) both suffer from similar problems. UI people will still have a
> > difficult time changing the layout of a page with out breaking anything.
> > You will find that parts of the page are the inlined presentation language
> > (X/HTML) and some of the dynamic content is now generated in imported
> > functions or included files. This can make it difficult or impossible for
> > the non-programmer to make sophisticated changes to site look and feel.
> > These modes of operation also lead to the situation where the more you
> > encapsulate and generate functionally the closer you are to framework
> > driven CGI and you need to question if you can successfully leverage the
> > *SP model any further.
> >
> > I realize that the world is not nearly as black and white as I might try
> > to make it seem here, but I do think that these are fundamental issue
> > associated with the *SP model. The possible solution that I propose is
> > nothing new, though I do think I describe it with a new spin and maybe
> > some incremental improvements.
> >
> > The notion is a simple one. Templates, like FastTemplates or PHPlib
> > have. Like WebMacros for java in some small way. I have only glanced at
> > these so I cannot talk about what they can and cannot do, but I would like
> > to share the system I came up with and I how I see it growing from here.
> >
> > Any system that enforces the clear separation of business logic from
> > presentation has an advantage over those that don't. The goal is to keep
> > the alterations to the UI as minimal as possible so that it can remain as
> > flexible as needed. This involves creating a system that doesn't rely on
> > 'little-languages' or some extensive new embedded mark-up.
> >
> > In my template system I tried to keep the X/HTML as pure as possible,
> > while still allowing it to show as form and content to the UI developer.
> > To this end I tried to keep the interface simple and the design of the
> > backend flexible.
> >
> > The interface looks very much like the fastTemplate system for PHP, in
> > that it uses {} to delimit keys, but I think things are a bit easier to
> > use.
> >
> > {key} subst key with value
> > {key E:e} subst key if available, otherwise use the error mode that
> > we set as an argument, where those are things like
> > w - warn
> > e - empty
> > s - non-breaking space
> > i - increment the error count*
> >
> > {key::DATASRC} Iterate over key for each entry in datasrc. This works
> > for python list, dictionaries and lists of dictionaries.
> >
> > In this case key would refer to an external template
> >
> > {BEGIN block} Delimit a section of text
> > {END block}
> >
> > Example
> > -------
> > {TITLE}
> > <h2>Users</h2>
> > <table border=1>
> > {BEGIN userlist::users}
> > <tr>
> > <td>{username}</td>
> > <td>{id}</td>
> > <td>{email}</td>
> > <td>{last_visit E:s}</td>
> > </tr>
> > {END userlist}
> > </table>
> >
> > This would create a table with a row for each user pulling out the name,
> > id and email address. In this example last_visited would be replaced with
> > a space if it was missing.
> >
> > This interface is simple enough, but it is the API that I am more
> > interested in getting people to think about.
> >
> > template.assign does the work of populating template variables. This
> > function deals with assignment of single valued strings, lists of strings,
> > dictionaries and lists of dictionaries.
> >
> > In the above example we would populate title like
> >
> > template.assign(TITLE="Template Examples")
> >
> > and the more interesting case of users for the USERLIST snippet looks
> > like:
> >
> > db = resource.request("dbi:///mysql/db[username:password]")
> > cursor = db.cursor()
> >
> > sql = """select * from users order by id asc"""
> > users = sqlexec(cursor, sql)
> >
> > template.assign(users=users)
> >
> > In this case sqlexec is a assignmentAdaptor. It prepares a dataset (in
> > this case a DBI2 result set) for assignment. This could be done with XML
> > files, CSV, CGI environment, anything really. Then you are in a situation
> > where confusing syntax and binding to physical models is removed from the
> > user interface and we can think of the UI as just one view on the data.
> >
> > I am interested in what people think of things as they stand now. This is
> > interesting in light of the recent discussions of tabbing and
> > indentation. You will see how be pulling that out of the UI we avoid the
> > problem, but retain the flexibility to use a good web object model.
> >
> > Benjamin Saller <case@...>
> > Technical Strategist AppliedTheory
> > Where tire hits pavement on the Information super-highway,
> > that's where my head is...
> >
> > ------------------------------------------------------------------------
> > Phone bills too big? Don't worry, beMANY!
> > http://click.egroups.com/1/4113/0/_/_/_/959190368/
> > ------------------------------------------------------------------------
> >
> > To unsubscribe from this group, send an email to:
> > python-web-modules-unsubscribe@...
>
> --
>
> -Chuck
> ____________________________________________________________
>
> http://webware.sourceforge.net
>
> ------------------------------------------------------------------------
> Failed tests, classes skipped, forgotten locker combinations.
> Remember the good 'ol days
> http://click.egroups.com/1/4053/0/_/_/_/959195919/
> ------------------------------------------------------------------------
>
> To unsubscribe from this group, send an email to:
> python-web-modules-unsubscribe@...
--
- Geoff Talvola
Parlance Corporation
gtalvola@...
|