Multi configuration editor

guillaumed · 2005-03-25 04:09:55

Hello,

With the development of functionalities on Xinha (hope it will continue...) the toolbar of the editor must be long and perhaps some buttons are really unusefull for rapid modification.

I have developped and extension (currently not a plugin for stupid implementation reason.. ) allowing to increase dynamically the functionality of the editor (its toolbar).

http://www.studiogdo.com/xinha/htmlarea … multi.html

I don't like how the code is currently written but it works, if others are finding this functionality interesting I will continue to develop it in a better way (if I can..)

A+

mokhet · 2005-05-21 02:22:07

If someone is wondering, it can be found here http://www.studiogdo.com/xinha/multi.html and it is very interesting.

I always loved the comments we can find in almost every source code. Oui guillaumed, je suis 100% d'accord avec toi, non mais

    _editor_lang = "fr"; // yep, there are other languages than "en"...

gea · 2005-05-24 07:31:16

hello guillaumed

i believe that your multiconfiguration editor is a must have for xinha.
normally i only want to offer a basic toolbar to the persons, wo are
editing the pages via my cms.

example toolbar:
special characters bold, italic, underline, <p>, <h1>..<h3>, align

but nothing else.

i can reach the other editing possibilities with your multiconfiguration
editor depending on user or page properties.

i have just integrated it in my html-cms babelcon at our university
an its just simple and perfect. -> http://info.hfg-gmuend.de/content/editor.jpg

ps
im good in programming with perl but not javascript,
so please continue your work.

please add the posibility to use
-several independant textareas
-configuration depending to the name of a textarea

it would be nice if you can integrate it in the default setup of xinha.

merci and
thanks a lot for your work

guenther

guillaumed · 2005-05-24 08:44:25

mokhet wrote:

je suis 100% d'accord avec toi, non mais

guillaumed · 2005-05-24 08:53:39

gea wrote:

please add the posibility to use
-several independant textareas
-configuration depending to the name of a textarea

I will do, but currently I am working to integrate Xhina in MyFaces.. But I'm thinking of a better implementation using the new design made by gogo..

gea wrote:

it would be nice if you can integrate it in the default setup of xinha.

It is up to gogo to decide...

gea wrote:

thanks a lot for your work

Thanks to you, it is always good to get such encouragements...
Promise I will continue... with other perhaps...?

gogo · 2005-05-24 17:08:05

It is up to gogo to decide...

Once version 1 is done, the toolbars system is due for a rethink and rewrite, I want to clean that whole thing up and am thinking about having "named" groups in toolbars so that a plugin can insert a button into a certain group of buttons (eg insert a button into the "character" group, or into the "lists" group or the "control" group etc....) rather than just smushing them onto the start or end of the bar without any care.

At the same time we will take a look at allowing for expanding and contracting the groups in the toolbar with a handle on the edge of each group and perhaps even rearranging them via drag-drop and saving the positions in a cookie, now that would be cool.

We may take a look at implementing progressive loading of plugins also, however I'm still not convinced that it's worth the extra trouble to save a few seconds of loading time.

guillaumed · 2005-05-25 02:48:41

gogo wrote:

Once version 1 is done..

I agree with you V1 should be the main focus.. I try to understand how I can help but I don't understand why "Tickets to be completed for V1.0" contains trunk elements and is not ordered by priority (I wasn't able to find your reply telling that the Xinha team shoiuld define the priority).

gogo wrote:

At the same time we will take a look at allowing for expanding and contracting the groups in the toolbar with a handle on the edge of each group and perhaps even rearranging them via drag-drop and saving the positions in a cookie, now that would be cool.

That's exactly what I was thinking..

If this thread can serve to start discussing ideas about that point which will be developped after V1 released (and champagne drinken) :

- Using the separator as a tag for declaring group seems good for me (as more explicit on your new design)

- I don't think that having only an handle on the edge of each group is a good idea. Using the separator to shrink will be ok but then the group should completly diseaper and then I would prefer one global button allowing a dialog for checking all the group displayed.

- For defining the name of the group, I propose to add this name to the separator which serves for starting group then the name should be something like ["separator:group1"..."separator:group2"]. Unamed group won't be checkable but then all old configurations still works.

- I consider this code should be still implemented as a plugin (then shrink/display would be available only when loaded) ?

