[Zope-PTK] CMS comments

[Tres Seaver]

Dieter Maurer wrote:

 > I played this week end with the CVS version of CMF.
 >
 > In general, it looks nice!
 >
 > There are a few things, I would consider as errors or
 > weaknesses. I know, I should probably report them to the
 > tracker. But that is much more work for me ;-)
 >
 >
 > Errors:
 >
 >  * the link color seems to vary arbitrary:
 >
 >      In some cases, it is white (which is good in the
 >      action box with its dark background),
 >      but usually, no link spec seems to be in effect.
 >      I, then, get my default link color, which is dark
 >      blue. Such links are invisible.
 >
 >      This may be a Netscape 4.7 effect, but I doubt it.
 >
 >      Now, I know it for sure! It is a Netscape bug!
 >      When I change the font family in the Netscape
 >      'Fonts Preferences' from "Helvetica" to "Times",
 >      all links become white. When I change back to
 >      "Helvetica" all links take on the default colors.
 >      Time to switch to a different browser....

NS 4.x *is* hard;  I usually customize the 'Basic' skin's colors
first thing, and make that color something like 'DarkMagenta'
instead of 'LightGrey'.  I'm specifically prohibited from changing
colors in the CVS checkout though, as I actually prefer the 'No CSS'
skin for many kinds of tasks. :)

 >  * the default 'NewsItem' view does not contain the LeadIn.

Hmm, true -- the "Leadin" is only used on the 'recent_news' page.
Check out Jeffrey's excellent post on skinning to fix that for
your site.

 >  * Most redirects in 'Topic.py' create invalid URL's:
 >    query strings with unquoted spaces.
 >
 >    This gives a really surprising error response,
 >    because already ZServer returns a '400 Bad Request'
 >    with minimal information: no error class, value, traceback.

Thanks for reporting this -- the spaces were all in the
'portal_status_message' strings.  I've just checked in a fix.

 >  * 'Topic' uses the 'Folder' icon.
 >
 >    The causes are many fold:
 >
 >      * 'Topic' inherits from 'PortalFolder' which
 >        in turn inherits from 'Folder' and 'DynamicType'
 >        (in that order).
 >    
 >        As a consequence, 'Topic' gets the 'icon'
 >        defined in 'Folder' and not the one in 'DynamicType'
 >    
 >      * The type factory of 'Topic' lacked the icon definition
 >    
 >      * The icon was at the wrong place.

OK.  This *really* should be in the tracker:

  http://www.zope.org/Products/PTK/Tracker

but I see that the mailhost / SMTP server on zope.org is
balky, so you're off the hook here.  (I'm not going to fix
this as we speak, though).

 >
 >  * 'Topic/subtopic_view' generates links to the subtopic
 >    that do not end in a skin. If they are clicked on,
 >    an 'index_html' is acquired. Of course, it has nothing
 >    to do with the subtopic.

Another wannabe tracker issue -- I've fixed this by adding a
skinnable 'index_html' (uses the 'view' action from the types
tool, or the first one).  Checked in.

 > Weaknesses:
 >
 >  * the color scheme was unusable for me: dark font color on dark
 >    background in the top bar and the action box and the news box.
 >
 >    May be a Netscape 4.7 problem that did not understand to
 >    make links white.

I am really hopeful that the PTK^H^H^CMF community will jump on this
and begin producing new skins, including at least some which are
"NS 4.x safe."

 >  * I was often surprised what folder a folder action operated on.
 >    All search, submits, publish actions lead to the 'Portal Folder'.
 >
 >    I implemented an "ActionTitle" for folder actions similar to
 >    that for object actions.
 >
 >    I did not find it easy to get at the folder the actions
 >    operate on. Sometimes, folder and object are identical
 >    (--> 'Topic'). This should be made easier.
 >    I currently use a Python script that determines the folder object
 >    via 'restrictedTraverse' from the action url.

Can you post a sample of how you are using this script?  I
don't doubt that the folder actions get confusing, but I am
not quite sure which behavior you refer to.

 >  * The search form should support searches for subjects.
 >    They are so prominent that it should be possible to search for
 >    them.

Yes, definitely so.  The search UI needs an overhaul.

 >  * The presentation of topics with subtopics is weak:
 >
 >     The standard view of a topic presents the search results.
 >     This is adequate if the topic does not have subtopics.
 >     However, with subtopics, the default view should
 >     present an interactively explorable tree containing
 >     these subtopics, maybe in addition to all documents
 >     and just the new ones.
 >    
 >     Probably the following views are relevant:
 >    
 >      1. all documents matched by the topic's query (the current 'view')
 >    
 >      2. just the subtopics (the current 'subtopics')
 >    
 >      3. an explorable hierarchy with the subtopics and
 >         any new documents, not already delivered by a
 >         subtopic

The model is actually only "trickle down":  subtopics acquire
criteria (optionally) from their parents.  We have discussed doing
a "Pachenko"-style topic, where items would fall through any parent
which had one or more subtopics matching them;  this requires more
help from the catalog than we can get right now without depending
heavily on the guts of its implementation (a la ZTopics).

 >      4. maybe, there should be a way to compute the
 >         result of a topic from its subtopics
 >         ('or' or 'and' come to mind).

Again, we could do more along these lines if the catalog gave us
a supported way to manage result sets from individual index queries.

 >
 >  * The 'Above in Thread' display in discussions is ugly:
 >
 >     The discussion ancestors of a discussion item
 >     are formated as a ':' separated list. This is unwieldy
 >     for deep discussions.

Can you suggest a replacement for the skin method which produces
this display?  The existing method is in
'portal_skins/generic/discussion_reply_view'.

 >  * The 'recent_news' view was unreadable.
 >
 >    I have never seen such tiny characters on my screen before.

I can't figure out why, either, but it is tiny in Mozilla, too
(at least there the font size adjustment works!)


 >    This probably is a Netscape 4.7 problem. I searched for
 >    hours to find any problem in the generated page (and its
 >    style specification) - without success.
 >
 >    Explicit 'font-size' specifications for the leaf classes
 >    finally made the text readable.

Again, I'm hoping the community can help here -- perhaps we
should start a contest for uploaded skins?

 > Despite the long list, I like the CMF.

Thank you, especially for the detailed and constructive feedback!

Tres.
-- 
===============================================================
Tres Seaver                                tseaver@digicool.com
Digital Creations     "Zope Dealers"       http://www.zope.org