[Phpmyadmin-devel] fckeditor support for TEXT fields

[Marc Delisle]

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 at 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=377411
>>> [2]:https://sourceforge.net/tracker/?func=detail&aid=1611770&group_id=23067&atid=377411
>>>
>>> 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.
>>>     
>>
>>
>>