phppgadmin-devel — For Developers Only

Re: [ppa-dev] Plugin Architecture - Action buttons

[Andreas 'a. S. <ad...@wa...>]

Hi,

Am 16.06.2011 15:15, schrieb Jehan-Guillaume (ioguix) de Rorthais:
> On 16/06/2011 15:05, Leonardo Sápiras wrote:
>>     Developers,
>>
>>     I have created a hook for action buttons in PPA
>> [http://wiki.postgresql.org/images/b/bd/Ppa_gsoc2011_screen.jpg]. Now
>> I will refactor the the pages that shows it.
>>
>>     [...]
>>
>>     My question is, about the second one, can I put the hook directly in
>> those places [https://gist.github.com/1029110]?
>
> I checked your list of file not using printTable.
> IMO you should refactor the code to use printTable for all of them but
> the display.php.
>
> I already tried to refactor display.php to use printTable in the past.
> It sounds feasible, but it would take way too much time. I am wondering
> if we need to hook a plugin action for each lines of a result set...my
> opinion is that we could probably ignore this one.
>
> Thoughts ?

My thought is: there should be only one such function.
Having two different functions or functionality in place leads to
future excuses to build more "workarounds".
Now is a good time to do it right, refactoring is already going on.

But: this is only my opinion, and I admit, I have no real idea how much 
work it is. Looked into the display.php but can't make an assumption
here.


Regards

-- 
				Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany - PostgreSQL Project

Re: [ppa-dev] Plugin Architecture - Action buttons

[Leonardo S. <l.s...@gm...>]

Jehan,

2011/6/16 Jehan-Guillaume (ioguix) de Rorthais <io...@fr...>:
> On 16/06/2011 15:15, Jehan-Guillaume (ioguix) de Rorthais wrote:
>>
>> On 16/06/2011 15:05, Leonardo Sápiras wrote:
>>>
>>>    Developers,
>>>
>>>    I have created a hook for action buttons in PPA
>>> [http://wiki.postgresql.org/images/b/bd/Ppa_gsoc2011_screen.jpg]. Now
>>> I will refactor the the pages that shows it.
>>>
>>>    [...]
>>>
>>>    My question is, about the second one, can I put the hook directly in
>>> those places [https://gist.github.com/1029110]?
>>
>> I checked your list of file not using printTable.
>> IMO you should refactor the code to use printTable for all of them but
>> the display.php.
>>
>> I already tried to refactor display.php to use printTable in the past.
>> It sounds feasible, but it would take way too much time. I am wondering
>> if we need to hook a plugin action for each lines of a result set...my
>> opinion is that we could probably ignore this one.
>>
>> Thoughts ?

What about to put the hook directly there?

> JFYI, my colleague sitting next to me has an opposite opinion :)

What is his opinion?

--
Atenciosamente
Leonardo Augusto Sápiras
[http://www.leonardosapiras.com.br]



2011/6/16 Jehan-Guillaume (ioguix) de Rorthais <io...@fr...>:
> On 16/06/2011 15:15, Jehan-Guillaume (ioguix) de Rorthais wrote:
>>
>> On 16/06/2011 15:05, Leonardo Sápiras wrote:
>>>
>>>    Developers,
>>>
>>>    I have created a hook for action buttons in PPA
>>> [http://wiki.postgresql.org/images/b/bd/Ppa_gsoc2011_screen.jpg]. Now
>>> I will refactor the the pages that shows it.
>>>
>>>    [...]
>>>
>>>    My question is, about the second one, can I put the hook directly in
>>> those places [https://gist.github.com/1029110]?
>>
>> I checked your list of file not using printTable.
>> IMO you should refactor the code to use printTable for all of them but
>> the display.php.
>>
>> I already tried to refactor display.php to use printTable in the past.
>> It sounds feasible, but it would take way too much time. I am wondering
>> if we need to hook a plugin action for each lines of a result set...my
>> opinion is that we could probably ignore this one.
>>
>> Thoughts ?
>
> JFYI, my colleague sitting next to me has an opposite opinion :)
>
>>>    My code can be found at [http://bit.ly/j4xg8N], and my changelog is:
>>>
>>> Action buttons hook:
>>> -Created hook in Misc->printTable with some refactor.
>>> -Created Example->add_plugin_actionbuttons.
>>> -Refactored Example->add_plugin_actionbuttons.
>>> -Registered hook for actionbuttons.
>>> -Created entry in Example's lang.
>>> -Updated call to printTable in all_db.php.
>>>
>>>   Thanks
>>>
>>> --
>>> Atenciosamente
>>> Leonardo Augusto Sápiras
>>> [http://www.leonardosapiras.com.br]
>>
>>
>>
>> ------------------------------------------------------------------------------
>> EditLive Enterprise is the world's most technically advanced content
>> authoring tool. Experience the power of Track Changes, Inline Image
>> Editing and ensure content is compliant with Accessibility Checking.
>> http://p.sf.net/sfu/ephox-dev2dev
>> _______________________________________________
>> phpPgAdmin-devel mailing list
>> php...@li...
>> https://lists.sourceforge.net/lists/listinfo/phppgadmin-devel
>
>

Re: [ppa-dev] Plugin Architecture - Action buttons

[Jehan-Guillaume (i. de R. <io...@fr...>]

On 16/06/2011 15:15, Jehan-Guillaume (ioguix) de Rorthais wrote:
> On 16/06/2011 15:05, Leonardo Sápiras wrote:
>>     Developers,
>>
>>     I have created a hook for action buttons in PPA
>> [http://wiki.postgresql.org/images/b/bd/Ppa_gsoc2011_screen.jpg]. Now
>> I will refactor the the pages that shows it.
>>
>>     [...]
>>
>>     My question is, about the second one, can I put the hook directly in
>> those places [https://gist.github.com/1029110]?
>
> I checked your list of file not using printTable.
> IMO you should refactor the code to use printTable for all of them but
> the display.php.
>
> I already tried to refactor display.php to use printTable in the past.
> It sounds feasible, but it would take way too much time. I am wondering
> if we need to hook a plugin action for each lines of a result set...my
> opinion is that we could probably ignore this one.
>
> Thoughts ?

JFYI, my colleague sitting next to me has an opposite opinion :)

>>     My code can be found at [http://bit.ly/j4xg8N], and my changelog is:
>>
>> Action buttons hook:
>> -Created hook in Misc->printTable with some refactor.
>> -Created Example->add_plugin_actionbuttons.
>> -Refactored Example->add_plugin_actionbuttons.
>> -Registered hook for actionbuttons.
>> -Created entry in Example's lang.
>> -Updated call to printTable in all_db.php.
>>
>>    Thanks
>>
>> --
>> Atenciosamente
>> Leonardo Augusto Sápiras
>> [http://www.leonardosapiras.com.br]
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> phpPgAdmin-devel mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phppgadmin-devel

Re: [ppa-dev] Plugin Architecture - Action buttons

[Jehan-Guillaume (i. de R. <io...@fr...>]

On 16/06/2011 15:05, Leonardo Sápiras wrote:
>    Developers,
>
>    I have created a hook for action buttons in PPA
> [http://wiki.postgresql.org/images/b/bd/Ppa_gsoc2011_screen.jpg]. Now
> I will refactor the the pages that shows it.
>
>    [...]
>
>    My question is, about the second one, can I put the hook directly in
> those places [https://gist.github.com/1029110]?

I checked your list of file not using printTable.
IMO you should refactor the code to use printTable for all of them but 
the display.php.

I already tried to refactor display.php to use printTable in the past. 
It sounds feasible, but it would take way too much time. I am wondering 
if we need to hook a plugin action for each lines of a result set...my 
opinion is that we could probably ignore this one.

Thoughts ?

>    My code can be found at [http://bit.ly/j4xg8N], and my changelog is:
>
> Action buttons hook:
> -Created hook in Misc->printTable with some refactor.
> -Created Example->add_plugin_actionbuttons.
> -Refactored Example->add_plugin_actionbuttons.
> -Registered hook for actionbuttons.
> -Created entry in Example's lang.
> -Updated call to printTable in all_db.php.
>
>   Thanks
>
> --
> Atenciosamente
> Leonardo Augusto Sápiras
> [http://www.leonardosapiras.com.br]

[ppa-dev] Plugin Architecture - Action buttons

[Leonardo S. <l.s...@gm...>]

  Developers,

  I have created a hook for action buttons in PPA
[http://wiki.postgresql.org/images/b/bd/Ppa_gsoc2011_screen.jpg]. Now
I will refactor the the pages that shows it.

  I identify these pages, but, I realize that we have two ways to show
the tables where these buttons are displayed:

  1) Using $misc->printTable: [https://gist.github.com/1029109]

  2) Using direct code (echo): [https://gist.github.com/1029110]


  For first way, I changed the Misc->printTable method, creating a
hook there and adding a new, an optional, parameter $place. This
parameter has the same logic from that I have added in
Misc->printNavLinks, that is passing the 'place' where the buttons
will be displayed.

  Example for all_db, function doDefault: $misc->printTable([.....],
'all_db-databases');


  My question is, about the second one, can I put the hook directly in
those places [https://gist.github.com/1029110]?


  My code can be found at [http://bit.ly/j4xg8N], and my changelog is:

Action buttons hook:
-Created hook in Misc->printTable with some refactor.
-Created Example->add_plugin_actionbuttons.
-Refactored Example->add_plugin_actionbuttons.
-Registered hook for actionbuttons.
-Created entry in Example's lang.
-Updated call to printTable in all_db.php.

 Thanks

--
Atenciosamente
Leonardo Augusto Sápiras
[http://www.leonardosapiras.com.br]

Re: [ppa-dev] Navigation links

[Leonardo S. <l.s...@gm...>]

Jehan,

[...]

>> We have a file sql.php that doesn't have actions to do, so, in these
>> cases I think we can do: $misc->printNavLinks($navlinks, 'sql');
>
> Mh, I would stick to the de-facto norm : $file-$action, even when no
> actions. So for this specific navlink section, I would label it 'sql-sql' or
> 'sql-query' or 'sql-form' or 'sql-default'. Maybe the last one is the best
> if you have some other 'default' in the code. If not, I would vote for
> 'sql-form'.

Ok, I think 'sql-form' better. Changed.

[...]

>> I have created some actions in Example, to show how we can create
>> navlinks hooks in all_db.php and display.php.
>
> great, I'll review this as soon as possible.

Thanks :)

--
Atenciosamente
Leonardo Augusto Sápiras
[http://www.leonardosapiras.com.br]



2011/6/14 Jehan-Guillaume (ioguix) de Rorthais <io...@fr...>:
> On 14/06/2011 14:23, Leonardo Sápiras wrote:
>>
>>   Jehan and Andreas,
>>
>> [...]
>>
>>>> But I am still wondering how we'll list existing names/section in the
>>>> doc...
>>>
>>> Yes the last one is simpler to do, but to document it is not. That's
>>> why I thougt using the file's name and function, with __FILE__ and
>>> __FUNCTION__. Maybe we could define a 'pattern' for this
>>> identification like 'navlinks_all_db_1'. What do you think?
>>>
>>> I didn't start working on the next step (action buttons) yet, but I
>>> think we will have to deal with something similar to it there.
>>
>> Discussing about it on IRC, we decided to use an identification for
>> the navlink, as below:
>>
>> For the script aggregates.php, function doProperties:
>> $misc->printNavLinks($navlinks, 'aggregates-properties');
>> For the script aggregates.php, function doDefault:
>> $misc->printNavLinks($navlinks, 'aggregates-aggregates');
>>
>> We have a file sql.php that doesn't have actions to do, so, in these
>> cases I think we can do: $misc->printNavLinks($navlinks, 'sql');
>
> Mh, I would stick to the de-facto norm : $file-$action, even when no
> actions. So for this specific navlink section, I would label it 'sql-sql' or
> 'sql-query' or 'sql-form' or 'sql-default'. Maybe the last one is the best
> if you have some other 'default' in the code. If not, I would vote for
> 'sql-form'.
>
>> I have created some actions in Example, to show how we can create
>> navlinks hooks in all_db.php and display.php.
>
> great, I'll review this as soon as possible.
>
>> The link for these commits is [http://bit.ly/kCub7z] and the changelog is:
>>
>> Navlinks refactor - 1
>>
>> -Refactored the files that have navlinks.
>> -Fixed wrong navlinks code.
>>
>> Navlinks refactor - 2
>>
>> -Refactored Misc->printNavLinks.
>> -Refactored Example->add_plugin_navlinks.
>> -Created Example->show_databases_extension.
>> -Created Example->show_display_extension.
>> -Created new entries in languages files of Example.
>>
>> Cheers
>>
>> --
>> Atenciosamente
>> Leonardo Augusto Sápiras
>> [http://www.leonardosapiras.com.br]
>>
>>
>>
>> 2011/6/11 Leonardo Sápiras<l.s...@gm...>:
>>>
>>> Jehan and Andreas,
>>>
>>>
>>>>>> $misc->printNavLinks($navlinks, 'doDefault', 'all_db.php')
>>>>>> or
>>>>>> $misc->printNavLinks($navlinks, __FUNCTION__, __FILE__)
>>>>>> or
>>>>>> $misc->printNavLinks($navlinks, __FUNCTION__, 'all_db')
>>>>>> or
>>>>>> $misc->printNavLinks($navlinks, 'databases_list_1')
>>>>>
>>>>> It occurs to me tonight that we might have more than one navlinks
>>>>> section in a single page, so other options are not possible.
>>>>> My vote goes to the last one. Just give a unique name to each navlinks
>>>>> section. Moreover, it's probably the simplest one.
>>>>
>>>> I agree, this looks like the simplest way to handle this problem.
>>>
>>> [Jehan's complemention]
>>>
>>>> But I am still wondering how we'll list existing names/section in the
>>>> doc...
>>>
>>> Yes the last one is simpler to do, but to document it is not. That's
>>> why I thougt using the file's name and function, with __FILE__ and
>>> __FUNCTION__. Maybe we could define a 'pattern' for this
>>> identification like 'navlinks_all_db_1'. What do you think?
>>>
>>> I didn't start working on the next step (action buttons) yet, but I
>>> think we will have to deal with something similar to it there.
>>>
>>>
>>> --
>>> Atenciosamente
>>> Leonardo Augusto Sápiras
>>> [http://www.leonardosapiras.com.br]
>>>
>>>
>>>
>>> 2011/6/11 Andreas 'ads' Scherbaum<ad...@wa...>:
>>>>
>>>> Hi,
>>>>
>>>> Am 10.06.2011 23:52, schrieb Jehan-Guillaume (ioguix) de Rorthais:
>>>>>
>>>>> On 10/06/2011 06:19, Leonardo Sápiras wrote:
>>>>>>
>>>>>>     Sorry guys, all_db.php is not a class, so:
>>>>>>
>>>>>> $misc->printNavLinks($navlinks, 'doDefault', 'all_db.php')
>>>>>> or
>>>>>> $misc->printNavLinks($navlinks, __FUNCTION__, __FILE__)
>>>>>> or
>>>>>> $misc->printNavLinks($navlinks, __FUNCTION__, 'all_db')
>>>>>> or
>>>>>> $misc->printNavLinks($navlinks, 'databases_list_1')
>>>>>
>>>>> It occurs to me tonight that we might have more than one navlinks
>>>>> section in a single page, so other options are not possible.
>>>>> My vote goes to the last one. Just give a unique name to each navlinks
>>>>> section. Moreover, it's probably the simplest one.
>>>>
>>>> I agree, this looks like the simplest way to handle this problem.
>>>>
>>>>
>>>> Regards,
>>>>
>>>> --
>>>>                                Andreas 'ads' Scherbaum
>>>> German PostgreSQL User Group
>>>> European PostgreSQL User Group - Board of Directors
>>>> Volunteer Regional Contact, Germany - PostgreSQL Project
>>>>
>

Re: [ppa-dev] Navigation links

[Jehan-Guillaume (i. de R. <io...@fr...>]

On 14/06/2011 14:23, Leonardo Sápiras wrote:
>    Jehan and Andreas,
>
> [...]
>
>>> But I am still wondering how we'll list existing names/section in the doc...
>>
>> Yes the last one is simpler to do, but to document it is not. That's
>> why I thougt using the file's name and function, with __FILE__ and
>> __FUNCTION__. Maybe we could define a 'pattern' for this
>> identification like 'navlinks_all_db_1'. What do you think?
>>
>> I didn't start working on the next step (action buttons) yet, but I
>> think we will have to deal with something similar to it there.
>
> Discussing about it on IRC, we decided to use an identification for
> the navlink, as below:
>
> For the script aggregates.php, function doProperties:
> $misc->printNavLinks($navlinks, 'aggregates-properties');
> For the script aggregates.php, function doDefault:
> $misc->printNavLinks($navlinks, 'aggregates-aggregates');
>
> We have a file sql.php that doesn't have actions to do, so, in these
> cases I think we can do: $misc->printNavLinks($navlinks, 'sql');

Mh, I would stick to the de-facto norm : $file-$action, even when no 
actions. So for this specific navlink section, I would label it 
'sql-sql' or 'sql-query' or 'sql-form' or 'sql-default'. Maybe the last 
one is the best if you have some other 'default' in the code. If not, I 
would vote for 'sql-form'.

> I have created some actions in Example, to show how we can create
> navlinks hooks in all_db.php and display.php.

great, I'll review this as soon as possible.

> The link for these commits is [http://bit.ly/kCub7z] and the changelog is:
>
> Navlinks refactor - 1
>
> -Refactored the files that have navlinks.
> -Fixed wrong navlinks code.
>
> Navlinks refactor - 2
>
> -Refactored Misc->printNavLinks.
> -Refactored Example->add_plugin_navlinks.
> -Created Example->show_databases_extension.
> -Created Example->show_display_extension.
> -Created new entries in languages files of Example.
>
> Cheers
>
> --
> Atenciosamente
> Leonardo Augusto Sápiras
> [http://www.leonardosapiras.com.br]
>
>
>
> 2011/6/11 Leonardo Sápiras<l.s...@gm...>:
>> Jehan and Andreas,
>>
>>
>>>>> $misc->printNavLinks($navlinks, 'doDefault', 'all_db.php')
>>>>> or
>>>>> $misc->printNavLinks($navlinks, __FUNCTION__, __FILE__)
>>>>> or
>>>>> $misc->printNavLinks($navlinks, __FUNCTION__, 'all_db')
>>>>> or
>>>>> $misc->printNavLinks($navlinks, 'databases_list_1')
>>>>
>>>> It occurs to me tonight that we might have more than one navlinks
>>>> section in a single page, so other options are not possible.
>>>> My vote goes to the last one. Just give a unique name to each navlinks
>>>> section. Moreover, it's probably the simplest one.
>>>
>>> I agree, this looks like the simplest way to handle this problem.
>>
>> [Jehan's complemention]
>>
>>> But I am still wondering how we'll list existing names/section in the doc...
>>
>> Yes the last one is simpler to do, but to document it is not. That's
>> why I thougt using the file's name and function, with __FILE__ and
>> __FUNCTION__. Maybe we could define a 'pattern' for this
>> identification like 'navlinks_all_db_1'. What do you think?
>>
>> I didn't start working on the next step (action buttons) yet, but I
>> think we will have to deal with something similar to it there.
>>
>>
>> --
>> Atenciosamente
>> Leonardo Augusto Sápiras
>> [http://www.leonardosapiras.com.br]
>>
>>
>>
>> 2011/6/11 Andreas 'ads' Scherbaum<ad...@wa...>:
>>>
>>> Hi,
>>>
>>> Am 10.06.2011 23:52, schrieb Jehan-Guillaume (ioguix) de Rorthais:
>>>> On 10/06/2011 06:19, Leonardo Sápiras wrote:
>>>>>      Sorry guys, all_db.php is not a class, so:
>>>>>
>>>>> $misc->printNavLinks($navlinks, 'doDefault', 'all_db.php')
>>>>> or
>>>>> $misc->printNavLinks($navlinks, __FUNCTION__, __FILE__)
>>>>> or
>>>>> $misc->printNavLinks($navlinks, __FUNCTION__, 'all_db')
>>>>> or
>>>>> $misc->printNavLinks($navlinks, 'databases_list_1')
>>>>
>>>> It occurs to me tonight that we might have more than one navlinks
>>>> section in a single page, so other options are not possible.
>>>> My vote goes to the last one. Just give a unique name to each navlinks
>>>> section. Moreover, it's probably the simplest one.
>>>
>>> I agree, this looks like the simplest way to handle this problem.
>>>
>>>
>>> Regards,
>>>
>>> --
>>>                                 Andreas 'ads' Scherbaum
>>> German PostgreSQL User Group
>>> European PostgreSQL User Group - Board of Directors
>>> Volunteer Regional Contact, Germany - PostgreSQL Project
>>>

Re: [ppa-dev] Navigation links

[Leonardo S. <l.s...@gm...>]

  Jehan and Andreas,

[...]

>>But I am still wondering how we'll list existing names/section in the doc...
>
> Yes the last one is simpler to do, but to document it is not. That's
> why I thougt using the file's name and function, with __FILE__ and
> __FUNCTION__. Maybe we could define a 'pattern' for this
> identification like 'navlinks_all_db_1'. What do you think?
>
> I didn't start working on the next step (action buttons) yet, but I
> think we will have to deal with something similar to it there.

Discussing about it on IRC, we decided to use an identification for
the navlink, as below:

For the script aggregates.php, function doProperties:
$misc->printNavLinks($navlinks, 'aggregates-properties');
For the script aggregates.php, function doDefault:
$misc->printNavLinks($navlinks, 'aggregates-aggregates');

We have a file sql.php that doesn't have actions to do, so, in these
cases I think we can do: $misc->printNavLinks($navlinks, 'sql');

I have created some actions in Example, to show how we can create
navlinks hooks in all_db.php and display.php.


The link for these commits is [http://bit.ly/kCub7z] and the changelog is:

Navlinks refactor - 1

-Refactored the files that have navlinks.
-Fixed wrong navlinks code.

Navlinks refactor - 2

-Refactored Misc->printNavLinks.
-Refactored Example->add_plugin_navlinks.
-Created Example->show_databases_extension.
-Created Example->show_display_extension.
-Created new entries in languages files of Example.

Cheers

--
Atenciosamente
Leonardo Augusto Sápiras
[http://www.leonardosapiras.com.br]



2011/6/11 Leonardo Sápiras <l.s...@gm...>:
> Jehan and Andreas,
>
>
>>>> $misc->printNavLinks($navlinks, 'doDefault', 'all_db.php')
>>>> or
>>>> $misc->printNavLinks($navlinks, __FUNCTION__, __FILE__)
>>>> or
>>>> $misc->printNavLinks($navlinks, __FUNCTION__, 'all_db')
>>>> or
>>>> $misc->printNavLinks($navlinks, 'databases_list_1')
>>>
>>> It occurs to me tonight that we might have more than one navlinks
>>> section in a single page, so other options are not possible.
>>> My vote goes to the last one. Just give a unique name to each navlinks
>>> section. Moreover, it's probably the simplest one.
>>
>> I agree, this looks like the simplest way to handle this problem.
>
> [Jehan's complemention]
>
>>But I am still wondering how we'll list existing names/section in the doc...
>
> Yes the last one is simpler to do, but to document it is not. That's
> why I thougt using the file's name and function, with __FILE__ and
> __FUNCTION__. Maybe we could define a 'pattern' for this
> identification like 'navlinks_all_db_1'. What do you think?
>
> I didn't start working on the next step (action buttons) yet, but I
> think we will have to deal with something similar to it there.
>
>
> --
> Atenciosamente
> Leonardo Augusto Sápiras
> [http://www.leonardosapiras.com.br]
>
>
>
> 2011/6/11 Andreas 'ads' Scherbaum <ad...@wa...>:
>>
>> Hi,
>>
>> Am 10.06.2011 23:52, schrieb Jehan-Guillaume (ioguix) de Rorthais:
>>> On 10/06/2011 06:19, Leonardo Sápiras wrote:
>>>>     Sorry guys, all_db.php is not a class, so:
>>>>
>>>> $misc->printNavLinks($navlinks, 'doDefault', 'all_db.php')
>>>> or
>>>> $misc->printNavLinks($navlinks, __FUNCTION__, __FILE__)
>>>> or
>>>> $misc->printNavLinks($navlinks, __FUNCTION__, 'all_db')
>>>> or
>>>> $misc->printNavLinks($navlinks, 'databases_list_1')
>>>
>>> It occurs to me tonight that we might have more than one navlinks
>>> section in a single page, so other options are not possible.
>>> My vote goes to the last one. Just give a unique name to each navlinks
>>> section. Moreover, it's probably the simplest one.
>>
>> I agree, this looks like the simplest way to handle this problem.
>>
>>
>> Regards,
>>
>> --
>>                                Andreas 'ads' Scherbaum
>> German PostgreSQL User Group
>> European PostgreSQL User Group - Board of Directors
>> Volunteer Regional Contact, Germany - PostgreSQL Project
>>
>>
>> ------------------------------------------------------------------------------
>> EditLive Enterprise is the world's most technically advanced content
>> authoring tool. Experience the power of Track Changes, Inline Image
>> Editing and ensure content is compliant with Accessibility Checking.
>> http://p.sf.net/sfu/ephox-dev2dev
>> _______________________________________________
>> phpPgAdmin-devel mailing list
>> php...@li...
>> https://lists.sourceforge.net/lists/listinfo/phppgadmin-devel
>>
>

Re: [ppa-dev] New Plugin Architecture - review 5

[Leonardo S. <l.s...@gm...>]

Jehan,

>> [...]
> Well, this problem was about calling plugin's php script directly. As we
> decided to use plugin.php in PPA root to execute plugin's actions, we don't
> have this problem anymore.

Ok


>>> #5
>>> plugins/Example/lang/*
>>> You don't need the following vars in translation files:
>>>        // Language and character set
>>>        $lang['applang'] = 'English';
>>>        $lang['appcharset'] = 'ISO-8859-1';
>>>        $lang['applocale'] = 'en_US';
>>>        $lang['appdbencoding'] = 'LATIN1';
>>>        $lang['applangdir'] = 'ltr';
>>
>> Actually, I need just the appcharset. If I don't have it, the lang2xml
>> will return for portuguese-br:
>>
>> recode: Entrada inválida no passo CHAR..ISO-10646-UCS-2
>>
>> translation: "Entry invalid in pass...."
>
> Oh, yeah, I forgot about that because of my WIP about PPA in UTF-8 only
> where I removed all this recoding stuff.
>
> So you are right, keep the appcharset.
>
>> Do you know why it happens?
>
> Because my lang2xml script rely on it to recode the file from the encoding
> this variable provide.

Done


>>> #6
>>> I don't like the icons you choose :-P
>>> if you really want to use some fancy icons, have a look to pgadmin's
>>> icons
>>> where we already take our icons from. They have something about plugins.
>>> See:
>>>
>>>
>>> http://git.postgresql.org/gitweb?p=pgadmin3.git;a=tree;f=pgadmin/include/images;h=42ec76234bd2b8aa07282b84885dfeee40aa607f;hb=refs/heads/master
>>>
>>> and particularly:
>>>
>>>
>>> http://git.postgresql.org/gitweb?p=pgadmin3.git;a=blob;f=pgadmin/include/images/plugins.png;h=88c15dc89d1f957fe90f5b018af9ad1be62bdabe;hb=refs/heads/master
>>
>> ok, I removed the pluginsExample/Hook.png. And I copy the pgAdmin
>> Plugins.png to images/default/
>>
>> I didn't drop the levels images, because them should be used as
>> example. Sorry, I am not designer, so can I keep those Example images
>> until we find better?
>
> That's perfectly fine. I just didn't like this 'J' icon I suspect was coming
> from your editor icons ;)

heheh :)

[...]

> Don't wait for my review and keep coding as I suspect we are on the edge of
> being late. I'll review as soon as possible.

Ok :)


--
Atenciosamente
Leonardo Augusto Sápiras
[http://www.leonardosapiras.com.br]

Re: [ppa-dev] New Plugin Architecture - review 5

[Jehan-Guillaume (i. de R. <io...@fr...>]

On 13/06/2011 18:47, Leonardo Sápiras wrote:
> Jehan,
>
> [...]
>
>> #4
>> ./libraries/lib.inc.php:26
>> I'm not very happy with this. What about removing it ? you just have to use
>> this in the plugins:
>>
>>   require_once('classes/Plugin.php');
>
> Ok, done. But it could be use in the future to fix those problems
> including the lib.inc.php.

Well, this problem was about calling plugin's php script directly. As we 
decided to use plugin.php in PPA root to execute plugin's actions, we 
don't have this problem anymore.

>> #5
>> plugins/Example/lang/*
>> You don't need the following vars in translation files:
>>         // Language and character set
>>         $lang['applang'] = 'English';
>>         $lang['appcharset'] = 'ISO-8859-1';
>>         $lang['applocale'] = 'en_US';
>>         $lang['appdbencoding'] = 'LATIN1';
>>         $lang['applangdir'] = 'ltr';
>
> Actually, I need just the appcharset. If I don't have it, the lang2xml
> will return for portuguese-br:
>
> recode: Entrada inválida no passo CHAR..ISO-10646-UCS-2
>
> translation: "Entry invalid in pass...."

Oh, yeah, I forgot about that because of my WIP about PPA in UTF-8 only 
where I removed all this recoding stuff.

So you are right, keep the appcharset.

> Do you know why it happens?

Because my lang2xml script rely on it to recode the file from the 
encoding this variable provide.

>> #6
>> I don't like the icons you choose :-P
>> if you really want to use some fancy icons, have a look to pgadmin's icons
>> where we already take our icons from. They have something about plugins.
>> See:
>>
>> http://git.postgresql.org/gitweb?p=pgadmin3.git;a=tree;f=pgadmin/include/images;h=42ec76234bd2b8aa07282b84885dfeee40aa607f;hb=refs/heads/master
>>
>> and particularly:
>>
>> http://git.postgresql.org/gitweb?p=pgadmin3.git;a=blob;f=pgadmin/include/images/plugins.png;h=88c15dc89d1f957fe90f5b018af9ad1be62bdabe;hb=refs/heads/master
>
> ok, I removed the pluginsExample/Hook.png. And I copy the pgAdmin
> Plugins.png to images/default/
>
> I didn't drop the levels images, because them should be used as
> example. Sorry, I am not designer, so can I keep those Example images
> until we find better?

That's perfectly fine. I just didn't like this 'J' icon I suspect was 
coming from your editor icons ;)

> The changes can be found at: [http://bit.ly/kQdM4H]
>
> Thanks

Don't wait for my review and keep coding as I suspect we are on the edge 
of being late. I'll review as soon as possible.

Thank you !
> --
> Atenciosamente
> Leonardo Augusto Sápiras
> [http://www.leonardosapiras.com.br]

Re: [ppa-dev] New Plugin Architecture - review 5

[Leonardo S. <l.s...@gm...>]

Jehan,


> Yet another one, but not a large one :)
>
> I didn't really look closely at the refactoring about all the navlinks in
> related files though.

Ok


> #1
> in classes/Plugin.php:__construct()
> You don't need to have a $plugin_directory parameter to the constructor:
>
>  function __construct($language) {
>    // Set the plugin's language
>    $plugin_directory = "plugins/". $this->get_name();
>    require_once("{$plugin_directory}/lang/recoded/english.php");
>    if (file_exists("{$plugin_directory}/lang/recoded/{$language}.php")) {
>      include_once("{$plugin_directory}/lang/recoded/{$language}.php");
>    }
>    $this->lang = $plugin_lang;
>  }

Done.


> #2
> in classes/Plugin.php:get_name()
> This function shouldn't be abstract and be implemented here, as it will be
> the same for all plugins

Yeah, done.

> #3
> in classes/PluginManager.php:13
> - private $avaliable_hooks
> + private $available_hooks

ops, fixed :)


> #4
> ./libraries/lib.inc.php:26
> I'm not very happy with this. What about removing it ? you just have to use
> this in the plugins:
>
>  require_once('classes/Plugin.php');

Ok, done. But it could be use in the future to fix those problems
including the lib.inc.php.

> #5
> plugins/Example/lang/*
> You don't need the following vars in translation files:
>        // Language and character set
>        $lang['applang'] = 'English';
>        $lang['appcharset'] = 'ISO-8859-1';
>        $lang['applocale'] = 'en_US';
>        $lang['appdbencoding'] = 'LATIN1';
>        $lang['applangdir'] = 'ltr';

Actually, I need just the appcharset. If I don't have it, the lang2xml
will return for portuguese-br:

recode: Entrada inválida no passo CHAR..ISO-10646-UCS-2

translation: "Entry invalid in pass...."

Do you know why it happens?


> #6
> I don't like the icons you choose :-P
> if you really want to use some fancy icons, have a look to pgadmin's icons
> where we already take our icons from. They have something about plugins.
> See:
>
> http://git.postgresql.org/gitweb?p=pgadmin3.git;a=tree;f=pgadmin/include/images;h=42ec76234bd2b8aa07282b84885dfeee40aa607f;hb=refs/heads/master
>
> and particularly:
>
> http://git.postgresql.org/gitweb?p=pgadmin3.git;a=blob;f=pgadmin/include/images/plugins.png;h=88c15dc89d1f957fe90f5b018af9ad1be62bdabe;hb=refs/heads/master

ok, I removed the pluginsExample/Hook.png. And I copy the pgAdmin
Plugins.png to images/default/

I didn't drop the levels images, because them should be used as
example. Sorry, I am not designer, so can I keep those Example images
until we find better?


The changes can be found at: [http://bit.ly/kQdM4H]

Thanks

--
Atenciosamente
Leonardo Augusto Sápiras
[http://www.leonardosapiras.com.br]

Re: [ppa-dev] Navigation links

[Leonardo S. <l.s...@gm...>]

Jehan and Andreas,


>>> $misc->printNavLinks($navlinks, 'doDefault', 'all_db.php')
>>> or
>>> $misc->printNavLinks($navlinks, __FUNCTION__, __FILE__)
>>> or
>>> $misc->printNavLinks($navlinks, __FUNCTION__, 'all_db')
>>> or
>>> $misc->printNavLinks($navlinks, 'databases_list_1')
>>
>> It occurs to me tonight that we might have more than one navlinks
>> section in a single page, so other options are not possible.
>> My vote goes to the last one. Just give a unique name to each navlinks
>> section. Moreover, it's probably the simplest one.
>
> I agree, this looks like the simplest way to handle this problem.

[Jehan's complemention]

>But I am still wondering how we'll list existing names/section in the doc...

Yes the last one is simpler to do, but to document it is not. That's
why I thougt using the file's name and function, with __FILE__ and
__FUNCTION__. Maybe we could define a 'pattern' for this
identification like 'navlinks_all_db_1'. What do you think?

I didn't start working on the next step (action buttons) yet, but I
think we will have to deal with something similar to it there.


--
Atenciosamente
Leonardo Augusto Sápiras
[http://www.leonardosapiras.com.br]



2011/6/11 Andreas 'ads' Scherbaum <ad...@wa...>:
>
> Hi,
>
> Am 10.06.2011 23:52, schrieb Jehan-Guillaume (ioguix) de Rorthais:
>> On 10/06/2011 06:19, Leonardo Sápiras wrote:
>>>     Sorry guys, all_db.php is not a class, so:
>>>
>>> $misc->printNavLinks($navlinks, 'doDefault', 'all_db.php')
>>> or
>>> $misc->printNavLinks($navlinks, __FUNCTION__, __FILE__)
>>> or
>>> $misc->printNavLinks($navlinks, __FUNCTION__, 'all_db')
>>> or
>>> $misc->printNavLinks($navlinks, 'databases_list_1')
>>
>> It occurs to me tonight that we might have more than one navlinks
>> section in a single page, so other options are not possible.
>> My vote goes to the last one. Just give a unique name to each navlinks
>> section. Moreover, it's probably the simplest one.
>
> I agree, this looks like the simplest way to handle this problem.
>
>
> Regards,
>
> --
>                                Andreas 'ads' Scherbaum
> German PostgreSQL User Group
> European PostgreSQL User Group - Board of Directors
> Volunteer Regional Contact, Germany - PostgreSQL Project
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> phpPgAdmin-devel mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phppgadmin-devel
>

Re: [ppa-dev] New plugin architecture - review 4

[Leonardo S. <l.s...@gm...>]

 Jehan,

>>
>> It's true, but, we have some methods in Example, like:
>>
>> get_hooks
>> add_plugin_toplinks
>> add_plugin_tabs
>> add_plugin_trail
>>
>> that cannot be private, and cannot be used as actions.
>
> You are right

:)

>
>>> #8
>>> I wonder if we shouldn't create a Plugin class that all other plugins
>>> should
>>> inherit from ? Or maybe an abstract class ?
>>> It might be useful to share some common methods (get_name() as instance)
>>> and
>>> putting some common things in its constructor (is it's not an abstract
>>> one)
>>> like loading plugin translation. So a basic plugin constructor would
>>> become
>>> something like:
>>>
>>>        function __construct($language) {
>>>                parent::__construct($language);
>>>        }
>
> mh, I thought we couldn't have a constructor in an abstract class...It
> appear I was wrong or php is too much laxist about that. Anyway that's fine
> like that. (but see my next review soon ;))

Ok.

>> This commit link is [http://bit.ly/mtqK4A] and changelog is:
>>
>> -Move some code from plugin.php to Example's actions.
>> -Dropped unuseless comments.
>> -Replaced some comments.
>> -Fixed code in Misc->getNavTabs.
>> -Created an abstract class to plugin's inherit from.
>> -Refactored Example's methods to use the parent class.
>> -Created a constant to have the ppa's class dir.
>
> Don't forget about splitting your commit in small parts ;)

 Yes, thanks :)

--
Atenciosamente
Leonardo Augusto Sápiras
[http://www.leonardosapiras.com.br]

Re: [ppa-dev] Navigation links

[Andreas 'a. S. <ad...@wa...>]

Hi,

Am 10.06.2011 23:52, schrieb Jehan-Guillaume (ioguix) de Rorthais:
> On 10/06/2011 06:19, Leonardo Sápiras wrote:
>>     Sorry guys, all_db.php is not a class, so:
>>
>> $misc->printNavLinks($navlinks, 'doDefault', 'all_db.php')
>> or
>> $misc->printNavLinks($navlinks, __FUNCTION__, __FILE__)
>> or
>> $misc->printNavLinks($navlinks, __FUNCTION__, 'all_db')
>> or
>> $misc->printNavLinks($navlinks, 'databases_list_1')
>
> It occurs to me tonight that we might have more than one navlinks
> section in a single page, so other options are not possible.
> My vote goes to the last one. Just give a unique name to each navlinks
> section. Moreover, it's probably the simplest one.

I agree, this looks like the simplest way to handle this problem.


Regards,

-- 
				Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany - PostgreSQL Project

[ppa-dev] New Plugin Architecture - review 5

[Jehan-Guillaume (i. de R. <io...@fr...>]

Yet another one, but not a large one :)

I didn't really look closely at the refactoring about all the navlinks 
in related files though.

#1
in classes/Plugin.php:__construct()
You don't need to have a $plugin_directory parameter to the constructor:

   function __construct($language) {
     // Set the plugin's language
     $plugin_directory = "plugins/". $this->get_name();
     require_once("{$plugin_directory}/lang/recoded/english.php");
     if (file_exists("{$plugin_directory}/lang/recoded/{$language}.php")) {
       include_once("{$plugin_directory}/lang/recoded/{$language}.php");
     }
     $this->lang = $plugin_lang;
   }

#2
in classes/Plugin.php:get_name()
This function shouldn't be abstract and be implemented here, as it will 
be the same for all plugins

#3
in classes/PluginManager.php:13
- private $avaliable_hooks
+ private $available_hooks

#4
./libraries/lib.inc.php:26
I'm not very happy with this. What about removing it ? you just have to 
use this in the plugins:

   require_once('classes/Plugin.php');

#5
plugins/Example/lang/*
You don't need the following vars in translation files:
	// Language and character set
	$lang['applang'] = 'English';
	$lang['appcharset'] = 'ISO-8859-1';
	$lang['applocale'] = 'en_US';
	$lang['appdbencoding'] = 'LATIN1';
	$lang['applangdir'] = 'ltr';

#6
I don't like the icons you choose :-P
if you really want to use some fancy icons, have a look to pgadmin's 
icons where we already take our icons from. They have something about 
plugins. See:

http://git.postgresql.org/gitweb?p=pgadmin3.git;a=tree;f=pgadmin/include/images;h=42ec76234bd2b8aa07282b84885dfeee40aa607f;hb=refs/heads/master

and particularly:

http://git.postgresql.org/gitweb?p=pgadmin3.git;a=blob;f=pgadmin/include/images/plugins.png;h=88c15dc89d1f957fe90f5b018af9ad1be62bdabe;hb=refs/heads/master

Cheers !

Re: [ppa-dev] Navigation links

[Jehan-Guillaume (i. de R. <io...@fr...>]

On 10/06/2011 23:52, Jehan-Guillaume (ioguix) de Rorthais wrote:
> On 10/06/2011 06:19, Leonardo Sápiras wrote:
>>     Sorry guys, all_db.php is not a class, so:
>>
>> $misc->printNavLinks($navlinks, 'doDefault', 'all_db.php')
>> or
>> $misc->printNavLinks($navlinks, __FUNCTION__, __FILE__)
>> or
>> $misc->printNavLinks($navlinks, __FUNCTION__, 'all_db')
>> or
>> $misc->printNavLinks($navlinks, 'databases_list_1')
>
> It occurs to me tonight that we might have more than one navlinks
> section in a single page, so other options are not possible.
> My vote goes to the last one. Just give a unique name to each navlinks
> section. Moreover, it's probably the simplest one.

But I am still wondering how we'll list existing names/section in the doc...

>> --
>> Atenciosamente
>> Leonardo Augusto Sápiras
>> [http://www.leonardosapiras.com.br]
>>
>>
>>
>> 2011/6/10 Leonardo Sápiras<l.s...@gm...>:
>>>    Hi devs,
>>>
>>>    Following the tasks in GSoC 2011, the next step is to integrate the
>>> plugin architecture with navigation links. I have verified that
>>> navigation links are spread everywhere in PPA code, and don't have a
>>> common function to be displayed, and they have been shown with
>>> 'echo's.
>>>
>>>    To be able creating hooks for this, we need to have a place where
>>> this links are printed.  So, I created a method in Misc, called
>>> printNavLinks, that will receive an array with the links, and
>>> atributtes as well, and will show these links. I also refactored the
>>> ppa code, to adapt it.
>>>
>>>    But now I have found a small problem. If we create a hook to
>>> navlinks, and a plugin need to show some link, this plugin's navlink
>>> will be displayed everywhere we have the navigation links. To fix it,
>>> we need to find some way to identify where the plugin 'desire' to show
>>> his navlink.
>>>
>>>    Jehan suggested me on IRC use $_REQUEST['subject'] and
>>> $_REQUEST['action'] to do it. But now I realize that, there are some
>>> places that don't have actions, and have the same subject. An example
>>> is the screens that list the databases (all_db.php) and the roles
>>> (roles.php). These pages don't have actions in their requests, and
>>> have the same subject, that is 'server'. Usually, when a request
>>> doen't have an action, our php script use a 'doDefault' to display
>>> something. In this case both all_db.php's doDefault and roles.php's
>>> doDefault will show the same plugin's navlink.
>>>
>>>    An alternative way is to pass more two parameters to the new method
>>> Misc->printNavLinks(): the file (file.php) and the place inside the
>>> code where the navlink is being created, maybe the function
>>> (doDefault, doTree, doSomething...).
>>>
>>> Example: for databases list we could do something like that:
>>>
>>> $misc->printNavLinks($navlinks, 'doDefault', 'all_db.php')
>>> or
>>> $misc->printNavLinks($navlinks, __METHOD__, __FILE__)
>>> or
>>> $misc->printNavLinks($navlinks, __METHOD__, 'all_db')
>>> or
>>> $misc->printNavLinks($navlinks, 'databases_list_1')
>>>
>>>    So, the plugin's developer can check where his navlink will be displayed.
>>>
>>> A code with more details can be found at [https://gist.github.com/1017912].
>>>
>>> Does anybody have more suggestions about it?
>>>
>>>
>>> The commits with these changes can be found at [http://bit.ly/my5ONa]
>>> and the changelog is:
>>>
>>> -Removed useless condition
>>> -Fixed problem in toplink
>>> -Created method printNavLink.
>>> -Navigation links - refactor:
>>>
>>> -tables.php.
>>> -schemas.php
>>> -domains.php
>>> -tables.php
>>> -tablespaces.php
>>> -operators.php
>>> -sequences.php
>>> -privileges.php
>>> -history.php
>>> -display.php
>>> -colproperties.php
>>> -rules.php
>>> -types.php
>>> -roles.php
>>> -groups.php
>>> -users.php
>>> -reports.php
>>> -aggregates.php
>>> -functions.php
>>> -views.php
>>> -all_db.php
>>> -triggers.php
>>> -constraints.php
>>> -indexes.php
>>> -viewproperties.php
>>> -fulltext.php
>>> -servers.php
>>> -tblproperties.php
>>> -sql.php
>>>
>>>
>>>    Thanks
>>>
>>> --
>>> Atenciosamente
>>> Leonardo Augusto Sápiras
>>> [http://www.leonardosapiras.com.br]
>>>
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> phpPgAdmin-devel mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phppgadmin-devel

Re: [ppa-dev] Navigation links

[Jehan-Guillaume (i. de R. <io...@fr...>]

On 10/06/2011 06:19, Leonardo Sápiras wrote:
>    Sorry guys, all_db.php is not a class, so:
>
> $misc->printNavLinks($navlinks, 'doDefault', 'all_db.php')
> or
> $misc->printNavLinks($navlinks, __FUNCTION__, __FILE__)
> or
> $misc->printNavLinks($navlinks, __FUNCTION__, 'all_db')
> or
> $misc->printNavLinks($navlinks, 'databases_list_1')

It occurs to me tonight that we might have more than one navlinks 
section in a single page, so other options are not possible.
My vote goes to the last one. Just give a unique name to each navlinks 
section. Moreover, it's probably the simplest one.

> --
> Atenciosamente
> Leonardo Augusto Sápiras
> [http://www.leonardosapiras.com.br]
>
>
>
> 2011/6/10 Leonardo Sápiras<l.s...@gm...>:
>>   Hi devs,
>>
>>   Following the tasks in GSoC 2011, the next step is to integrate the
>> plugin architecture with navigation links. I have verified that
>> navigation links are spread everywhere in PPA code, and don't have a
>> common function to be displayed, and they have been shown with
>> 'echo's.
>>
>>   To be able creating hooks for this, we need to have a place where
>> this links are printed.  So, I created a method in Misc, called
>> printNavLinks, that will receive an array with the links, and
>> atributtes as well, and will show these links. I also refactored the
>> ppa code, to adapt it.
>>
>>   But now I have found a small problem. If we create a hook to
>> navlinks, and a plugin need to show some link, this plugin's navlink
>> will be displayed everywhere we have the navigation links. To fix it,
>> we need to find some way to identify where the plugin 'desire' to show
>> his navlink.
>>
>>   Jehan suggested me on IRC use $_REQUEST['subject'] and
>> $_REQUEST['action'] to do it. But now I realize that, there are some
>> places that don't have actions, and have the same subject. An example
>> is the screens that list the databases (all_db.php) and the roles
>> (roles.php). These pages don't have actions in their requests, and
>> have the same subject, that is 'server'. Usually, when a request
>> doen't have an action, our php script use a 'doDefault' to display
>> something. In this case both all_db.php's doDefault and roles.php's
>> doDefault will show the same plugin's navlink.
>>
>>   An alternative way is to pass more two parameters to the new method
>> Misc->printNavLinks(): the file (file.php) and the place inside the
>> code where the navlink is being created, maybe the function
>> (doDefault, doTree, doSomething...).
>>
>> Example: for databases list we could do something like that:
>>
>> $misc->printNavLinks($navlinks, 'doDefault', 'all_db.php')
>> or
>> $misc->printNavLinks($navlinks, __METHOD__, __FILE__)
>> or
>> $misc->printNavLinks($navlinks, __METHOD__, 'all_db')
>> or
>> $misc->printNavLinks($navlinks, 'databases_list_1')
>>
>>   So, the plugin's developer can check where his navlink will be displayed.
>>
>> A code with more details can be found at [https://gist.github.com/1017912].
>>
>> Does anybody have more suggestions about it?
>>
>>
>> The commits with these changes can be found at [http://bit.ly/my5ONa]
>> and the changelog is:
>>
>> -Removed useless condition
>> -Fixed problem in toplink
>> -Created method printNavLink.
>> -Navigation links - refactor:
>>
>> -tables.php.
>> -schemas.php
>> -domains.php
>> -tables.php
>> -tablespaces.php
>> -operators.php
>> -sequences.php
>> -privileges.php
>> -history.php
>> -display.php
>> -colproperties.php
>> -rules.php
>> -types.php
>> -roles.php
>> -groups.php
>> -users.php
>> -reports.php
>> -aggregates.php
>> -functions.php
>> -views.php
>> -all_db.php
>> -triggers.php
>> -constraints.php
>> -indexes.php
>> -viewproperties.php
>> -fulltext.php
>> -servers.php
>> -tblproperties.php
>> -sql.php
>>
>>
>>   Thanks
>>
>> --
>> Atenciosamente
>> Leonardo Augusto Sápiras
>> [http://www.leonardosapiras.com.br]
>>

Re: [ppa-dev] New plugin architecture - review 4

[Jehan-Guillaume (i. de R. <io...@fr...>]

On 08/06/2011 16:30, Leonardo Sápiras wrote:
> [..]
>
>> #7
>> in classes/PluginManager.php
>> I'm wondering if registering plugin actions is really needed or just useless
>> code. During my last review, I didn't realized you wanted to have one action
>> == one plugin method. Seems like a good idea. But then, why do we need to
>> register the actions ?
>> If this is to avoid calling private methods by specifying them from url by
>> hand, I guess the method visibility "private" should be enough, isn't it ?
>
> It's true, but, we have some methods in Example, like:
>
> get_hooks
> add_plugin_toplinks
> add_plugin_tabs
> add_plugin_trail
>
> that cannot be private, and cannot be used as actions.

You are right

>> #8
>> I wonder if we shouldn't create a Plugin class that all other plugins should
>> inherit from ? Or maybe an abstract class ?
>> It might be useful to share some common methods (get_name() as instance) and
>> putting some common things in its constructor (is it's not an abstract one)
>> like loading plugin translation. So a basic plugin constructor would become
>> something like:
>>
>>         function __construct($language) {
>>                 parent::__construct($language);
>>         }

mh, I thought we couldn't have a constructor in an abstract class...It 
appear I was wrong or php is too much laxist about that. Anyway that's 
fine like that. (but see my next review soon ;))

> Yes, it makes sense with a class to inherit from, IMHO. I made one
> abstract class (Plugin) with some abstract methods (get_hooks,
> get_actions, get_name), and with a common method (__construct).
>
>> Finish for tonight :)
>> I gonna answer you on review 3.
>
> This commit link is [http://bit.ly/mtqK4A] and changelog is:
>
> -Move some code from plugin.php to Example's actions.
> -Dropped unuseless comments.
> -Replaced some comments.
> -Fixed code in Misc->getNavTabs.
> -Created an abstract class to plugin's inherit from.
> -Refactored Example's methods to use the parent class.
> -Created a constant to have the ppa's class dir.

Don't forget about splitting your commit in small parts ;)

>
> Thanks
>
> --
> Atenciosamente
> Leonardo Augusto Sápiras
> [http://www.leonardosapiras.com.br]

Re: [ppa-dev] Switching to UTF-8

[Jehan-Guillaume (i. de R. <io...@fr...>]

On 09/06/2011 06:36, Nozomi Anzai wrote:
>> Hello,

Hello,

>> On 08/06/2011 07:40, Nozomi Anzai wrote:
>>> [...]
>
>>> My report is as follows:
>>>
>>> Browser.php (in the right column in each page) says what means 'Error
>>> loading' like my attached image.
>>> However, another page seems to work without problem, I can watch table
>>> informations, any data with Japanse chars in tables, and so on.
>>>
>>> Opening the url in that message,
>>>
>>>     database.php?subject=database&server=%3A8400%
>>> 3Aallow&action=tree&database=<dbname>
>>>
>>> it shows XML parse error
>>>
>>> <tree text="... (what means 'Schemas')" action="schemas.php?
>>> subject=database&amp; server=%3A8400%3Aallow" src="schemas.php?
>>> subject=database&amp;server=%3A8400%3Aallow&amp;action=tree"
>>> icon="images/themes/default/Schemas.png"
>>> openicon="images/themes/default/Schemas.png" />
>>> ------------^
>>>
>>> And I replaced the word in 'text=""' to another $var in Misc.php
>>> l.1844, parse error message dissapeard.
>>>
>>> Do you have any ideas ?
>>
>> Maybe your browser didn't parse the xml as utf-8 and one byte in the
>> japanese string is breaking it ? Or maybe your lang/japanese.php is not
>> in UTF-8 ? To check it:
>>
>>     $ file japanese.php
>>     japanese.php: PHP script, UTF-8 Unicode text
>>
>> What is your browser and its version ? I tested with firefox 4 and
>> google-chrome 11.0.6.
>>
>> Can you send me the full http answer with headers and body ?
>
> Oh, I forgot confirming my current encoding setting in php.ini at all...
>
> I (and also a certain amount of Japanese) often use 'default_charset =
> "euc-jp"', and that XML was parsed as EUC_JP.
> But I'd like to avoid change my setting, I will be glad if the header
> written by printTreeXML() is as follows:
>
> classes/Misc.php l. 1834
> - header("Content-Type: text/xml;);
> + header("Content-Type: text/xml; charset=UTF-8");

Done

> like the one in other part of source codes.
> Rewriting this, now the left column in frame came to work well.
>
>
> BTW, I can't watch the schema named in Japanese which is created in a not
> UTF-8 (EUC_JP) database.
> Opening the schema page, error message was shown.
>
> ERROR:  invalid byte sequence for encoding "EUC_JP": 0xe383
> SET SEARCH_PATH TO "...(schemaname in Japanese)","public"
>
> It seems that setClientEncoding('utf-8') is lacked before setSchema() in
> libraries/lib.inc.php l.216.

Yeah, you are right, setSchema() was called before 
setClientEncoding('utf-8'). As we don't need setClientEncoding anymore, 
I removed it and simply set the encoding right after connecting to the db.

To ease reviewing and testing, I pushed my local branch to github. SO 
you can get the current code with latest fixes from your comments here:

   1. git clone gi...@gi...:ioguix/phppgadmin.git ppa.ioguix
   2. cd ppa.ioguix
   3. git checkout utf8

Thank you for your fix and pointing me this bug Nozomi !

>> Anyway, it seems to me something might be wrong in
>> libraries/decorator.inc.php, I'm not sure why we use strtr instead of
>> htmlentities at line 68.
>> I attached a patch to apply on top of the first one to test with
>> htmlentities specifying explicitly the text is in UTF-8. Could you tell
>> me if this fix your problem if none of the above worked ?
>>
>> Thank you for your tests Nozomi !
>>
>>>> Please, could you make some tests and report any errors with Japanese
>>>> translation ?
>>>> Tests might include:
>>>>
>>>>     * browsing various database objects
>>>>     * querying the database
>>>>     * querying the database with some WHERE clause using Japanese chars
>>>>     * upload SQL scripts with Japanese chars in queries
>>>>     * creating a database Japanese chars in name
>>>>     * creating database objects with/without Japanese chars
>>>>     * creating database objects with Japanese chars
>>>>     * ...
>>>>
>>>> Thank you in advance !
>>>> - --
>>>> Jehan-Guillaume (ioguix) de Rorthais
>>>> DBA
>>>> http://www.dalibo.com
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG v1.4.11 (GNU/Linux)
>>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>>>
>>>> iEYEARECAAYFAk3snJ4ACgkQXu9L1HbaT6IIrACfTe4NoJSRCGNxZCLyX2zyZp8C
>>>> sagAn3auN07n1U3eA/L66eRz87gQ9r9i
>>>> =l/P+
>>>> -----END PGP SIGNATURE-----

Re: [ppa-dev] Navigation links

[Leonardo S. <l.s...@gm...>]

  Sorry guys, all_db.php is not a class, so:

$misc->printNavLinks($navlinks, 'doDefault', 'all_db.php')
or
$misc->printNavLinks($navlinks, __FUNCTION__, __FILE__)
or
$misc->printNavLinks($navlinks, __FUNCTION__, 'all_db')
or
$misc->printNavLinks($navlinks, 'databases_list_1')

--
Atenciosamente
Leonardo Augusto Sápiras
[http://www.leonardosapiras.com.br]



2011/6/10 Leonardo Sápiras <l.s...@gm...>:
>  Hi devs,
>
>  Following the tasks in GSoC 2011, the next step is to integrate the
> plugin architecture with navigation links. I have verified that
> navigation links are spread everywhere in PPA code, and don't have a
> common function to be displayed, and they have been shown with
> 'echo's.
>
>  To be able creating hooks for this, we need to have a place where
> this links are printed.  So, I created a method in Misc, called
> printNavLinks, that will receive an array with the links, and
> atributtes as well, and will show these links. I also refactored the
> ppa code, to adapt it.
>
>  But now I have found a small problem. If we create a hook to
> navlinks, and a plugin need to show some link, this plugin's navlink
> will be displayed everywhere we have the navigation links. To fix it,
> we need to find some way to identify where the plugin 'desire' to show
> his navlink.
>
>  Jehan suggested me on IRC use $_REQUEST['subject'] and
> $_REQUEST['action'] to do it. But now I realize that, there are some
> places that don't have actions, and have the same subject. An example
> is the screens that list the databases (all_db.php) and the roles
> (roles.php). These pages don't have actions in their requests, and
> have the same subject, that is 'server'. Usually, when a request
> doen't have an action, our php script use a 'doDefault' to display
> something. In this case both all_db.php's doDefault and roles.php's
> doDefault will show the same plugin's navlink.
>
>  An alternative way is to pass more two parameters to the new method
> Misc->printNavLinks(): the file (file.php) and the place inside the
> code where the navlink is being created, maybe the function
> (doDefault, doTree, doSomething...).
>
> Example: for databases list we could do something like that:
>
> $misc->printNavLinks($navlinks, 'doDefault', 'all_db.php')
> or
> $misc->printNavLinks($navlinks, __METHOD__, __FILE__)
> or
> $misc->printNavLinks($navlinks, __METHOD__, 'all_db')
> or
> $misc->printNavLinks($navlinks, 'databases_list_1')
>
>  So, the plugin's developer can check where his navlink will be displayed.
>
> A code with more details can be found at [https://gist.github.com/1017912].
>
> Does anybody have more suggestions about it?
>
>
> The commits with these changes can be found at [http://bit.ly/my5ONa]
> and the changelog is:
>
> -Removed useless condition
> -Fixed problem in toplink
> -Created method printNavLink.
> -Navigation links - refactor:
>
> -tables.php.
> -schemas.php
> -domains.php
> -tables.php
> -tablespaces.php
> -operators.php
> -sequences.php
> -privileges.php
> -history.php
> -display.php
> -colproperties.php
> -rules.php
> -types.php
> -roles.php
> -groups.php
> -users.php
> -reports.php
> -aggregates.php
> -functions.php
> -views.php
> -all_db.php
> -triggers.php
> -constraints.php
> -indexes.php
> -viewproperties.php
> -fulltext.php
> -servers.php
> -tblproperties.php
> -sql.php
>
>
>  Thanks
>
> --
> Atenciosamente
> Leonardo Augusto Sápiras
> [http://www.leonardosapiras.com.br]
>

[ppa-dev] Navigation links

[Leonardo S. <l.s...@gm...>]

  Hi devs,

  Following the tasks in GSoC 2011, the next step is to integrate the
plugin architecture with navigation links. I have verified that
navigation links are spread everywhere in PPA code, and don't have a
common function to be displayed, and they have been shown with
'echo's.

  To be able creating hooks for this, we need to have a place where
this links are printed.  So, I created a method in Misc, called
printNavLinks, that will receive an array with the links, and
atributtes as well, and will show these links. I also refactored the
ppa code, to adapt it.

  But now I have found a small problem. If we create a hook to
navlinks, and a plugin need to show some link, this plugin's navlink
will be displayed everywhere we have the navigation links. To fix it,
we need to find some way to identify where the plugin 'desire' to show
his navlink.

  Jehan suggested me on IRC use $_REQUEST['subject'] and
$_REQUEST['action'] to do it. But now I realize that, there are some
places that don't have actions, and have the same subject. An example
is the screens that list the databases (all_db.php) and the roles
(roles.php). These pages don't have actions in their requests, and
have the same subject, that is 'server'. Usually, when a request
doen't have an action, our php script use a 'doDefault' to display
something. In this case both all_db.php's doDefault and roles.php's
doDefault will show the same plugin's navlink.

  An alternative way is to pass more two parameters to the new method
Misc->printNavLinks(): the file (file.php) and the place inside the
code where the navlink is being created, maybe the function
(doDefault, doTree, doSomething...).

Example: for databases list we could do something like that:

$misc->printNavLinks($navlinks, 'doDefault', 'all_db.php')
or
$misc->printNavLinks($navlinks, __METHOD__, __FILE__)
or
$misc->printNavLinks($navlinks, __METHOD__, 'all_db')
or
$misc->printNavLinks($navlinks, 'databases_list_1')

 So, the plugin's developer can check where his navlink will be displayed.

A code with more details can be found at [https://gist.github.com/1017912].

Does anybody have more suggestions about it?


The commits with these changes can be found at [http://bit.ly/my5ONa]
and the changelog is:

-Removed useless condition
-Fixed problem in toplink
-Created method printNavLink.
-Navigation links - refactor:

-tables.php.
-schemas.php
-domains.php
-tables.php
-tablespaces.php
-operators.php
-sequences.php
-privileges.php
-history.php
-display.php
-colproperties.php
-rules.php
-types.php
-roles.php
-groups.php
-users.php
-reports.php
-aggregates.php
-functions.php
-views.php
-all_db.php
-triggers.php
-constraints.php
-indexes.php
-viewproperties.php
-fulltext.php
-servers.php
-tblproperties.php
-sql.php


 Thanks

--
Atenciosamente
Leonardo Augusto Sápiras
[http://www.leonardosapiras.com.br]

Re: [ppa-dev] Switching to UTF-8

[Nozomi A. <an...@sr...>]

> Hello,
> 
> On 08/06/2011 07:40, Nozomi Anzai wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Hello Nozomi,
> >>
> >> I accepted your subscription to ppa-dev the mailing list this morning.
> >> Thank you for registering !
> >>
> >> So, as you missed the last emails about having PPA core code in UTF-8
> >> only, please find in attachment my current patch about it.
> >
> > In conclusion, the patched source cord seems not to work well in
> > Japanese.
> >
> >
> > But, first of all, I'm afraid I did a wrong way, What I did are:
> >
> > 1. Got the source cord by git.
> > 2. Confirmed that the original PPA worked in Japanese too.
> > 3. Patched.
> > 4. Confirmed that the patched PPA worked in English and French.
> > 5. Chose Japanese (and Chinese, Russian).
> >
> > Is there any lacked or extra step ?
> 
> Sounds good to me. I did another test myself:
> 
> 1. git clone gi...@gi...:phppgadmin/phppgadmin.git && cd phppgadmin/
> 2. zcat ../full_utf8-2.patch.gz | patch -p1
> 3. cp ../ppa/conf/config.inc.php conf/
> 
> and I can not reproduce your problem you describe bellow. See my 
> screenshot in attachment.

I see. Thank you for your advice.

> > My report is as follows:
> >
> > Browser.php (in the right column in each page) says what means 'Error
> > loading' like my attached image.
> > However, another page seems to work without problem, I can watch table
> > informations, any data with Japanse chars in tables, and so on.
> >
> > Opening the url in that message,
> >
> >    database.php?subject=database&server=%3A8400%
> > 3Aallow&action=tree&database=<dbname>
> >
> > it shows XML parse error
> >
> > <tree text="... (what means 'Schemas')" action="schemas.php?
> > subject=database&amp; server=%3A8400%3Aallow" src="schemas.php?
> > subject=database&amp;server=%3A8400%3Aallow&amp;action=tree"
> > icon="images/themes/default/Schemas.png"
> > openicon="images/themes/default/Schemas.png" />
> > ------------^
> >
> > And I replaced the word in 'text=""' to another $var in Misc.php
> > l.1844, parse error message dissapeard.
> >
> > Do you have any ideas ?
> 
> Maybe your browser didn't parse the xml as utf-8 and one byte in the 
> japanese string is breaking it ? Or maybe your lang/japanese.php is not 
> in UTF-8 ? To check it:
> 
>    $ file japanese.php
>    japanese.php: PHP script, UTF-8 Unicode text
> 
> What is your browser and its version ? I tested with firefox 4 and 
> google-chrome 11.0.6.
> 
> Can you send me the full http answer with headers and body ?

Oh, I forgot confirming my current encoding setting in php.ini at all...

I (and also a certain amount of Japanese) often use 'default_charset =
"euc-jp"', and that XML was parsed as EUC_JP.
But I'd like to avoid change my setting, I will be glad if the header
written by printTreeXML() is as follows:

classes/Misc.php l. 1834
- header("Content-Type: text/xml;);
+ header("Content-Type: text/xml; charset=UTF-8");

like the one in other part of source codes.
Rewriting this, now the left column in frame came to work well.


BTW, I can't watch the schema named in Japanese which is created in a not
UTF-8 (EUC_JP) database.
Opening the schema page, error message was shown.

ERROR:  invalid byte sequence for encoding "EUC_JP": 0xe383
SET SEARCH_PATH TO "...(schemaname in Japanese)","public"

It seems that setClientEncoding('utf-8') is lacked before setSchema() in
libraries/lib.inc.php l.216.


> Anyway, it seems to me something might be wrong in 
> libraries/decorator.inc.php, I'm not sure why we use strtr instead of 
> htmlentities at line 68.
> I attached a patch to apply on top of the first one to test with 
> htmlentities specifying explicitly the text is in UTF-8. Could you tell 
> me if this fix your problem if none of the above worked ?
> 
> Thank you for your tests Nozomi !
> 
> >> Please, could you make some tests and report any errors with Japanese
> >> translation ?
> >> Tests might include:
> >>
> >>    * browsing various database objects
> >>    * querying the database
> >>    * querying the database with some WHERE clause using Japanese chars
> >>    * upload SQL scripts with Japanese chars in queries
> >>    * creating a database Japanese chars in name
> >>    * creating database objects with/without Japanese chars
> >>    * creating database objects with Japanese chars
> >>    * ...
> >>
> >> Thank you in advance !
> >> - --
> >> Jehan-Guillaume (ioguix) de Rorthais
> >> DBA
> >> http://www.dalibo.com
> >> -----BEGIN PGP SIGNATURE-----
> >> Version: GnuPG v1.4.11 (GNU/Linux)
> >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> >>
> >> iEYEARECAAYFAk3snJ4ACgkQXu9L1HbaT6IIrACfTe4NoJSRCGNxZCLyX2zyZp8C
> >> sagAn3auN07n1U3eA/L66eRz87gQ9r9i
> >> =l/P+
> >> -----END PGP SIGNATURE-----


-- 
Nozomi Anzai
SRA OSS, Inc. Japan

Re: [ppa-dev] New plugin architecture - review 4

[Leonardo S. <l.s...@gm...>]

Jehan,

> Hey, yet another bunch of comments :)
> As always, I didn't test the patch, just reviewed the code.

Ok

> #0 don't put useless comment all over the place (/* * */)

Ok, dropped.

> #1
> in classes/Misc.php:506
> classes/Misc.php:686
> classes/Misc.php:791
> classes/Misc.php:949
> You return from the function before beeing able to execute the hook...

Yeah, fixed :)

> #2
> in classes/Misc.php:1087-1100
> You should escape everything you print from $link there to make sure it
> doesn't break html code

Done, escaped with htmlentities.

> #3
> in classes/Misc.php:1087-1100
> This code should probably be more generic as plugins might want to use some
> other link attributes.

Ok, I made a code similar what you suggested on IRC.

> #4
> in classes/Misc.php:1380
> shouldn't this hook need the level/subject as well here ?

your last comment:

> yeah, it should. If you click on your tolink outside of any database, everything is ok.
> But go in another level in the tree, click on your toplink, then move to the next level, and you'll have a different trail than before

It was happening because I removed some returns in Misc->getNavTabs,
and I didn't put breaks in the cases. Fixed.

I am getting the subject (section) in Example->add_plugin_trail. Do
you think it would be better I pass the section (subject) instead of
get this value direct from $_REQUEST['subject']?

> #5
> in classes/PluginManager.php:81
> This line could be inverted with line 80

Yeah, more CPU friendly ;)

> #6
> in classes/PluginManager.php:98
>
> This:
>  if (isset($this->plugins_list[$plugin_name])) {
>    $plugin = $this->plugins_list[$plugin_name];
>  } else {
>    // Show an error and stop the application
>    printf($lang['strpluginnotfound']."\t\n", $name);
>    exit;
>  }
>
> Is cleaner like that:
>  if (! isset($this->plugins_list[$plugin_name])) {
>    // Show an error and stop the application
>    printf($lang['strpluginnotfound']."\t\n", $name);
>    exit;
>  }
>  $plugin = $this->plugins_list[$plugin_name];

Done.

> #7
> in classes/PluginManager.php
> I'm wondering if registering plugin actions is really needed or just useless
> code. During my last review, I didn't realized you wanted to have one action
> == one plugin method. Seems like a good idea. But then, why do we need to
> register the actions ?
> If this is to avoid calling private methods by specifying them from url by
> hand, I guess the method visibility "private" should be enough, isn't it ?

It's true, but, we have some methods in Example, like:

get_hooks
add_plugin_toplinks
add_plugin_tabs
add_plugin_trail

that cannot be private, and cannot be used as actions.

> #8
> I wonder if we shouldn't create a Plugin class that all other plugins should
> inherit from ? Or maybe an abstract class ?
> It might be useful to share some common methods (get_name() as instance) and
> putting some common things in its constructor (is it's not an abstract one)
> like loading plugin translation. So a basic plugin constructor would become
> something like:
>
>        function __construct($language) {
>                parent::__construct($language);
>        }

Yes, it makes sense with a class to inherit from, IMHO. I made one
abstract class (Plugin) with some abstract methods (get_hooks,
get_actions, get_name), and with a common method (__construct).

> Finish for tonight :)
> I gonna answer you on review 3.

This commit link is [http://bit.ly/mtqK4A] and changelog is:

-Move some code from plugin.php to Example's actions.
-Dropped unuseless comments.
-Replaced some comments.
-Fixed code in Misc->getNavTabs.
-Created an abstract class to plugin's inherit from.
-Refactored Example's methods to use the parent class.
-Created a constant to have the ppa's class dir.

Thanks

--
Atenciosamente
Leonardo Augusto Sápiras
[http://www.leonardosapiras.com.br]

Re: [ppa-dev] New plugin architecture review 3

[Leonardo S. <l.s...@gm...>]

#6
[...]
> better, but see my comments about it in review 4.

Ok.

>>> #15
>>> in ./plugin.php
>>> let's open another discussion :)
>>> IMO, calling "$misc->printHeader($lang['strdatabase']);" here is wrong,
>>> initially because of the given title. PLugins should be able to control
>>> the
>>> page title.
>>> But actually, maybe "printHeader", "printBody", "printTopbar" and
>>> "printFooter" should all be in the plugin code directly of they need to
>>> create a full page ?
>>
>> I don't see any problem. Does anybody else have some comments about?
>
> what if your plugin is hooking to the table level ? Will you still print the
> header with $lang['strdatabase'] as title ?
>
> What if the plugin doesn't need the top bar or trail ?
>
> Worst: what if the plugin actually doesn't generate any html but allows you
> to download something ?

Yeah, good points, I moved that code to Example's actions


>> This commit can be found at [http://bit.ly/jo064O] and the changelog is:
>>
>> -Refactored printTabs method comment.
>> -Created Example's icon.
>> -Refactored Misc->icon method to accept an array as icon.
>> -Remove some unecessary code.
>> -Created more icons.
>> -Changed Example's trail to use the new icons.
>> -Refactored Example->add_plugin_toplinks.
>> -Refactored Misc->printTabs and Misc->getNavTabs.
>> -Moved tabs' hook to getNavTabs.
>> -Refactored Misc->printTrail and Misc->getTrail.
>> -Moved trail's hook to getTrail.
>> -Created Misc->getTopLinks method.
>> -Refactored PluginManager->add_plugin to check if plugins are using
>> avaliable hooks.
>> -Created entries in languages files for new PluginManager's strings.
>> -Removed PluginManager->get_plugin.
>> -Created new attibutes in PluginManager class, $hooks and $actions.
>> -Renamed PluginManager->execute_plugin_funtions to do_hook and
>> refactored this method.
>> -Dropped PluginManager->get_plugin.
>
> Nice work Leonardo ! I'm impressed by your reactivity as usual, thank you :)

Thank you :D


--
Atenciosamente
Leonardo Augusto Sápiras
[http://www.leonardosapiras.com.br]

Re: [ppa-dev] Switching to UTF-8

[Jehan-Guillaume (i. de R. <io...@fr...>]

Hello,

On 08/06/2011 07:40, Nozomi Anzai wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hello Nozomi,
>>
>> I accepted your subscription to ppa-dev the mailing list this morning.
>> Thank you for registering !
>>
>> So, as you missed the last emails about having PPA core code in UTF-8
>> only, please find in attachment my current patch about it.
>
> In conclusion, the patched source cord seems not to work well in Japanese.
>
>
> But, first of all, I'm afraid I did a wrong way, What I did are:
>
> 1. Got the source cord by git.
> 2. Confirmed that the original PPA worked in Japanese too.
> 3. Patched.
> 4. Confirmed that the patched PPA worked in English and French.
> 5. Chose Japanese (and Chinese, Russian).
>
> Is there any lacked or extra step ?

Sounds good to me. I did another test myself:

1. git clone gi...@gi...:phppgadmin/phppgadmin.git && cd phppgadmin/
2. zcat ../full_utf8-2.patch.gz | patch -p1
3. cp ../ppa/conf/config.inc.php conf/

and I can not reproduce your problem you describe bellow. See my 
screenshot in attachment.

> My report is as follows:
>
> Browser.php (in the right column in each page) says what means 'Error
> loading' like my attached image.
> However, another page seems to work without problem, I can watch table
> informations, any data with Japanse chars in tables, and so on.
>
> Opening the url in that message,
>
>    database.php?subject=database&server=%3A8400%3Aallow&action=tree&database=<dbname>
>
> it shows XML parse error
>
> <tree text="... (what means 'Schemas')" action="schemas.php?subject=database&amp;
> server=%3A8400%3Aallow" src="schemas.php?subject=database&amp;server=%3A8400%3Aallow&amp;action=tree"
> icon="images/themes/default/Schemas.png" openicon="images/themes/default/Schemas.png" />
> ------------^
>
> And I replaced the word in 'text=""' to another $var in Misc.php l.1844,
> parse error message dissapeard.
>
> Do you have any ideas ?

Maybe your browser didn't parse the xml as utf-8 and one byte in the 
japanese string is breaking it ? Or maybe your lang/japanese.php is not 
in UTF-8 ? To check it:

   $ file japanese.php
   japanese.php: PHP script, UTF-8 Unicode text

What is your browser and its version ? I tested with firefox 4 and 
google-chrome 11.0.6.

Can you send me the full http answer with headers and body ?

Anyway, it seems to me something might be wrong in 
libraries/decorator.inc.php, I'm not sure why we use strtr instead of 
htmlentities at line 68.
I attached a patch to apply on top of the first one to test with 
htmlentities specifying explicitly the text is in UTF-8. Could you tell 
me if this fix your problem if none of the above worked ?

Thank you for your tests Nozomi !

>> Please, could you make some tests and report any errors with Japanese
>> translation ?
>> Tests might include:
>>
>>    * browsing various database objects
>>    * querying the database
>>    * querying the database with some WHERE clause using Japanese chars
>>    * upload SQL scripts with Japanese chars in queries
>>    * creating a database Japanese chars in name
>>    * creating database objects with/without Japanese chars
>>    * creating database objects with Japanese chars
>>    * ...
>>
>> Thank you in advance !
>> - --
>> Jehan-Guillaume (ioguix) de Rorthais
>> DBA
>> http://www.dalibo.com
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.11 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iEYEARECAAYFAk3snJ4ACgkQXu9L1HbaT6IIrACfTe4NoJSRCGNxZCLyX2zyZp8C
>> sagAn3auN07n1U3eA/L66eRz87gQ9r9i
>> =l/P+
>> -----END PGP SIGNATURE-----