Item8387: JHotDrawPlugin does save content only on first edit.

-- IngoWolf - 11 Jan 2010

System foswiki 1.07 on fresh installed debian lenny.

JHotDraw seems to work as expected, but after saving and closing a drawing no more editing gets saved. Only the firstly saved content appears in the drawing. Existing drawings like in the JHotDraw Documentation can be also edited once and the changes get saved on the first edit, but lateron no more.

-- IngoWolf - 11 Jan 2010

I tested a little more - it is saving on second edit. However when you create a drawing with ABC save and exit. result: drawing ABC When edit ABC and add D save and exit. result: drawing ABCD When edit ABCD you see in JHotDraw Editor only ABC. So it seems that when editing the image is created and saved, but not the JHotDraw data. This happens only with new created drawings.

-- IngoWolf - 11 Jan 2010

Testing with IE8 and Java Plug-in 1.6.0_07 image creation works, but saving results in hanging java and explorer - have to kill processes.

-- IngoWolf - 11 Jan 2010

Update to 1.08 brings no improvement, still only the content of the first edit is saved to JHotDraw data file. To the Image only these data are saved together with Objects created during last edit. Objects created in an earlier edit are dropped.

-- IngoWolf - 11 Jan 2010

I come closer to the problem - JHotDraw Editor takes the data for editing not from highest version in draw,v but always from version 1.1 Copying the text from 1.7 over section 1.1 showed up the correct objects in editor. So the problem is the way, JHotDraw interprets image.draw,v

-- IngoWolf - 11 Jan 2010

JHotDrawPlugin (version 5263 (2009-10-13)) seems to be working on my Foswiki 1.0.7. I had some problems with old drawings (from tmwiki times) but so far creating and editing new drawings works flawlessly in 1.0.7.

-- MartinKaufmann - 11 Jan 2010

I have to say it works fine on a vanilla 1.0.8 too. But there are strange problems on svn installs (editor doesn't close or save at all). KennethLavrsen mentioned that JHotDrawPlugin doesn't seem to work with any validation method other than strikeone at the moment.

-- PaulHarvey - 11 Jan 2010

Yes.

There are TWO problems I found. One we can docu our way out of. And one where we need to solve the javascript that comes with JHotDrawPlugin.

• When you upgrade JHotDrawPlugin from an older version you need to REMOVE/DELETE the jhotdraw.pattern.tmpl. If you do not - the plugin does not correctly get the drawing name and it will not open and it cannot close.
• The plugin currently handles strikeone very well and can save multiple times in a session. But if you disable the strikeone the javascript code does not know it and assumes failure which it reports back to the plugin which reports failure. And worse - again will not exit. You have to kill the java engine in the Windows task manager.

-- KennethLavrsen - 11 Jan 2010

I can confirm the bug for 1.0.9-1 JHotDrawPlugin loads only edit data from first edit+save (1.1) and ignores newer revisions.

-- IngoWolf - 18 Jan 2010

This applies to -Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 under IE8.06 the content is loaded, but saving not possible and application must be killed by closing browser.

-- IngoWolf - 18 Jan 2010

Can you confirm that you have stikeone enabled?

And what type of authentication? Apache or Template?

Is the rest script authenticated?

(I do not know why someone put this Waiting for Sven.)

-- KennethLavrsen - 18 Jan 2010

I think Ingo might be running a custom skin. If I set the SKIN to asdf (fall-back skin), I am able to reproduce the problem.

As shipped the current version seems to only work with PatternSkin and NatSkin.

The problem is that we assume that whatever skin is running will load our Foswiki JavaScript Event.js

But I think only PatternSkin does this.

Ingo: Please try doing Set COVER = jhotdraw.nat in your hotdraw topics.

I think this will fix your problem

The jhotdraw.nat is not actually specific to natskin. It just loads the missing Event.js. So it might be a generic solution to any skin which does not load Event.js. Probably we should do this in the Javascript we use in the Foswiki customisaiton of JHotDraw instead (if we don't find Event.js methods, then load it dynamically, instead of using these template hacks)

I am interested in doing more work on JHotDrawPlugin, see also Item8305

-- PaulHarvey - 18 Jan 2010

I have tested with skin plain and it seems the fixes Arthur did for Item9917 also fixed this one.

-- KennethLavrsen - 29 Oct 2010

Commenting is disabled while not logged in