[Phpmyadmin-devel] GSoC Removal of Frames : New Navigation

[Dieter Adriaenssens]

Hi Rouslan,

>> Thanks for explaining how the navigation is generated. It is clearer to me now.
>>
>> So when clicking on a table, an AJAX request is sent to the server to
>> generate HTML only for everything below (columns/indexes) that table,
>> which on it's turn is added by a JS script to the HTML defining the
>> current expanded tree in the navigation?
>> Or is the structure of the parent nodes generated as well?
>
> You are correct, the parent nodes need to be loaded into memory in the
> form of objects that inherit from the Node class. This way we can have a
> representation of a valid branch of the tree. Then only the active node
> and it's children are rendered into HTML (which is the most expensive
> operation).
>
>>> The improvements that I was talking about on the blog for this system
>>> would be partial refreshes and removal of preloading for children of
>>> table nodes.
>>>
>>> * Partial refreshes would be nice when we add/modify a table, for
>>> example. In this case, we only need to reload the database, not the
>>> whole tree, but we need to know which database to reload, so it would be
>>> necessary to pass some parameters to the refreshing function, which at
>>> the moment takes none.
>>
>> Where would this parameter come from? I guess it would come from the
>> process that renamed/removed/added a table/database/column.
>
> That's right. And it means that it's necessary to go every piece of JS
> code that interacts with the DBMS in a way that requires a refresh of
> some part of the navigation tree.

True, and you would still miss the changes to the database done
outside phpMyAdmin.


>>> * Preloading of indexes and columns for tables seemed like a good idea
>>> when I was first writing the code, but I didn't foresee that it would
>>> considerable slow down the refreshing of the tree, so it need to go.
>>
>> Can't you do a two stage refreshing? First the visible things (tables
>> of a database, when opening a database with only tables (no events,
>> ..)) and then in a second stage (when the tree is populated with
>> tables) the level below that (in this example columns and indexes for
>> every table).
>> This way the users sees the tree populated quite fast, because only
>> the tables are displayed. In the background, what's below the tables
>> is populated, resulting in a quick opening of a node when clicking on
>> a table, because what's below is already loaded.
>>
>> With database with many tables this might be a problem, so there
>> probably should be some kind of limit to the amount of preloading.
>
> I think that I would like to keep this simple for the moment. I might
> dedicate it more time at a later stage.

Agreed! Spending too much time on this could disrupt your GSoC schedule.
This is something that can be improved afterwards. ;)

Kind regards,

Dieter