Jump to content

Module want: Repeatable elements


almonk
 Share

Recommended Posts

Hi there,

Loving the look of processwire so far, walks the line very nicely between a simple 'page based' cms and more powerful solutions - thanks for all your hardwork.

One thing I think would be an awesome addition is a module to enable repeatable elements, somewhat like the Matrix expression engine plugin (http://pixelandtonic.com/matrix).

I guess this would work as a field type similar to the Fieldsets but called Repeatable and effectively allow the editor of a page to add a new 'row' of repeatable elements defined in the template.

Bit of a braindump but I hope this makes sense!

Al

Link to comment
Share on other sites

Hi there almonk, welcome to forums! :)

Not sure I understand your needs though. What do you want to do with this repeatable? Because basic idea of PW is that everything is repeatable. You just define new 'template' type.

And then, in the one template that should show this 'repeatables', you API your pages of that repeatable template based on their location/other paramaters like this:

 echo $page->body; //echo something from the 'page with repeatables'

 $reps = $pages->find('template=repeatable, ...params');
 foreach($reps as $rep){
   //here you go, array of 'repeatables' to go through
 }

I know, sometimes it's hard to wrap your head around this seemingly endless possibilites, but in the end, you can gain a lot from having clear, custom defined structure. Everything is possible.

Edit: I mean, even if you look at this picture from Matrix plugin:

config.jpg

It really does resemble template creation :)

Link to comment
Share on other sites

As far as I remember Matrix is more like "repeatable set of fields". So you could have template like "Football game" (soccer, not American ;))

There you could have Matrix for different events:

[table]

[tr]

[td]Minutes played[/td]

[td]Event type[/td]

[td]Player[/td]

[td]Team[/td]

[td]Details[/td]

[/tr]

[tr]

[td]12 min[/td]

[td]Goal[/td]

[td]A. Peisa[/td]

[td]Chelsea[/td]

[td]Chelsea leads 1-0[/td]

[/tr]

[tr]

[td]35 min[/td]

[td]Goal[/td]

[td]J. Litmanen[/td]

[td]Ajax[/td]

[td]1-1[/td]

[/tr]

[tr]

[td]72 min[/td]

[td]Red Card[/td]

[td]A. Peisa[/td]

[td]Chelsea[/td]

[td]Peisa is out of the game[/td]

[/tr]

[tr]

[td]88 min[/td]

[td]Goal[/td]

[td]J. Litmanen[/td]

[td]Ajax[/td]

[td]Ajax leads 1-2[/td]

[/tr]

[/table]

And those fields (or cells) are not only text, but also images, files, links, relations, dates etc...

This is ideal for situations where these are relevant data mainly for this template, they have to be easily updated etc. It would be really slow to create 1-20 different pages for every event for each game. I'm not sure if this is best example, but hope it makes this idea clearer.

I actually think that it would be better (and maybe easier module and more in line with current way of building sites), if we could add/edit/remove other pages through editing other page. I mean if I have two templates: soccer_game & soccer_game_event. Soccer game template has page reference field for multiple game events. This reference field could have some pretty ajax magic that it would allow creating new soccer game events right on soccer game page. It would be so nice :)

Link to comment
Share on other sites

Edit: I mean, even if you look at this picture from Matrix plugin:

config.jpg

It really does resemble template creation :)

It is true that you can achieve all the same results with pages & templates, but I think most important thing here is to make it easier for editors to create and manage the data. You can see the difference here:

hero.png

(That little plus sign on the bottom is important -> You add more "rows" easily when editing the page)

But I also do not like that there is 2 very different ways to create same end result. So that is why I think that it would be better to allow creating & editing of other pages inside parent page.

Link to comment
Share on other sites

These are some cool features no doubt, something to think about. I can see how we could get these kind of results by building Fieldtype modules, like a Fieldtype module that contains one or more other fields (like it was mentioned a Fieldset). Developing this Fieldtype would be a rather big project in it's own right, but certainly within the bounds of what ProcessWire would support, so I think this is definitely a worthwhile addition to the roadmap.

Link to comment
Share on other sites

I'd certainly like a solution along these lines - agree about the usefulness of Matrix (and you can do similar thing in SilverStripe using the DOM module).

Seems like ProcessWire is already pretty close if you look at the images field type for example (see the way this works on the home page in the skyscraper demo - where you have the file and a description and can add new 'rows' for additional images). Seems like you could adapt that so you can add other fields to a field like that as well as to a template (in the way you just have description text field) and you'd be there? Of course I realise that's simple to say and more difficult to implement - but looking at how the fields are added in tables in the backend db then seems like the system would lend itself to that relatively easily?

