[daisy] Sketch Editor

[Wolfram Kaiser]

Hello all,


Karel asked me to comment on his e-mail to this mailing list. First of 
all, it is difficult for me to comment on something I haven't been 
involved so far: I am not aware of the ongoing discussion, neither of 
the original problem, nor of the referred reply of the JHotDraw project 
member. So I can just presume that the JHotDraw project member wanted to 
stress the point that JHotDraw is not just a library but rather a 
framework. As you will know the level of integration is usually much 
higher when working with a framework than when working with a library 
because you build your application which not just uses some library 
functionality but which is built around a framework's predefined 
application structure. This means that you not only do API calls but 
also extend the framework by filling in some pre-defined extension 
points in your own sub-classes. As a result your source code typically 
relies more heavily on the framework classes. Of course, that doesn't 
mean you have to copy those framework classes ;-)

The precaution of using JHotDraw as a library/framework might be based 
on the fact that JHotDraw has undergone a major re-work and re-design 
between version 6 and version 7. So if your application is still based 
on a JHotDraw 6 codebase your application is likely to change a lot when 
switching to JHotDraw 7. However, at least within a major release we 
attempt to keep the interfaces and the API pretty stable and provide 
backward compatibility as much as possible. Using interfaces from the 
API (instead of the real implementation classes) usually helps a lot in 
terms of portability and reduces the amount of work necessary if an 
interface/API happens to change after all.

Thus, I don't see any problems with using JHotDraw as a 
library/framework as opposed to copying source code (something you 
should always try to avoid ;-). Karel clearly outlines the effort 
necessary in following the library approach but also stresses the 
expected benefit and advantages. Finally, we usually encourage people to 
contribute, report bugs and - even better - provide bugfixes and new 
features.

All in all I think that JHotDraw can be used in library/framework 
approach and believe - from what I understand - that the reference to 
the JHotDraw library vs copying approach has been misunderstood.


Hope this helps,

Wolfram

Karel Vervaeke wrote:
> I really don't see the point that the authors of JHotdraw are making.
> There are two alternatives:
>
> (a) use JHotdraw as a library.  If I want to make changes to the applet,
> and I want to use the newest JHotdraw version (be it because of bugfixes
> or because I want new features), I can do so and I will have no problem
> changing my code to take JHotdraw API changes into account. 
>
> (b) copy JHotdraw source code into the applet code and compile from
> there.  If I want to upgrade to the newest JHotdraw version, I have to
> find out which files have changed, copy the relevant files over to the
> applet.  If I make changes to the copied JHotdraw the next upgrade is
> going to be horribly painful:  I need to merge changes from JHotdraw
> proper with the copied JHotdraw code.
>
> There even is added value for the JHotdraw project: If I want to make
> changes to JHotdraw in situation (a), I have to report my changes
> (bugfixes, new features) and wait for the next release - everybody using
> JHotdraw wins.  OTOH, if I make changes to JHotdraw in situation (b), 
> those changes are much more unlikely to get shared with others (not that
> I'm selfish, I just have much to do and am likely to move on after
> fixing things.
>
> Regards,
> Karel
>
>
> On Thu, 2008-06-12 at 15:04 +0200, Michael Hänni wrote:
>   
>> Hi Karel
>>
>> I'm afraid you discovered a delicate problem.
>> I contacted the developer of JHotDraw.
>> He told me not to use JHotDraw as a library.
>> He told me, that each update of JHotDraw would also require changes in 
>> my code.
>>
>> A possible workaround would be to completely integrate the source files 
>> of the classes I need from JHotDraw into my SektchApplet (The same way 
>> you suggested in an earlier mail).
>> This way JHotDraw would be built from source as part of building the 
>> applet and there would not be a separate JHotDraw jar file. On the other 
>> hand the Sketch applet jar would again contain both "ch.ergon.**" and 
>> "org.jhotdraw.**" classes.
>>
>> Would this workaround be a possibility for you? Or can you think of 
>> another solution?
>>
>>
>> Regards,
>> Michael
>> _______________________________________________
>> daisy community mailing list
>> Professional Daisy support: http://outerthought.org/en/services/daisy/support.html
>> mail to: daisy at lists.cocoondev.org
>> list information: http://lists.cocoondev.org/mailman/listinfo/daisy
>>     
>
>