[Phpmyadmin-devel] fckeditor support for TEXT fields
Hi, any objection about integrating fckeditor[0] to TEXT field in insert/edit modes? [0] See http://www.fckeditor.net/demo Marc
Marc Delisle wrote:
Hi, any objection about integrating fckeditor[0] to TEXT field in insert/edit modes?
[0] See http://www.fckeditor.net/demo
I myself am more a fan of tinymce [1], but the issue is more general weather we should integrate a wysiwyg editor. When the content is HTML I immediately agree that a wysiwyg editor is nice to have, however we must ensure that it does not break other types of content. One additional objection is that these editors are generally a lot slower that a plain text-area. It should therefore be configurable weather it is used at all. Even better would be to make it configurable per mime-type. One additional thing I like which the Drupal wysiwyg API [2] has included is a simple "Disable rich-text" link below the editor to convert back to a regular text area. [1] http://tinymce.moxiecode.com/ [2] http://drupal.org/project/wysiwyg Herman
Herman van Rink a écrit :
Marc Delisle wrote:
Hi, any objection about integrating fckeditor[0] to TEXT field in insert/edit modes?
[0] See http://www.fckeditor.net/demo
I myself am more a fan of tinymce [1], but the issue is more general weather we should integrate a wysiwyg editor.
When the content is HTML I immediately agree that a wysiwyg editor is nice to have, however we must ensure that it does not break other types of content. One additional objection is that these editors are generally a lot slower that a plain text-area.
It should therefore be configurable weather it is used at all. Even better would be to make it configurable per mime-type.
One additional thing I like which the Drupal wysiwyg API [2] has included is a simple "Disable rich-text" link below the editor to convert back to a regular text area.
[1] http://tinymce.moxiecode.com/ [2] http://drupal.org/project/wysiwyg
Yes there would be some config.inc.php (and probably user preference setting) to activate or not the editor. What do you mean, per mime-type? Do you have in mind launching GIMP for jpeg, for example? About disabling, these editors usually have a "source" button, isn't this sufficient? Marc
Marc Delisle wrote:
Herman van Rink a écrit :
Marc Delisle wrote:
Hi, any objection about integrating fckeditor[0] to TEXT field in insert/edit modes?
[0] See http://www.fckeditor.net/demo
I myself am more a fan of tinymce [1], but the issue is more general weather we should integrate a wysiwyg editor.
When the content is HTML I immediately agree that a wysiwyg editor is nice to have, however we must ensure that it does not break other types of content. One additional objection is that these editors are generally a lot slower that a plain text-area.
It should therefore be configurable weather it is used at all. Even better would be to make it configurable per mime-type.
One additional thing I like which the Drupal wysiwyg API [2] has included is a simple "Disable rich-text" link below the editor to convert back to a regular text area.
[1] http://tinymce.moxiecode.com/ [2] http://drupal.org/project/wysiwyg
Yes there would be some config.inc.php (and probably user preference setting) to activate or not the editor.
What do you mean, per mime-type? Do you have in mind launching GIMP for jpeg, for example?
Not directly, but it would be nice if the code/api for this would allow additional editors for specific content types. What Michal suggested, to base it on the transformation info we already have, also looks promising.
About disabling, these editors usually have a "source" button, isn't this sufficient?
Yes, that could be ok. Herman
Hi Dne Wed, 03 Jun 2009 06:35:15 -0400 Marc Delisle <marc@infomarc.info> napsal(a):
any objection about integrating fckeditor[0] to TEXT field in insert/edit modes?
Not unconditionally. I would prefer to have transformation options also for editing, so that you can use wysiwig editor for HTML, but not only limiting to this. PS: I more prefer TinyMCE. -- Michal Čihař | http://cihar.com | http://blog.cihar.com
Michal Čihař a écrit :
Hi
Dne Wed, 03 Jun 2009 06:35:15 -0400 Marc Delisle <marc@infomarc.info> napsal(a):
any objection about integrating fckeditor[0] to TEXT field in insert/edit modes?
Not unconditionally. I would prefer to have transformation options also for editing, so that you can use wysiwig editor for HTML, but not only limiting to this.
PS: I more prefer TinyMCE.
I think that transformations require the PMADB mechanism? so more users would not have access to them by default. Also, I would not be in favor of having more than one such editor integrated. Do you have other "transformations" in mind for this case? Note that currently, with the display options (in browse mode), user has a certain latitude for display. Also, transformations imply some API we have to prepare, with the idea of attracting developers; so I wonder if we can have an API generic enough in this case. It probably depends on what other transformations would be supported. Marc
Hi Dne Wed, 03 Jun 2009 08:43:02 -0400 Marc Delisle <marc@infomarc.info> napsal(a):
I think that transformations require the PMADB mechanism?
Yes.
so more users would not have access to them by default.
Yes, but we can hardly do something about it. But we're anyway going to this direction (per user configuration).
Also, I would not be in favor of having more than one such editor integrated. Do you have other "transformations" in mind for this case? Note that currently, with the display options (in browse mode), user has a certain latitude for display.
After quick look into our feature tracker, we could offer at least following editors: - input - textarea - wysiwig - textarea with deserialized data [1] - textarea with hexadecimal data [2] [1]:https://sourceforge.net/tracker/?func=detail&aid=1615116&group_id=23067&atid... [2]:https://sourceforge.net/tracker/?func=detail&aid=1611770&group_id=23067&atid... There would be definitely more options and configuring this per whole phpMyAdmin installation does not make sense.
Also, transformations imply some API we have to prepare, with the idea of attracting developers; so I wonder if we can have an API generic enough in this case. It probably depends on what other transformations would be supported.
The API can be based on our current transformations - the function which will display edit form can get same parameters, the function for fetching updated data would get current row of form. I definitely miss something here, but I don't see why it should be complex. -- Michal Čihař | http://cihar.com | http://blog.cihar.com
Michal Čihař a écrit :
Hi
Dne Wed, 03 Jun 2009 08:43:02 -0400 Marc Delisle <marc@infomarc.info> napsal(a):
I think that transformations require the PMADB mechanism?
Yes.
so more users would not have access to them by default.
Yes, but we can hardly do something about it. But we're anyway going to this direction (per user configuration).
Also, I would not be in favor of having more than one such editor integrated. Do you have other "transformations" in mind for this case? Note that currently, with the display options (in browse mode), user has a certain latitude for display.
After quick look into our feature tracker, we could offer at least following editors:
- input - textarea - wysiwig - textarea with deserialized data [1] - textarea with hexadecimal data [2]
[1]:https://sourceforge.net/tracker/?func=detail&aid=1615116&group_id=23067&atid... [2]:https://sourceforge.net/tracker/?func=detail&aid=1611770&group_id=23067&atid...
There would be definitely more options and configuring this per whole phpMyAdmin installation does not make sense.
But... I don't like the idea of having to configure this for each column (unless you have something else in mind). Well in some situations, per column could make sense but not generally.
Also, transformations imply some API we have to prepare, with the idea of attracting developers; so I wonder if we can have an API generic enough in this case. It probably depends on what other transformations would be supported.
The API can be based on our current transformations - the function which will display edit form can get same parameters, the function for fetching updated data would get current row of form. I definitely miss something here, but I don't see why it should be complex.
Hi Michael, I remember now :) and in your integration the editor's language follows the PMA one. Michael Keck a écrit :
Hi all,
I've made an integration of TinyMCE since Version 2.9.x month ago. Here you can see the demo: http://www.michaelkeck.de/projects/pma/demo/
Regards Michael
--- Original Message --- Mail from: Marc Delisle Date: 03.06.2009 15:50
Michal �iha� a écrit :
Hi
Dne Wed, 03 Jun 2009 08:43:02 -0400 Marc Delisle <marc@infomarc.info> napsal(a):
I think that transformations require the PMADB mechanism?
Yes.
so more users would not have access to them by default.
Yes, but we can hardly do something about it. But we're anyway going to this direction (per user configuration).
Also, I would not be in favor of having more than one such editor integrated. Do you have other "transformations" in mind for this case? Note that currently, with the display options (in browse mode), user has a certain latitude for display.
After quick look into our feature tracker, we could offer at least following editors:
- input - textarea - wysiwig - textarea with deserialized data [1] - textarea with hexadecimal data [2]
[1]:https://sourceforge.net/tracker/?func=detail&aid=1615116&group_id=23067&atid... [2]:https://sourceforge.net/tracker/?func=detail&aid=1611770&group_id=23067&atid...
There would be definitely more options and configuring this per whole phpMyAdmin installation does not make sense.
But... I don't like the idea of having to configure this for each column (unless you have something else in mind). Well in some situations, per column could make sense but not generally.
Also, transformations imply some API we have to prepare, with the idea of attracting developers; so I wonder if we can have an API generic enough in this case. It probably depends on what other transformations would be supported.
The API can be based on our current transformations - the function which will display edit form can get same parameters, the function for fetching updated data would get current row of form. I definitely miss something here, but I don't see why it should be complex.
Hi Dne Wed, 03 Jun 2009 16:38:20 +0200 Michael Keck <sfnet@michaelkeck.de> napsal(a):
I've made an integration of TinyMCE since Version 2.9.x month ago. Here you can see the demo: http://www.michaelkeck.de/projects/pma/demo/
Hmm, this way it looks good! I was just thinking about replacing textarea, what is something I did not like. -- Michal Čihař | http://cihar.com | http://phpmyadmin.cz
Michal Čihař a écrit :
Hi
Dne Wed, 03 Jun 2009 16:38:20 +0200 Michael Keck <sfnet@michaelkeck.de> napsal(a):
I've made an integration of TinyMCE since Version 2.9.x month ago. Here you can see the demo: http://www.michaelkeck.de/projects/pma/demo/
Hmm, this way it looks good! I was just thinking about replacing textarea, what is something I did not like.
Indeed it looks good, plus it integrates nicely with the general way we offer special editing for fields like dates and foreign keys (when there any too many foreign values). Michael, can you share again the link to the zip file containing this integration? I volunteer to merge this into trunk. Michal, I'm not against offering more features like you wrote: 1. input 2. textarea 3. wysiwig 4. textarea with deserialized data 5. textarea with hexadecimal data but with Michael's proposal, I don't think we would need 1, 2 and 3. About 4 and 5, maybe show more option icons next to the textarea? This way we remove the burden of configuration and give back the power to users in the interface. Marc
Hi Dne Fri, 05 Jun 2009 05:42:16 -0400 Marc Delisle <marc@infomarc.info> napsal(a):
Indeed it looks good, plus it integrates nicely with the general way we offer special editing for fields like dates and foreign keys (when there any too many foreign values).
Michael, can you share again the link to the zip file containing this integration? I volunteer to merge this into trunk.
Michal, I'm not against offering more features like you wrote: 1. input 2. textarea 3. wysiwig 4. textarea with deserialized data 5. textarea with hexadecimal data
but with Michael's proposal, I don't think we would need 1, 2 and 3. About 4 and 5, maybe show more option icons next to the textarea? This way we remove the burden of configuration and give back the power to users in the interface.
Yes, it might be an option. But the hex data you will probably want to use on BLOBs, where we do not have any editor right now... -- Michal Čihař | http://cihar.com | http://blog.cihar.com
participants (4)
-
Herman van Rink -
Marc Delisle -
Michael Keck -
Michal Čihař