ProcessWire ProFields: Table

[renobird]

I've been using PageTable a lot this last week. Grab the latest dev and give it a whirl, it's really cool. So far I have one repeater scenario that I can't replace with PageTable.

[ryan]

Is this a replacement for the repeater fieldtype? somehow I guess

Multiplier and Table can be used as more efficient (and perhaps preferable UI) repeater replacements in a lot of instances. If either Multiplier or Table will serve your needs as well as repeater, they will be able to scale a lot better than repeater. 

Is this a replacement for the repeater fieldtype? somehow I guess

File fields aren't supported by Table at present.  I agree with Antti that PageTable is your best bet to replace repeaters for your particular need. While PageTable won't be as fast/efficient as Table, it will still be a lot better than repeaters in that respect. PageTable is actually very simple and I think you'll find it easy to get going without needing to read anything about it. From the API side you are just dealing with a PageArray like any other. 

[Torsten Baldes]

thanks!

i'll take a look at the magic of PageTable.

Is there any use for Repeaters in the future, when we have Profields: Table and PageTable?

[ryan]

Is there any use for Repeaters in the future, when we have Profields: Table and PageTable?

Definitely still use for repeaters, but fewer for sure. I think it's all a good thing to have more options, as I expect repeaters will end up being used more for more appropriate situations rather than for everything. 

[cstevensjr]

Definitely still use for repeaters, but fewer for sure. I think it's all a good thing to have more options, as I expect repeaters will end up being used more for more appropriate situations rather than for everything. 

Ryan, when you have more time, can you please write something up (more in-depth) on suggested best uses for repeaters, tables, multipliers and all of the new tools?  It would also be interesting to know why you think some use cases are not good for these things.  Thanks

[ryan]

Table

Use this for tabular data, like rate tables or other things that you might typically represent in a spreadsheet. Use it for situations where you don't need the full-blown flexibility of repeaters, as it's technically more efficient with far less overhead than repeaters. Something like the Events Fieldtype could be very easily re-created via a Table field, but the potential uses are far broader. But for the most part, think tabular data when it comes to the Table field. 

Multipliers

This is good for when you need a range of values (whether text, textarea, numbers, dates, etc.). If you are using repeaters with just one field in them, you might be a lot better off with a Multiplier. Like the Table field, Multipliers are very efficient and low overhead relative to something like Repeaters. Use Multipliers when you need to repeat a single input multiple times, optionally with a min and max number of inputs. Lets say you are building an employee directory, and each employee has between 1 and 3 email addresses. Rather than using 3 separate email fields, you would use 1 multiplier field and specify min=1 and max=3. 

Repeaters

These are infinitely flexible in terms of what they represent, but each row of values is technically a page in the system. As a result, with the flexibility comes significant overhead. This is really only an issue when the quantity of repeater items gets high, or when you have lots (thousands) of pages using repeaters. I recommend repeaters for setting up things like homepage carousels. For example, if you go to the Villas of Distinction homepage, there are 3 separate repeaters in use on that page, each holding a photo, title, description, link. The client can have as many items in each of those sections as they want. Currently it looks like the first repeater as 6 items, the 2nd has 2, and the 3rd has 6. The possibilities of what can be represented with repeaters is endless, but look for potential alternatives when dealing with large quantities (whether large quantities of repeater items, or large quantities of pages using repeaters). 

PageTable

This is one of the ProFields that is available for free (thanks to Avoine sponsorship) on the ProcessWire dev branch. Meaning, it'll be available for everyone to use as part of the core in ProcessWire 2.5. And you can use it now if you don't mind running the dev branch. PageTable has all the flexibility of repeaters, but with lower overhead from the admin/input perspective. Rather than trying to bundle all the inputs on one screen, PageTable shows you a table of items and you click on the item to edit it in a modal window. This enables it to be a lot more efficient from the admin UI perspective. It's also more flexible than repeaters are in terms of where you store your items. PageTable lets you choose where they should live, whether as children of the page being edited, or as children of some other parent page you designate. They might be a little more work to setup than repeaters, but I think that most situations where you need the flexibility of repeaters may be better served by PageTable. PageTable still can't compete with the speed and efficiency of Table or Multiplier, but consider using PageTable anywhere that you might have used Repeaters before. Repeaters and PageTable are fundamentally different from the admin UI/input perspective, so you'd want to compare them yourself to see what suits your individual input needs better. PageTable involves more clicking to create and edit items, making Repeaters potentially faster for entering data rapidly. But PageTable will scale much further in the admin UI than Repeaters will, so I would personally favor PageTable in more situations than Repeaters.

[cstevensjr]

Thanks!

[peterfoeng]

Hi Ryan,

I am wondering if Page Fieldtype will be part of Table field in the future? Not sure if this is even possible though, lol

[GuruMeditation]

This looks interesting.

Would this be ideal for setting up a custom profile page? I'm thinking the Table fieldtype might be ideal for that purpose?

Let's say I want my user to be able to fill in all the following for their profile:

• Avatar
• Display name
• E-mail
• Gender
• Hobbies
• Dislikes
• Location
• About Me

