[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