PW 3.0.4: Repeaters Revisited + ProFields Matrix

[ryan]

This week is all about repeaters, something that we didn't cover on the roadmap last week–we always like to save a few surprises to keep things interesting. We've also got a preview of the new Repeater Matrix field coming soon to the ProFields package… 

Read the post here: https://processwire.com/blog/posts/processwire-3.0.4-repeaters-revisited-preview-of-profields-matrix/

[Peter Knight]

There aren't enough Like buttons for this!

[Tom.]

Tell me about it! 3.0 is going to be awesome! Every time I think ProcessWire is perfect, Ryan keeps proving me wrong by improving it  

Keep proving me wrong Ryan! 

[Martijn Geerts]

I love what you've done GUI wise to... you removed the unnecessary space the old repeater took and making these not only more beautiful but also more practical. 

Awesome work !

[diogo]

They are beautiful, both, the new repeaters and the matrix. Beautiful!!

[qtguru]

Hi Ryan how can i follow PW 3.0, I want to know the Core updates to the internal so i can contribute.  

[Tom.]

Hi Ryan how can i follow PW 3.0, I want to know the Core updates to the internal so i can contribute.  

https://github.com/ryancramerdesign/ProcessWire/tree/devns

[SiNNuT]

Hi Ryan how can i follow PW 3.0, I want to know the Core updates to the internal so i can contribute.

https://github.com/ryancramerdesign/ProcessWire/tree/devns

And also the weekly blogposts detail most new stuff:

http://processwire.com/blog/

[Mike Rockett]

How exciting! So amped for final release. Ryan, you are amazing.

:D :D

wire('payments')->recipient('ryan')->amount(10000000.00)->currency('us_dollars')->pay(['express' => true]);

[thetuningspoon]

We also have an alternative option available where you can specify PHP files that render the output markup for each type, not unlike baby template files, but we'll cover more on that next time, as it leads into yet another new feature coming to PW3 that we're saving as a surprise.

Color me curious...

The new Matrix field is huge!!! Is this using pages behind the scenes like a PageTable, or is it more like the table field?

[Tom.]

I imagine it's a more powerful repeater. But we will have to wait and see.

[tpr]

There aren't enough Like buttons for this!

Put it in a repeater

[ryan]

Thanks guys glad you like what you see!

I love what you've done GUI wise to... you removed the unnecessary space the old repeater took and making these not only more beautiful but also more practical. 

Actually I haven't done anything in that respect, other than add the option to have them be collapsed by default (something that's been requested by a few people). But I agree just having that option makes quite a difference. 

The new Matrix field is huge!!! Is this using pages behind the scenes like a PageTable, or is it more like the table field?

It is using pages in exactly the same manner as regular Repeaters. Repeater Matrix actually extends Repeater, in the PHP class sense. So the core Repeater class handles all the page management for Repeater Matrix. This also enables you to convert a Repeater to a Repeater Matrix field (or back again) just by changing the field type.

[thetuningspoon]

It is using pages in exactly the same manner as regular Repeaters. Repeater Matrix actually extends Repeater, in the PHP class sense. So the core Repeater class handles all the page management for Repeater Matrix. This also enables you to convert a Repeater to a Repeater Matrix field (or back again) just by changing the field type.

Oh wow, that's perfect! So the Matrix field is basically an enhanced repeater with multiple templates? Similar to a PageTable except the fields are visible and editable inline and the setup is all automated?

I think we are going to need to develop some sort of flow chart or documentation page specifically about the different types of repeating fields and why you would choose one over the other for a particular use case

[ryan]

Oh wow, that's perfect! So the Matrix field is basically an enhanced repeater with multiple templates? Similar to a PageTable except the fields are visible and editable inline and the setup is all automated?

It's like an enhanced repeater, but it doesn't actually use multiple templates. It uses just one, and pulls a few tricks behind the scenes to make it all work, while remaining perhaps more efficient than if it were using multiple templates. 

One other update I've been working on this morning for regular Repeaters, and now have functional (though have not pushed to GitHub) is making all repeater items ajax-driven, so they don't load until you click on them. This enables Repeaters to scale just as well as PageTable. It's a configurable option, but one that I think will be good to enable for folks that have lots and lots of repeater items... it should make a major different in editor performance. 

[pwired]

I think we are going to need to develop some sort of flow chart or documentation page specifically about the different types of repeating fields and why you would choose one over the other for a particular use case

I think the latest developments in Processwire is going to make you ask to reconsider the workflow you follow when building a website. For example in my case wireRenderFile() and $layout changed my old workflow into a much better one. Now with the new matrix field I think it will go again to a next level

