[PEAK] peak.web has landed (but is still very alpha)

[Phillip J. Eby]

At 07:28 PM 1/21/05 +0200, alexander smishlajev wrote:
>there was no essential news in peak.web land since then, wasn't it?

Only the changes I've made since then for e.g. the peak.security 
refactoring.  That, and the realization that I'll probably refactor again 
to cut out more stuff.


>we are planning to add web user interface to our PEAK-based server 
>application, and peak.web seems to be a natural platform choice.

If you're using just the sitemap and template facilties with limited 
in-Python customization of the framework itself, you should be relatively 
safe from my generic-function refactoring of peak.web.  In any case, it 
will probably be some time before I get to start that refactoring, as I'm 
currently under contract for work that doesn't directly relate to PEAK, at 
least not yet.


>at least quick introduction to tier1 functionality would be very helpful...

Tier 1 is basic sitemaps with views, templates, and containers in 
locations.  Pretty much everything you need to create sites that do not 
have any authentication or forms processing.  Pure display applications, in 
other words.  You just write templates for whatever pages you need, 
implement containers that return your domain objects given an item 
identifier, and then use a sitemap to put it all together.  You can also 
make applications skinnable, which is to say using different templates or 
images or languages for different users (sorry, no message catalogs yet, 
you would have to translate entire templates right now).

There is a hook for you to specify an authentication service to let users 
log in, but you should expect it to be gutted during the generic function 
refactoring and replaced with some sort of before/around methods, or with a 
generic function to figure out what authentication method is in use.  But 
as long as you're prepared for that possible issue you shouldn't have much 
trouble hooking any login facility you need into the current 
version.  Essentially 'getUser(environ)' needs to return a user object 
suitable for use with peak.security, which is to say it can return anything 
you want; it's just a matter of defining security rules that work with 
whatever you're using as user objects.

Form processing is basically waiting until I have something approaching a 
UI toolkit in PEAK, which is in turn waiting on me to actually implement 
the peak.schema ideas.  It's possible that my contract work will support 
some peak.schema work and maybe even UI toolkit work, but it's way too 
early to say.

In the meantime, of course, you can build your own framework using custom 
DOMlet classes or just using plain old forms and Python methods.  I do 
recommend that you limit your use of handle_http methods, as it is fairly 
likely that I'll be refactoring that to a generic function when I do 
refactor, as that's an easy way to add "around" wrappers and to have 
various other conditional dispatch stuff for peak.web.