TF & ZMI, was: RE: [Zope-dev] Zope 2.6 and OrderedFolders
You know, the funny thing is that TF really accomplishes the goals of a ZMI/UI-improvement hack (unclutter a view of a folder to VISUALLY separate the software/content/presentation space) implemented, IMHO, in the wrong place. I would think there is another way that a Folder UI could be uncluttered without the magic of TF, and that is add "translucency" (items are there, but obscured from view) to the UI layer - that is, the ability to VISUALLY unclutter different users' views of objects in a folder via ZMI; views could be stored per user. For example, you could select ZSQL Methods and RDB connections in a folder to be hidden from everybody but the Database programmer; you could keep these and Python Scripts obscured from the view of a content person or presentation designer, etc. Well, they wouldn't be hidden, but visually 'compacted' and relegated to a small drop-down box at the bottom of the page to unclutter it... so the standard tabled object list wouldn't iterate over objectIds() or objectValues(), but instead a higher-level filter function. A complimentary filter function would render the 'hidden' objects as a sequence as well. __ZMI manage_main Now:______________________ ________________________ ===\===\===\===\======== <--- ZMI tabs % :::::::::::::::::::=== TP.NAME..... .SZ. ..LM.. []---------- ---- ------ []---------- ---- ------ []---------- ---- ------ []---------- ---- ------ []---------- ---- ------ [RN][CT][CP][DL][I/E][SA] <--- Buttons for checked __ZMI With Translucency:___________________ ________________________ ===\===\===\===\======== <--- ZMI tabs % :::::::::::::::::::=== TP.NAME..... .SZ. ..LM.. []---------- ---- ------ []---------- ---- ------ []---------- ---- ------ []---------- ---- ------ []---------- ---- ------ [RN][CT][][][][][Hide] <--- New HideBtn ________________________ Hidden Items: [Select Item... [v] [Open][Unhide][ViewAll] <--- Buttons for doing things ^ with hidden | items | +-----------> ViewAll => pop-up new window ____________________________________________ This would be more visually convenient. I'm thinking of trying to monkey-patch OFS.Folder to just do this. Of course, with these kind of modifications, for any given folder, there's no mandatate that anything need to be hidden at all. Thoughts? Sean -----Original Message----- From: Casey Duncan [mailto:c.duncan@nlada.org] Sent: Wednesday, March 06, 2002 12:02 PM To: sean.upton@uniontrib.com; Eric.Roby@noaa.gov; zope-dev@zope.org Subject: Re: [Zope-dev] Zope 2.6 and OrderedFolders On Wednesday 06 March 2002 02:49 pm, sean.upton@uniontrib.com allegedly wrote:
Is this a suggestion that TF go into the core? One other (major) problem with TF is that it breaks session tracking site-wide, or at least the ability to have more than one session id manager per Zope instance in CST; I'm not sure about sessions in Zope 2.5...
TF seems to have too much normalcy-hijacking magic to go into the core, if you ask me...
Sean
-1 on TF in the core. Nice hack, but too much magic and there are significant performance implications if I remember correctly. Also Zope 3 will render TF superfluous. /---------------------------------------------------\ Casey Duncan, Sr. Web Developer National Legal Aid and Defender Association c.duncan@nlada.org \---------------------------------------------------/
On Thu, 2002-03-07 at 19:39, sean.upton@uniontrib.com wrote:
You know, the funny thing is that TF really accomplishes the goals of a ZMI/UI-improvement hack (unclutter a view of a folder to VISUALLY separate the software/content/presentation space) implemented, IMHO, in the wrong place. I would think there is another way that a Folder UI could be uncluttered without the magic of TF, and that is add "translucency" (items are there, but obscured from view) to the UI layer - that is, the ability to VISUALLY unclutter different users' views of objects in a folder via ZMI; views could be stored per user.
[...]
Maybe you could have a 'Views' tab where you could configure groups of filters where each filter would be configured like a 'Find Objects' query. Then, in the 'Contents' tab you'd have buttons to switch between those views and the default view, which show all objects. -- Ideas don't stay in some minds very long because they don't like solitary confinement.
I think this is an excellent alternative to handle the UI aesthetics. The other part of this issue (for me) is the acquisition of these objects. Even if they are hanging out in the root, I would still like to be able to put templates in a template folder, scripts in a scripts folder etc... and not have to go through a great deal of fanfare to acquire them. It would be nice to be able to define mappings (or not) for the acquision process to evaluate once the trail hits root and before it looks in REQUEST. This feature of TF is really nice (just dangerous). Eric
You know, the funny thing is that TF really accomplishes the goals of a ZMI/UI-improvement hack (unclutter a view of a folder to VISUALLY separate the software/content/presentation space) implemented, IMHO, in the wrong place. I would think there is another way that a Folder UI could be uncluttered without the magic of TF, and that is add "translucency" (items are there, but obscured from view) to the UI layer - that is, the ability to VISUALLY unclutter different users' views of objects in a folder via ZMI; views could be stored per user.
For example, you could select ZSQL Methods and RDB connections in a folder to be hidden from everybody but the Database programmer; you could keep these and Python Scripts obscured from the view of a content person or presentation designer, etc. Well, they wouldn't be hidden, but visually 'compacted' and relegated to a small drop-down box at the bottom of the page to unclutter it... so the standard tabled object list wouldn't iterate over objectIds() or objectValues(), but instead a higher-level filter function. A complimentary filter function would render the 'hidden' objects as a sequence as well.
__ZMI manage_main Now:______________________ ________________________ ===\===\===\===\======== <--- ZMI tabs % :::::::::::::::::::===
TP.NAME..... .SZ. ..LM.. []---------- ---- ------ []---------- ---- ------ []---------- ---- ------ []---------- ---- ------ []---------- ---- ------
[RN][CT][CP][DL][I/E][SA] <--- Buttons for checked
__ZMI With Translucency:___________________ ________________________ ===\===\===\===\======== <--- ZMI tabs % :::::::::::::::::::===
TP.NAME..... .SZ. ..LM.. []---------- ---- ------ []---------- ---- ------ []---------- ---- ------ []---------- ---- ------ []---------- ---- ------
[RN][CT][][][][][Hide] <--- New HideBtn ________________________ Hidden Items: [Select Item... [v] [Open][Unhide][ViewAll] <--- Buttons for doing things ^ with hidden | items | +-----------> ViewAll => pop-up new window ____________________________________________
This would be more visually convenient. I'm thinking of trying to monkey-patch OFS.Folder to just do this.
Of course, with these kind of modifications, for any given folder, there's no mandatate that anything need to be hidden at all. Thoughts?
Sean
sean.upton@uniontrib.com writes:
... and that is add "translucency" (items are there, but obscured from view) to the UI layer - that is, the ability to VISUALLY unclutter different users' views of objects in a folder via ZMI; views could be stored per user. Not sure that I would be happy with this...
I do not see the objects but they may interfere with my code (because acquisition returns these invisible objects and not my visible object higher above in the hierarchy). I fear lots of messages: Why do I get "AttributeError" when accessing my objects... Dieter
participants (4)
-
Dieter Maurer -
Eric Roby -
Leonardo Rochael Almeida -
sean.upton＠uniontrib.com