See, at the moment we don’t have a special type for images. All files are just files. However, this is on a map down a road, so, one day it will not require coding.
However, now it also doesn’t require a lot of coding. You can find an example here.
When was the last time where you read some of CUBA’s presentations / marketing material? They raise very high expectations (which is good, but you must ensure that users get not disappointed). Look at this:
“Unlike other full-stack frameworks available on the market, the platform offers a higher level of abstraction and a wider range of out-of-the-box features, while still allowing direct access to the low-level API.”
And then I cannot even make a simple Entity without code? And yes, an Entity which contains an Image field is basic functionality. Any RAD tool should be able to handle this - otherwise its simply no a RAD tool.
As to your code:
What is this? How can this be reused? By copy&paste? Is this how CUBA is extended? Is this how you use CUBA @ Haulmont?
I cannot believe this.
Possibly you could provide an example of how to extend the CUBA.studio UI palette with an reusable(!) “embeddedImage” panel (e.g. inherited from embedded).
So then we could talk about “Reuse within a RAD tool”.
If you now tell me “CUBA does not provide such an extension mechanism”, well then I have a really big problem!
First, we don’t position the platform as low-code framework.
Second, the platform is opensource, so go ahead, develop such component and make a pull request to github or wait until we develop it. You always can create an idea and if it is highly upvoted it will be included into the next release.
Third, you mixed up so many things that are not even closely related to the initial message.
Finally, “absolutely basic functionality”, “any RAD tool”? Really? Can you support any of your points with some evidence?
You may, I’m a developer advocate of the CUBA Platform, you could easily google it.
Your request is understandable and I support it, so if you read my first reply, it is in the roadmap. If you see so much drama in it, you are welcome to take part in CUBA development, implement this functionality and be helpful for the community.
Thanks for the info. I leave Google to you. Do a research on “professional pride”, and “Difference between Senior Dev Grade Customers and Open Source Developers”.
Now, I am awaiting a reply from a (product / business-people oriented) person who knows how to treat customers(!) of a commercial(!) product (CUBA.platform).
The main question is:
How do I provide the functionality of the discussed embeddedImage (Or lets call it imageDisplay) in an reusable way, thus I (and other team-members) can reuse it easily from within CUBA.studio?
(I close my machine now, and want to start to implement this in my best 4 hours tomorrow morning. So please, if possible, just provide me with the technical info to achieve this. Otherwise I’ll most possibly loos the 4 hours in fighting through documentation and code-samples - not very much RAD like…)
I agree that this should be a part of the CUBA framework … sooner rather than later. Yes we could develop the functionality, but as a paying customer, I hope that this issue is considered by the developers.
The current position seems to be ‘images don’t belong in the database’. Unfortunately, I use images ALL the time in my UI and store them in the database. They are usually less than 10Kb and usually stored using a 1-1 relation.
Dealing with individual image files on a file system is problematic from a backup/restore perspective.
This is a recurring question and needs to be addressed IMHO.
This issue + the Azure SQL database issue are roadblocks for me to use the CUBA framework seriously. I really like what you have done with the framework and appreciate that this is not a ‘No Code’ environment but ‘Sugar’ should be allowed