[Ivan Gretsky]

I think we are going to need to develop some sort of flow chart or documentation page specifically about the different types of repeating fields and why you would choose one over the other for a particular use case

There is such a comaraison. But now it seems to become outdated. Ryan wrote then "But PageTable will scale much further in the admin UI than Repeaters will, so I would personally favor PageTable in more situations than Repeaters", but with upgrades to Repeaters UI and the introduction of the Matrix field I think it is no longer the case. At least I cannot find significant reasons to prefer PageTable over Repeaters anymore (well, exept the licence). So I also would also ask for an updated comparaison.

[teppo]

At least I cannot find significant reasons to prefer PageTable over Repeaters anymore (well, exept the licence). So I also would also ask for an updated comparaison.

PageTable is particularly handy if you need control over where the data is stored. Repeaters handle this part automatically behind the scenes, but with PageTable you have more options, such as making stored items children of current page, etc. In some cases the UI of PageTable is also preferable.

Of course there's also the free vs. commercial point of view: with PageTable you get the multiple templates feature right out of the box, but with Repeaters you'll have to get the (commercial) Matrix version in order to pull that off.

[mr-fan]

The new repeater is awesome in design and function!

At least I cannot find significant reasons to prefer PageTable over Repeaters anymore (well, exept the licence). So I also would also ask for an updated comparaison.

I use PageTableExtended for a similar feature like repeater matrix but with prerendered output like a contentblock builder on every page where you can put in text, text with image, galleries, maps and so on - for such complex things rendering the single templates is much more easier to maintain but more complex to setup.

Also PTE works like a preview of the builded contentblocks and on other things you could create a own view for backend and frontend...

I'm very exited about the new features, but Pagetable would take his place i think.

[Ivan Gretsky]

Thanks, your points are valid. Still they show that the two are pretty similar, so the comparaison would be a nice thing to have. Maybe with preferable use cases...

I do not know why, but I have an impression that PageTable is more scalable than Repeater. Or is it only from the UI point of view? Are there any difference for the page rendering time, etc?

@teppo: Is there any benefit in storing PageTable pages as children?

[thetuningspoon]

I think one enhancement that would really help pageTable stand out in certain use cases would be if it had the ability to search for and add existing pages that matched the templates assigned to it from anywhere in the system (or a limited set).

Basically, a PageTable/Page Field crossover.

[mr-fan]

@teppo: Is there any benefit in storing PageTable pages as children?

Usecase would be you have one element under a specific parent (children are pagetable pages) and in a process for example a review or some kind of sorting so you could have a hook or module that switch the parent if some options are set or some process happens...

Usually i've a hidden parent for all normal pageelements but sometimes pagetable childpages are fit better.

[thetuningspoon]

Usecase would be you have one element under a specific parent (children are pagetable pages) and in a process for example a review or some kind of sorting so you could have a hook or module that switch the parent if some options are set or some process happens...

Usually i've a hidden parent for all normal pageelements but sometimes pagetable childpages are fit better.

 

I've found that in every case I've wanted to have the PageTable pages stored in a visible part of the page tree, I run into issues where the client tries to add a page in the page tree and it isn't added in the PageTable automatically, so I've taken to keeping all of my PageTable pages hidden anyway to avoid confusion. It seems that in these cases I'm not really looking for a separate field to store page references, but just a different interface for managing the existing page tree that can be embedded in the page edit view.

[adrian]

I've found that in every case I've wanted to have the PageTable pages stored in a visible part of the page tree, I run into issues where the client tries to add a page in the page tree and it isn't added in the PageTable automatically, so I've taken to keeping all of my PageTable pages hidden anyway to avoid confusion. It seems that in these cases I'm not really looking for a separate field to store page references, but just a different interface for managing the existing page tree that can be embedded in the page edit view.

Have you tried this: https://processwire.com/talk/topic/8177-page-table-howto/?p=89960

Not that I am suggesting you should use PageTables if the new repeaters work as required, but that does provide a way to have the new pages automatically added - I use it when I want separate URLS, but the client is confused about not being able to edit under the main parent page - like a list of staff for example.

[thetuningspoon]

Have you tried this: https://processwire.com/talk/topic/8177-page-table-howto/?p=89960

Not that I am suggesting you should use PageTables if the new repeaters work as required, but that does provide a way to have the new pages automatically added - I use it when I want separate URLS, but the client is confused about not being able to edit under the main parent page - like a list of staff for example.

Yes, see the next two posts in that thread  Your solution is helpful but still requires the page with the PageTable to be viewed in the editor before the item actually gets added to it.