binary-resources-linkable

[meddle]

• Make all the binary resources in sophie 2 linkable from the file system.
• Handle the missing resources problems like with the media resources.
• Remove linked and embedded book items and use the file accessory for that too.
• Make ImmImage truly immutable and lazy.

[deyan]

Batch update from file active_tickets.csv

[meddle]

• Handling source problems.
  • The problems are common for every binary resource with linked data.
  • So the property binSourceProblem() will be moved from the MediaFrameView to the FrameView class. The manipulation view showing the error will be moved in the package of the FrameView class and will be renamed to ErrorManipulationView. It will be registered there.
  • The source problems can be different. For example with the linked embedded books which files are removed the problem is not with binary data and with Sophie data :)
    • The property binSourceProblem will be renamed to sourceProblem
    • The logic for refreshing will be moved ot the FrameViewLogic.

• Importing linked resources.
  • The logic for importing linked binary resources is in the MediaImportManager.
  • That is bad, because all the binary resources should become linkable.
  • There will be BinaryResourceImportManager which will have getBinData(...) method that has the logic for getting the different types of binary data.
  • The Image, Pdf and Media import managers will extend this class and use it's methods to get their binary data.
  • The PDF and Image import managers will declare as FileAccessory the BinDataAccessory. This will let the user see the link/embed options.

• Persisting linked data:
  • The logic is written only for the media.
  • The common logic for persisting linked/embedded BinData will be moved to the ResourceFileUtil#persistBinData(...) method. It will be used by the PDF and Image BinData persistence.
  • For the PDF there will be need for backward compatibility with the current format, because it is different from the image/media in that that the location of the PDF is attribute, not XML child.
  • The MediaPersistenceTest works with the moved/updated logic.

• ImmImage
  • The ImmImage will become truly immutable:
    • the method toBufferedImage() will be removed.
    • At its place there will be added a method exportToAwtImage() which will copy the immutable image's source.
  • Drawing the image with Graphics will be done via helper methods drawImage(...) in the ImmImage class.
  • Saving the image will be done via helper methods too.
  • The ImmImage will be lazy. The idea is that only if the image is displayed it will be read from its source file or another URL.
    • The image will contain a BinData source.
    • If the BufferedImage source of the image is not initialized and it should be displayed, it will be loaded form the binary source.
    • The size of the image will be get lazy too. And it should be read from the file separately from the image data if the image is not loaded.
  • The exportToAwt() method should be called rarely only if the image is used from the AWT API.
  • Some of the image tests should be fixed.
  • ImageFrameView will handle BinSourceNotFoundExceptions.
    • In ImageContentSceneElement#setupDynamic() if there is problem the dummy image will be set.
    • In ImageElementHelper#getImage if there is problem null will be returned, because the logic handles nulls.

• PDF
  • As with the image the use of RawBinData will be changed to use of BinData.
  • The persistence and the import will work with the refactoring done for the image.
  • Handling source problems:
    • In PdfContentView when initializing the image shown the error will be set or removed.
    • In Next/Prev PDFPageContentViews the error will be handled.

• Embedded books
  • Linking embedded books with the accessory will be different from the bin data linking.
  • The InsertResourceMenuItems have isLinked method, that is made only because of the books. It will be removed.
  • The InsertBook item will become InsertResourceMenuItem.
  • All the sophie format resources should be linkable from files, so the logic for mode linked resources will be in the SophieFromatImportManager.
    • In the ResourceImportManager there will be protected method isModelLinked, that will return false by default.
    • In the SophieFromatImportManager the method will return true if the resource is choosen to be linked by the accessory.
  • I suggest new name for the accessory. Not BinDataChooser and SourceLocationChooser. Suggest better name if you care.
  • All the logic for linked model resources will become more inner for the import utils and managers. The ImportLogic will not pass this options.
  • The ResourceImportInfo class will have isModelLinked getter and modelLinked field.
  • I think that is good idea, because all the resources in sophie can be exported to our format and can be linked from it.
  • This option will be set from the file choosing logic of the import managers or by the DND logics...
  • So now the books can be linked form the accessory.
  • The first problem is that if the linked book is not found there is exceptions in the moment.
    • New SophieSourceNotFound exception will be introduced in the org.sophie2.base.model.resources.r4.file package and will be thrown by the FileAccessUtil's methods.
    • The EmbeddedBookView will handle it and will provide empty book view if there is problem.
    • The EmbeddedBooksPalette will handle it and will not add an item for the not found book.
    • The next/prev page logic of the embedded books will handle it.
    • The refactored ErrorManipulationView will work if the exception is handled correctly.
    • The exception is unchecked like the binary source one.
  • The second problem is copy and link.
    • If we want copy and link at this stage, we will have to persist the refs correctly.
    • Of course there are methods for that in the ResourceFilesUtil.
    • The true problem is that we persist the data type with the binary datas. And here with every resource ref we will have to persist it's type : linked, embedded, relatively linked.
    • I have one solution. It is simple but different from the binary logic.
      • We don't preserve the linked/relatively linked/embedded options in the resource refs, so we can not pass it when persisting, but form the location of the ref the type will be guessed:
        • If the ref is inner -> embedded
        • If the ref is absolute and its location contains the special resource folder - relatively linked
        • If it is absolute and does not contain the folder => absolutely linked.
  • The third problem is that in the import resource dialog raised by the resource's tab there is no accessory.
    • I suggest a task in which we make the accessory use bound controls, and is also visible in this dialog. It's content can be not enabled for file types that can not be linked/imported.

