Create a file upload button for binary fields

[krichter722]

next to the current text input field. I guess orientdb is capable of handling streamed input of binary data and I think I could implement that myself if you could give me a pointer where to start.

[PhantomYdn]

As you may already notice on demo site: after selecting of particular field type then you can select proper visualizer for that type. By default almost all types has "default" visualizer, but some are missing (like binary).
There is some map of supported visualizers or links to issues: https://github.com/PhantomYdn/Orienteer/wiki/Property-types-support

So: visualizers are registered right there: https://github.com/PhantomYdn/Orienteer/blob/master/orienteer-core/src/main/java/ru/ydn/orienteer/components/properties/UIVisualizersRegistry.java

And as I said there is a default one which should be used if no specific visualizer was specified:
https://github.com/PhantomYdn/Orienteer/blob/master/orienteer-core/src/main/java/ru/ydn/orienteer/components/properties/visualizers/DefaultVisualizer.java

Visualizer is Orienteer's entity, but to be able create real component for view and edit specific types you should be familiar with Apache Wicket. I recommend following book: http://wicket.apache.org/guide/guide/ . Book is really cool and can be easily just within one evening:)

[krichter722]

Thanks a lot for the help to get started and the link to the wicket guide. It's a great framework! I'm now at the point of finalizing the IVisualizer and need to store uploaded files in a different model (V is enforced by generic method parameter and FileUploadField requires List<FileUpload>). I guess the model can be provided by the IVisualizer and be reset or recreated after every upload. How do I get the data of the second model into orientdb? Can you help me out again, please?

[PhantomYdn]

V in IVisualizer is for type stored in DB: so that's just of IModel<V> valueModel. So it's definitely not a FileUploadField or List<FileUpload>. But once OrientDB supports different types of binary data (https://github.com/orientechnologies/orientdb/wiki/Binary-Data): I guess it will be better to keep it generic like IModel and dynamically try to apply type in get: if object is byte[a] - one action, if object is ORecordBytes - another, if Serializable - third. During set pretty much the same: but if initial type can't be determinded use some generic option like sroring in ORecordBytes. What do you think?

[krichter722]

I have to admit that I have so superficial knowledge about orientdb that I didn't realize that there's more than one types of binary data (storage). I'll have to become familiar with that.

Regarding the type of valueModel you're right. I need to figure you're model architecture.

if object is byte[a] - one action, if object is ORecordBytes - another, if Serializable - third. During set pretty much the same: but if initial type can't be determinded use some generic option like sroring in ORecordBytes. What do you think?

Regardless of how different action are put in place for the three different types, I think we need partially loadable OProperty in order to make the data previewable without fetching it completely. Currently I imagine a lazy loading non-editable text area and a file download button for viewing mode and an editable text area and a file upload button for editing mode for binary fields (it doesn't make much sense to edit binary data, but there should be a component providing the most basic form or editing). Due to the fact that I plan an IVisualizer composed of different components a maximum of choice can be left to the user (e.g. by choosing the type from a drop down list). I'm missing the point where the type can't be determined, though, please explain :)

[PhantomYdn]

Small note for better picture. For Orienteer 1.1 I'm planning to make visualizers configurable, so it'll be possible in this particular case to specify: a) how to store b) how to "preview", c) content type d) default filename and etc..
For now I recommend to have something quite simple. For example for common binary it might be just a link "data" to a download. There is another type planned: binary for images in this case preview is the image themself. Later it will be possible to use thumbnail instead of picture, but for the beginning just picture will be more than enough.

[krichter722]

I've seen that you've opened quite a lot of issues without descriptions of which I can guess what they're supposed to stand for, but it's quite hard without. Currently the abstraction in the model is very good and the changes you scetched in #131 (comment) seem to be realizable without any drastic changes, so work on a "primitive" binary upload visualizer wouldn't be lost imo.

[PhantomYdn]

Duplication of #41
But lets keep this instance due to additional information