240 replies to this topic

[vknt]

For my work this is a HUGE step forward. I'm using this on a site that we're developing right now and the structure look so much better.

The only bug so far is the one christoph has already mentioned: the visibility settings don't work. Will we have separate options for the repeater and the items inside the repeater?

[Soma]

I already reported that settings for the reapeater field doesn't save. I think Ryan missed it, but sure he will look into it now

[wes]

Just gave this a try today (both adding entries through the CMS and displaying them through the API). Works wonders, no complaints.

Props to ryan!

[Pete]

I've been tinkering with this with a view to some sort of invoicing system (if you think about it, the only thing missing to produce something like that in PW was repeatable fields and adjustable-width columns, both of which are now here ).

The only thing I feel is missin is the ability to display repeatable fields as a table, or more of a grid view. What I mean is the field titles are repeated with every repeater row, whereas for invoicing or similar needs it would be great to have them as a grid.

One of the problems here is that as far as I can tell grid views aren't part of jQueryUI (yet), however when I looked at the example 3rd party plugins I immediately got excited by SlickGrid's examples - check out the Making it editable example, as well as looking at the different ways to display data (although data display should be more about the end-user experience and doesn't belong in the admin, but you get where I'm going with the editable part of it at least).

My thinking is that to achieve something like this requires:

• Settling on a jQuery plugin to use - requires some thought as you wouldn't want to have to change it at a later date ideally
• Adding a checkbox to repeatable field configuration to choose to display it as a grid instead of the normal repeater - this needs the usual "only tick this if your repeater will display tabular data" disclaimer as it will obviously break if you add image fields or RTE text fields etc to your repeater.
• Some code to display it as a grid
• Some code to add a button to the end of the table to add another row, as well as a button at the end of each row to remove only that row

I think that's it - sounds easy huh? I'm not sure whether ryan already has plans for something like this, or whether it should be included as part of the current module or as an additional module if it were ever to be built, but I think the possibilities for this could be very exciting indeed.

[Soma]

I think I would be better to build a "table grid" module, rather than "violating" the repeater for a "table" like display which isn't meant to be in first place, it's an "element repeater". I could imagine having table like field type for this sort of table data, that is configurable to have certain number of columns. Then use such a plugin as datatables or slickgrid's to handle the UI.

[Pete]

That's pretty much what I was saying - take a look at the example I linked to

My thinking was that when they're in the database they're essentially the same thing, so rather than reinvent the wheel...

You still want the fields values to be stored separately in the database - for example if you then built a template to display rows from an invoice it would need to calculate the totals for each row (quantity x unit price) and the overall subtotal, tax and total. Similarly you could then build a module to automatically email something like that to a client when the page is published.

The way I'm thinking about it, a "row" is a repeatable element, which is where I thought it would be a natural extension of the current module (whether as part of this module or another additional module that requires the current module).

[Soma]

I know them Pete, I already used them in projects (even PW), I just can't see that it's something easy to implement for the repeater field the way it's done.. .

But maybe I'm wrong. As I see it is that you have a table with text and number, not images, page refs , RT's etc. So I could see an easy implementation that's using datatables and the data stored as serialized array. Just trying to look at it different.

[Pete]

I did think serialized arrays at first and they would be cool too, but then you can't easily show multiple invoices for clients with total value outstanding etc - I'm thinking more complex, searchable, sortable needs which is why I thought of repeaters, as then you just iterate through each row and build your totals up to display at the bottom (on the front-end or a client-restricted admin page)

[ryan]

Darn, I just wrote up a long reply and accidentally closed the window trying to do a screencap. I've run out of time to redo it, but going to try and summarize:

• You can sort of use repeatable fields for this now, but they won't look like a spreadsheet
• Repeatable fields aren't ideal for this because they can support ANY fieldtype. In a grid/spreadsheet view, you only need to support limited data types.
• I think it would work best as it's own FieldtypeMulti, where it manages it's own data with columns in a table… more traditional database style. PW API supports searches in anything that has it's own column in the DB schema, so long as an index is defined for it (in MySQL). This would be more efficient in this case because the limited set of data types you'd need to support line up nicely with how you'd define a DB table. Pages are of course a lot more flexible, but you don't need that flexibility here.
• I've built fieldtypes like this for managing property availability and rates. It's not hard to do by making your own FieldtypeMulti. This is exactly what the FieldtypeMulti class is designed to do. (FieldtypeComments and others are based on it). The main challenge in this Grid Fieldtype would be in making the schema configurable per field, but I still think it's well within reach.

The only bug so far is the one christoph has already mentioned: the visibility settings don't work. Will we have separate options for the repeater and the items inside the repeater?

