handling binary data types (content, lenght and type)

[ghost]

Reported by radu epure on 29 Jun 2005 19:50 UTC Handling issues like adding the photo of a member or adding a document to the archive is a pain right now.

It would be very nice if somehow makumba could provide some simple tools to manipulate this data. I was thinking of a new MDD data type (i called it binary) and when i do a

over that field makumba just takes the content and places it there. Maybe also besides this makumba could provide some parameters like lenght and type to be handled in the BL (or in a response jsp). Migrated-From: http://trac.makumba.org/ticket/846

[ghost]

Comment by @stefanb on 30 Jun 2005 06:36 UTC This seems related to bug 615 and bug 68.

[ghost]

Comment by @manuelbernhardt on 3 Aug 2007 16:32 UTC this is partly implemented and should be released in some 0.6.2 version. Marius created a binary data type in order to make the difference with Text (for handling the UTF-8 character set). however no content type, length etc is provided with that yet.

[ghost]

Comment by @rudolfmayer on 7 Jul 2008 20:57 UTC In the congress in stockholm, we discussed the following about file uploading:

1.) if there is a binary file type, and a form with a mak:input on this type is provided, makumba should automatically store the binary data in the field

2.) based on 1.), add a new data type "file", that is actually a pointer-structure containing

• content: binary
• contentLength: int
• contentType: String
• originalFileName: String
• (maybe) filename: String

it might be that we are interested in storing both the original name, and assigning a new name that might based on where we upload the file to.

It is needed to modify the MDD parser, and replace an occurance of attachment = file with a pointer to the pre-defined pointer structure.

maybe also attachments=set file should be supported; that could however be written as attachments = set attachment->attachment=file

I personally favour the latter.

we might have a separate handler method on_newDataDefinitionNameFiedName(..) that allows handling of the file data only. alternatively, this could be in the Dictionary of the main type as "fieldName.contentLength", etc.

In the latter case, it might be difficult to treat fieldName = set file, but this should be no problem if we have the notation mentioned above.

Also, Makumba might provide support for detecting the content type of a file, e.g. using http://sourceforge.net/projects/mime-util

[ghost]

Comment by @rudolfmayer on 8 Jul 2008 02:39 UTC For downloading, two different ideas where discussed

1.) using mak:value to

-- provide displaying an image from an external source, so it can be used in an tag

-- otherwise provide displaying a link (to a servlet) where the file can be downloaded or viewed inline in the browser. In this case, Makumba shall be able to decide upon the content type whether to inline or download as attachment

2.) make dedicated tags like <mak:download ..> and / or <mak:image ...> and similar

[ghost]

Comment by @rudolfmayer on 11 Jul 2008 10:51 UTC (In reply to comment #3)

2.) based on 1.), add a new data type "file", that is actually a pointer-structure containing

• content: binary
• contentLength: int
• contentType: String
• originalFileName: String
• (maybe) filename: String

another alternative would be to still let he user create those fields in the MDD. Assuming the field data=binary in the MDD, we can then either

a.) use a heuristic approach, so if the a field dataContentLength, dataContentType etc exists, we populate them automatically

b.) specify in the <mak:input name="someBinary" contentTypeField="someBinaryContentTypeField" contentLengthField=".." ... />

personally i am not so fond of a.), i don't like implicit magic functions that do something w/o explicitly being requested.

[ghost]

Comment by @rudolfmayer on 11 Jul 2008 11:59 UTC (In reply to comment #3)

1.) if there is a binary file type, and a form with a mak:input on this type is provided, makumba should automatically store the binary data in the field

this works actually already today, though one needed to provide type="file". I added now a binary editor that is much simpler than text editor, and requires no params, so one can directly do

[ghost]

Comment by @rudolfmayer on 23 Jul 2008 22:28 UTC (In reply to comment #3)

2.) based on 1.), add a new data type "file", that is actually a pointer-structure containing

• content: binary
• contentLength: int
• contentType: String
• originalFileName: String
• (maybe) filename: String

this is now implemented, it also has imageWidht and imageHeight, which are set when applicable.

addiationally, a servlet that takes care of downloading is implemented.

doing a mak:value on the file-field itself will render as a link to that servlet, thus one can create a download link as Download and it can be used to display images as <img src="

[ghost]

Comment by @rudolfmayer on 23 Jul 2008 22:32 UTC Another idea is to also provided file-system based storage of the content. To indicate this, we should add another keyword in the MDD, maybe someAttachment = disc file where disc indicates to store it on the file system.

the storage shall be as in Karamba, i.e.

• using the pointer value as file name
• zipped
• in one specific folder, definable in MakumbaDefaults.properties
• per usage of the file field, one subdir with the name of the MDD & field shall be created
• in there, there are two levels of sub-directories, so for a pointer ah23bca, it will be stored in /mddNameFieldName/a/h/ah23bca.zip

the download servlet shall handle this transparently.

[ghost]

Comment by @rudolfmayer on 25 Jul 2008 09:48 UTC Yet another feature makumba could provide in regard to binary data is to automatically convert the content to a text-only representation.

This would allow easy search in attachments, whether it is in the end performed by doing a db-engine supported LIKE query, or using e.g. Lucene as search engine.

Quite some code exists for that in Karamba, the major problem most likely being that it makes extensive use of Linux binaries to do the transformation; Java libraries that can do the same job would obviously be preferred.

[ghost]

Comment by @rudolfmayer on 25 Jul 2008 09:49 UTC Similar to the idea in comment 9, Makumba could also generate a HTML version of the binary content, to allow quick previews of the contents in the Browser, similar to GMail e.g.

Also for this, code exists in Karamba, but the same issues as with comment 9, it relies on Linux binaries.

[ghost]

Comment by @rudolfmayer on 20 Aug 2008 14:31 UTC Bug 615 has been marked as a duplicate of this bug.

[ghost]

Modified by @manuelbernhardt on 28 Jun 2010 07:22 UTC

[ghost]

Modified by @manuelbernhardt on 28 Jun 2010 07:36 UTC