51 replies to this topic

[almonk]

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

[adamkiss]

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:


It really does resemble template creation

[apeisa]

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

[apeisa]

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


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:

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

[adamkiss]

There are some features to simplify content managment on the roadmap 

I'll write more in about an hour.

[ryan]

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.

[martinluff]

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?

[ryan]

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.

[adamkiss]

But I bet you can figure that out – after all, you built the awesome basics we love to build upon.

Hey, that's actually pretty catcy headline!

Awesome foundation you'll love to build upon

;D

[martinluff]

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

[martinluff]

...Hey, that's actually pretty catcy headline!
Awesome foundation you'll love to build upon

;D

You might be onto something there. Or perhaps you've just been looking at too many skyscraper demo sites  ;D

[ryan]

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. 

[almonk]

Ryan, I don't suppose open sourcing your custom field would help progress towards this feature?

[ryan]

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.

[adamkiss]

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.

[ryan]

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.

[adamkiss]

Edit: I replied to a different thread. Fucking confusing previous/next buttons. OT: Ryan, SMF is ugly and bad. Don't you want to try vanilla forums instead?

Ryan: It actually shows a need for deeper API documentation [hint hint]

[ryan]

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.

[adamkiss]

Ryan: send me an e-mail with modified SMF CSS file and I could do it If you will give me access to server [although i doubt that] or create me separate FTP account just for css folder of smf, I could also test it and put it live.

[ryan]

Adam, just sent you an email and attachment. I think sometimes my emails don't get through (maybe because of attachments), so just let me know if you don't get it.