Hi, all.
I'm trying to make enum and set editors (https://sourceforge.net/tracker/index.php?func=detail&aid=1494550&gr...). I added the special button near text input (see attachment enum-button.png). When you click on the button, editor dialog are shown.
And i have a question about possibility of using jquery ui dialog for this.
In js/ folder i'm seeing only mootols js-framework. And i made custom dialog for enum editor (see attachment enum-editor.png). But i think that jquery ui dialog is better solution for this task (http://jqueryui.com/demos/dialog/modal-form.html).
What do you think?
Best regards. Pavel Konnikov
Hi,
I think that there is no need for another JS framework. There is a library called MochaUI (http://mochaui.com/), which is based on MooTools and provides lots of UI elements (buttons, dialogs, windows, frames, boxes...). Maybe, you could use one of the dialogs from MochaUI, if you do not like plain JS.
Best Regards, Tomas
On Thu, Mar 4, 2010 at 12:25 PM, Pavel Konnikov konnikov@gmail.com wrote:
Hi, all.
I'm trying to make enum and set editors (https://sourceforge.net/tracker/index.php?func=detail&aid=1494550&gr...). I added the special button near text input (see attachment enum-button.png). When you click on the button, editor dialog are shown.
And i have a question about possibility of using jquery ui dialog for this.
In js/ folder i'm seeing only mootols js-framework. And i made custom dialog for enum editor (see attachment enum-editor.png). But i think that jquery ui dialog is better solution for this task (http://jqueryui.com/demos/dialog/modal-form.html).
What do you think?
Best regards. Pavel Konnikov
Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Hi
Dne Thu, 4 Mar 2010 14:25:38 +0300 Pavel Konnikov konnikov@gmail.com napsal(a):
I'm trying to make enum and set editors (https://sourceforge.net/tracker/index.php?func=detail&aid=1494550&gr...). I added the special button near text input (see attachment enum-button.png). When you click on the button, editor dialog are shown.
Looks nice.
And i have a question about possibility of using jquery ui dialog for this.
In js/ folder i'm seeing only mootols js-framework. And i made custom dialog for enum editor (see attachment enum-editor.png). But i think that jquery ui dialog is better solution for this task (http://jqueryui.com/demos/dialog/modal-form.html).
What do you think?
I personally do not have any preference to jquery or mootools and I can't tell which one is better. On the other side we already use mootools for some things and it is definitely not a good idea to include both of them.
So the option is either to migrate everything to jquery or to find some mootools based solution.
And just a quick search showed me also several modal window scripts, for example http://netzelf.de/releases/yamoodow/
Hi all,
my own opinion is to use jQuery, cause it's stable fast and has lo's of plugins and a themeable UI. It's easy to learn, cause it's really good documented. The other point is, I've developed some plugins like grid (for the table view), UI-Uploader (a uploading tool for files) and the planned WYSIWYG Html-Editor wich I prefer is TinyMCE. This editor is jQuery compatible.
Perhabs we should make a discussion or vote, wich js-framework we should use for phpMyAdmin.
Regards Michael
Am 04.03.2010 13:11, schrieb Michal Čihař:
Hi
Dne Thu, 4 Mar 2010 14:25:38 +0300 Pavel Konnikov konnikov@gmail.com napsal(a):
I'm trying to make enum and set editors (https://sourceforge.net/tracker/index.php?func=detail&aid=1494550&gr...). I added the special button near text input (see attachment enum-button.png). When you click on the button, editor dialog are shown.
Looks nice.
And i have a question about possibility of using jquery ui dialog for this.
In js/ folder i'm seeing only mootols js-framework. And i made custom dialog for enum editor (see attachment enum-editor.png). But i think that jquery ui dialog is better solution for this task (http://jqueryui.com/demos/dialog/modal-form.html).
What do you think?
I personally do not have any preference to jquery or mootools and I can't tell which one is better. On the other side we already use mootools for some things and it is definitely not a good idea to include both of them.
So the option is either to migrate everything to jquery or to find some mootools based solution.
And just a quick search showed me also several modal window scripts, for example http://netzelf.de/releases/yamoodow/
Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev
Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Michael Keck a écrit :
Hi all,
my own opinion is to use jQuery, cause it's stable fast and has lo's of plugins and a themeable UI. It's easy to learn, cause it's really good documented. The other point is, I've developed some plugins like grid (for the table view), UI-Uploader (a uploading tool for files) and the planned WYSIWYG Html-Editor wich I prefer is TinyMCE. This editor is jQuery compatible.
Perhabs we should make a discussion or vote, wich js-framework we should use for phpMyAdmin.
Regards Michael
Let's switch to jQuery if it's better known, this will help us attract developers. But who wants to convert our current Mootools code? Also, should we convert pmd/scripts too?
Hi,
I can convert existing mooTools code into jQuery - I do know both frameworks.
Tomas
On Thu, Mar 4, 2010 at 3:12 PM, Marc Delisle marc@infomarc.info wrote:
Michael Keck a écrit :
Hi all,
my own opinion is to use jQuery, cause it's stable fast and has lo's of plugins and a themeable UI. It's easy to learn, cause it's really good documented. The other point is, I've developed some plugins like grid (for the table view), UI-Uploader (a uploading tool for files) and the planned WYSIWYG Html-Editor wich I prefer is TinyMCE. This editor is jQuery compatible.
Perhabs we should make a discussion or vote, wich js-framework we should use for phpMyAdmin.
Regards Michael
Let's switch to jQuery if it's better known, this will help us attract developers. But who wants to convert our current Mootools code? Also, should we convert pmd/scripts too?
-- Marc Delisle http://infomarc.info
Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
On Thu, Mar 4, 2010 at 7:45 PM, Tomas Srnka tomas.srnka@gmail.com wrote:
Hi,
I can convert existing mooTools code into jQuery - I do know both frameworks.
Tomas
Me too, I know about jQuery and have a vague idea about Mootools , i guess it will be enough for the conversion part. And regarding using AJAX please sent in your views coz this can be used for multiple purposes, like "Query syntax suggestions", field name etc, and many others.
On Thu, Mar 4, 2010 at 3:12 PM, Marc Delisle marc@infomarc.info wrote:
Michael Keck a écrit :
Hi all,
my own opinion is to use jQuery, cause it's stable fast and has lo's of plugins and a themeable UI. It's easy to learn, cause it's really good documented. The other point is, I've developed some plugins like grid (for the table view), UI-Uploader (a uploading tool for files) and the planned WYSIWYG
Html-Editor
wich I prefer is TinyMCE. This editor is jQuery compatible.
Perhabs we should make a discussion or vote, wich js-framework we should use for phpMyAdmin.
Regards Michael
Let's switch to jQuery if it's better known, this will help us attract developers. But who wants to convert our current Mootools code? Also, should we convert pmd/scripts too?
-- Marc Delisle http://infomarc.info
Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Rohin, I think that only mootools code is the color picker (that can be replaced by http://www.eyecon.ro/colorpicker/) and import progress bar.
Tomas
On Thu, Mar 4, 2010 at 3:20 PM, Rohit Kalhans rohit.kalhans@gmail.com wrote:
On Thu, Mar 4, 2010 at 7:45 PM, Tomas Srnka tomas.srnka@gmail.com wrote:
Hi,
I can convert existing mooTools code into jQuery - I do know both frameworks.
Tomas
Me too, I know about jQuery and have a vague idea about Mootools , i guess it will be enough for the conversion part. And regarding using AJAX please sent in your views coz this can be used for multiple purposes, like "Query syntax suggestions", field name etc, and many others.
On Thu, Mar 4, 2010 at 3:12 PM, Marc Delisle marc@infomarc.info wrote:
Michael Keck a écrit :
Hi all,
my own opinion is to use jQuery, cause it's stable fast and has lo's of plugins and a themeable UI. It's easy to learn, cause it's really good documented. The other point is, I've developed some plugins like grid (for the table view), UI-Uploader (a uploading tool for files) and the planned WYSIWYG Html-Editor wich I prefer is TinyMCE. This editor is jQuery compatible.
Perhabs we should make a discussion or vote, wich js-framework we should use for phpMyAdmin.
Regards Michael
Let's switch to jQuery if it's better known, this will help us attract developers. But who wants to convert our current Mootools code? Also, should we convert pmd/scripts too?
-- Marc Delisle http://infomarc.info
Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
-- Rohit Kalhans
Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Tomas Srnka a écrit :
Rohin, I think that only mootools code is the color picker (that can be replaced by http://www.eyecon.ro/colorpicker/) and import progress bar.
There is also the slider that is used on a few panels.
Tomas
On Thu, Mar 4, 2010 at 3:20 PM, Rohit Kalhans rohit.kalhans@gmail.com wrote:
On Thu, Mar 4, 2010 at 7:45 PM, Tomas Srnka tomas.srnka@gmail.com wrote:
Hi,
I can convert existing mooTools code into jQuery - I do know both frameworks.
Tomas
Me too, I know about jQuery and have a vague idea about Mootools , i guess it will be enough for the conversion part. And regarding using AJAX please sent in your views coz this can be used for multiple purposes, like "Query syntax suggestions", field name etc, and many others.
On Thu, Mar 4, 2010 at 3:12 PM, Marc Delisle marc@infomarc.info wrote:
Michael Keck a écrit :
Hi all,
my own opinion is to use jQuery, cause it's stable fast and has lo's of plugins and a themeable UI. It's easy to learn, cause it's really good documented. The other point is, I've developed some plugins like grid (for the table view), UI-Uploader (a uploading tool for files) and the planned WYSIWYG Html-Editor wich I prefer is TinyMCE. This editor is jQuery compatible.
Perhabs we should make a discussion or vote, wich js-framework we should use for phpMyAdmin.
Regards Michael
Let's switch to jQuery if it's better known, this will help us attract developers. But who wants to convert our current Mootools code? Also, should we convert pmd/scripts too?
-- Marc Delisle http://infomarc.info
Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
-- Rohit Kalhans
Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Dne Thu, 4 Mar 2010 15:25:08 +0100 Tomas Srnka tomas.srnka@gmail.com napsal(a):
Rohin, I think that only mootools code is the color picker (that can be replaced by http://www.eyecon.ro/colorpicker/) and import progress bar.
There are also some more things spead in js directory which do use mootools.
Rohit Kalhans a écrit :
On Thu, Mar 4, 2010 at 7:45 PM, Tomas Srnka <tomas.srnka@gmail.com mailto:tomas.srnka@gmail.com> wrote:
Hi, I can convert existing mooTools code into jQuery - I do know both frameworks. Tomas
Me too, I know about jQuery and have a vague idea about Mootools , i guess it will be enough for the conversion part. And regarding using AJAX please sent in your views coz this can be used for multiple purposes, like "Query syntax suggestions", field name etc, and many others.
About AJAX, there is this request: https://sourceforge.net/tracker/index.php?func=detail&aid=2131880&gr...
and I suggest to post suggestions and comments there for easier tracking.
On Thu, Mar 4, 2010 at 3:12 PM, Marc Delisle <marc@infomarc.info <mailto:marc@infomarc.info>> wrote: > Michael Keck a écrit : >> Hi all, >> >> my own opinion is to use jQuery, cause it's stable fast and has lo's of >> plugins >> and a themeable UI. >> It's easy to learn, cause it's really good documented. >> The other point is, I've developed some plugins like grid (for the table >> view), >> UI-Uploader (a uploading tool for files) and the planned WYSIWYG Html-Editor >> wich I prefer is TinyMCE. This editor is jQuery compatible. >> >> Perhabs we should make a discussion or vote, wich js-framework we should >> use for phpMyAdmin. >> >> Regards >> Michael > > Let's switch to jQuery if it's better known, this will help us attract > developers. But who wants to convert our current Mootools code? Also, > should we convert pmd/scripts too? > > -- > Marc Delisle > http://infomarc.info > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Phpmyadmin-devel mailing list > Phpmyadmin-devel@lists.sourceforge.net <mailto:Phpmyadmin-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel > ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net <mailto:Phpmyadmin-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
-- Rohit Kalhans
Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev
Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
hi Marc Delisle,
On Thu, Mar 4, 2010 at 8:08 PM, Marc Delisle marc@infomarc.info wrote:
Rohit Kalhans a écrit :
Me too, I know about jQuery and have a vague idea about Mootools , i guess it will be enough for the conversion part. And regarding using AJAX please sent in your views coz this can be used for multiple purposes, like "Query syntax suggestions", field name etc, and many others.
About AJAX, there is this request:
https://sourceforge.net/tracker/index.php?func=detail&aid=2131880&gr...
and I suggest to post suggestions and comments there for easier tracking.
I just saw the page that you cited above but the last posted comment was Oct 2008, cant track out what work have been done after that, but anywa ill post in my comments over there.
Hi
Dne Thu, 4 Mar 2010 22:16:25 +0530 Rohit Kalhans rohit.kalhans@gmail.com napsal(a):
I just saw the page that you cited above but the last posted comment was Oct 2008, cant track out what work have been done after that, but anywa ill post in my comments over there.
I don't think there was ever any progress in introducing AJAX into phpMyAdmin.
On Fri, Mar 5, 2010 at 12:53 AM, Michal Čihař michal@cihar.com wrote:
Hi
Dne Thu, 4 Mar 2010 22:16:25 +0530 Rohit Kalhans rohit.kalhans@gmail.com napsal(a):
I just saw the page that you cited above but the last posted comment was
Oct
2008, cant track out what work have been done after that, but anywa ill
post
in my comments over there.
I don't think there was ever any progress in introducing AJAX into phpMyAdmin.
I am working on *ajaxifying* the RUN SQL (the second tab in the tab list at the top), using JQuery, for now lets test it before we try to proceed any further. We need to check the tradeoff between the speed and UI experience and the overheads involved.
--
Michal Čihař | http://cihar.com | http://blog.cihar.com
Regards
Hi
Dne Fri, 5 Mar 2010 01:00:03 +0530 Rohit Kalhans rohit.kalhans@gmail.com napsal(a):
I am working on *ajaxifying* the RUN SQL (the second tab in the tab list at the top), using JQuery, for now lets test it before we try to proceed any further. We need to check the tradeoff between the speed and UI experience and the overheads involved.
Also please remember that phpMyAdmin should still work without javascript.
Hi all,
that's the point why I prefer jQuery. First building full functional a web app without any javascript. Then with jQuery add animations, effects, styles and behaviors to dom elements.
Perhabs, we should use a template engine (like smarty), for seperating code and layout. Perhabs this would make adding styles and themes easier. Other point is, all things, that have not to do with core functions, could be add to the templates, like plugins, effects or javascripts. And with templates we are able to cache basics, like menus, help, forms etc. This would increase performance.
Regards Michael
Am 04.03.2010 22:29, schrieb Michal Čihař:
Hi
Dne Fri, 5 Mar 2010 01:00:03 +0530 Rohit Kalhans rohit.kalhans@gmail.com napsal(a):
I am working on *ajaxifying* the RUN SQL (the second tab in the tab list at the top), using JQuery, for now lets test it before we try to proceed any further. We need to check the tradeoff between the speed and UI experience and the overheads involved.
Also please remember that phpMyAdmin should still work without javascript.
Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev
Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Hi
Dne Fri, 05 Mar 2010 10:27:15 +0100 Michael Keck sfnet@michaelkeck.de napsal(a):
that's the point why I prefer jQuery. First building full functional a web app without any javascript. Then with jQuery add animations, effects, styles and behaviors to dom elements.
I don't think it's much different with mootools.
Perhabs, we should use a template engine (like smarty), for seperating code and layout. Perhabs this would make adding styles and themes easier. Other point is, all things, that have not to do with core functions, could be add to the templates, like plugins, effects or javascripts. And with templates we are able to cache basics, like menus, help, forms etc. This would increase performance.
Yes, we already agreed some time ago that it would be great to use templates, but it is quite a lot work which nobody did to far :-).
Am 05.03.2010 10:55, schrieb Michal Čihař:
Hi
Dne Fri, 05 Mar 2010 10:27:15 +0100 Michael Keck sfnet@michaelkeck.de napsal(a):
that's the point why I prefer jQuery. First building full functional a web app without any javascript. Then with jQuery add animations, effects, styles and behaviors to dom elements.
I don't think it's much different with mootools.
I don't know mootools in details, but I think it's more a developer preference. Somebody likes mootools, other prototype, next ext.js and others jquery. But I guess with Marc, we should use one js-framework at the moment wich is the best for us at the moment.
Perhabs, we should use a template engine (like smarty), for seperating code and layout. Perhabs this would make adding styles and themes easier. Other point is, all things, that have not to do with core functions, could be add to the templates, like plugins, effects or javascripts. And with templates we are able to cache basics, like menus, help, forms etc. This would increase performance.
Yes, we already agreed some time ago that it would be great to use templates, but it is quite a lot work which nobody did to far :-).
I will try to do this with smarty. But you're right it's really quite a lot of work. It would be nice, to comment in the current development all html-outputs with a special comment to search for it. I'm working at the moment on a smarty port in a seperated development environment and it's really diffucult to get all html outputs by reading each script and code.
Then it's possible to create with templates different pma environments: - with javascript - without javascript - for text browsers - for PDAs - etc.
The other point with a template base soulution is, it doesn't really matter wich framework for javascript is used. Cause it's included in the templates.
A other great thing is, other great oss projects are able to use our core functional in their own applications.
Regards Michael
Michael Keck a écrit :
Am 05.03.2010 10:55, schrieb Michal Čihař:
Hi
Dne Fri, 05 Mar 2010 10:27:15 +0100 Michael Keck sfnet@michaelkeck.de napsal(a):
that's the point why I prefer jQuery. First building full functional a web app without any javascript. Then with jQuery add animations, effects, styles and behaviors to dom elements.
I don't think it's much different with mootools.
I don't know mootools in details, but I think it's more a developer preference. Somebody likes mootools, other prototype, next ext.js and others jquery. But I guess with Marc, we should use one js-framework at the moment wich is the best for us at the moment.
Perhabs, we should use a template engine (like smarty), for seperating code and layout. Perhabs this would make adding styles and themes easier. Other point is, all things, that have not to do with core functions, could be add to the templates, like plugins, effects or javascripts. And with templates we are able to cache basics, like menus, help, forms etc. This would increase performance.
Yes, we already agreed some time ago that it would be great to use templates, but it is quite a lot work which nobody did to far :-).
I will try to do this with smarty. But you're right it's really quite a lot of work. It would be nice, to comment in the current development all html-outputs with a special comment to search for it. I'm working at the moment on a smarty port in a seperated development environment and it's really diffucult to get all html outputs by reading each script and code.
Please, have a look at http://nosmarty.net/
Hi all,
Am 05.03.2010 13:29, schrieb Marc Delisle:
Michael Keck a écrit :
Am 05.03.2010 10:55, schrieb Michal Čihař:
Perhabs, we should use a template engine (like smarty), for seperating code and layout. [...]
Yes, we already agreed some time ago that it would be great to use templates, but it is quite a lot work which nobody did to far :-).
I will try to do this with smarty. But you're right it's really quite a lot of work. [...]
Please, have a look at http://nosmarty.net/
And what's about Symfony (http://www.symfony-project.org/) or Zend-Framework (http://framework.zend.com/)? I prefer Symfony.
Regards Michael
Michael Keck a écrit :
Hi all,
Am 05.03.2010 13:29, schrieb Marc Delisle:
Michael Keck a écrit :
Am 05.03.2010 10:55, schrieb Michal Čihař:
Perhabs, we should use a template engine (like smarty), for seperating code and layout. [...]
Yes, we already agreed some time ago that it would be great to use templates, but it is quite a lot work which nobody did to far :-).
I will try to do this with smarty. But you're right it's really quite a lot of work. [...]
Please, have a look at http://nosmarty.net/
And what's about Symfony (http://www.symfony-project.org/) or Zend-Framework (http://framework.zend.com/)? I prefer Symfony.
Regards Michael
Hi Michael, you are volunteer to port the phpMyAdmin code base to a template-based framework? I surely am not volunteer for such a job.
Hi Marc,
Am 07.03.2010 22:05, schrieb Marc Delisle:
Hi Michael, you are volunteer to port the phpMyAdmin code base to a template-based framework? I surely am not volunteer for such a job.
Yes, why not? But it would really help me, if developers leave comments, what is for output. My goal is to seperate PMA-function from html (-output). This will support more flexibility for layout and theming and perhabs to invide developers to make only php code and others the html-output.
But which should I use?
I've found follow template engines, and I want to get little feeadback which would be right and good for us:
* TWIG Link: http://www.twig-project.org/) Info: it's made from the same peoples wich made Symfony. What I say: It's really fast (see http://fabien.potencier.org/article/34/templating-engines-in-php)
* Dwoo Link: http://dwoo.org/ Info: PHP5 template engine positioned as an alternative to Smarty, it is (nearly) fully compatible with its templates and plugins, but it is written from scratch and aimed at going one step further with a cleaner codebase. What I say: I'm using Smarty on a other project, Dwoo has nearly same syntax.
* Smarty Link: http://www.smarty.net/ Info: The most known. What I say: May be not a good choice. Marc gives me the link http://www.nosmarty.net
At my own, I think Symfony or Zend-Framework would be little overkill.
Regards Michael
Hi
Dne Mon, 08 Mar 2010 09:07:27 +0100 Michael Keck sfnet@michaelkeck.de napsal(a):
Yes, why not? But it would really help me, if developers leave comments, what is for output. My goal is to seperate PMA-function from html (-output). This will support more flexibility for layout and theming and perhabs to invide developers to make only php code and others the html-output.
This is definitely needed for long time, thanks for volunteering!
But which should I use?
I've found follow template engines, and I want to get little feeadback which would be right and good for us:
* TWIG Link: http://www.twig-project.org/) Info: it's made from the same peoples wich made Symfony. What I say: It's really fast (see http://fabien.potencier.org/article/34/templating-engines-in-php)
I don't know anything about most of them, but the syntax of Twig looks same as Django uses and I use Django quite a lot these days (I understand this is really not a big argument for a project written in PHP :-))).
* Smarty Link: http://www.smarty.net/ Info: The most known. What I say: May be not a good choice. Marc gives me the link http://www.nosmarty.net
At my own, I think Symfony or Zend-Framework would be little overkill.
Well this website rather looks like it is against using separate template system and prefers using full featured frameworks. It might be not a bad idea, however it is much more work for us and because of this I'd stay with separate template system, but possibly with some where upgrade path to some framework would not be that hard.
Okay ...
... if I should use a PHP-Framework, I'm thinking we should use the newest Symfony and if released I would prefer use Symfony Reloaded 2.0 (http://symfony-reloaded.org/). The final release of Reloaded 2.0 is planned for *late 2010* and will only support *PHP 5.3.2*. This mean I (and others to) would have more time for integrate Symfony in PMA.
Should we open a separated development folder for this project?
Symfony has a full support for jQuery, so I think, it would be a good solution, to use it as our new JS-Framework?
Is it possible to make discussion about comments for html-output? It would be helpfull for me, to search in whole PMA-Scripts for it, and then sperate PHP from HTML. Many Thanks ;)
Regards Michael
Am 08.03.2010 17:14, schrieb Michal Čihař:
Hi
Dne Mon, 08 Mar 2010 09:07:27 +0100 Michael Keck sfnet@michaelkeck.de napsal(a):
Yes, why not? But it would really help me, if developers leave comments, what is for output. My goal is to seperate PMA-function from html (-output). This will support more flexibility for layout and theming and perhabs to invide developers to make only php code and others the html-output.
This is definitely needed for long time, thanks for volunteering!
But which should I use?
I've found follow template engines, and I want to get little feeadback which would be right and good for us:
* TWIG Link: http://www.twig-project.org/) Info: it's made from the same peoples wich made Symfony. What I say: It's really fast (see http://fabien.potencier.org/article/34/templating-engines-in-php)
I don't know anything about most of them, but the syntax of Twig looks same as Django uses and I use Django quite a lot these days (I understand this is really not a big argument for a project written in PHP :-))).
* Smarty Link: http://www.smarty.net/ Info: The most known. What I say: May be not a good choice. Marc gives me the link http://www.nosmarty.net
At my own, I think Symfony or Zend-Framework would be little overkill.
Well this website rather looks like it is against using separate template system and prefers using full featured frameworks. It might be not a bad idea, however it is much more work for us and because of this I'd stay with separate template system, but possibly with some where upgrade path to some framework would not be that hard.
Michael Keck a écrit :
Okay ...
... if I should use a PHP-Framework, I'm thinking we should use the newest Symfony and if released I would prefer use Symfony Reloaded 2.0 (http://symfony-reloaded.org/). The final release of Reloaded 2.0 is planned for *late 2010* and will only support *PHP 5.3.2*. This mean I (and others to) would have more time for integrate Symfony in PMA.
Should we open a separated development folder for this project?
Symfony has a full support for jQuery, so I think, it would be a good solution, to use it as our new JS-Framework?
Is it possible to make discussion about comments for html-output? It would be helpfull for me, to search in whole PMA-Scripts for it, and then sperate PHP from HTML. Many Thanks ;)
Regards Michael
Michael, I suggest you find volunteers for this project before starting it. Personally I don't have the time and energy to contribute to this rewrite.
Hi
Dne Mon, 08 Mar 2010 18:26:36 +0100 Michael Keck sfnet@michaelkeck.de napsal(a):
... if I should use a PHP-Framework, I'm thinking we should use the newest Symfony and if released I would prefer use Symfony Reloaded 2.0 (http://symfony-reloaded.org/). The final release of Reloaded 2.0 is planned for *late 2010* and will only support *PHP 5.3.2*. This mean I (and others to) would have more time for integrate Symfony in PMA.
Maybe it was not clear from me, but I think that we should really go just to templates, because using some framework would require much more changes in the code.
Should we open a separated development folder for this project?
Just a separate branch. Preferably wait with creating it after moving to git (I'll post schedule later today).
Is it possible to make discussion about comments for html-output? It would be helpfull for me, to search in whole PMA-Scripts for it, and then sperate PHP from HTML. Many Thanks ;)
I don't know what kind of comments you want, but as HTML output is really spread around the code, adding comments to identify it and then separate it in another step looks like double work.
Hello,
Am 09.03.2010 14:19, schrieb Michal Čihař:
Hi
Dne Mon, 08 Mar 2010 18:26:36 +0100 Michael Keck sfnet@michaelkeck.de napsal(a):
... if I should use a PHP-Framework, I'm thinking we should use the newest Symfony and if released I would prefer use Symfony Reloaded 2.0 (http://symfony-reloaded.org/). The final release of Reloaded 2.0 is planned for *late 2010* and will only support *PHP 5.3.2*. This mean I (and others to) would have more time for integrate Symfony in PMA.
Maybe it was not clear from me, but I think that we should really go just to templates, because using some framework would require much more changes in the code.
Okay I see this point ... then I will start with Twig.
Should we open a separated development folder for this project?
Just a separate branch. Preferably wait with creating it after moving to git (I'll post schedule later today).
No problem I can wait .... (I've not done anything cause im clonig at moment). But many thanks.
Is it possible to make discussion about comments for html-output? It would be helpfull for me, to search in whole PMA-Scripts for it, and then sperate PHP from HTML. Many Thanks ;)
I don't know what kind of comments you want, but as HTML output is really spread around the code, adding comments to identify it and then separate it in another step looks like double work.
I mean: if html is generated with php (like echo/print ...) * only in new code *, that would help me. Not in the current code, thats overkill ;) I prefer: /* <!-- HTML OUTPUT --> */ in php code. For direct HTML output (not with php echo/print etc.) I'm have a good script to search after in my IDE ;)
Michael Keck a écrit :
Hello,
Am 09.03.2010 14:19, schrieb Michal Čihař:
Hi
Dne Mon, 08 Mar 2010 18:26:36 +0100 Michael Keck sfnet@michaelkeck.de napsal(a):
... if I should use a PHP-Framework, I'm thinking we should use the newest Symfony and if released I would prefer use Symfony Reloaded 2.0 (http://symfony-reloaded.org/). The final release of Reloaded 2.0 is planned for *late 2010* and will only support *PHP 5.3.2*. This mean I (and others to) would have more time for integrate Symfony in PMA.
Maybe it was not clear from me, but I think that we should really go just to templates, because using some framework would require much more changes in the code.
Okay I see this point ... then I will start with Twig.
Michael, what is your plan? When someone downloads a future phpMyAdmin, will he get plain PHP that was compiled by Twig from the code base + templating syntax, or will he get the code base + templating syntax itself?
(I have not experienced Twig yet, just read a bit on their site).
Should we open a separated development folder for this project?
Just a separate branch. Preferably wait with creating it after moving to git (I'll post schedule later today).
No problem I can wait .... (I've not done anything cause im clonig at moment). But many thanks.
Is it possible to make discussion about comments for html-output? It would be helpfull for me, to search in whole PMA-Scripts for it, and then sperate PHP from HTML. Many Thanks ;)
I don't know what kind of comments you want, but as HTML output is really spread around the code, adding comments to identify it and then separate it in another step looks like double work.
I mean: if html is generated with php (like echo/print ...) * only in new code *, that would help me. Not in the current code, thats overkill ;) I prefer: /* <!-- HTML OUTPUT --> */ in php code. For direct HTML output (not with php echo/print etc.) I'm have a good script to search after in my IDE ;)
Hi,
downloading phpMyAdmin includes php files and template files. Compilation and caching is done by the local environment.
It mean: We will have new subdirectories called:
* skins/theme_name/ there are stored all things wich have directly to do with layout and theming (I will name it Front-End) with subfolders o styles for the theme/layout and jQuery-UI (Theme Roller) o jscripts for theme/layout specified functions o images for the theme/layout specified images o templates html files with TWIG-Syntax * libraries/twig/ template class * jscripts/jquery/ all new jQuery things * plugins/ for TinyMCE and others * _cache o templates o jscripts o styles o images (for browsers which can't handel png's) o files (uploading files like SQL-Dumps, tempfiles for exporting) this directory and any of it's subdir is dynamicly created
I prefer, to use for language and configuration files XML-structure to support the usage in javascript and php.
I think the rest shouldn't be needed to modify.
Michael
Am 09.03.2010 14:46, schrieb Marc Delisle:
Michael Keck a écrit :
Hello,
Am 09.03.2010 14:19, schrieb Michal Čihař:
Hi
Dne Mon, 08 Mar 2010 18:26:36 +0100 Michael Keck sfnet@michaelkeck.de napsal(a):
... if I should use a PHP-Framework, I'm thinking we should use the newest Symfony and if released I would prefer use Symfony Reloaded 2.0 (http://symfony-reloaded.org/). The final release of Reloaded 2.0 is planned for *late 2010* and will only support *PHP 5.3.2*. This mean I (and others to) would have more time for integrate Symfony in PMA.
Maybe it was not clear from me, but I think that we should really go just to templates, because using some framework would require much more changes in the code.
Okay I see this point ... then I will start with Twig.
Michael, what is your plan? When someone downloads a future phpMyAdmin, will he get plain PHP that was compiled by Twig from the code base + templating syntax, or will he get the code base + templating syntax itself?
(I have not experienced Twig yet, just read a bit on their site).
Should we open a separated development folder for this project?
Just a separate branch. Preferably wait with creating it after moving to git (I'll post schedule later today).
No problem I can wait .... (I've not done anything cause im clonig at moment). But many thanks.
Is it possible to make discussion about comments for html-output? It would be helpfull for me, to search in whole PMA-Scripts for it, and then sperate PHP from HTML. Many Thanks ;)
I don't know what kind of comments you want, but as HTML output is really spread around the code, adding comments to identify it and then separate it in another step looks like double work.
I mean: if html is generated with php (like echo/print ...) * only in new code *, that would help me. Not in the current code, thats overkill ;) I prefer: /* <!-- HTML OUTPUT --> */ in php code. For direct HTML output (not with php echo/print etc.) I'm have a good script to search after in my IDE ;)
Hi
Dne Tue, 09 Mar 2010 16:06:12 +0100 Michael Keck sfnet@michaelkeck.de napsal(a):
downloading phpMyAdmin includes php files and template files. Compilation and caching is done by the local environment.
It mean: We will have new subdirectories called:
* skins/theme_name/ there are stored all things wich have directly to do with layout and theming (I will name it Front-End) with subfolders o styles for the theme/layout and jQuery-UI (Theme Roller) o jscripts for theme/layout specified functions o images for the theme/layout specified images o templates html files with TWIG-Syntax * libraries/twig/ template class * jscripts/jquery/ all new jQuery things * plugins/ for TinyMCE and others * _cache o templates o jscripts o styles o images (for browsers which can't handel png's)
I don't think we care about such browsers as all our themes already use png.
o files (uploading files like SQL-Dumps, tempfiles for exporting) this directory and any of it's subdir is dynamicly created
The directory can not usually be automatically created because of permissions.
I prefer, to use for language and configuration files XML-structure to support the usage in javascript and php.
What we are currently planning (and I will work on that quite soon after finishing migration to Git) is to use Gettext for translations. Main reason for this is to use standard format where there are plenty tools which translators can use and we can easily provide web based interface to translations.
So when choosing templating system, it should easily integrate with gettext. Unfortunately I don't see any of mentioned system to talk about translations as their feature. (I mean something like translations in Django [1])
[1]:http://docs.djangoproject.com/en/dev/topics/i18n/internationalization/#speci...
Hi Michal,
Am 10.03.2010 09:53, schrieb Michal Čihař:
Hi
Dne Tue, 09 Mar 2010 16:06:12 +0100 Michael Keck sfnet@michaelkeck.de napsal(a):
downloading phpMyAdmin includes php files and template files. Compilation and caching is done by the local environment.
It mean: We will have new subdirectories called:
* skins/theme_name/ there are stored all things wich have directly to do with layout and theming (I will name it Front-End) with subfolders o styles for the theme/layout and jQuery-UI (Theme Roller) o jscripts for theme/layout specified functions o images for the theme/layout specified images o templates html files with TWIG-Syntax * libraries/twig/ template class * jscripts/jquery/ all new jQuery things * plugins/ for TinyMCE and others * _cache o templates o jscripts o styles o images (for browsers which can't handel png's)
I don't think we care about such browsers as all our themes already use png.
o files (uploading files like SQL-Dumps, tempfiles for exporting) this directory and any of it's subdir is dynamicly created
The directory can not usually be automatically created because of permissions.
Okay ... then we should distributed needed directories. But wat is with files ... (cached/compiled templates)? Same limitations as directories? I personality think, we should add documentation for setting rights on the new planned _cache/ directory.
I prefer, to use for language and configuration files XML-structure to support the usage in javascript and php.
What we are currently planning (and I will work on that quite soon after finishing migration to Git) is to use Gettext for translations. Main reason for this is to use standard format where there are plenty tools which translators can use and we can easily provide web based interface to translations.
So when choosing templating system, it should easily integrate with gettext. Unfortunately I don't see any of mentioned system to talk about translations as their feature. (I mean something like translations in Django [1])
Should not be a problem with Twig, I can use a filter ... Please take a look http://groups.google.com/group/twig-users/browse_thread/thread/53547a447d03f...
Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev
Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Hi
Dne Wed, 10 Mar 2010 10:49:44 +0100 Michael Keck sfnet@michaelkeck.de napsal(a):
Okay ... then we should distributed needed directories. But wat is with files ... (cached/compiled templates)?
Is it possible to distribute them? Generally having writable directory is problematic.
Same limitations as directories? I personality think, we should add documentation for setting rights on the new planned _cache/ directory.
Yes, we do so already for upload/save directories.
Should not be a problem with Twig, I can use a filter ... Please take a look http://groups.google.com/group/twig-users/browse_thread/thread/53547a447d03f...
This really does not look like native support and will probably need special tool to extract messages from the templates.
Michal Čihař a écrit :
Hi
Dne Wed, 10 Mar 2010 10:49:44 +0100 Michael Keck sfnet@michaelkeck.de napsal(a):
Okay ... then we should distributed needed directories. But wat is with files ... (cached/compiled templates)?
Is it possible to distribute them? Generally having writable directory is problematic.
Same limitations as directories? I personality think, we should add documentation for setting rights on the new planned _cache/ directory.
Yes, we do so already for upload/save directories.
Yes but these are optional features. We took great care of disabling these by defaut, knowing that many users have problems even with permission setting. Most users expect a solution that works out-of-the-box.
It might be different with distros, however. I don't really know how many users run phpMyAdmin via a distro but seeing our download rate, a huge number install it by themselves.
Okay,
I see the points. Then by default caching is disabled. I can distribute the compiled templates, but cached templates makes no sense, because theese are genereted by the installed environment. It means the cached files includes servers, databases, language specific things etc. Caching would be only a feature to improve perfomance.
Compiled templates are mainly php files. Perhabs, the we don't need to distribute the template sources, only the compiled version of them is required. For developers we can distribute a default template source. For us we should perhabs store all template sources in an etxra trunk?
Regards Michael
Am 12.03.2010 12:18, schrieb Marc Delisle:
Michal Čihař a écrit :
Hi
Dne Wed, 10 Mar 2010 10:49:44 +0100 Michael Keck sfnet@michaelkeck.de napsal(a):
Okay ... then we should distributed needed directories. But wat is with files ... (cached/compiled templates)?
Is it possible to distribute them? Generally having writable directory is problematic.
Same limitations as directories? I personality think, we should add documentation for setting rights on the new planned _cache/ directory.
Yes, we do so already for upload/save directories.
Yes but these are optional features. We took great care of disabling these by defaut, knowing that many users have problems even with permission setting. Most users expect a solution that works out-of-the-box.
It might be different with distros, however. I don't really know how many users run phpMyAdmin via a distro but seeing our download rate, a huge number install it by themselves.
Michael Keck a écrit :
Okay,
I see the points. Then by default caching is disabled. I can distribute the compiled templates, but cached templates makes no sense, because theese are genereted by the installed environment. It means the cached files includes servers, databases, language specific things etc. Caching would be only a feature to improve perfomance.
We'll have to see what kind of performance we get without caching.
Compiled templates are mainly php files. Perhabs, the we don't need to distribute the template sources, only the compiled version of them is required.
This is why I asked a question, in a previous message. Templates are done for who? The developers? Would they be beneficial also to anyone who wants to contribute/modify the code?
What is the real goal of going to templates?
For developers we can distribute a default template source. For us we should perhabs store all template sources in an etxra trunk?
I don't have experience with templating systems to offer insight about this question.
Regards Michael
Hi Marc,
Am 12.03.2010 12:41, schrieb Marc Delisle:
Michael Keck a écrit :
Okay,
I see the points. Then by default caching is disabled. I can distribute the compiled templates, but cached templates makes no sense,because theese are genereted by the installed environment. It means the cached files includes servers, databases, language specific things etc. Caching would be only a feature to improve perfomance.
We'll have to see what kind of performance we get without caching.
On things, wich are not changed every time, caching increase performance. Please take a look at: http://www.ohrensessel-filme.de. This page loads 10 times faster with cache. Templates are only written, if any thing has been changed, means html-files are written and then included. Otherwise, the cache file is used, it means php includes a html-file.
Compiled templates are mainly php files. Perhabs, the we don't need to distribute the template sources, only the compiled version of them is required.
This is why I asked a question, in a previous message. Templates are done for who?
The compiled for all, the sources for developers and interested peoples only. A compiled version of a template is like a procedural php-file with some functions and is written by the template-engine from the sources.
The developers?
Yes.
Would they be beneficial also to anyone who wants to contribute/modify the code?
Yes, they only need to modify the skin (sources), not the functional of phpMyAdmin. That's the pro.
What is the real goal of going to templates?
* Separate php-code from html output * Making layouting and theming (I call this skins) more flexible. * User can download the source of a base skin and build there own: They don't need anything know about functional things in phpMyAdmin. o If in user's environment, permission is set to write files and directories they can directly use their skin o If a user want to share his skin, he can upload his skin-sources in theme tracker. o Then we can check and compile and release it.
* Less security problems, cause only skins are changed, phpmyadmin core functions are excluded from this. Things wich are not supported, allowed or restricted are ignored by the template engine. * Better bugfixing: we know directly where the bug is, in skin or in pma-functions
I get this idea of template-based phpMyAdmin, cause I have some problems to fix the current themes (which are at the moment done only with cascading stylesheet) of changed html-code in php-functions:
* ID's are changed, * clases are changed * new icons * new features
This is not flexible enough (see i.e. artic-ocean, I've to write a terribble fix to make navigationbar fixed).
For developers we can distribute a default template source. For us we should perhabs store all template sources in an etxra trunk?
I don't have experience with templating systems to offer insight about this question.
I mean, we have in svn/git a '/themes' folder? Perhabs I would add new one: '/skins' with the subdirs '/skins/sources/' and '/skins/compiled/'.
Regards Michael
Michael Keck a écrit :
Hi Marc,
Am 12.03.2010 12:41, schrieb Marc Delisle:
Michael Keck a écrit :
Okay,
I see the points. Then by default caching is disabled. I can distribute the compiled templates, but cached templates makes no sense,because theese are genereted by the installed environment. It means the cached files includes servers, databases, language specific things etc. Caching would be only a feature to improve perfomance.
We'll have to see what kind of performance we get without caching.
On things, wich are not changed every time, caching increase performance. Please take a look at: http://www.ohrensessel-filme.de. This page loads 10 times faster with cache.
It surely loads fast right now: Error 500 - Internal server error
Ein interner Fehler ist aufgetreten! Bitte versuchen Sie es zu einem späteren Zeitpunkt.
Michael Keck a écrit :
* Separate php-code from html output
Michael, are you sure of this? Looking at http://www.twig-project.org/ I am under the impression that the goal is to express HTML output in a cleaner way but the template expressions are still interspersed into the PHP code.
Also, I wanted to do some refactoring because there is too much repetition of HTML output currently in our codebase. I don't like repetition. I don't like repetition.
I would really like to see a small test -- say, just one phpMyAdmin small file translated into Twig.
Hi
Dne Fri, 12 Mar 2010 08:09:56 -0500 Marc Delisle marc@infomarc.info napsal(a):
Also, I wanted to do some refactoring because there is too much repetition of HTML output currently in our codebase. I don't like repetition. I don't like repetition.
I would really like to see a small test -- say, just one phpMyAdmin small file translated into Twig.
I think it is great idea to convert some simple page to use template engine. At least we will get an idea what to expect and how big amount of work it is.
I will post soon as possibe a link, to show ... at the moment I'm busy ...
Regards Michael
Am 12.03.2010 14:44, schrieb Michal Čihař:
Hi
Dne Fri, 12 Mar 2010 08:09:56 -0500 Marc Delisle marc@infomarc.info napsal(a):
Also, I wanted to do some refactoring because there is too much repetition of HTML output currently in our codebase. I don't like repetition. I don't like repetition.
I would really like to see a small test -- say, just one phpMyAdmin small file translated into Twig.
I think it is great idea to convert some simple page to use template engine. At least we will get an idea what to expect and how big amount of work it is.
Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev
Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Hi
Dne Fri, 12 Mar 2010 13:43:44 +0100 Michael Keck sfnet@michaelkeck.de napsal(a):
On things, wich are not changed every time, caching increase performance. Please take a look at: http://www.ohrensessel-filme.de. This page loads 10 times faster with cache. Templates are only written, if any thing has been changed, means html-files are written and then included. Otherwise, the cache file is used, it means php includes a html-file.
Well the interface parts do not change, while the data will change quite a lot in our case. As the templates are compiled to PHP code, I don't think they add that much overhead. Of course it will improve a lot for websites like you linked, which has most of the content really static, but I don't think this is the case for phpMyAdmin. And we need to show up to date data (nobody is interested to seeing listing of tables he had ten seconds ago, but for the current listing).
I mean, we have in svn/git a '/themes' folder? Perhabs I would add new one: '/skins' with the subdirs '/skins/sources/' and '/skins/compiled/'.
Yes, we would add new repository for templates. But this can wait until the code is ready.
Hi
Dne Fri, 12 Mar 2010 12:33:09 +0100 Michael Keck sfnet@michaelkeck.de napsal(a):
I see the points. Then by default caching is disabled. I can distribute the compiled templates, but cached templates makes no sense, because theese are genereted by the installed environment. It means the cached files includes servers, databases, language specific things etc. Caching would be only a feature to improve perfomance.
Okay, then this needs to be disabled by default (and can be for example enabled by distros).
Compiled templates are mainly php files. Perhabs, the we don't need to distribute the template sources, only the compiled version of them is required. For developers we can distribute a default template source. For us we should perhabs store all template sources in an etxra trunk?
It should be same as is with current themes - basic set (or maybe just default one) will be in main repository and contributed ones will be stored in other.
When doing release, the compiled ones will be created and stored in release file (same needs to be done with Gettext).
Hi all,
I'm preparing the transition to template-based framework. My question is: Should we add for this a new trunk and perhabs a new version to differ what is now development without templates and what is with templates? I suggest to make a complete new major version, perhabs Version 5, cause my goal is to finish templating before Version 5 is released.
Michal, please can you open an new trunk for it, after discussion? I'm new to git, I don't know how to create a new trunk.
Regards Michael
Hi
Dne Fri, 12 Mar 2010 10:17:42 +0100 Michael Keck sfnet@michaelkeck.de napsal(a):
I'm preparing the transition to template-based framework. My question is: Should we add for this a new trunk and perhabs a new version to differ what is now development without templates and what is with templates?
It should probably go to separate branch.
I suggest to make a complete new major version, perhabs Version 5, cause my goal is to finish templating before Version 5 is released.
I don't think there is reason for skipping version 4 ;-). Anyway there will be probably quite a lot of changes in next release, so it might sense to call it 4.0.
Michal, please can you open an new trunk for it, after discussion? I'm new to git, I don't know how to create a new trunk.
This should help you:
http://wiki.phpmyadmin.net/pma/Devel:Git#Working_on_new_features
Hey all,
Here is a speed comparison between a number of major js libraries, which may aid in your decision: http://mootools.net/slickspeed/
Also, you may want to weigh the pros and cons of the methodologies of the different frameworks, e.g. jQuery keeps all its functionality separated into a separate jQuery object and is therefore less likely to interfere with other js, whereas Prototype prototypes onto the js object classes directly.
On 03/05/2010 06:52 AM, Michael Keck wrote:
Am 05.03.2010 10:55, schrieb Michal Čihař:
Hi
Dne Fri, 05 Mar 2010 10:27:15 +0100 Michael Keck sfnet@michaelkeck.de napsal(a):
that's the point why I prefer jQuery. First building full functional a web app without any javascript. Then with jQuery add animations, effects, styles and behaviors to dom elements.
I don't think it's much different with mootools.
I don't know mootools in details, but I think it's more a developer preference. Somebody likes mootools, other prototype, next ext.js and others jquery. But I guess with Marc, we should use one js-framework at the moment wich is the best for us at the moment.
Perhabs, we should use a template engine (like smarty), for seperating code and layout. Perhabs this would make adding styles and themes easier. Other point is, all things, that have not to do with core functions, could be add to the templates, like plugins, effects or javascripts. And with templates we are able to cache basics, like menus, help, forms etc. This would increase performance.
Yes, we already agreed some time ago that it would be great to use templates, but it is quite a lot work which nobody did to far :-).
I will try to do this with smarty. But you're right it's really quite a lot of work. It would be nice, to comment in the current development all html-outputs with a special comment to search for it. I'm working at the moment on a smarty port in a seperated development environment and it's really diffucult to get all html outputs by reading each script and code.
Then it's possible to create with templates different pma environments:
- with javascript
- without javascript
- for text browsers
- for PDAs
- etc.
The other point with a template base soulution is, it doesn't really matter wich framework for javascript is used. Cause it's included in the templates.
A other great thing is, other great oss projects are able to use our core functional in their own applications.
Regards Michael
Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev
Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Sonny Michaud a écrit :
Hey all,
Here is a speed comparison between a number of major js libraries, which may aid in your decision: http://mootools.net/slickspeed/
Also, you may want to weigh the pros and cons of the methodologies of the different frameworks, e.g. jQuery keeps all its functionality separated into a separate jQuery object and is therefore less likely to interfere with other js, whereas Prototype prototypes onto the js object classes directly.
Thanks Sonny. This test page uses jQuery 1.2.6 but the current release is 1.4.2.
Just wondering, whats this discussion about? Is it about using AJAX and a better UI in phpMyAdmin or is it about which framework to use. I both the case I guess people want to shift towards a Framework other than mootools, and I guess everyone seems to be happy with JQuery. I may be wrong and in that case please *enlighten *me.
On Fri, Mar 5, 2010 at 8:16 PM, Marc Delisle marc@infomarc.info wrote:
Sonny Michaud a écrit :
Hey all,
Here is a speed comparison between a number of major js libraries, which may aid in your decision: http://mootools.net/slickspeed/
Also, you may want to weigh the pros and cons of the methodologies of the different frameworks, e.g. jQuery keeps all its functionality separated into a separate jQuery object and is therefore less likely to interfere with other js, whereas Prototype prototypes onto the js object classes directly.
Thanks Sonny. This test page uses jQuery 1.2.6 but the current release is 1.4.2.
-- Marc Delisle http://infomarc.info
Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Rohit Kalhans a écrit :
Just wondering, whats this discussion about? Is it about using AJAX and a better UI in phpMyAdmin or is it about which framework to use. I both the case I guess people want to shift towards a Framework other than mootools, and I guess everyone seems to be happy with JQuery. I may be wrong and in that case please /enlighten /me.
The discussion should be about what's in the subject line (switching to jQuery) and indeed we'll do the switch.
Hey,
On Thu, Mar 4, 2010 at 7:29 PM, Michael Keck sfnet@michaelkeck.de wrote:
Hi all,
my own opinion is to use jQuery, cause it's stable fast and has lo's of plugins and a themeable UI.
Apart for this JQuery provides support for AJAX in the easiest way possible and is Quite fast, Using AJAX in phpMyAdmin will possibly improve the user experience especially those using it on slow connections.
It's easy to learn, cause it's really good documented. The other point is, I've developed some plugins like grid (for the table view), UI-Uploader (a uploading tool for files) and the planned WYSIWYG Html-Editor wich I prefer is TinyMCE. This editor is jQuery compatible.
Of course it is, and this will certainly improve the developers' involvement in the phpMyAdmin project.
Perhaps we should make a discussion or vote, wich js-framework we should use for phpMyAdmin.
Regards Michael
Am 04.03.2010 13:11, schrieb Michal Čihař:
Hi
Dne Thu, 4 Mar 2010 14:25:38 +0300 Pavel Konnikov konnikov@gmail.com konnikov@gmail.com napsal(a):
I'm trying to make enum and set editors (https://sourceforge.net/tracker/index.php?func=detail&aid=1494550&gr...). I added the special button near text input (see attachment enum-button.png). When you click on the button, editor dialog are shown.
Looks nice.
And i have a question about possibility of using jquery ui dialog for this.
In js/ folder i'm seeing only mootols js-framework. And i made custom dialog for enum editor (see attachment enum-editor.png). But i think that jquery ui dialog is better solution for this task (http://jqueryui.com/demos/dialog/modal-form.html).
What do you think?
I personally do not have any preference to jquery or mootools and I can't tell which one is better. On the other side we already use mootools for some things and it is definitely not a good idea to include both of them.
So the option is either to migrate everything to jquery or to find some mootools based solution.
And just a quick search showed me also several modal window scripts, for example http://netzelf.de/releases/yamoodow/
Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev
Phpmyadmin-devel mailing listPhpmyadmin-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel