Xinha Discussion Forum

I could have sworn I posted a status update on the forum yesterday, but I may have spaced it.

Anyways, I've committed a bunch of changes to the unified_backend branch. Trace messages are much faster now such that you can use the editor with all trace messages turned on. They now all go to a single popup window. I've added a preprocessing script that patches in file and line numbers into each debugging message so you can see where each message was generated.

I've put up a small demo. Make sure to turn off any popup blockers:

  http://www.formvista/uploaded_html/xinh … index.html

Click on the Simple Example. To get an idea of what Xinha does for any given action, you can click the "add separator" link in the trace window and then go do something in Xinha and check the trace window again. It's a nice way to see how event propagate through the code.

I've found it extremely useful in coming up to speed on how all this works.

If you want to look at the code and you have a subversion client you can download it using:

  svn co http://svn.xinha.python-hosting.com/bra … ed_backend

If you have write access I would ask that you not post patches directly to the branch. Send them to me instead using:

  http://www.formvista.com/contact.html

This branch is now severely out of date with respect to the trunk. Once I finish the work I've got on my plate I'll see about merging in all those changes to bring it up to date.

On my todo list:

- the buildruntime.php script to strip out all the comments and debugging messages to create a "runtime" version of the code.

- actually do the central backend.php script that all plugins will route through (and create placeholders for other backend languages to be used). Initially I'll do Linker and SpellChecker.

- fix up the linker plugin to route all URLs through a central processor so we can avoid having fully qualified links in the content.

- fix EnterParagraphs (big job).

If you have any questions or comments please post them here or contact me using the form above. If you look at this branch I'd be curious to know what you think. My coding style tends to be really simple and verbose .. which may not be to everyone's taste.

thanks,

-- Yermo

I'm beginning to wonder that myself.

I haven't gotten that far yet. I'm still getting a handle on how everything fits together.

I have, however, made some radical improvements to the trace system which now means my branch is useable even with all the trace messages turned on. (The version in SVN right now is ridiculously slow).

In addition, I've added a preprocessor that patches in file and line numbers to all debugging trace messages. It's making it wicked easy to see how everything works ... interestingly the full_example.html has a bug, it's generating everything twice since xinha_init is being called on body.onLoad and once on window.onLoad.

Actually, from the trace messages one can immediately see where Xinha is doing a tremendous amount of repetitive processing.

I've got some more hacking to do and then I'll do another commit. For anyone trying to come up to speed on how Xinha works the next commit of the unified backend branch might be a much better place to start.

