Jump to content

Organization; templates and fields, by category, etc.


Grays
 Share

Recommended Posts

I'm mulling over organization of fields and templates - would love some advice, suggestions, or advantages/disadvantages of, please.

Using a blog as an example, let's say 95% of the pages would usually have the fields: title, body, images

However, perhaps the remaining 5% of the pages might need several additional fields. Would it generally be better to just use one template that has all the fields even though half of them won't get used most of the time? Or two templates, one of them having all the fields and another only the basic title/body/images fields? Is one or the other more complicated to make happen in the template files coding (I'm guessing I'd be using the if() statement...)

OR is this a case where I'd be better off putting those 5% of posts under another section/parent? (My hesitation here would be the URL structure and also the fact that on the frontend, the posts shouldn't be treated as separate sections.)

Along (maybe) similar lines, is it possible to display certain fields based on the category chosen (either at posting, or outputting via the template file)?

And one more question, please, regarding images. If a blog post may sometimes have a picture in the textarea but other times also have a group of images at the bottom of the post, mini-gallery style... what would be the best way to organize the fields? Two separate image fields, one for inserting into the body text and another for simply displaying like a gallery? Or can they use one and the same image field?

Thanks in advance for your help, and sorry for the multiple this or that questions... I'm still trying to wrap my brain around the organization and if there are any pros/cons to the various ways.

Link to comment
Share on other sites

Can you be more specific about what kind of website/project you are currently about to build?
Processwire is too flexible, that you can simply decide for one way over another, since you can accomplish a project in a wide variety of approaches,

Regarding your thinking about those 5% of different types of "posts" or the concern of how to display certain categories, you may have it easier, when differencing between how your "database of infos is structured" and the way you actually display the wanted data via templates.
 

Link to comment
Share on other sites

Hi Grays, 

I personally would stick with one template and use an if statement to check if it has a value or not. No need for two templates which could later cause confusion. I would create two separate fields for the images. 1 for the body text and image, then 1 for the image gallery.

The body field is likely to spit out <p> tags and your <img> within it. (although you can have it spit out whatever you like)

The image gallery field, you could spit out a list of images and it would allow you to do all sorts of things with them using jquery or css.

 Just my opinion though.

Link to comment
Share on other sites

Can you be more specific about what kind of website/project you are currently about to build?

Sorry, I didn't get into specifics because it was a semi-general question that came up as I was talking to a friend about PW, testing things out, and imagining the various ways I could convert existing sites (I've only just discovered PW and it's probably too early for me to be able to truly convert anything right now since a couple of sites I initially wanted to convert is likely way too complicated at this point).

So, I'm using his site as a jumping point.

If it helps, the site that inspired this series of question is a general TV series blog that the aforementioned friend used to run. Basically, he had three main sections - blog, reviews, and graphics.

- The blog: general posts, 95% of which would only require the usual title, body, images, etc.

- Reviews: reviews he writes on various series, this one would need other fields like number of episodes, summary, rating, etc. So, a different template if built on PW.

- Graphics: various graphics he shares, like wallpapers, avatars, memes, etc. Sometimes these are just single images and other times, there's a mini-gallery (hence the images fields question)

The questions I had was related to the main blog. As mentioned, 95% of the posts are just typical blog posts. However, once in a long while, he posts about a series he's watched a bit of or a new one he's previewing. These posts would have additional fields like name of series, number of episodes out/watched, genre, summary, etc. These are fields that wouldn't ever be used on most of his posts... but only when he posts these "preview" posts, which isn't all that often.

He didn't have a separate section for it because they were more like an asides type of post that only crept up on a whim. And they weren't in-depth enough to be sorted under Reviews, so they're just under a category, hence all those questions I had.

I hope that gives you a better idea of where I'm coming from.

I personally would stick with one template and use an if statement to check if it has a value or not. No need for two templates which could later cause confusion. I would create two separate fields for the images. 1 for the body text and image, then 1 for the image gallery.

