I think this is a great question.

IMO, it depends on how "structured", "important", and re-usable this data is. If these reference numbers and monetary amounts are going to be involved in calculations elsewhere on your site (or in some as-yet-to-be-built addon that aggregates prices, for example), then you probably want them in page attributes. But if they're really only for users to see and read (like they're part of the marketing message more than feeding into a price calculation database), then putting it into page content is going to be better (especially because it will come up in search more easily as you suggest).

Hope that helps. I'd love to hear more details about how you're using this and what your eventual decision is, if you don't mind sharing.

-Jordan

Tuning in to this one - I've wondered the same thing on just about every project I've done. I love the idea of being able to pre populate a page based on filling out some for fields, comes in handy on repetitive pages clients will be adding. Ive done it both ways, using page attributes and as a block, even a combo of both. I always wondered what the "best practice" way of doing it was though, would be nice to see what others do.

hursey, care to share your experiences? What were some pros and cons with doing it each of those two ways?

Kind of a tangent, but... it would be nice if page attributes would filter down from page defaults to new pages of that type. (Not gonna happen anytime soon though so not really a practical solution to think about).

I think you should look at having an associated record with a page that isn't necessarily a bunch of page attributes. You can also do an attribute category like how eCommerce has with Product attributes, or the way User Attributes are handled. The attributes all inherit from base classes(if done correctly) of select, text, textarea(tinymce) etc etc.

You still get the parsing of post array for saving w/ the built in attributes, but you don't clutter up your properties pane, or you can further restrict who can edit what outside of concrete5 permissions, but with that flexibility you might have to create different and probably better UI more specific to the problem you are trying to solve.

So once you have the 1:1 relation of page related record to collection then you can literally associate anything with anything :).

A good example would be tying a concrete5 page to a MLS ID listing, where a request for a page is tied to a MLS ID, and if you have say better pictures or something like that for the listing(be it inside your brokerage or the listing client is on staff(or paying you or whatever)) then you can swap in that content instead of using those crappy downres'd and compression artifact riddled jpegs that the MLS serves up.

If you're interested in going down this route, be sure to check out this thread:
http://www.concrete5.org/index.php?cID=66258...

(and note the very last comment where someone has posted starter code to github -- this can be downloaded and used without you needing to install git or have a github account, by the way)

I think what you are talking about may be an approach that I would like to try, I'm having a little trouble wrapping my head around exactly what you are talking about. I'm basically at the point in my c5 journey where I can pull page attributes into custom page types, and also create basic blocks that can arrange some user inputted info.

In reference to Scott's suggestion, I guess what I'm missing is how exactly to go about creating an "associated record" to a specific page. It's obviously over my head, but if either of you can dumb it down a bit for me I think it could be very helpful.

As for my past experiences, my usual approach is to set up reoccurring pages like (locations, employee profiles, etc) using a custom page type that has some custom page attributes tied to it, and I create a custom block that is added to the page automatically using page defaults. That way, when a new location page for example is created all I have to do is fill out the attributes and block and everything is formatted nicely.

The problem with this approach is more for the end user. When they need to edit a page, half the stuff is in page attributes in the page properties and half the stuff is in a block, its kind of confusing. Typically, I only use page attributes for things that other functionality rely on. For example, I'd add like zip code, state, address, etc as page attributes because I use that information in a custom location finder. Stuff thats not tied to anything else (phone numbers, hours, etc) I just throw in the block.

Anything in the future I'd like to try a new approach such as what you guys are discussing, or I've been waiting to try jgarcia's new data display/advanced form packages, because it does accomplish alot of what I'm looking for (for those repetitive type pages), you guys have any experience with it?

Hi Brian,
I can try to explain this more -- I understand it at a high level but not all the details (maybe Scott can chime in with some of those)...

Have you used the ecommerce addon? If so, you'll notice that when you add a new product, you're given the choice of associating it with a page, but you don't have to. What's going on behind the scene is that there's a record in the database somewhere with all of the data for the product (actually it's several records because it uses C5's attribute system which splits things up into different tables, but that's not really important to understand right now). Then if you choose to create a page for it, there's another record in the database for the page and it will be associated with the data for the product. In effect, there is one bundle if data for the page (containing the content as well as some custom attributes) and then another bundle of data just for the product (which contains custom attributes only -- no content or page data).

In other words, the "associated record" is a bunch of custom attributes off on their own, not tied to a specific page.

How is this useful? Well, it allows you (as a developer) to save it and provide an editing interface in the dashboard for it and query it in any way you like -- outside of C5's built-in page search, sitemap, etc.
So it requires a lot more development effort, because all that's provided by C5 is the data structures to save stuff to, but it gives you more flexibility to work with it in any way you want.

In your specific situation, for example, you could create some kind of dashboard page that allowed for easy entry of the data, then write code that creates the page based on the data that the user entered and output data in any way you like (using php echo statements, for example -- not via editable blocks on the page itself -- the user would have to go back to the dashboard page you created to edit the data, and you of course as the developer would have to write code that provided an interface for the user to do such editing).

So depending on the exact situation, it very well might not be worth all of this trouble. But if you're building something very complex that doesn't fit into the "page with content and some extra attributes" idea, it can be quite useful.

Hope that helps clear things up a little.

-Jordan

Interesting discussion. I'm erring towards page attributes, I think, because they feel less 'impermanent' than blocks, and since most of them will be small pieces of information (like reference number, price, contact email) it seems somehow inelegant to use blocks. I'll still use blocks for the more descriptive content though (e.g. full description, photograph).

But keep in mind, easing yourself into the eventual understanding of C5 "attribute types" and how they can be an assembly of existing core attribute types - is powerful stuff. In other words, you can assemble two text attributes, a checkbox and a ....(whatever) into one attribute type that you call "myownAt". That attribute(s) - which is now a group of attributes, hence the (s) - can be attached to any attribute category. These attribute types can only be created through coding (not the dashboard). But C5 has provided good tutorials on how to do it in the Attributes section of the Developers Guide.

Out of the box, C5 comes with three categories (File, User and Collections - or what is referred to as a Page Attribute). Building a new "category" on which to bind "attribute types" is a great way to keep your data distinct from existing core categories and facilitate what Jordan describes as "meta-data" for that particular category of attributes - for the purpose of controlling how your data is displayed in various pages based on your (view) code's expectation and use of that meta data.

A perfect example is the User category. Take a look at the UserAttributeKeys table; the values in that table are attached to each "attribute" that gets added to this attribute category (because Andrew thought of it; "nice goin' man"). And you can say yes/no to each of those values within the Dashboard page when creating your attribute. That process is essentially what Jordan is describing in his second-to-last paragraph. Except, C5 makes it even easier because "some kind of attribute page that allows for easy entry of the data" is actually already done for you - you just need to "make it your own." I know that's a bit vague and it requires more study than what I can articulate here, but I wanted to point out that the system is there to do it and the documentation is there that describes how to do it. It just takes a bit to really figure it out. Not because it's poorly conceived. C5 is far from poorly conceived. You just need time to wrap your brain around it (by reading the actual code). So I would suggest to keep investigating it while continuing to do what you know to do - then one day it will click.

There's already lots of replies in this thread but in case it helps here's an answer I wrote to a very similar question the other week: http://www.concrete5.org/community/forums/customizing_c5/getting-st...