Sorry, I missed that before. I fixed and committed it over the weekend.

2) Is there a special setting to make the output of a repeatable field viewable to users who are not logged in? Currently I only see the output when I'm logged in.

Repeater fields are meant to be iterated like any other group of pages, and they are technically no different. That means you have to foreach() them and output them in the manner you want. I will probably include some default render() method in there in a future version, but it would mainly only be useful for testing/debugging. There is also an example of how to output repeater fields on the first page of this thread.

Field contexts on a template level will allow so much flexibility in the admin. We can then create ever more usable, custom admin screens for clients - simplifying the editing process for them.

I'm glad to report that Template>Field contexts are now completed and working. I'm going to be testing here more before committing to the core source, but wanted to let you guys know you'll be able to use them in the next week. I'll be posting a video in the next day or two. Also, I have limited the field properties that can be configured per-template to include just these:

• Label (including all languages)
• Description (including all languages)
• columnWidth
• Visibility (collapsed settings)

I think these are the most likely ones to be configured in this manner. Though technically, the core can support configuration of any field property (including all custom ones defined with an inputfield or fieldtype). But I've specifically disabled those for now as it makes me think I'd need to do a lot more testing before putting this out there. I'll probably enable it as an advanced mode option for anyone that wants it, after confirming that everything works well with these basic settings in lots of different contexts.

[Pete]

Thanks ryan - for some reason I completely forgot about FieldtypeMulti which will, as you say, eliminate most of the headache as well as be able to provide me with a more sensible single table in the database with many fields, which is perfect for the various scenarios I was thinking of (I actually mocked up an idea for the invoicing repeater before my previous post and noticed I was quickly racking up a lot of separate fields just for that, so this is a much better way to go).

Sorry Soma if you had suggested that or that was what you meant - it wasn't until ryan said FieldType multi that it sank in

[Christoph]

Repeater fields are meant to be iterated like any other group of pages, and they are technically no different. That means you have to foreach() them and output them in the manner you want. I will probably include some default render() method in there in a future version, but it would mainly only be useful for testing/debugging. There is also an example of how to output repeater fields on the first page of this thread.

Thanks for your reply, Ryan.
The problem I have is a little different. I have no problem creating output with a foreach(), the problem is that I only see that rendered HTML output if I'm currently logged into the system. So if I log out or view the page with a different browser I see nothing rendered.

Oh, and while I wanted to check the page just now in the back end I got an error:

Duplicate entry 'for-page-5799-5807' for key 2

[Pete]

Christoph - are you sure that the page in question's template has view access for guest users? I can't see why it wouldn't, as the default is for guests to view all new templates, but I'm wondering if this might somehow be the case.

[Christoph]

Hi Pete,
I haven't changed any settings, so it should work.
But I can't check currently due to the afore mentioned error

[ryan]

Christoph, it's hard for me to tell for sure how to locate the error without actually seeing it. If you have an admin login you can PM to me, that might help me to see what's going on. Another thing to look at is: Pages > Admin > Repeaters > [your field name] > for-page-5799 (this is where it stores the repeater pages), and see if there's anything there that doesn't look like the others. As for displaying the repeater pages, could I see the block of code you are using to display them?

[Soma]

Christoph is right, it's not possible to render the repeater field when not logged in as superuser. It must be simply that the repeater pages are located under /admin/ pages. I got similar problems when creating the shop with saved orders as pages under /admin/. I had to do include=all to get it working for other users.

I can't imagine you're not able to reproduce this. I got simple repeater and the following code won't show anything when I'm logged out.

foreach($page->items as $p) {
    echo "<p>$p->item_title</p>";
}

[ryan]

You guys are right about that. Looks like I removed a check_access=0 from the selector to make sure it was working and neglected to add it back. Sorry about that. It is fixed in the latest commit.

[Soma]

Just pulled it down, copied over, refreshed page... it's working now! Thanks Ryan

[Christoph]

Ah, cool, now it's working like a charm!

According to my error: Not sure what it was, solved it the quick way by deleting the page and changing the parent for the repeater fields ;-)

[diogo]

Mayday!! Some floats need to be cleared here!

hm... how do I attach an image here??
oh, apparently I'm also not allowed to embed and image without extension... Pete, help!
...i will just link to it: https://lh4.googleus...JdizWZlDsybcyIw Updated link: https://docs.google....tTWZ3SUN6TmNBQQ

EDIT: Now I see the attach files option on the reply full editor... I swear it wasn't there when I wanted to attach the above image!

[formmailer]

...i will just link to it: https://lh4.googleus...JdizWZlDsybcyIw

This link results in a 403 error. Maybe that's why the image couldn't be embedded?