For a taste of what a partial startup trace of a single Xinha editor with the Stylist and ContentMenu plugins looks like (I haven't changed the order of how anything is called ... but the line numbers in my branch don't match the trunk at all since I've moved everything around) - something to note, see how loadPlugins() keeps cloning the plugins array as it recurses? .... :

(startup) htmlarea.js:828 - loadScript(): Top with url 'http://formvista.yml.com/TESTS/xinha_ub/dialog.js' and plugin 'undefined'
(startup) htmlarea.js:828 - loadScript(): Top with url 'http://formvista.yml.com/TESTS/xinha_ub/inline-dialog.js' and plugin 'undefined'
(startup) htmlarea.js:828 - loadScript(): Top with url 'http://formvista.yml.com/TESTS/xinha_ub/popupwin.js' and plugin 'undefined'
(startup) htmlarea.js:1263 - loadStyle(): top with style 'htmlarea.css' and plugin 'undefined'
(startup) htmlarea.js:1281 - loadStyle(): appending 'http://formvista.yml.com/TESTS/xinha_ub/htmlarea.css' to document
(startup) htmlarea.js:872 - init(): top
(startup) htmlarea.js:937 - init(): calling first loadNextScript()
(startup) htmlarea.js:916 - loadNextScript(): loading 'http://formvista.yml.com/TESTS/xinha_ub/dialog.js'
(startup) htmlarea.js:916 - loadNextScript(): loading 'http://formvista.yml.com/TESTS/xinha_ub/inline-dialog.js'
(startup) simple_example.html:71 - Setting up xinha_init()
(startup) htmlarea.js:916 - loadNextScript(): loading 'http://formvista.yml.com/TESTS/xinha_ub/popupwin.js'
(startup) htmlarea.js:927 - loadNextScript(): end of list reached. Firing HTMLAreaonLoad handler which is 'undefined'
(startup) simple_example.html:76 - xinha_init called from window.onload handler for simple_example.html
(startup) simple_example.html:92 - calling HTMLArea.loadplugins()
(startup) htmlarea.js:1160 - loadPlugins(): top - cloning plugins array.
(startup) htmlarea.js:1342 - cloneObject(): top
(startup) htmlarea.js:1353 - cloneObject(): contructing an array object.
(startup) htmlarea.js:1369 - cloneObject(): copying object members.
(startup) htmlarea.js:1101 - loadPlugin(): loading plugin 'Stylist'
(startup) htmlarea.js:1132 - loadPlugin(): callback defined. Using _loadback() to load plugin
(startup) htmlarea.js:1790 - _loadback(): top with src 'http://formvista.yml.com/TESTS/xinha_ub/plugins/Stylist/stylist.js'
(startup) htmlarea.js:1812 - _loadback(): script tag to load javascript file appended to head section.
(startup) htmlarea.js:1221 - loadPlugins(): end
(startup) htmlarea.js:1160 - loadPlugins(): top - cloning plugins array.
(startup) htmlarea.js:1342 - cloneObject(): top
(startup) htmlarea.js:1353 - cloneObject(): contructing an array object.
(startup) htmlarea.js:1369 - cloneObject(): copying object members.
(startup) htmlarea.js:1101 - loadPlugin(): loading plugin 'ContextMenu'
(startup) htmlarea.js:1132 - loadPlugin(): callback defined. Using _loadback() to load plugin
(startup) htmlarea.js:1790 - _loadback(): top with src 'http://formvista.yml.com/TESTS/xinha_ub/plugins/ContextMenu/context-menu.js'
(startup) htmlarea.js:1812 - _loadback(): script tag to load javascript file appended to head section.
(startup) htmlarea.js:1221 - loadPlugins(): end
(startup) htmlarea.js:1263 - loadStyle(): top with style 'menu.css' and plugin 'ContextMenu'
(startup) htmlarea.js:1281 - loadStyle(): appending 'http://formvista.yml.com/TESTS/xinha_ub/plugins/ContextMenu/menu.css' to document
(startup) htmlarea.js:1160 - loadPlugins(): top - cloning plugins array.
(startup) htmlarea.js:1342 - cloneObject(): top
(startup) htmlarea.js:1353 - cloneObject(): contructing an array object.
(startup) htmlarea.js:1369 - cloneObject(): copying object members.
(startup) htmlarea.js:1192 - loadPlugins(): no plugins left to load
(startup) simple_example.html:76 - xinha_init called from window.onload handler for simple_example.html
(startup) simple_example.html:92 - calling HTMLArea.loadplugins()
(startup) htmlarea.js:1160 - loadPlugins(): top - cloning plugins array.
(startup) htmlarea.js:1342 - cloneObject(): top
(startup) htmlarea.js:1353 - cloneObject(): contructing an array object.
(startup) htmlarea.js:1369 - cloneObject(): copying object members.
(startup) htmlarea.js:1177 - loadPlugins(): plugin 'Stylist' was already loaded
(startup) htmlarea.js:1177 - loadPlugins(): plugin 'ContextMenu' was already loaded
(startup) htmlarea.js:1192 - loadPlugins(): no plugins left to load

The codebase seems in pretty bad shape to me. I'm still working through it trying to come up to speed. As I see it, before we undertake a large re-engineering project there are a few things that have to be accomplished:

1. set the code up so that it's maintainable. My approach is to comment everything I can, establish a trace
   message architecture and standardize client/server communications. Others may have a different approach
   that they would like to see.

2. create a stable release including a core set of plugins that works with MSIE and Gecko as we want it to with
   all major bugs and usability problems solved. Top of my list is EnterParagraphs and relative vs. absolute
   vs. fully qualified link handling.

3. create documentation to cover the plugin API and general code architecture to make it easier for newbies
   like myself to come up to speed.

Once these things are done and we have the codebase under control we'll be in a much better position to break out the browser specific code. From my relatively inexperienced point of view, it seems that doing this might be tricky since there isn't a one-to-one mapping of functionality between all browsers.

In the meantime, I'm making slow progress on the unified backend branch. I'll probably commit another round of changes to it some time next week. At least for me, having trace message everywhere is making it much easier to see how the code works ... unfortunately it does make things painfully slow when all messages are turned on.

In separate SVN managed projects over here I ended up having to write a shell script to patch in a new version number before the SVN commit to solve this problem.

For Xinha I don't know how Gogo wants to handle it. I'll probably copy over the svn_commit script I have to the Unified Backend branch that I'll be starting shortly; so the version number will be correct in the about box.

I absolutely agree.

Yea, EnterParagraphs and the whole <p> vs. <br> thing is a real pain. I'm swamped with work at the moment but the next thing on my TODO list is to implement the design gogo and I came up with in where both IE and FF go through EnterParagraphs and we use style sheets for <p> tags to get the correct behavior in all cases.

For my customers, who are using Xinha, this issue has become priority #1.

Hopefully, I'll be able to start on that work next week as part of my upcoming Unified-Backend branch of Xinha.

You will see this if you are using the Linker plugin and the number of files being sent back is large. In my case I tried sending back a directory structure of about 1000 files (scan.php) .. and got that warning.

Separately I do notice Mozilla/FireFox slows down after a while of running Xinha. It would be cool if the Mozilla folks added the ability to list out the threads that are currently running so one might be able to see what's going on.

Yea, my approach was just a quick hack ...

Actually, I have this exact functionality working here with an older version of the Linker plugin. The content management portion of the business platform (mobie) we've developed does exactly that.

I've also got the edit case working where if it's a link in the tree it highlights it. I haven't had a chance to make my changes backwards compatible with the default linker which is why I haven't checked it in yet.

It loops through all the files you send back. In my case I'm sending files back as a single string  from a modified scan.php as in:

['/,General'],
        [
        ['/,Home'],
        ['/contact.php,Contact Us'],
        ['/staff/,Staff'],
        ['/links/,Links']
        ]

So each string has the name to be displayed in the tree and the value to assign as a single string separated by a comma. It's a major kludge ...

The trick is then in makeNodes(). Each string from  your array is an entry in the files[] argument.

Linker.Dialog.prototype.makeNodes = function(files, parent)
{
  for(var i = 0; i < files.length; i++)
  {

    if(typeof files[i] == 'string')
    {

     // the text to display is separated from the link by a ,
         // file_args[0] == string to display
         // file_args[1] == string to set in the URL.

     var file_args  = files[i].split(',');

      this.dTree.add(Linker.nxtid++, 
                            parent,
                     file_args[0].replace(/^.*\//, ''),
                     'javascript:document.getElementsByName(\'' + this.dialog.id.href + '\')[0].value=unescape(\'' + escape(file_args[1]) + '\');document.getElementsByName(\'' + this.dialog.id.type + '\')[0].click();document.getElementsByName(\'' + this.dialog.id.href + '\')[0].focus();void(0);',
                     file_args[1]);

    }
    else
    {

    // this entry in files is an array, so we recurse.

     var file_args = files[i][0].split(',');

      var id = this.Dialog_nxtid++;
      this.dTree.add(id, parent, file_args[0].replace(/^.*\//, ''), null, file_args[0]);
      this.makeNodes(files[i][1], id);
    }
  }
}

Hopefully this will help you get over the hump.

Contact me at http://www.formvista.com/contact.html if you get stuck; I can email you what I have.

-- Yermo

I think that's fantastic! A great play on words.

Personally I like the top one better as well, but to my eye the line descending into the H doesn't look right. It seems to me that the pictograph should be a little higher and maybe proprtionally a bit smaller so there's a nice separation similar to the separation in the bottom one.

Just my $0.02.

(smacks self on head with hand producing a hollow empty sound)

version 48 submitted. config.inc.php now figures out the install directory using PHP_SELF. This will at least make it work in the "default demo case". Users will still need to update the config if they want to move the directory elsewhere.

I also went ahead and changed plugin= to __plugin= and f= to __function= per your suggestions.