Module want: Repeatable elements

[ryan]

These are great links, thanks Martin!

[Svet]

Hmm, I'm thinking this would be something I'd like as well.

Site I have upcoming will have a large number of quotes from customers, good feedback stuff, and it'd be nice to have that as something where a single page just keeps on adding to a single array.

Would be nice to have multiple input fields on the admin end like images have.

[landitus]

Recently, Craft CMS added the Matrix field. Looks quite nice! Check it out here

[teppo]

Looks quite nice!

Agreed. Almost as nice as Repeaters in ProcessWire

[apeisa]

It supports multiple content types, meaning that you could choose multiple templates for repeater. That is powerful feature in some cases.

[titanium]

Agreed. Almost as nice as Repeaters in ProcessWire

Sorry to disagree, but this time the Craft CMS' Matrix field is far superior to what Processwire has now. Compared to the Craft solution, PW repeaters feel a bit clunky IMHO and they don't offer the same functionality. Time for us to catch up... 

[teppo]

Sorry to disagree, but this time the Craft CMS' Matrix field is far superior to what Processwire has now. Compared to the Craft solution, PW repeaters feel a bit clunky IMHO and they don't offer the same functionality. Time for us to catch up... 

Looks like I got confused by their UI, sorry for that

Taking another look at it, the Matrix field seems more like having multiple types of repeaters within repeaters. Not sure if that's the way I'd prefer it, considering that this could easily be (ab)used to create some pretty wild combinations, but I'll agree that it seems very flexible.

To compete with that, our repeaters would need to support a) multiple templates and b) nesting. Doesn't sound entirely unreasonable request, though I wouldn't be surprised if that raised some new issues. I wonder what Ryan thinks of this?

[ryan]

I would fully expect those guys to come up with a pretty implementation for matrix fields. After all, aren't they the ones that wrote the EE matrix fields plugin? I think that matrix fields make good eye candy, and provide a quick n' dirty way to solve some things in lieu of real structure. But I don't think they are great for the long term or large scale. I'm much more interested in creating timeless tools with well defined data formats and structure, and separating our clients from getting involved with defining schema. I can see the solution presented there being a bit of a monster as the format of data becomes more ambiguous than a rich text field (chances are it actually isn't much more than a rich text field from the storage end). Chances are that data can't be indexed, searched and plucked field-by-field the way ProcessWire's repeaters can. But I haven't actually used it, so maybe I'm making assumptions from what I see on that page.

Such things would certainly be possible in ProcessWire, but I'm just not convinced it's right. I can see why the Craft guys are doing it, because they are trying to sell stuff and candy sells. Whereas we're trying to make the best, most sustainable tools for the long term and large scale... the meat and potatoes rather than the candy. So something like this from Craft is not something to "catch up" to, because their bottom line is to make candy you will buy, not on providing what's really the best. My full time job is to develop web sites and applications that use ProcessWire (rather than to sell you something), so I'm simply not interested in colorful gadgetry and instead want the best foundation of quality and substance, at least when it comes to the core. Matrix fields and repeaters are somewhat at odds with that goal (even ours to some extent). These types of fields should be used occasionally and sparingly, for specific purposes. As it is now, I don't personally use repeaters very often. Half the time that I see people using them, they are being used in situations when the person really would have been better off without them. So I'm not so enthusiastic about pushing the core further in encouraging use of repeater/matrix type fields, when I don't personally use them very often, nor do I often recommend them. Don't get me wrong though, I do like candy too (sparingly), but really want to limit it in our core. When you get down to the core, Craft doesn't hold a candle ProcessWire. But I'm always glad to support whatever people want to build as 3rd party modules, and ProcessWire is a good engine for this. 

[wes]

I personally don't see a reason to extend pwire's core to support Craft's matrix block stuff. It's taking the repeater paradigm a little too far / specific for inclusion out of the box. For me, processwire's repeater fieldtype is pretty much perfect as-is, and actually is the sole reason I started using processwire.

The way I see it, the jump from child pages to in-template repeaters for organizing certain kinda of data is substantial and incredibly useful from a client UX/UI perspective, but the jump from the existing repeater type to something like matrix blocks from Craft is not as substantial. Just use multiple child templates

Half the time that I see people using them, they are being used in situations when the person really would have been better off without them. So I'm not so enthusiastic about pushing the core further in encouraging use of repeater/matrix type fields, when I don't personally use them very often, nor do I often recommend them.

I'm curious Ryan, what for you is the ideal situation for repeaters vs child pages? For me, I use them in situations where it's helpful to see repeating data all at once, as opposed to seeing a list of child pages and having to drill down into the individual pages to see specific data.

For instance, if I have a relatively complicated gallery in a page (which requires more fields than the images field offers) repeaters are perfect because they allow clients to see all of their images in a single page, drag them around, etc. If I were to build all the gallery fields into a separate template and have them as child pages, it would be difficult to visualize the entire gallery all at once. So a repeater works wonders.

Ryan I hope you aren't considering phasing out repeaters because you don't use them yourself. For me, it's a killer feature. They aren't candy, they serve a real distinguished purpose from normal child pages. When the next version of pwire comes out with gridded image galleries, that will be icing on the cake for my CMS wishlist. The only weakness I see with the current pwire release is the inefficiency of viewing image galleries. Pwire is near-perfect
 

[ryan]

I'm curious Ryan, what for you is the ideal situation for repeaters vs child pages? 

Sideshows and rate tables are examples of good use cases. Anything naturally bound by scale that produces in-page components, rather than groups of data that need to be represented by their own URLs.

For instance, if I have a relatively complicated gallery in a page (which requires more fields than the images field offers) repeaters are perfect because they allow clients to see all of their images in a single page, drag them around, etc. If I were to build all the gallery fields into a separate template and have them as child pages, it would be difficult to visualize the entire gallery all at once. So a repeater works wonders.

This sounds like another good use case example. 

Ryan I hope you aren't considering phasing out repeaters because you don't use them yourself. 

Who said anything about phasing out repeaters? That is definitely not the plan. I currently have a big to-do list of items to improve repeaters, which I'm slowly working through. But just wanted to clarify that we're not trying to follow the path that Craft has taken. 

[onjegolders]

You make some great points Ryan. I'll admit to being someone who is/has been in the past, enticed by some of the nice UI of systems like Craft (or SquareSpace) but more and more I see them as tools for the hobbyist, whereas Processwire has always been a tool for developers and designers.

Thanks to Processwire we have far more control over the data and structure of the sites we create and this is one very important asset when competing with tools which make it easier and easier for people to "build their own" sites (and put us all out of business )