Jump to content

ProcessWire ProFields: Table


ryan

Recommended Posts

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. 

Link to comment
Share on other sites

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. 

  • Like 2
Link to comment
Share on other sites

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

  • Like 11
Link to comment
Share on other sites

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.

  • Like 44
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 

  • Like 1
Link to comment
Share on other sites

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. 

  • Like 2
Link to comment
Share on other sites

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.

  • Like 3
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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?

  • Like 1
Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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 by Macrura
  • Like 1
Link to comment
Share on other sites

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...

  • Like 2
Link to comment
Share on other sites

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....

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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? 

  • Like 2
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...