[PEAK] discovering peak.web

[Phillip J. Eby]

At 10:24 PM 2/4/05 +0200, alexander smishlajev wrote:
>alexander smishlajev wrote, at 04.02.2005 21:26:
>>lately i was trying to find out what peak.web is and how it ticks.
>
>there are some things i didn't want to add to that quite long post.
>
>in TALES, if path component points to callable, it is called to evaluate 
>the component.  i didn't find such thing in PWT.  that's why the generator 
>in my example component became property (it was method initially).

Yeah, I don't really want paths to be that magic in PWT.  Note that you can 
easily create a "call" view in your sitemap if you want to.  Or just create 
the glue for whatever you need as a view expression.  This is the intended 
way to interface with arbitrary Python, as it keeps code out of the PWT and 
avoids multiplying the number of ways that magic can happen.

>it seems to me that docstring in class Expects (module peak.web.templates) 
>is wrong.

Yes, it should say that it adapts the current object to the specified 
protocol, and that it raises an adaptation error if the object cannot be 
adapted.  The adapted object then becomes the "current object" for 
traversal purposes within
that block.


>i didn't get the concepts of skins and ++ traversals.  we can go with what 
>i've learned already, so i do not intend to dig into those matters, but 
>i'm still curious, and would appreciate if someone could explain these 
>concepts in simple words.

Skins are just a way to provide alternate versions of resources from ones 
contained in the packages.  This allows the producer of a web component to 
supply default templates, images, etc. as resources included in the 
component's packages.  However, the user of the component can create a skin 
by making a special directory structure where the alternate templates and 
images are contained.  Any resources they do not supply an alternate 
version for will usually then default to the ones included in the package.

Skins are a completely optional feature; all the defaults are configured so 
that normally everything just comes from package-bundled 
resources.  However, you can use skins to not only customize 
package-supplied resources, you can also use them to have different "look 
and feel" UIs for a site, or a version optimized for mobile phone browsers 
and one version optimized for desktop browsers.  You can even use skins to 
perform internationalization, if for example you have different images or 
templates for different countries.  The skin is simply what controls the 
mapping from resource names to the actual resource files.

++ traversals, on the other hand, are an escaping mechanism in URLs, to 
allow you to break out of the normal path traversal.  For example, the 
++resources++ escape lets you refer to a specific resource from within a 
template, such as ++resources++/mypackage/someIcon.gif.  These escapes are 
valid in URLs as well as in PWT paths.  ++skin++ is an escape that lets you 
switch to a different skin, so you can create links that change the current 
UI.  ++id++ is a way to refer to path shortcuts defined using 'id=""' 
attributes and <offer> tags in a sitemap file.

++id++, by the way, is another component integration feature; sometimes a 
component will need to refer to a path without knowing the right path for 
the application.  Location IDs let such components just refer to an ++id++, 
and then the component user adds an 'id=""' attribute to the right location 
in the sitemap, or uses an '<offer>' to specify the path that should be used.


>>=== Simple WSGI handler ===
>>We start with simple wrapper component, itself doing most of the request 
>>processing.  {{{peak.web.Location}}} seems to be a good base for such 
>>wrapper: request path traversal and security rules will be processed by 
>>PEAK, so we can focus on our application.
>
>i think we'll use this for web actions since "tier 2" isn't expected to 
>appear in the nearest future...

Note that you can also just use regular functions, by setting them up as 
views.    E.g.:

     def some_function(context):
         # do the equivalent of handle_http here

And then make 'some_function' a view for the content type that the action 
is performed on.  So there is no need to even create a class for simple 
actions, and you can set the permissions right from the sitemap.