"Repeatable" or "Duplicable" TVs, per page

Hi all.
So as make my MODx installations more and more "idiot proof" for my clients, I find myself creating extra TVs just in case, like this:
- Image 1, Image Caption 1
- Image 2, Image Caption 2
- Image 3, Image Caption 3
- Image 4, Image Caption 4
- Image 5, Image Caption 5

What would be better, clearly, would be to group "Image" and "Image Caption" into a single "TV group", then add a link to "Add another image" that’d duplicate the group.

The caption TV and grouping isn’t really necessary, but nice.

Anybody have any ideas for a way to accomplish this without a massive hack? The most challenging thing would be the database structure. It’d be easy to just throw in another table and store them there, but you’d probably lose a bit of MODx functionality (calling them as TVs for PHx, Ditto, etc.). This would probably be the most flexible though, as you could create your own snippets to manage and output the data however you wanted.

I can’t wrap my head around how else they’d work in the current MODx table structure, unless you create 10 or 20, then hide them with javascript. That’d probably be the easiest thing to do, though it just feels messy to me to have tons of TVs that are there "just in case". But it’s probably what I’ll end up doing unless somebody has a better idea (which I’m hoping for).

Thoughts? Thanks!

I’d certainly use MaxiGallery for images + captions.

In case you have other scenarios that are a little more complex than picture galleries...

I can tell you how I solved a somewhat related problem:

In a product page template (for a basic shop) I set up various TVs: manufacturer, short + long product text, price, stock, active yes/no, images, SKU etc.

Now, in the case where one item can have several attributes - like T-shirt sizes, or colors - I needed to find a flexible way to include all these with the number of TVs I already got.
I now simply use a delimiter and add all those infos one after another:

e.g. one "base" product that comes in 3 varieties:
article numbers: ITEM0001||ITEM0002||ITEM0003
colors (option): green||red||yellow

That way I don’t have to create 3 docs, but can "summarize" them in one.

In my snippet for the actual display, I check if there’s a delimiter, create radio-buttons or a select-menu dynamically with the TV values I got. That way I’m sure I always receive the correct form variables for the user-selection (for the shopping cart).

This might be a simple, but efficient way to handle an undefined number of admin-entries. Of course, if you run into a situation where you need 2 dozen extra entries, this gets chaotic because you end up with lines of text 50 miles long. It’s also very important to "sync" / match the number of options. In the above example, you gotta have a matching color for every SKU, not 1 more or 1 less. But I think that’s still better than littering the DB and the manager with fields you’ll never use most of the time...

I’ve actually done the exact same thing on a site I built a while back, for product options as well. Problem is that it doesn’t work with non-text TVs very well (like images or files). (I’ve actually used that trick in chunks too. Lots of fun.)

MaxiGallery might work (I haven’t used it in ages; will take another look now), but I’m really going after document-specific elements, like 5 or 10 photos for a news/blog/content entry. Or a couple files associated with a content item. The image/file TV interface is pretty easy for clients to figure out and manage.

(In case you’re wondering, I don’t ever do RTEs because they invariably end up uploading 8megapixel images. I like my images in TVs so I can resize them, make them black and white, position them appropriately, etc.)

Well, I’ve read several discussions about future modx releases. One thing that’s always mentioned is how TVs will become much more flexible (or replaced by something else altogether; I’m too lazy to search for the threads right now). However, that’s of little use to you right now, of course...

For a simple feature like "related documents for download", I’d probably use a TV that grabs a folder’s content and displays a select-menu. Or use weblinks, which should give you more flexibility in terms of naming/labelling/adding a short description along with the actual links.

In any case, I guess I’ll bookmark this thread and see what others will suggest; perhaps there’s a super-secret ninja trick/hack out there we haven’t heard about

I actually wasn’t going to bring this up because I thought 0.9.7 would take care of this, but it doesn’t look like it’s in the cards, so I figured I’d get some ideas. Thanks for the feedback so far, Ganesh.

Using weblinks (or child documents), as you suggested, is another idea I’ve kicked around (and implemented), but it’s a bit tedious. Definitely not super ninja

Just FYI:

The idea I had for future capabilities along these lines involved allowing users to dynamically assign an Element (a.k.a. TVs, chunks, snippets, etc. are called Content Elements in 0.9.7), or a predefined set of related Elements, to a Resource (a.k.a. Documents and Web Links are referred to generically as Web Resources in 0.9.7). In this case, you would need a user interface to allow editors to "duplicate" a set of related Elements directly attached to an individual Resource, and I guess rename them slightly when duplicated. I call this concept ResourceElements, and it bypasses the template relationship altogether, so you wouldn’t be adding overhead to every Resource using a specific Template if one Resource had 50 sets of these image-related Elements. I also want to allow these relationships to define additional relationships between Elements in a specific Resource relationship (i.e. this TV is a child of this Chunk when attached to Resource #12).

This is a complex and flexible approach to doing this, and will require careful consideration when planning a generic management interface for it, but I think this is the right approach. Using it, we can tackle situations as you describe, attach free-form or highly formal metadata to Resources, attach elements for programmatic security checks, and just about anything else you can imagine doing by creating a direct relationship between a Web Resource and a single or collection of Content Elements.

Haha, awesome. Sounds kind of like the child document idea, but streamlined enough to make sense. Thanks for the update Jason, and keep up the great work on 0.9.7.

Or maybe even have categories of Resources and attach Elements to the category...

Quote from: sottwell at Nov 16, 2007, 11:56 PM

Or maybe even have categories of Resources and attach Elements to the category...

Not a bad idea, though I’d say implement the relationship as ResourceElements and simply use another structure to define rules of when to apply certain Elements to a Resource based on just about any information (i.e. by context, by content type, etc.). Sort of like predefined sets of Elements that serve as "metadata" templates to be applied to a Resource in any way imaginable.