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

Jim Fulton jim@zope.com
Mon, 13 Jan 2003 17:56:54 -0500


Leonardo Rochael Almeida wrote:
> On Mon, 2003-01-13 at 18:03, Jim Fulton wrote:
> 
>>Shane Hathaway wrote:
>>
>>>Jim Fulton wrote:
>>>
>>>
>>>>Shane Hathaway wrote:
>>>>

..

> 
>>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?

Then could could create a new photo folder content type that has the
desired behavior.

 > 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...

Right, which is why you're probably better off creating a new content
type.

> 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.

I agree that something based on prototypes might be useful.

> 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

I think that this is a worthwhile idea to pusue. Good luck. :)

Jim


-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (888) 344-4332            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org