[Zope3-dev] IMPORTANT RFS: Through the Web Site Development

[Leonardo Rochael Almeida]

On Mon, 2003-01-13 at 18:03, Jim Fulton wrote:
> Shane Hathaway wrote:
> > Jim Fulton wrote:
> > 
> >> Shane Hathaway wrote:
> >>
> [...]
> > 
> > My hathaway.freezope.org site has a little bug I noticed yesterday. 
> > There are five folders with separate photos, and if you try to directly 
> > visit any of the photo folders, instead of seeing photos, you'll see the 
> > listing of all photo folders.  index_html is being acquired.  I can 
> > imagine a few ways to fix it:
> > 
> > 1) Add an index_html to each of the photo folders.  I'd have to remember 
> > to do this for all new photo folders as well.
> > 
> > 2) Change /Photos/index_html to recognize when it has been acquired, and 
> > show the photos instead of the photo folder listing.  This makes 
> > /Photos/index_html kind of complicated.
> > 
> > 3) Add a "Photo Folder" content type and use it for all photo folders. 
> > This seems heavy, since photo folders exist only for categorization, not 
> > to add any functionality to the site.

IMO, it shouldn't be heavier, if we had a more lightweight system than
ZClasses in place, especially one that didn't depend on access to the
Control Panel. What if we had Prototypes like in the Self Programming
Language?

> > 4) Visit each folder under /Photos and say that its default view is not 
> > index_html but instead photos_view.  This is the solution that I'd 
> > prefer, if only because it seems the most obvious.

And this could be automated, by copying a folder with this setting,
instead of creating a new Folder, next time you needed a new Photo
"folder" (this kind of automation could also be applied to 1). By
creating the "canonical" Photo folder with the photos_view setting you'd
be creating a Prototype. 

In any case, it's clear that Acquisition alone doesn't cut it here, but
we need something more flexible than inheritance or site-global view
settings. This is what Prototype programming gives us.

> As far as the folder display, you'd like all of the folders containing
> pictures to display the pictures as images. 
> 
> Because you want to affect many
> objects, you'd create a new default view for folders that displayed pictures inline
> [...]
> The default view for all folders is controlled through configuration.
> The default view that comes out of the box checks to see if a folder has
> an index.html item. If it does, it displays that, otherwise, it displayes
> a simpler folder listing.
> 
> You can override the default view using your own template.  You would do
> that the following way. In the default package of your site:
> 
> - Add a template that provides the desired view.
> 
> - Add a page configuration that configures the template as
>    the default view for folders.

Now all my folders behave differently, what if I just want the folders
that contain photos to act like that? I could have other folders for,
say, downloads, that just listed it's contents, and it could contain
large images that I don't want to force the browser to view
automatically (or waste server cicles generating thumbnails, or
whatever).

Well I could make my photo-album into another "site" with it's own
default view and stuff, so that my download folders retained their
default views, but this feels much more heavyweight than creating a
Folder-derived ZClass with it's own default view. Actually it feels like
I'm suddenly reinventing ZClasses with the "Site" mechanism...

IMO, the huge success of ZClasses, despite it's shortcommings, and the
existence of the "Abracadabra
product":http://www.zope.org/Members/mjablonski/AbracadabraObject show
that there's a kind of programming that can be made possible by simply
repeating what a user already knows about creating and copy/pasting
objects.

I do believe we might be missing an actor here, even though I don't know
yet how to properly write her use-cases. But it's an actor that is not
satisfied by the mere ability to write templates, SQLs and
PythonScripts. I do see a better solution than ZClasses for these users,
though: Prototype-based programming.

IMO, once a user is familiar with the concept of Acquisition,
Prototype-based programming is the next logical step. It's simply
"programming by copy/pase" with object-inheritance working as a kind of
explicit "remote-acquisition" in which you specify from what other
object your cloned objects acquire attributes/methods (which is what
some users think when they are programming with ZClasses: the
acquisition machinery goes to look in the ZClass when it reaches an
instance).

The paper "Using a prototype-based language for user interface
programming: the Newton project's experience", that can be found here:
http://wsmith.best.vwh.net/works.html was the paper that finally
convinced me that Prototype programming was the way to go. It explains
why a prototype language is a nice fit for a GUI system. And as anyone
who has played with HyperCard (or one of it's clones, like ToolBook) and
Zope can tell you, GUI and Web programming have a lot in common,
especially when you compare systems that have some form of acquisition

Cheers, Leo

-- 
Ideas don't stay in some minds very long because they don't like
solitary confinement.