Best approach: Repeatable fields Vs separate PW pages

[Peter Knight]

I have a feed of "studio updates" on a site. They're essentially 1 liners of plain text. Using the ProField called Table, I've setup a simple repeatable table of fields consisting of a date and an update.

The mechanism above works perfectly and I know I'll get a lot of mileage from it. I don't need the complexity of a blog for this or comments, categories and tags. Or at least I don't need that stuff right now.

BUT...

I wonder if I should at least consider something a bit more scalabale.  I have a niggling sense that I should look at each entry as a seperate PW page and consider the fact that I *may* need some entries to include RTE fields, link to pages and even feature a photo.

I don't need that functionality *right now* but right now is actually the best time to build it in?

I suppose I already know the answer is to think ahead and think scalable but I liked the simplicity of having a single page with my repeatable fields within this.

What would you do?

[Joss]

I would make it scalable from the outset.

I have had exactly the same issue, though I have approached it for different reasons - SEO.

In this case, each product can have a different material or different base. It suddenly struck me that people might want to look through the cataglogue from a differetn angle - look at the materials, see what the differences are and then list the products that are made with that material.

That meant those materials needed to be pages.

Page table might be the way to go. There is a module called page table extended that improves layout, by the way, but it has problems with the current dev - the lovely chappy is working on it, though

[Peter Knight]

Cheers Joss. You're right re. scalability. I was getting hung on "the simplicity" of the first approach (which uses PageTable).

What I should be doing is making a simple template called "studio-update" with just my body field as date can be handled by the page creation date. Later on, I can add and remove fields if requirements grow. Or I could even have a Blog for this where posts for Updates are simply tagged "update". They could then be hidden from the main blog secton but displayed on their own "updates" page.

Too much choice. That's my problem

[Joss]

Too much choice. That's my problem

Aw shame, you could always go and use Drumlapress......

[SiNNuT]

I always tend to collect these types of items as pages under one parent page. Ideally even using one template, when needed multiple. This can be news items, press releases, blog posts, status updates, you name it. It's basically just a container for a stream of 'timestamped' items in varying categories.

More often than not they can share the same fields: a body text, some images and/or files etc, whatever you wish. I categorize them by using a page field. In the long run this kind of setup, to me, is the most flexible and scalable.

[Peter Knight]

 I categorize them by using a page field. 

So you have a select field which selects an item Category. And each Category is a page?

[SiNNuT]

Basically, yeah.

As an example, (part of) a fictional site tree:

items
-item(newsitem)
-item(pressrelease)
-item(statusupdate)
-item(newsitem)
-item(newsitem)
-item(pressrelease)
tools
-item_categories
--newsitem
--statusupdate
--pressrelease

My item template would have a page field referencing 'item_categories' as the parent for my item categories. This way, when you make a new item you choose the category which it belongs to. Very flexible, and using selectors you can then use your items to display however and wherever you want in your site. Make an RSS feed of your press releases? easy. And, because it's all pages, infinitely scalable. For easy back-end management you could set up a couple listers, if you want to.

EDIT: the tools section would usually be a hidden section, a building block section if you will.

[Peter Knight]

@Sinnut - Your last suggestion worked out very well.

I'm still using the Blog to create most news items of various types. I have a new field called "Post Type" from which I can categorise a post as a "Studio Update".

The only issue I had was that my Studio Update tags were appearing in my general Blog tags. I just created a seperate tagging system  for Studio Updates.

Thanks for the advice.