Link to comment
Share on other sites

You are right the system would definitely support it pretty easily. The challenge would just be in making it configurable with any fields, and supporting a matrix display... most fieldtypes assume they aren't width limited. In addition, making the individual components of the fieldtype searchable/selectable with the API. But these things are already partially worked out.

Link to comment
Share on other sites

...The challenge would just be in making it configurable with any fields, and supporting a matrix display... most fieldtypes assume they aren't width limited. In addition, making the individual components of the fieldtype searchable/selectable with the API. But these things are already partially worked out.

Great! Yes, I was kind of thinking that it's one of those things that sounds simple but has a number of implications. I think the matrix display is less of an issue - even if the fields were full-width one above the other then you'd still get most of the benefits...

Link to comment
Share on other sites

Another option is to build a custom fieldtype for the data you need it to hold. With the project I'm working on now, they needed a multi-column pricing table with any number of rows. So the easiest solution was to just build a custom Fieldtype module for the client. But it sounds like this matrix-type configurable module might solve, or at-least reduce, the need for that type of custom module. 

Link to comment
Share on other sites

I would except that it's not mine to open source (it was paid work for a client). In addition, it was done in PW1, which is quite different. However, it would actually be easier to do in PW2. If it helps, the fieldtype was based on what was done in FieldtypeFile. But give me a little time, and we'll come up with something much better specific to this need.

Link to comment
Share on other sites

I'm actually starting to think, that it should be done via some 'partials' system...

The same way you define templates, you define 'partial-templates' [or 'repeatables'] and the only thing we would have to add as field would be something as 'repeatable-select', which would then point to one repeatable/partial template.

Link to comment
Share on other sites

That makes sense, and is worth looking at more. On the back end, fields are actually assigned to fieldgroups, and fieldgroups to templates (rather than just fields and templates like it appears on the front end). Technically, a given fieldgroup can be attached to multiple templates, though that option is not visible on the front end (to keep things as simple as possible). But fieldgroups would represent the partials that you are talking about, which are already in the system and API accessible.

Link to comment
Share on other sites

Vanilla forums is originally what I wanted to use... and I tried to hard to get it working. I installed locally and seemed to encounter a lot of odd bugs. It worked, but it was not stable. Then downloaded another fresh copy and tried to install to the server, and couldn't even complete the install. Rather than spend days trying to get it working, I gave up on it. Granted it's code looks a lot cleaner than SMF's, but SMF "just worked" right out of the box. I probably need to tweak the theme more, but I'm reasonably happy with SMF so far.

Link to comment
Share on other sites

+1 on the request for a FieldSet/EE 'Matrix' style field type.

Just working on a project with SilverStripe and while it is quite easy to define additional content types and associate them to my 'main content type' (and have them displayed in a 'tab' on the edit page of the main content type), I think the 'Matrix' style display and set-up is very user-friendly and really versatile! One of the best 'features' in EE (that is not even a 'core' feature as 'Matrix' is a commercial extension).

Basically just meaning to say this would be a great feature putting ProcessWire one step ahead of 'the competition' again :).

Link to comment
Share on other sites

Does anyone know if there is a screencast or something that demonstrates how this works in EE? I don't currently have access to an EE installation where I can play with it, but am interested in getting a better look at this functionality.

Link to comment
Share on other sites

  • 1 month later...

Hmm, I'm thinking this would be something I'd like as well.

Site I have upcoming will have a large number of quotes from customers, good feedback stuff, and it'd be nice to have that as something where a single page just keeps on adding to a single array.

Unless I'm missing the blindingly obvious here?

Link to comment
Share on other sites

@ragnarkarlsson: with stuff like quotes, you should have no trouble doing this with another template ('client_quote') and one place to keep your children with this template.

As I see it, repeatable elements is good for you when you have these big structures (like eshops with 200+ products) with 2-5 variations each – in that way, it can be handy. However, your quotes problem can be simply managed via one page holder+template+quote pages

If you want to group the quotes, you can do this via another tree level (so you have 'quotes'->'category'->quote itself tree) or one text field 'group'. Or even page field to link it to other page ('related')

All of this is of course true unless you have 20 projects each with two quotes... then it would be nice for you to have this, which is unfortunate. :D

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
 Share

  • Recently Browsing   0 members

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