I’d like to request a new data type for TVs: an image array. In the years that I’ve been using MODx, I can’t count how many times I’ve wished I had this in the manager. Maxigallery does something similar on the front end, but then you’re largely restricted to the intended use of Maxigallery.
The way I envision this working is that you would create a TV, and select the image array data type. Then when you create a document, in the area where you would edit this TV, there would be an image field with a browse button next to it, much like the existing image data type TV, but there would also be an button below this that says "add an image". When you click it, a new image field appears below the current image field, and the button drop down a step. There would also be an "remove" button next to all image fields except the first one. So you can add as many images as you want to a single TV value, or remove as many as you’d like.
The value of this TV would be saved as a CSV of image paths. This would give developers the ability to loop through this list and output a list of images quickly and easy, in whatever way they see fit. It would also eliminate the need to have some fixed amount of image TVs listed at the bottom, when what is needed is the ability to have an arbitrary list of images with no limitations to the number of images.
Alternatively, you could have a data type called "file array", and do the same thing, but with any type of files, mixed or uniform. This data type could be used for my purposes just as easily, but would also widen its versatility for other needs.
-
☆ A M B ☆
- 24,524 Posts
Well, if the images are placed in appropriate folders, you can use the @DIRECTORY binding to get a list of filenames.
http://sottwell.com/tv-bindings.html (still needs to be written up with examples and stuff)
To my knowledge, the @DIRECTORY binding does not help in giving the user a way to easy specify the directory, outside of just typing it out. If you could somehow specify a data type, like the file data type, to use the file browser to select that directory, then this would be almost as good as my suggestion in some situations (IMO, because you could not specify files from different locations), and perhaps better than my suggestion in others (because you would not have to select the files one-by-one). And of course if you could use the file browser in this way, you could just as easily upload files to that directory.
But I don’t think there is a way to select a directory as the final path in the file browser; you can only select files. Seems like a change in this regard, to make selecting directories in the file browser possible, could largely satisfy this need, and might be simpler than adding a whole new data type.
-
☆ A M B ☆
- 2,475 Posts
A couple of thoughts...
The @DIRECTORY binding does return directories contained in the directory specified... in fact, it seems to return ANYTHING within that directory... which is somewhat of a problem.
Is there a way to filter the file types that are returned by the @DIRECTORY command? E.g. @DIRECTORY /images/*.jpg
Second thought... if you wanted to specify a default directory for clients, you can mix the @ Bindings with Chunks, e.g.
@DIRECTORY {{default_client_upload_directory}}