I'm assuming ProFields will make this easy to accomplish?

Also, as I'm creating a basic forum, I'd like a create a page that can store forum permissions etc for each user group. Would ProFields fit my needs? It would need options to allow or disallow topic editing, profile viewing, content deletion, content posting etc etc. A bit like the AdminCP for this forum, only on a far smaller scale.

Thanks.

[peterfoeng]

Hi GuruMeditation,

Regarding the profile scenario above, I am pretty sure profields will make it easier and save you time. I recently move across my billing & shilpping information from invidual fields to profields textarea which I believe should have saved me time and will be easier to maintain over the long run. Cheers 

[ryan]

Would this be ideal for setting up a custom profile page? I'm thinking the Table fieldtype might be ideal for that purpose?

Probably not. The Table ProField is good for repeated tabular information. If your user profile needed to include a links, memberships, family members or something like that (each with multiple properties) then the Table field would be good. But the examples you listed all sound like they would still be best kept as separate fields to me. The only exception would be that I think you might potentially benefit from combining Hobbies, Dislikes, and About Me into a single Textareas field (similar to what @peterfoeng mentioned). 

Also, as I'm creating a basic forum, I'd like a create a page that can store forum permissions etc for each user group. Would ProFields fit my needs? It would need options to allow or disallow topic editing, profile viewing, content deletion, content posting etc etc. A bit like the AdminCP for this forum, only on a far smaller scale.

This doesn't sound consistent with ProFields, or ProcessWire for that matter. If you are setting up a forum, your best bet us to use a forum software. We use IP.Board here and really like it, but there are plenty of other great forum packages that are smaller in scope too (I've heard good things about Vanilla). Also, I wouldn't worry about having too much power when it comes to forum software. Even if your needs are only basic, having a powerful forum software doesn't necessarily make it harder to implement. It just makes it more likely that it'll do what you need it to, when you need it to. 

I am wondering if Page Fieldtype will be part of Table field in the future? Not sure if this is even possible though, lol

The Page fieldtype won't be part of it, as Table isn't actually using Fieldtypes. But some kind of Page reference field will likely be added to Table. 

[renobird]

Hi Ryan,

I don't how complicated this would be, but I have a feature request.

If a field using the Table Fieldtype is set to required, then have the first row of the field automatically visible.

I just watched some of our interns test calendar entry using a "dates" table field. They got tripped up on the field being required, but no rows immediately visible. Most of them missed entering the field the first pass.

[GuruMeditation]

Hi GuruMeditation,

Regarding the profile scenario above, I am pretty sure profields will make it easier and save you time. I recently move across my billing & shilpping information from invidual fields to profields textarea which I believe should have saved me time and will be easier to maintain over the long run. Cheers 

Thanks for the headsup.

This doesn't sound consistent with ProFields, or ProcessWire for that matter. If you are setting up a forum, your best bet us to use a forum software. We use IP.Board here and really like it, but there are plenty of other great forum packages that are smaller in scope too (I've heard good things about Vanilla). Also, I wouldn't worry about having too much power when it comes to forum software. Even if your needs are only basic, having a powerful forum software doesn't necessarily make it harder to implement. It just makes it more likely that it'll do what you need it to, when you need it to.

Hi Ryan. I actually do run an IP.Board website and have purchased IP.Content / downloads etc etc, but since using PW, it just feels fat. I've always found it a pain to get my site looking how I want. I know the new upcoming version looks set to address a lot of the issues, but I still much prefer to use PW as I can get my site to behave exactly how I want.

I'm just after a basic forum for my new site, one where members can post new threads, reply, view each others profiles etc. I was under the impression that this could be achieved with PW, although perhaps I'm missing something?

Thanks.

[Macrura]

regarding PageTable, is it possible to retroactively use pages that already exist in a PageTable, and if so how would you 'manually' associate them with the page they need to display on;

to clarify i have a template called "class" which is an art class; then i have another template called 'session' which is an actual instance of that class (with dates, time, instructor etc); It would be cool if i could show the class instances (sessions) on the Class page editor, using the PageTable; i have a page select on the session to select the class.. just not sure how to deal with this  since i'm guessing the page connection between an item in a PageTable is hidden?

[adrian]

Macrura,

If you look at the DB table for the PageTable field you'll see how the data column lists the page ids that are included as items in the PageTable. I think you should just have to add rows for each of the pages you want included for editing in the page table.

I was actually thinking this morning about this - currently it is possible for someone to add a new child page manually, but these won't appear in the PageTable field for editing. I wonder if there needs to be a way to prevent this as it could get confusing. 

Another issue for PageTable fields in my mind - if you use the default page as the parent for storing the entry child pages, but you also have regular child pages mixed in, it may become quite confusing for editors. I guess this comes down to the dev being careful about choosing a different parent in cases where there might be confusion. Did that make sense?

[Macrura]

thanks adrian, cool, i haven't poked around in the database yet.. i think i would need the ability for users to be able to add those PageTable entries from either the 'class' page, or from the page tree; so i think i'll need to write a module that adds the appropriate 'session' pages to the 'class' when a new session is added not from the place where the page table is... and i'll probably need to run some api code to add all of the sessions to those class pages...

