4 replies to this topic

[Rob]

Hi all.

I've been using PW for a few months now and I'm very much enjoying it on the whole.

Before the repeater field became available I had, with the help of Ryan, coded my own repeater-style field that uses JS etc so I could have a multi-part field (in this case a URL and text for a link) and was able to add/delete as many of these items to a page as I like. The issue here was really the learning curve in understanding the underlying code and making it work correctly with the load/save of data and the JS interface bits. Not super complex, but not easy either!

Now the repeater has come along it means it is possible for us all to make much more complex data models, which can only be a good thing, without needing the ability to develop our own code.

The benefit of the repeater field comes at one price that I have noticed, and that is that the DB structure suffers in terms of readability. When I wrote my own code it saved all the data into a single DB table like "regular" fields and so when, as a developer, I needed to go into the DB manually to check things or do debugging it was straightforward. I can easily see what data is attached to what page.

With the repeater, there is a layer of abstraction added. It makes it more difficult to analyse the page data and also, I suspect, it adds a bit of DB performance overhead although it is likely so small as to be insignificant in most typical CMS cases i.e. not millions of page impressions.

I just wanted to kick-start an open discussion about the benefits of either approach and if there are any pitfalls we should be aware of or practises that we should try to stick to. I think the repeater is a brilliant concept and it opens up PW to a whole world of more complex uses as a data modelling tool, but I think perhaps we need to tread carefully and consider the bigger picture and whether it is suitable in all cases.

[diogo]

I think the correct way of using repeaters, is using them, only after deciding that we really can't achieve what we want by the traditional ways. In some situations the pagefield, for instance, will do the same work effectively and even in a more elegant way. I love that we have the repeaters, but i agree we should use them consciously.

[apeisa]

There are at least two clear indicators when repeaters are no go:

1. You need url for each item
2. You need hundreds or thousands items

Performance wise (in my knowledge) repeaters are pretty much same as having one page reference and you access the values of that other page. That is what repeaters does under the hood.

So while you could create news-template and have news-items as repeater field there, I don't think that is a good idea. No urls for each news item, not fully scalable (on UI side, from db/api it is the same) and you lose lots of flexibility on API side, ie. $pages->find("template=news-item, limit=10, sort=-created");

[MarcC]

apeisa, is it possible to use URL segments to provide a simple scheme for direct access to individual repeater items as if they were pages? I mean, if you have a set list of 10 repeater items (company board members, for example) and wanted to work it that way...

[apeisa]

Marc: It is possible, but I think that if you want to do that, then pages are probably better way to go. If only reason is nicer ui, then you better watch this development: http://processwire.c...rom-inputfield/