Select custom CSS for Page

[Pascal]

Edit: Sorry for the Title which has nothing to do with what you are hopefully about to read. I was about to write on a different topic and got carried away.

Hi there!

I just watched the video for the new repeatable fields and this seems to be one of the last features that were missing. It is great! First I thought it would solve the problem I am about to describe, but then noticed that it wouldn't.

I am currently building a page for myself and want to have a modular layout. I don't want a classic layout with a body, a sidebar and a definite number of editable fields per template. What I want to achieve in the content of my page are floatig (inline-blocking, to be accurate) columns which can be added more dynamically. For example, I could have the following "blocks" to build my page's body:

A = A column which has a width of 20em

B = One with a width of 42.5 em

C = One with a width of 65 em

D = One with a width of 65 em and a dark background

So let's say I want three pages where content is supposed to be arranged like this:

A A A
A B__
C____

A A A
D____
B___A
A A A

B___A
A A A
A A A

The normal way would be creating four fields (A, B, C, D) and three templates where these fields are placed in the order described above. The problem is that if I wanted to create a fourth layout, I would have to create a fourth template. As you can see, there is a quite large number of possible combinations. What I want to achieve is the liberty to add new layouts and rearrange content independently of the code out of a set of blocks. Think of it like a letterpress where you can exchange individual characters and rearrange them as you like.

At the moment I am creating each block as a child of the page where it should be placed and assign css classes based on the template name (for example, echo <div class="$templatename">$page->body</div> for each child) Unfortunately, that means that the individual parts of a page appear as individual Processwire pages and clutter the site tree. While this approach is useable, it is not very elegant and abuses the pages for lower-level objects which are not meant to be accessed single pages.

Now this is a feature suggestion and I am feeling bad for it because I value all the hard work that has gone into this great CMS. This is what I was thinking about:

How about allowing users not only to add but to create sub-pages to a page while editing it. Much like the repeating fields which create pages in the background and add a page with the same template over and over again, one could chose from a previously set range of templates (like the template limitation for child pages: allow template-a, template-b and template-c to be added as fields to this template). So one could still render all sub-pages through the markup but would only have to add a new field and some CSS if he wanted to have a field E, which might be a 20em wide column with pink background and bright green text in Comic Sans.

I hope what I wrote made sense to you and would be very happy if someone suggested a workaround that already exists and that I completely missed until now.

[apeisa]

I think this is great example for what Soma was asking for in Repeatable fields topic: multiple "block" templates. It would allow this very easily. I am not sure if that is direction where repeater is going at the future.

But I guess there is at least one decent workaround:

a) Wait for repeater to be released

b) Create repeater, which has: 3 textareas (all collapsed if blank) and one Page reference. That would be dropdown called: Layout

c) Layout dropdown has different options: AAA, AB, BA, C, D

If you choose AAA, then it will use all 3 textareas for content. If you choose AB, then first textarea is for A column and second is for B. C and D uses only first textarea.

Just on idea and not sure how usable that would be in real life scenario. You gotta try

[diogo]

If you don't want to wait for the repeatable fields, here is a completely different idea. create 10 different fields (or whatever number you think will be the maximum you will use) and create a template with all of them. Put the letters A, B, C, or D on the first line of each texarea and the content from the 2nd line on. Now, with PHP, explode each field string on the first /n and assign the letter to the div class.

With repeatable fields you don't have to create 10 fields and clutter your edit page edit: or even using explode()

[apeisa]

Diogo: your idea is maybe little bit better than mine. If you add repeater to that, then your repeater would be just one textfield and one dropdown. Instead of combination (AAA, AB etc) you would choose A. B, C or D

Then you would create blocks, one by one:

A

A

A

A

B

C

B

A

D

And that would become:

AAA

AB_

C__

B_A

D__

[diogo]

Yep, that simple

[Soma]

AAA, BBB BUUUMMMM my head explodes. What? I don't get it.

[ryan]

I'm with Soma, explode('BAM' 'my head'); It's late here, I'm sampling Belgian beers while typing, and I'm tired, so I think that means I'm done for the day. Will revisit this thread tomorrow.

[SiNNuT]

I dun gettit

[slkwrm]

Child pages as building blocks for versatile layouts? Sounds cool! Can imagine how I could pimp some landing page using it. With repeater fields it must be very easy to do (and I think Ryan mentioned nesting capabilities!). The only thing that's missing to make workflow really handy is, as Pascal said, a possibility to create new pages (building blocks) instead of just being able to select them. I guess it's possible to implement this feature with a module, though I don't know how hard it would be, Definitely not too easy, as it would require good knowledge of PW internals and (am I right?) some ajax magic.

[ryan]

Unfortunately, that means that the individual partsof a page appear as individual Processwire pages and clutter the site tree. While this approach is useable, it is not very elegant and abuses the pages for lower-level objects which are not meant to be accessed single pages.

Some great ideas here. I just wanted to add that this really is how ProcessWire is supposed to be used, and it's not considered "abuse". It is perfectly fine (and encouraged) to use pages for lower level stuff.

[Adam Kiss]

I would totallly create XY templates [one for each block] and one 'layout' template, which is basically your layout holder/creator.

In the layout template I would hold just the structure (saved some way, maybe like csv or so), and in the other part of the site tree, I would hold all the blocks - this way it's easy to create block, update them, delete them, reuse them, etc.

[alan]

Having read this thread (thanks diogo for pointing it to me) I think my question here also addresses this issue, but differently — BUT I've not been clever enough to work out how to code it

[DaveP]

Anyone wanting to read some related stuff see http://bem.github.com/bem-method/pages/beginning/beginning.en.html

[alan]

Thanks DaveP, bookmarked.