Hook to modify how repeater fields are rendered?

[Valery]

Hello everybody,

I am a bit stuck with the code, so I am asking for a helping hand here.

Where should I hook to if I want repeater fields to be rendered differently inside repeater items ? For example, instead of rendering them as a stack I would like them to be displayed as a table. How do I do this?

Any advice is appreciated.

[fmgujju]

Have you read this http://processwire.com/api/fieldtypes/repeaters/

You can use your own template for each repeater item. There is section called "Implementing templates for repeater fields" at the end of the page.

[Valery]

Thanks for the hint, fmgujju.

I forgot to mention that I need to modify the output of repeater items for a backend module, not a template.

To be a bit more clear:

public function ___executeEdit() {

$editor = $this->modules->get("ProcessPageEdit");

return $editor->execute();

}

Is there a way to do the same trick for a module?

[Martijn Geerts]

And rebuild the EventsFieldtype a little?

[Valery]

Thanks, Martijn. Events do look more "hard-coded" than Repeaters but they also look more suitable for a product list (I am doing a small web shop).

Guess I will be sticking to Events then.

[kongondo]

Thanks, Martijn. Events do look more "hard-coded" than Repeaters but they also look more suitable for a product list (I am doing a small web shop).

Guess I will be sticking to Events then.

Is this a product list on page by page basis? If not, if it is site-wide, why no create a simple ProcessModule? On the other thread you talked about locking the Events fields...do you want your product listing to be read only?

[Valery]

Hi kongondo,

What I am developing is, basically, order management for shop owners. My "order" template has a Repeater inside of which there's a Page field that links to a product name. I keep it read-only because shop owners are unlikely to modify names of ordered products. Every product has its own page.

It works like this: people select products from the front-end, then place their order --> a new page is created with template=orders. Inside this page I have a repeater with all the ordered items. Shop owners can see this page from the backend. I attach a screenshot for clarity.

I like repeaters for their scalability. Let's say my customers want to see product photos inside an order page. No problem, I just add the image field into the repeater.

Event field? Database modifications, code modifications. No means to delete an event when it's displayed as locked/read-only.

There's some thinking for me to do before I decide on either solution...

[Soma]

This sounds like best option to go for pages. Scalable flexible ...easy

[kongondo]

@Valery,

Thanks for the explanation. I would use pages too for each product in this case but probably not repeaters since they are not infinitely scalable. At some point, they do require a lot of resources since repeaters are just pages "hidden" in the admin and when you edit a page with repeaters, you are editing all items at once. Instead of repeaters, I would create a simple Process Module that would list the products (your pages with products) and their status in a Table. You could even have two tabs - one with new orders only and one with older orders (older versus new could be differentiated using a checkbox, for instance). I don't know how comfortable you are with coding but this is not too complicated....

[Craig]

I haven't done this before, but if faced with this problem - I would attempt to have child pages using a template of "order_items", instead of repeaters. Yes, there would be lots of them (eventually), but it shouldn't be a problem as you know where they are and hopefully add the correct fields & data to them.

[Valery]

Thanks guys. 

kongondo, I like the idea of designing a tailored field type or taking apart a PadeEdit process for that matter. However, my initial goal was to go for a ready made solution in the first place. I guess I will have to stick to repeaters for now (orders are usually up to a dozen of items for a small web shop), but I will keep thinking here.

Craig, good idea. I will add it to my "knowledge base" even though I would like something different for my "orders" template.

What I am thinking of right now, is a new field type programmable through the API, which would be displayed in the backend. Think of this field type as a holder for your code. A Lego field type, so to speak, or a field-template.

Not ready to get down to detail here for now.

[kongondo]

Valery,

I think you misunderstood my post? I would go for pages (just like you showed in the screenshot) but unlike you, instead of using repeaters, I would use normal pages  - one for each product. Then....for the client, instead of showing orders via pages (i.e. in your case repeaters); I would show orders on the Process Module - in a table. For other ideas, see also Pete's Dashboard module that you can add to using 'normal' PW $pages API. These are just by the ways; l agree with what you've said. Work with what you are most comfortable with as long as it doesn't negatively impact the site

[Valery]

Hi all,

Thank you all for the feedback. To refresh, I am doing a backend for a shop owner. My challenge was to display a page with ordered articles, each one of these being a repeater item (I am sticking with the "good old" reppies for now because I also need to store the quantity of ordered items somewhere).

Ideally, the shop owner should see a table of ordered items, not the combersome list of repeaters.

At first I went down the wrong way trying to modify the way repeaters are rendered. However, some tips (thanks kongondo!) gave me a different idea of how to display repeaters (and actually any other field) in the backend the way I want.

So here's a quick update: I switched from messing with repeater formatting/output to writing a custom module.

The module uses the standard ProcessPageEdit except that I construct the form manually ($field->getInputfield($page) + InputfieldMarkup). There's a hook after buildForm() which makes ProcessPageEdit display my form rather than the default one.

Now I have a custom InputfieldForm combined with hooks, which allows making use of ProcessPageEdit with no modifications.

I've never been happier.

Oh, and a couple of screenshots to go with the post. One shows how my backend page looked with repeaters, and the other one shows a leaner, present-state page made with the approach described above.

[kongondo]

Nice to see this is coming along nicely Valery. Be warned though, Process Modules are addictive!