We may take a look at implementing progressive loading of plugins also, however I'm still not convinced that it's worth the extra trouble to save a few seconds of loading time.

Loading time is not the main reason for me (even that shorter Xinha will be, better it will): consider the Linker plugin, why don't you imagine that there could be several "Linker" implementations which should be defined on need (on content for example or due to the fact that I ask for a more and more powerfull one) and not at start.

For doing that now the only way is to create one super plugin which will put such on-demand loading in my plugin, but I think this is exactly the kind of functionality that Xinha core should provide... Otherwise we will face a lot of synchronisation problem and cohenrency.

gogo · 2005-05-25 05:48:53

I agree with you V1 should be the main focus.. I try to understand how I can help but I don't understand why "Tickets to be completed for V1.0" contains trunk elements and is not ordered by priority (I wasn't able to find your reply telling that the Xinha team shoiuld define the priority).

Trunk is because thats where we are working, on the trunk, when V1 is done and released it will become a branch and tickets specific to V1 and not V2 would be assigned to the V1 branch, while tickets specific to V2 development are assigned to trunk.

The tickets are shown ordered by priority, the severity is a different thing. Severity should be set by the ticket submitted (so if they think something is very serious they select serious) it is an indicator of how bad the problem is, Priority on the other hand should be set by the Xinha developers after looking at the ticket, it is an indicator of how quickly we should look at the problem in relation to other problems. But really the ordering doesn't matter, just pick something you can do and do it

For defining the name of the group, I propose to add this name to the separator which serves for starting group then the name should be something like ["separator:group1"..."separator:group2"]. Unamed group won't be checkable but then all old configurations still works.

No, I was thinking of turning the current toolbar array into a toolbar object

this.toolbar =
  {
     'character' : ['color', 'font', 'size'],
     'control'     : ['htmlmode', 'infopopup']
  }

etc. Then plugins can do toolbar.control.push(my_new_control_button_here)

Loading time is not the main reason for me (even that shorter Xinha will be, better it will): consider the Linker plugin, why don't you imagine that there could be several "Linker" implementations which should be defined on need (on content for example or due to the fact that I ask for a more and more powerfull one) and not at start.

But shouldn't it be that you just extend Linker into your own plugin which caters for all your needs, or make a Meta-plugin that combines features from other plugins etc etc. I can't really imagine a situation where you would be benefited by being able to "unregister" a plugin and then register another plugin in it's place, without reloading the page.

gogo · 2005-05-25 05:52:22

Forgot..

all old configurations still works

nope, not on your nelly, Version 1 configs are extremely unlikely to work for Version 2, that's why it's going to be Version 2 and not Version 1.x, different major numbers = not expected to be backwards compatable.

guillaumed · 2005-05-25 07:44:36

If you don't want backward compatibility I also prefer your option... I didn't understand that V1 will die so quickly

gogo wrote:

being able to "unregister" a plugin

I don't think of unregister a plugin but defining if or which plugin should be registered can be defined in execution not at start. If you force plugin to be defined at start, it will be a limitation for Xinha, but Xinha power comes from plugin extension... By the way, don't you think that Xinha is a kind of Meta Plugin?

gogo · 2005-05-25 10:19:20

I didn't understand that V1 will die so quickly

New features would not be added to the V1 branch except if really necessary, bugfixes would of course be maintained there. But there is no point in striving for backwards compatability with V1.0 in v2 as it will just hinder development.

Xinha Discussion Forum

Announcement

#1 2005-03-25 04:09:55

Multi configuration editor

#2 2005-05-21 02:22:07

Re: Multi configuration editor

#3 2005-05-24 07:31:16

Re: Multi configuration editor

#4 2005-05-24 08:44:25

Re: Multi configuration editor

#5 2005-05-24 08:53:39

Re: Multi configuration editor

#6 2005-05-24 17:08:05

Re: Multi configuration editor

#7 2005-05-25 02:48:41

Re: Multi configuration editor

#8 2005-05-25 05:48:53

Re: Multi configuration editor

#9 2005-05-25 05:52:22

Re: Multi configuration editor

#10 2005-05-25 07:44:36

Re: Multi configuration editor

#11 2005-05-25 10:19:20

Re: Multi configuration editor

Board footer