Announcement

Do not use the forums to submit bug reports, feature requests or patches, submit a New Ticket instead.

#1 2006-04-13 15:02:20

ianb
Xinha Community Member
Registered: 2005-05-17
Posts: 10

'unobtrusive' enabling of Xinha?

Does anyone have any code to set up Xinha editors declaratively?  Something like:

  <script type="text/javascript" src="enable_xinha.js"></script>
  <textarea name="content" type="xinha" plugins="A,B,C"></textarea>

What exactly it would look like, I'm not sure.  Some options could be controlled with attributes, others might be best controlled with callbacks.

We're getting ready to write something like this, but if someone has already done this that would be great.  Also, including something like this with Xinha would also be great (I think one of the things that people really like about TinyMCE is this method of setting it up).

Offline

#2 2006-04-14 08:27:45

steveo125
Xinha Community Member
Registered: 2006-04-04
Posts: 24

Re: 'unobtrusive' enabling of Xinha?

I've not seen such a system.  But I also can't see a massive advantage to it in terms of end results.  It would just be an alternate way of doing everything which can be done via the  'xinha_init = xinha_init ? xinha_init : function()' approach as detailed in the newbie guide (method 2).

Using javascript it is possible to configure each text area with different settings and you have access to the full range of xinha configurables, so it's pretty powerful. (But I've never seen a definitive list of these options without looking at the code).

Basically, even putting the parameters as textarea attributes is going to involve writing extra information into the html so it may as well be JS as textarea attributes.

If you do write something to do this then it could be done as a plugin fairly easily I think.

Offline

#3 2006-04-14 11:52:26

ianb
Xinha Community Member
Registered: 2005-05-17
Posts: 10

Re: 'unobtrusive' enabling of Xinha?

We actually want people without much Javascript knowledge to be able to set these things up.  And in general, there's lots of places where I *could* use Xinha but don't now, because of the setup overhead.  If the overhead is low, I know I will be using Xinha in applications much more.

The full configurability of Xinha wouldn't be present in this form, but hooks for callbacks would let us represent higher-level ideas fairly concisely.  For instance, in an application we have, we have a button to insert images from a library, and target is just some custom code on our end, and so we go through the process of adding a button in Xinha.  This isn't something you could reasonable embed in attributes of a textarea.  But for the application we'll write a function like:

  function image_insert_button(xinha_config) {
    futz with config to add button...
  }

And then the user will do:

  <textarea class="xinha" callback="image_insert_button"></textarea>

And after setting up a basic configuration we'll call image_insert_button() on that configuration, and it can do whatever it wants.  This lets us encapsulate our extensions, while keeping them seperate from a basic setup process that is common to everyplace we use Xinha.

Anyway, if nothing comes up here we'll submit a ticket with the result of what we've done.

Offline

Board footer

Powered by FluxBB