Thanks for the input, RJay - always good to hear another person's opinion. I initially thought that'd be the way to go too... but ended up questioning if it's inefficient somehow to have a bunch of fields that would hardly ever be used. And perhaps also a bit cluttered when posting (probably not that bad for a personal site, but maybe not so great for someone else or a client per se).

I may very well just do it like you said - just wondered if PW had a different way I could approach for handling such a scenario.

Link to comment
Share on other sites

I initially thought that'd be the way to go too... but ended up questioning if it's inefficient somehow to have a bunch of fields that would hardly ever be used. And perhaps also a bit cluttered when posting (probably not that bad for a personal site, but maybe not so great for someone else or a client per se).

The cool thing about the fields is that you can just collapse them in the back-end if they are not used that often. And when you need them, just un-collapse them. 

Link to comment
Share on other sites

If you have more than one template, you will force the editor to choose each time, while if you have only one, you can force the children of one age to use that template removing this step when creating a page.

The ideal for you is to use field sets or tabs. Play a bit with the fieldstypes FieldSetOpen and FieldSetTabOpen. The first allows you to group a set of fields and even collapse them under a common bar. The second moves those fields to a new tab.

  • Like 2
Link to comment
Share on other sites

-edit: i hate this forum, every time you take a second too long to come up with a reply someone else steps in and beats you to it  :) -

Look at it this way, you will have to create the fields for holding *any kind of data* anyway. I don't think there will be a lot of overhead in adding all the fields to one template.

From a UI perspective look at FieldsetTabOpen: You could just have your 'title, body, images' on the main content tab. Additional fields for Reviews and/or Graphics can be put on 1 or multiple other 'tab(s)' in the user interface. It's an easily overlooked feature but very useful: in 95% of page creations you won't visually be bothered by fields that are on other tabs. 

  • Like 3
Link to comment
Share on other sites

:P

Edit: Forgot to mention on my previous post. By using a fieldset you can still change layout based on if it was used or not. Just choose a field that wouldn't make sense to be empty, and check if it was filled or not:

if($series_name != "") {
    // series post layout
} else {
    // normal layout
}

Link to comment
Share on other sites

This was a bit of an eye opener. So in general, do you guys usually just have one template for your content pages, even across sections? Of course, I realize this would also depend on the site, but this is beginning to sound like: unless it's really pretty darn different, we can really just use the same template even if they're not quite the same (especially if they have similar fields, types of data, or share portions of them)?

(Also, good to know that putting all fields in one template shouldn't add much overhead, as that was a concern as well.)


And much thanks to you both, diogo & SiNNuT, for suggesting FieldSetTabOpen. That sounds perfect and would actually solve another problem I was having for an actual site I will eventually convert to PW once I'm more familiar with it. :D

Forgot to mention on my previous post. By using a fieldset you can still change layout based on if it was used or not. Just choose a field that wouldn't make sense to be empty, and check if it was filled or not:

Just to make sure I'm understanding this correctly: Basically, using the FieldSetTabOpen is just purely for backend UI and doesn't affect the layout on the template files? So we'd still check for it the same we would any other field without needing to do anything else, correct?

Link to comment
Share on other sites

This was a bit of an eye opener. So in general, do you guys usually just have one template for your content pages, even across sections

Hm, not exactly. I would only use the same template in the situation that you described: pages are siblings and share lots of common info. In some cases it just doesn't make sense to use the same template.

Just to make sure I'm understanding this correctly: Basically, using the FieldSetTabOpen is just purely for backend UI and doesn't affect the layout on the template files? So we'd still check for it the same we would any other field without needing to do anything else, correct?

Yes, this only affects the admin, in the template file you don't have a way to know that these fields are grouped (at least that I know of...), so you have to find a way of determining if the editor wants them to be active. I mentioned checking for one field, but you could use a checkbox inside the group, so the editor can activate it manually instead.

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