• I fixed/used all tests for the logics because the refactoring generalized the import/persist logics.
• Source code can be found in branches/private/meddle/linkable.
• This time there are only a few grammatical errors because I am not only ultra programmer but and ultra linguist :)

[pap]

• Accepted
• ResourceFilesUtil#getFilesDir - shouldn't the part of assert about startsWith(LocationPrefix.FILE) be removed?
• sourceProblem() may be named resourceSourceProblem(). Not really sure but otherwise sounds too general.
• ImportBinDataType should also be renamed. What about "ResourceImportType"
• Maybe the name of the beforementioned should be consistent with the name of the used FileAccessory
• Don't forget to fix the JavaDoc of those classes as now it talks alot about BinDatas.
• I somewhat dislike BinSourceNotFoundException and SophieSourceNotFoundException. To me "source" is a bit unclear. Not mandatory to change this.
• Should the Embedded books palette really display nothing about the missing item? I'd ask an experienced person about that, but IMHO there should be something similar to the ErrorManipulationView there.
• EmbeddedNavigationActionsLogic should probably also be fixed to handle the SophieSourceNotFoundException
• This probably is something that we don't need right now, but what would happen if the embedded book is a link to a server book, not a child of the current one.
• So I dislike the solution with guessing the link type except for backward compatibility.
• Will the ImmImage thing reduce the memory usage of sophie at least a bit?
• No analysis score !!

[meddle]

• Thanks :)
• I think no, because at the moment the util works only with stored on the FS files => file refs.
• Yes you are right, I will rename it.
• Yeah good name, may be better that SourceType :)
• OK, the file accessory will be renamed too.
• I'll try to fix the JavaDoc.
• Suggest a better word that source and I will use it.
• Hmm but the resource is missing, the book is not there, so when there is no book, there is no item... That is my logic, so please make me ask Deyan tomorrow, because I'll forget.
• I think I fixed this, but it is possible that I forgot to mention it.
• And what about linked binary resources in the server? The time for this will come, don't worry.
• Heh me too, but is an idea, the other idea is something like the case with the binary data, but the persistence will be changed... Ufff :) I think that maybe there had to be another ticket for these embedded books... but I wrote the analysis, so I'm guilty for my problems :)
• Don't know, I guess :) In nay case I think the image is way better now.
• I wrote the analysis, so the reviewer takes the guilt, may be you should speak to him/her.

[meddle]

So the implementation is finished:

• When persisting resource refs to linked relatively Sophie 2 Format resources the templates is generated or the absolute ref when loading is generated int the ResourceFrame#KEY_MAIN_RESOURCE#persistR3(ValueRef<ResourceRefR4> ref, Storage destination, PersistenceOptions options, String format) method.
  • The most clean implementation I think, if another resource ref key can link relatively the logic will be pulled out with ease.
  • There are some new methods for saving and loading resource refs to ralatively linked resources analogical to these for the binary resources. They are in the ResourceFilesUtil and are tested in ResourceFilesUtilTest
  • Another new thing. The relatively linked resources of an imported relatively linked or embedded resource are copied to the right places in the '_files' folder of the resource in which it is imported. (Ask me if you don't get this sentence, it is hard to explain these relations...)
• I merged the branch at straxil:10 for you, there are renamed some thing you wanted additionally you can make me rename something there.
• The branch can be browsed here branches/private/meddle/linkable
• The branches URL : ​svn://sophie2.org/sophie2/branches/private/meddle/linkable
• I additionally fixed the resource export logic tests.

[pap]

• Commited in [8810]
• Generally I liked what you did as code.
• From user's point of view it is quite nice.
• There were some problems that were fixed on the fly.
• I really cannot understand some methods by their signature and JavaDoc. I don't want to make you angry but that's the case... ResourceFilesUtil needs better JavaDoc that explains what "savable", "loadable" and "resource" mean in its context.
• You fixed some indentation of new lines in EmebeddedBookLogic but these still stay ugly.

[meddle]

Closing all the tickets before M Y1