Re: Use of MidCOM toolbars

Torben Nehmer wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> - --Henri Bergius wrote on 2006-02-14 09:37:
>> Please comment.
> 
> Before we are going about the technical implemetnation on this, I recommend that
> we focus a bit on the usability point of it first:
> 
>> I would propose the toolbars to be used in the following fashion:
>>
>> * `top`: actions user can take, including "Create article", "Report
>> as spam"
>>
>> * `bottom`: different views of the same object or listing, including
>> "Edit", "Delete", "Revisions"
> 
> Generally I agree for this distinction.
>> * `aegir_menu`: Global actions like "Help" and "Logout" (help should
>> be contextual help using the midcom.admin.help component)
> 
> I recommend naming this simply "admin", as it is not bound to aegir2 but to
> general administrative tasks; system administrators could have access to more
> advanced options like cron jobs etc. as well here. Also, logout should not be in
> that toolbar, but replace the login form on-site by default. IMHO at least.
+1. A lot of Aegir naming in Midcom should probably be renamed as the 
services provided are used by both Ais2 and Aegir2 now.


> What I'm wondering now is how the Site style authoer can render these toolbars.
> The old toolbar set was always interconnected, they were displayed immediately
> adjecant to each other.
> This is not always viable in a live site style I guess.
> Then, what's "aegir-location" for?
The breadcrumbline.

> Also I'd recommend renaming the "top" and "bottom" toolbar to something more
> meaningful, perhaps node/object.
The reason I didn't do that was I thought that those two distinctions 
are not always applicable.
> One (big) conceptual problem is this:
>> First you need to get it by:
>>      $toolbars = &midcom_helper_toolbars::get_instance();
> 
> That is the very best way to break your neck with dynamic_loaded stuff. Toolbars
> must be MidCOM request- not HTTP request-specific, otherwise you'll end up with
> tons of unneccessary icons in the toolbars. (And if-checking for being in
> request 0 everywhere you use toolbars makes no sense as it is error prone.)
Well, I guess the solution is to provide different objects based on 
different contexts. This is fairly doable by having an array indexed by 
context to deliver the static objects from.

But Aegir depends on getting this across the context :-/

> Instead, the toolbars have to go into the request context (custom data area),
> much like the NAP breadcrumb line extensions do. 
> That way, dl'ed stuff can also have its toolbars as much as they (or the style
> authors) deem neccessary.

> Essentially I think we should work out some illustrated style/UI guide that we
> adapt components to step-by-step. This should focus not on technical issues but
> on presentation and functionality. It is imperative, that various constellations
> are taken into account there, not just simple I-display-a-single-article cases.
> DL, stuff like OpenPSA or Aegir2 or complex homepage portals must be considered
> there as well as the basic, simple cases.
Good idea. Also I'd love to see some cleanup in the way we write the 
component styleelements.

> As for a few technical notes: 
> 1. Already at tigris is the support for POST forms
at tigris == ? Is it implemented in CVS?
> 2. We also need submenus, preferrably in some kind of dropdown style.
+1
> 3. There should be a way where the toolbars added to the system just are
> represented in their own dropdowns. (Well, essentially a real menu system would
> be great.)
Hmm, I think most of the work needed is in the Aegir css style.
> 4. The toolbars need some more default options, so that you don't have to
> specify every single option each time (like ENABLED=true or HELPTEXT=null)
Maybe keep every entry as simple objects instead of arrays?

> 5. When this all stabilizes, the toolbars will go into the request classes for
> easy access.
They are allready in the request classes - at least the admin one.


Tarjei
> Live long and Prosper!
> Torben Nehmer
> 
> - --
> Torben Nehmer, Guenzburg, Bavaria, Germany
> http://www.nathan-syntronics.de, mailto:[email protected]
> PGP Public Key: https://www.link-m.de/pgp/t.nehmer.asc
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.0 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFD8Z8iJPh4Kn6d5FYRAtcrAKDnh4FaXdl9zQGhtczGBHPBc5IjjgCgsrKC
> VKa0aaK3zKJu5vL7owdu4EI=
> =rAUQ
> -----END PGP SIGNATURE-----
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe-b5ZhpPVuLA+tlBvVaVFjCkB+6BGkLq7r@public.gmane.org
> For additional commands, e-mail: [email protected]
>