On Wednesday 20 December 2006 16:03, Jeff Shell wrote: > On the other end of the spectrum is Django, whose admin screens are > actually usable by other humans and very very easy to customize. How > easy is it in Zope 3 to customize a folder contents view so that it > shows different columns, allows sorting only on certain ones, and > allows quick searching, grouping, and filtering? I know (or assume) > that 'zc.table' can provide for this functionality, but it's nowhere > near the core. As a developer, doing custom 'listing' or index pages > is something I need to do all of the time. 'title', 'size', and > 'modified' aren't interesting to me in a folder full of invoices.
Right, the contents view of the container is very static. The problem here is that noone wants to touch the existing skins for a multitude of reason. My main reason is that I am not using the UI patterns anymore, so I have either the choice of rewriting all management screens or deal with the old stuff. > I would be interested to know if anyone has succesfully used the TTW > ZPT Page and SQL Scripts or SQL Exprs to make a usable application. Me too. But I doubt that anyone uses them in production. They are just too limited. I think TTW would only become interesting, if you could develop components in the UI. I had started this work a while ago at z3c.webdev but decided I want to concentrate on other areas. Approaches like z3c.baseregistry are much more promising and I have built a very simple plugin system (took about 4 hours) on top of it. > Those never seemed to be the focus of Zope 3, and with the lack of > auto-acquisition and Python scripts, they felt extremely crippled > compared to their Zope 2 cousins. I certainly could never get them to > do anything useful, because I had no answers about what > objects/namespaces/modules/etc I could even access. All of the things > that were easy in Zope 2's TTW environment didn't seem doable in Zope > 3's. But that's OK, as custom Python / product / etc development is > much easier. I'd rather see the elevation and inclusion of tools like > 'zc.table' and 'zc.resourcelibrary' which can be useful across so many > application domains and could solve some very common problems. I think that once Zope 3 is eggified, we will have two Zope 3 default installation options; a bare bones one and one with batteries included. I could also imagine taking the plugin concept a bit further and have something similar to the Plone add-on installer. We can do a lot here. > And if we want to give casual newcomers something to look at, lets > focus on how Instance Homes and Products/Applications are used and can > be built. Perhaps give templated starting points like paster does:: > > $ paster create --template=zope3product easytodo Note that ArchGenXML's new implementation is a generic system now that can be used for Zope 3 packages. I think Jens wants to work on it during the Snow Sprint again. > The Zope 3 experience does nothing to start the casual newcomer > towards building a simple starter application. Both Pylons and > TurboGears have a 'quick wiki' tutorial which includes a line similar > to the one above. Unlike 'mkzopeinstance', the generated directories > and files reflect a working product with some starter modules, > classes, and templates: the equivalent of 'BoringProduct', in a sense, > but with some skeleton parts (class names, etc) filled in instead of > having to be manually replaced. Yes, I think there is a lot of oppurtunity for us here. But note that I also think that Zope 3 has been taught and introduced incorrectly in the past years. I have started a training outline that takes a vastly different approach. See the attached file. I have taught the training once this way, and it worked out great! The reason it works so well is because it concentrates on the following three goals: 1. Early success by creating something visual first. This is a well-known technique in pretty much any field, but we have been neglecting this in Zope 3. Writing a content type and checking it out in Python just does not cut it. It's too boring for the non-hardcore Python developer which cannot appreciate the machinery behind it. 2. Introduce fundamental concepts later. I have tried very hard to introduce a minimal set of concepts for each session. I have managed to not introduce components (including adapters and utilities) until the third day. (BTW, this is one of the reasons that we need high-level ZCML directives.) I have found that I lost a good set of students when introducing components; this is not surprising, since many of them did not have a solid Python foundation or formal CS education. 3. Teach what they need. The way the training is structured is the way people are integrated as developers at Lovely Systems. A junior/new programmer will not start by developing content types, adapters and other business logic, but write view-related code, in Lovely's case ZPT-templating, viewlets, pages, etc. With the referenced training structure, I had created productive people at the end of the second day of training. Even if they did not comprehend the CA, they could work on a project together with a senior developer. The result of those goals is that I taught Zope 3 the opposite way to how it is commonly done. I will have soon the opportunity to try this outline on a nother group of trainees at a different company to validate this model/outline. Okay, I am done with my OT rant and self-promotion. :-) Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
============================== Lovely Zope 3 Training Outline ============================== The primary goal of this training is to prepare the participants to work on Lovely Systems projects. The choice of topics is organized to reflect this goal, but everything is valuable to any participant, since no proprietary software is used. - Front Matter [0:30h] + Introduction + Proposed Schedule + Training Setup, Rules, etc. + Documentation Sources - Initial (Minimal) Setup [0:30h] + Setup Zope 3 (simplest way possible) + Access APIDOC + Create a Package (project) Unit I -- Presentation ====================== - Functional Tests [0:30h] + Motivation + Simple Functional Tests + Error Analysis - Resources [1:00h] + Simple Resources -- Use hello world HTML example + ZRT Resources + Resource Directories - Pages (Views) [1:30h] + Simple (Templated) Pages -- Reuse hello world HTML/template + Simple Python Page + Python Page with Template - Internationalization and Localization [1:00h] + TAL i18n syntax + Message Catalogs + gettext + Locales - Interfaces [0:30h] + Simple Interfaces + Motivation + Marker Interfaces + Implementation - Advanced Views [1:30h] + Views using View Templates + Using Content Providers + Utilizing Viewlets + Viewlets and View Templates - Skinning [1:00h] + Default Skins + Layers versus Skins + Minimal Layer + Setup a New Skin Unit II -- Data Management ========================== - Data Storage [1:00h] + Content Components + Persistence + ZODB - Basic Security [0:30h] + Permissions and Roles + Principals and Groups + Asserting Security + Security Proxies - Schemas [0:30h] + Simple Schemas + Field Overview + Vocabularies + Validation - Forms [1:30h] + Simple Forms + Customizing Form Fields + Customizing Widgets + Display versus Edit Forms + 3rd Party Widgets (z3c.widget, z3c.sessionwidget) Unit III -- Other Components ============================ - Component Architecture [2:00h] + Simple Adapters (Meta-data) + Named Adatpers + Multi-Adapters + Subscription Adapters + Utilities + Global versus Local + Base Registries - Annotations [1:00h] + Annotations + Annotations Factory + Dublin Core + Dublin Core Properties - Traversers [1:00h] + Simple Traversers + Pluggable Traversers + Namespaces - Sessions [0:30h] + Using Sessions + Customizing Session Properties - Events [0:30h] + Listening for Events + Sending Events - Catalogs and Indices [1:00h] + Utilizing Catalogs and Indices + Setting up Catalogs + ``hurry.query`` - Security [1:30h] + Design Goals and Philosophy + Granting Permissions and Roles Locally + Setting up an Authentication Service Unit IV -- Project Organization =============================== - Programmed Configuration [1:00h] + Using the Configurator + Developing Configurator Plugins - Sample Data [1:00h] + Motivation + Sample Data Managers + Sample Data Plugins - Testing Setups [1:00h] + Placeful Setup + Test-Layers + Initial ZODB Setups - Updating Software [1:00h] + Deprecating a Property or Method + Deprecating a Class or Module + Using Generations + Writing a Generation - Packaging [1:00h] + Install Python package using ``easy_install`` + Create an Egg for a Package - Deployment [1:00h] + Install Zope (from release) + Create Instances + Instance Configuration + Setting up dependencies and software + Managing the Zope System Process + Working with Virtual Hosting Unit V -- Miscellaneous Topics ============================== - Tables [1:00h] + Simple Table + Custom Columns + Extending Table Formatters + Sorting + Batching - Sending Mails [0:30h] + Setting up a Mailer and Mail Delivery + Using the Mailer - Trees [0:30h] + Simple Static Trees + Replacing Node Adapters - Relational Databases [1:00h] + Creating and testing a Database Connection + Writing SQL Scripts + Using Relational Databases in Python + Using ``sql`` TALES namespace - File Representations [1:30h] + Accessing Content via FTP + Providing File Representations + Providing Directory Representations for Containers - Help [1:00h] + Registering package with APIDOC + Registering Documentation as APIDOC book chapter + Registering Interfaces with APIDOC + Writing a new APIDOC module + Developing Online Help screens - Solving Problems [1:00h] + The Debug Skin + Investigating System Errors + Debugging Unauthorized Errors
_______________________________________________ Zope3-dev mailing list Zope3firstname.lastname@example.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com