[Phpmyadmin-devel] 2.6.0-rc1

Garvin Hicking phpmyadmin at supergarv.de
Sat May 8 06:06:08 CEST 2004


(Repost as this didn't seem to get through the list?)

Hi Alexander!

>> Michal said, we need to apply our coding style to the patch
>> and most of all try to maintain some backwards-compatibility
>> for the 'old' look.
>
> What do you mean by "backwards-compatibility"?

I have not yet looked at the code of the redesign, only the live-demo. There are
lots and lots of icons, which I tend to like personally and for newebie users.
But as we all know from the several angry users after adding icons in first
place, I guess many users do not want to have those buttons, so they need to be
optional. And any other improvements, if making a definite difference in the UI
should be tweakable.

I think PMA benefits from long-term users who gotten used to it and who we might
annoy by forcing a new UI upon them.

>> I was already thinking of splitting up the configuration file
>> into a ".design"
>> php file where one could apply the many optical directives.
>> But doing so would mean huge work on the config_import utility...
>
> No, it won't. Trust me. :-)

So you're doing this? :)

Today I was thinking of how we could make preferences toggle-able for users
based on a DB-config. There are two approaches:

1. The "DB"-way.

You'd have a new panel inside PMA where you can see a list of all tweakable
settings and toggle them as you like. Those preferences get stored inside a new
PMA table. After PMA reads the config.inc.php it overrides any settings stored
in the table. Each user will get a cookie to identify him with the personal ID
stored in the table.

So a user could have one or even more "profiles" available by extending the ID
values (as an serialized array) inside his cookie. If he has more than one ID
cookie he can choose the profile he wants to have applied.

Once we have a GUI for adjusting options (maybe we could use dropdown/enum code
from our tbl_change already and just take care of a global PHP file defining
possible and default values plus short/long descriptions) this should be fairly
easy to implement. There could also be a way to share profiles which can be
marked as profile.

2. The "cookie way"

Basically same as above, but the config data is stored as a serialized array in
the cookie.

Benefits for this option: No need for setting up PMA tables, works out of the
box. Performance should be equal; what is saved on not querying the SQL-table is
lost on unserializing and submitting cookie data.

Drawback: If the cookie is lost, the profile is lost. No use accross different
browsers.

We could implement both ways and make the 2nd the default to give all users that
feature; we may also offer a "export my profile" setting which stores a profile
inside the file system of the webserver and reload it in a checkbox.

Choosing a different CSS layout could also be part of this new functionality,
but we'd than have to make the CSS file static and split up for left/right
frame. This would also make it easier for CSS-designers to work on non-PHP code.

Opinions? :-)

Regards,
Garvin.

-- 
Garvin Hicking   | Web-Entwickler | Make me happy:
www.supergarv.de | #ICQ 21392242  | http://wishes.garv.info/



-- 
Garvin Hicking   | Web-Entwickler | Make me happy:
www.supergarv.de | #ICQ 21392242  | http://wishes.garv.info/




More information about the Developers mailing list