I need to build a form which has a selection of images (blobs) in a grid rather than a list view.
I would be grateful for any advice on the best way to approach this. I was starting to think about doing it with an html table, but I think it would be tricky to be able to interact with the data on the form (like clicking an image to focus on that record etc.)
Should I do this with a solution model form instead? Is there a plugin for a grid view?
I have done stuff like that using the labels and global relations on a detail form.
So for each image in the grid you have a global field for the ID and corresponding relationship to your image table. Then you can put the labels with related dataproviders on the form at designtime or via code using the solution model. Then using code you fill (or clear) these global variables with the PK’s of the images you want to show.
In my experience this is a better approach than using HTML because it takes a while for all the images to load inside a HTML_AREA. With labels you have the benefit of lazy loading so it feels more responsive to the user.
Thank you for that. How do you deal with putting x number of labels across and y number down? I might also want to be able to programatically change the size of the images (I could calculate how many times a given width image will fit across the width of the form, but how do you actually place x number of labels across and then y number down the form?) I will not know how big my foundset will be on any given search.
You can do this using the solutionModel and some math . You can then also adjust the height of the form so it actually scrolls like it was a list view.
And for changing the size of the images, you can do that using runtime properties or by recreating the labels using the solutionModel (like on the onResize event).
There are many html/jquery galleries out there (http://192.241.236.31/themes/preview/sm … llery.html). An alternative approach would be to wire one of these up via the html viewer (if smart client) or just a plain html field (if web client). The trade off is that for an advanced UI that is already built you have to wire it up. Performance-wise the results should be better than using native Servoy elements because the UI is all in the client and you are just passing data back and forth. I suspect the new Servoy 8 web client operates along the same principles.
At this point, I"m not sure how valuable learning solution model from scratch really is. And I speak from being the first outfit to do “servoy-within-servoy” (2008?). For starters the target of solution model is the current Servoy clients, all of which are all way behind the tech curve now. For future web client, there is no reason for the extra solution model abstraction for dynamic UI’s when the you can just do it in html/jquery/components/whatever directly.
Learning solution model and client-side html programming is about the same level of difficulty (and have a lot of similarities). So do you want to learn an approach where you have to build all of your own UI’s by hand or do you want to learn an approach where you can start with a whole world of UI components as your starting point?
Apart from the global/relationship approach you could also use HTML inside the labels and then use the blobloader to load the images.
No dataproviders needed on the labels then.
The problem I have is how do I literally place independent labels across a form? If it is not one html label that then does the tables within it, how do I make it flow right across x columns, and then down etc.?
Hmm… Use solutionmodel / DON’T use solutionmodel… I am confused.
I still have not made the jump to pure webclient, but I suspect that when I do, I expect the html way of doing it will be the better choice…
I suppose I have to accelerate the process of moving to webclient. I will look through the html/jquery galleries and see if I can figure out how to wire it up…
My worry at the moment is still how to approach rows in the database and graphically tell them to appear in columns. I guess it is a programatic factor of how big the columns are, and how many rows we have ?..
I’ve got my work cut out for me. Might just tell the client that I can’t do that, not sure that this one little feature is actually worth the time.
bevil:
The problem I have is how do I literally place independent labels across a form? If it is not one html label that then does the tables within it, how do I make it flow right across x columns, and then down etc.?
You will have the same challenge when you create the HTML table since you need to generate the rows and columns then too. Of course the HTML engine will take care of the filling out across the form.
I started on a small module to easily create such a grid using the solutionModel and the blob loader but I ran into some snags.
With the following code I create the grid below:
function onLoad() {
foundset.loadAllRecords();
// params are form name to show the grid on, foundset with images, image colum name
var _oGrid = new scopes.IMAGEGRID.JSFoundSetImageGrid(controller.getName(), foundset, 'image_data');
// set the amounts of columns
_oGrid.setColumnCount(5);
// create the grid on the form using the solutionModel and the blob loader
_oGrid.createGrid();
}
[attachment=0]Screen Shot 2014-09-09 at 13.04.54.png[/attachment]
But as you can see it crops the images instead of reducing them (even though I very much tell it to).
And another issue is that it performs pretty well in Developer 6.1 but when running it in Developer 7.4 it’s an incredible hog. So it looks like this will be a non-starter unless Servoy really fixes these performance issues in 7.4.
Ah…I guess I know why it doesn’t reduce. It’s in HTML so the HTML renderer controls it and not the label.
Nonetheless the performance issue in 7.4 is still showstopper.
bevil:
Hmm… Use solutionmodel / DON’T use solutionmodel… I am confused.
Solution model is great (especially years ago) but it’s not the future.
bevil:
My worry at the moment is still how to approach rows in the database and graphically tell them to appear in columns. I guess it is a programatic factor of how big the columns are, and how many rows we have ?..
As Robert mentioned, the html engine (ie, browser) takes care of the “flow” of your images. Shrink this page down to phone size and back to desktop size: http://192.241.236.31/themes/preview/sm … llery.html. Basically, all you do is set how many columns you want for each particular viewport size and let frameworks (which you don’t have to write) do the rest. Note that not only are columns handled for you but image size as well.
Responsive web UI’s is a huge leverage point for business apps right now. Develop only one UI that works on all devices (with great performance, unlike Servoy’s webclient) and a ton of components to choose from. Learning solution model isn’t going to get you there…learning web technologies will.
An example: scrolling through a million records using a http://datatables.net/ grid component (same UI code for both desktop and phone):
[attachment=1]BgTUS9_CcAAeuBO.png[/attachment]
[attachment=0]BgTUEVLCEAASA2X.png[/attachment]
Now of course there are a number of challenges to making it somewhat easier to code UI’s with this approach. The WYSIWYG editor part is very hard to do, the async nature of a browser app is not part of Servoy’s DNA, and Servoy’s justly famous automatic data broadcasting is only recently becoming mainstream in the html development world.
So while we think Servoy whiffed hard (wasted two or three years) with their mobile client (viewtopic.php?f=16&t=19471&start=15#p105151), we are definitely curious about what Servoy 8 has in store. There may still be time to catch up.