[Pmwiki-users] PmWikiDraw New version

[Ciaran]

> >Following yet more great feedback from Knut.  I've released another
> >version of PmWikiDraw containing some small bugfixes.
> >
> >This script now works on either PmWiki 1 or 2  and the only changes to
> >a vanilla pmwiki installation (other than including the script!) is a
> >small change to upload.php.
> >
> >Fixes
> >* Uses $ScriptUrl?pagename=<page> rather than $ScriptURL/<page>/ for
> >servers that can't handle the latter
> >* Fixed the directive so it can be used anywhere on a line, rather
> >than at the start of the line (doh!)
> >
> >Pending fix
> >* Ability to use 'Group.PageName' as a url in the editing window.
> >I've fixed this on my test version, but it uses a <base/> element and
> >I'm not convinced this is a good solution :)  So it isn't included in
> >this version of PmWikiDraw.
> 
> Ok, it's up and running in v2 !!!
> 
> * you were absolutely right: the full qualified url must be supplied. I
> changed it in my setup's.
> * I would suggest to check this in the script pmwikidraw (can work this out
> tomorrow), cause it may be that the ScriptURL will not contain the full
> path (have to ask Pm) ? I think that will make the script more stable to
> install.
> *  updated the docs in the cookbook
> * have to do a F5 to refresh the screen
> 
> suggestions:
> * what about an option to create an edit-link (with a PagePmwikidrawFmt-var
> to let the admin decide what format will be used), maybe as a textlink or a
> small icon with a-attribute title="click here to edit the drawing" ? Could
> prepare something like that (again: tomorrow). When I just copied a sample
> *.draw without a *.map I couldn't edit the drwaing cause the link to edit
> was missing (cause the map-file was missing)
> * and a Pmwiki-Doc-Page should be good where the usage of the draw-applet
> is described, we could ask Pm if this should be delivered only with the
> cookbook or could be in the standard installation.
> * I think next week I'll have a look on the java-code concerning the
> symbol-library we discussed. Maybe this could "simply" be done by drawing
> them and then getting the source-code from the *.draw-file ? Yes, then it
> has to be packed into a java-class as well.
> * another thing would be nice: specifying the size of the drawing-applet
> (width / height) in the applet-parames and then in the pmwikidraw-setup or
> within the drawing-directive
> * maybe when all is done it should be placed within a zip-file as
> attachment of the cookbook
> * when using URL's for an object, e.g. a pagename, this will result in an
> wrong URL in the map. maybe this could be fixed by using something like:
> "{$ThisWiki}/Group.Page" as the url set in the Object. The string can be
> set in the applet, but then all vars should also be substituted (like in a
> wikipage) when displaying the map. e.g. "%BUILDEDITLINK%" could then be
> turned into "{$editImageUrl}" to get exchanged.
> 
> I'll try to make changes and test them for the topics suggested above. If
> you like them you can add them to your code. Or better: it could be made
> configurable.
> 
> Anyway: it's a great start ! Well done !
> 
> haven't checked this on linux. I have to setup the apache and php and
> pmwiki and java first on my debian system. Will take a while.
> 
> -Knut
> 
> --
> Pmwiki-users mailing list
> Pmwiki-users at pmichaud.com
> http://pmichaud.com/mailman/listinfo/pmwiki-users_pmichaud.com
> 

Sorry for the late reply, somehow GMail hid this message from me, I've
only just spotted it after PM's post!

I'm glad its working for you.!  If I miss a few points please forgive
me,  this email is getting rather large ;)

1) ScriptURl
    I'm not sure about the relative/full ness of this variable,
possibly needs more work.  Although I though tit was recommended to
not be relative...

2) F5 to refresh, this is because teh browser caches images, the map
file actually updates, which makes for a nasty effect if you
completely change the dimensions of the drawing :(

3) Edit-Link.  I've also thought of this, would be easy enough to do,
the MAP will always be there as its generated automagically in the
applet.  But as an extra it's probably a good idea (especially for
when you move .draw files about from other JHtoDraw packages)

4) I'm lost as to what people are meaning/want me to do with this Doc
page.  What should be distributed ? Where should I put it!

5) The Symbol library, I've had a look at this, every shape is
represented by an object, there is an object that can contain multiple
shapes, however there's no reasonable way to  take the generated Class
and get it back as source (technically not true as its all
serialisable) but we'd be better off create a new class for each one. 
There's a good article on this on JavaWorld (google for JHotDraw and
JavaWorld) [Please note this is for the latest version of JHotDraw
which is Java2 based.  This brings me to an interesting point.  I'm
considering porting the plugin to the very latest version of JHotDraw
which offers features such as undo/redo, snap to grid, images
[possibly won't be able to do this straight away would need some
consideration]   However this latest version is Java2 based.  If
everyone who requires this plugin where I work has Java2 then I'll be
happy to do this, otherwise I might have to spend my time doing other
things.  If this does happen I'd like to  work on some code that can
run the correct applet depending on the available VM on the machine it
runs.  Not certain if this can be done with object tags or not, but
hopefully so.

6). Width/Height.  This could be done easily enough, but I'm not sure
what the directive would look like [[Drawing:drawingName width
height]] (:drawing drawingName width height:)  perhaps ? but I'm not
keen on ordering mattering etc.  Any conventions for PmWiki2 that
should be followed

7) Zip file on PmWiki, would love to , but I tried this in the first
place and PmWiki won't allow uploads of  the size I would need.

8) URLS: On my local dev version Wiki Pages are in fact correctly
referenced as I insert a <BASE> tag which is honoured by the ImageMap.
 However I don't want to go 'live' with this solution as its nasty and
could break pages.  Your suggestion of another 'Template variable' is
good, I may well do this ;)   If the user puts in a relative url  I'll
automatically pre-pend it with %WIKIPAGE% or something

9) I've been chatting to Pm in IRC a little bit ago and he's going to
make a permanent modification to the redirect code in PmWiki2 so users
will no longer have to moidy the upload.php script (in PmWiki2 at
least) which will be great.  *However* the post parameter he's going
to use is different to the one I'm currently using so there will be a
brief period where the plugin is broken, i.e. you'd need to install
the new plugin and revert upload.php to its vanilla state.

10 I've run it on Linux, running firefox, and it seemed fine.  

I hope this answers everything, (There is a slightly newer version of
the script up on the normal site at the moment, this fixes an issue in
PHP5.0.1. with array_merge/array_unique)

Thanks
- ciaran
(Sorry again for the delayed response!)