Re: Use of MidCOM toolbars

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

- --- On 14.02.06 14:50 (+0100) Tarjei Huse wrote:

>> 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.

What has the Breadcrumb line to do with toolbars?


>> 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.

For example?


>> 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 :-/

So what hinders you then just using the component context? It works with 
the new extended NAP breadcrumbs like a breeze.

You don't needc your own array/solution here, MidCOM core delivers you 
everything you need. Check the new breadcrumb functions how to do 
something like this.


>> 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.

What I'd like to have is one person in the MidCOM team (not equaling me) 
that'll go over all default styles and beautify them. I've never been an 
HTML expert...


>> As for a few technical notes: 1. Already at tigris is the support for 
>> POST forms
>
> at tigris == ? Is it implemented in CVS?

more like a bug filed ... ;-)


>> 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.

We need some API that controls these toolbars more elaboartely.

Essentially one big thing is that we need a flexible but "stylish" menu 
system if we want to bring much of the administrative stuff on-site.


>> 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?

I wouldn't do this, too much overhead for this level of "simplicity". The 
toolbars just have to auto-complete all defaults (much like dm2 
types/widgets or request switches do).


>> 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.

We need them generally, but for that the clean request context separation 
as outlined above. Remember that we want admin tools on-site, not in 
administrative requests. Thus it needs integration into MidCOMs new 
request architecture (where the request base class (not the admin one) is 
the current foundation).


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.2 (GNU/Linux)
Comment: Made with pgp4pine 1.76

iD8DBQFD8jW/JPh4Kn6d5FYRAsfKAJ9RGBy5hiH393Ug35c0/52bAiOEwgCeLKHV
Go6F3V0FirCFHps0AYmuLgI=
=Ss7L
-----END PGP SIGNATURE-----