51 replies to this topic

[aleksblendwerk]

+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 :).

[ryan]

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.

[adamkiss]

http://tinyurl.com/5tv2cje ;D

but, seriously:

[ragnarkarlsson]

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?

[adamkiss]

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

[ragnarkarlsson]

Yes I figured that the simplest thing to do would have a "Quotes" page with children that have the title, quote, person, date, etc will work.

It just struck me as being somewhat tidier to have all of that data encapsulated within a singular array on the "Quotes" page.

I'll keep an eye on developments in future as undoubtedly I'll have something more complex later!

[adamkiss]

Well, 'tidier' depends on point of view. I, for one, like to have main site structure here and various little 'bits' (quotes, team, ...) in one place (e.g. 'bits/team' and 'bits/news' and 'bits/quotes')

[ragnarkarlsson]

True, it is potentially subjective choice on which works better in my particular case.

Personally it makes no difference to myself which way I implement it, but my suspicion is that for my client's user experience it'd be simpler to keep adding quotes to that given page.

Guess the challenge for me is to help him understand 

[harry]

Hey all,

Great CMS Ryan, I've really grown to like it in the space of just a few hours!

Just thought I'd bump this thread because when starting to develop a page I was looking for a field type / module that could provide this functionality - for example  it would be perfect for creating bespoke list elements primarily for a client to add themselves rather than hard code <li>'s etc!

Was this development ever fully finished? I'd love to try it out or help test / debug to make it an integrated part of the CMS.

Harry

[apeisa]

Hi Harry and welcome to the forums. This feature is planned for 2.4.

Major feature for 2.2 is multilang support and 2.3 will have form builder. 2.1 just came out with user system update, big improvements for templates and instant ajax file uploads.

[apeisa]

it would be perfect for creating bespoke list elements primarily for a client to add themselves rather than hard code <li>'s etc!

For simple needs you could go with textarea and "Newlines to Unordered List" textformatter.

[harry]

Hey Apeisa,

Great stuff, I'll check back regularly to keep up with updates and future releases.

Really like the interface, it's easy to use from fresh and super intuitive.

I'll stick with the Textarea and also using several fields for now, but will eagerly await 2.4!

~ Harry

[Michael Murphy]

I also agree that a matrix style interface would be a very useful for content editors.
I think @martinluff mentioned earlier in the thread, that the image field is actually very close to what we need. It's a repeatable element with a textfield. Maybe just take out the image part and call it a repeatable textfield.

I am currently using a textarea to list opening times for museums. I want to show what museums are open today / tomorrow. I put each day of the week and opening times on a single row, separated by a semicolon ;
In my template, I turn that into an array and parse thought it (if today > show museum).

The textarea solution is fine for me to edit, but if I ask a normal user to do this, it won't be long before it breaks. That's where a simple repeatable element would be useful.

[ryan]

Repeatable fields are planned for 2.4, though we may get some rudimentary variations of it before that.

[egecan]

Repeatable fields are planned for 2.4, though we may get some rudimentary variations of it before that.

May I ask if you have a roadmap or an estimate? I really like Processwire and I would feel much more comfortable to use it on larger-scale projects if I knew the project have important milestones in a reasonable time-frame.

edit: do you also accept donations or have a commercial end that offers customization? that'd be great to know^^

[ryan]

May I ask if you have a roadmap or an estimate? I really like Processwire and I would feel much more comfortable to use it on larger-scale projects if I knew the project have important milestones in a reasonable time-frame.

Here is a link to the roadmap, though it's a bit of a work in progress as I've not yet added everything to it that should be added:
http://processwire.com/about/roadmap/

The direction of the roadmap is dictated by equal parts of:

• What features are consistent with the needs of the development team and the clients they work with.
• What features are most requested by the community.
• What features are others wanting to sponsor the development of.
• What features are most tangible to accomplish in the short term.

edit: do you also accept donations or have a commercial end that offers customization? that'd be great to know^^

We don't accept donations, but you can sponsor development of ProcessWire features. For instance, if there is something that you need and you want to see it happen sooner rather than later, then we can give you an estimate and timeline to build it. For instance, the company that @apeisa works for is sponsoring the development of the multi language support in the admin planned for 2.2 (currently in progress). My company (RCD) specializes in the design and development of ProcessWire sites, as well as the development of custom modules in ProcessWire, so please feel free to email me if you'd like to talk more, my email is ryan at this domain name.

[diogo]

For answering to this http://processwire.c...opic,621.0.html, i revisited this thread and thought again about it. Maybe this can be done without breaking the way processwire naturaly behaves.
This field type could simply mirror inside the edit page one branch of the tree. It can be only an interface to create children of a page from inside the editing of another page (or even the same, whatever...)

• So, while creating the field, we would only have to define a preexisting page to be the parent of our repeatable elements.
  
• On the edit page, this field type could work much like the image field already works.
  
• When adding a new repeatable element, a new page would be automatically created under the parent that we defined while creating the field.
  
• The fields for each element would be the same from the template that was chosen for the children of our parent page (or could be even different for each element of the group if the editor as permission to choose the template).
  
• Templating would target the tree normaly and ignore this field..
  
• The editor would have the feeling of creating repeatable elements inside a page, but everything would still work on a processwire way.

Would this be easy to implement has a module?

I'm getting quite sleepy but i hope i was clear enough

[ryan]

Good ideas Diogo! This really may be a feasible way to accomplish this type of field without major changes underneath, while also enabling any existing field to be repeatable without consideration from the fieldtype/inputfield. Or to word it differently, a simpler approach that is more powerful than the alternative. I am enthusiastic about this approach… it's something we should continue thinking and talking about.

[diogo]

Nice! I'm glad you liked the idea

It occurred to me that it might be less simple to do it as i imagined. If inside pages there are already children, The children created by the field would be mixed with them... quite confusing...
Instead, maybe it would be better to have a special page dedicated to this field type (like the admin page, or the trash page).

> Admin
> Repeatable field type
    > Edited page A
           > Repeated field of A 1
           > Repeated field of A 2
           > Repeated field of A 3
    > Edited page B
           > Repeated field of B 1
           > Repeated field of B 2
           > Repeated field of B 3
> Trash

[apeisa]

I also like this approach very much. Actually I had the same idea in January (last paragraph), but didn't give that thought too much thoughts back then. I think that in symphony cms there is good implementation if this method.

Other scenarios where this approach would shine is ie. tags. You could keep tags as their own pages, but could add new pages when adding new blog posts. Also - you could add architects while editing your skyscraper etc.