[Macrura]

update, so here's a super simple module that is doing this now and seems to be working...

(where session_table is the PageTable)

(moved revamped code to github..see next post)

Edited June 2, 2014 by Macrura

[Macrura]

I've figured out a way to have this work in both scenarios, though still a bit hackish..

https://gist.github.com/outflux3/0a013ea20b46e706a6f9

say you have pages being managed by PageTable, and they all live somewhere other than children of the page managing the pageTable items, and you want to be able to have a visible page reference field on the PageTable items;  when editing the item from somewhere other than the PageTable, the module first checks to see if it is already in the PageTable array and if not, it adds it (using the page reference)..

when you add it from the page managing the items, i have the users leave out the page reference and then when saving the page, it sets all of the items that don't have the page reference, to the page where they are now associated with.. hope i'm making sense...

[DaveP]

I'm getting some weirdness using a PageTable field. After adding a row, the backend output is messed up.

[Macrura]

have you checked the console - maybe there is some error; last time something like this happened to me there was an issue with a conditional field which was causing an error and halting parts of the editor screen to load....

[DaveP]

Nothing in the console.

<silly question>Having never used this field before, what is the output supposed to look like?</silly question>

[ryan]

Just to clarify, all the recent messages in this thread have to do with the PageTable field, not the ProFields Table field. So the subject of this thread seems to have changed. They are completely different modules, and PageTable is part of the ProcessWire core (on the dev branch), not a commercial module. My responses below have to do with this core PageTable field since that's what all of the questions above are about. For people wondering about the ProFields Table field, please ignore this message.  

 

Another issue for PageTable fields in my mind - if you use the default page as the parent for storing the entry child pages, but you also have regular child pages mixed in, it may become quite confusing for editors. I guess this comes down to the dev being careful about choosing a different parent in cases where there might be confusion. Did that make sense?

 

That behavior is intentional. It means you can have multiple PageTable fields on the same page storing their items as children of the page. You might even be using a PageTable field specifically for the purpose of managing children. Though perhaps an option to have them to default to a hidden status might be useful here. In your template page list settings (under advanced) you might also want to specify some other property from your PageTable pages to show in the page list, so that you can easily differentiate them from other children (if any) in the Page List. For instance, you might tell it to display the template name in addition to the page title.

 

For situations where storing them as children is not what you want, then you'd want to specify your own parent. In fact, most of the time when I use PageTable, I specify my own parent where I want them to live, usually off in /tools/my-field-name/ or something like that.  

 

I was actually thinking this morning about this - currently it is possible for someone to add a new child page manually, but these won't appear in the PageTable field for editing. I wonder if there needs to be a way to prevent this as it could get confusing. 

We don't want to prevent that because that would mean the PageTable now owns the children of that page and you couldn't use them for anything else, nor could you have multiple different PageTable fields storing their items as children. If you are in a situation where confusion is resulting from letting PageTable store items as children of the page, then that would be a situation where you'd want to specify what parent they should go to instead. In fact, I think that using PageTable with children is really for specific uses, and using PageTable with a specified parent is the more common use case. 

I'm getting some weirdness using a PageTable field. After adding a row, the backend output is messed up.

Try clearing your cache and hitting reload a couple of times in the browser. It looks like something isn't loaded. I'm honestly surprised you aren't seeing a JS error because it definitely has the appearance of that. 

Beyond the above, try switching your color theme back to "Classic" (just in case I missed something in the last CSS update). You can do this from Modules > Core > Admin Theme. If it's still not working right, I would try updating your core again just in case some files didn't make it through when you last updated it. Please let me know what you find. 

[adrian]

In fact, I think that using PageTable with children is really for specific uses, and using PageTable with a specified parent is the more common use case.

After going through the process of testing out PageTable fields I came to this conclusion as well, but I don't think it is obvious the first time you set up a field, especially given that "Select a parent for items" is closed by default and even when you open it, it reads "This is optional. If no parent is selected, then items will be placed as children of the page being edited.". I guess I think it might help if this was initially open and the decription or note field stated that a specified parent is the more common usage because of the issues that can occur with mixing in PageTable children with regular children in a URL accessible part of the site structure. I can see lots of dropdown menus containing PageTable children before people figure it out.

But, maybe it's just me Anyone else initially confused? 

[DaveP]

Try clearing your cache and hitting reload a couple of times in the browser. It looks like something isn't loaded. I'm honestly surprised you aren't seeing a JS error because it definitely has the appearance of that. 

Beyond the above, try switching your color theme back to "Classic" (just in case I missed something in the last CSS update). You can do this from Modules > Core > Admin Theme. If it's still not working right, I would try updating your core again just in case some files didn't make it through when you last updated it. Please let me know what you find. 

Tried all the above, to no avail. However, I did notice in the DOM there are 2 instances of <ul class="WireTabs nav" id="PageEditTabs">, which contain different content. They aren't in the page source so I assume they get injected by js. I would be surprised if two with the same id was intentional / desirable.

[cstevensjr]

Is it possible to move the PageTable comments to a new Thread?