I Need Input on a Possible Component for Contacts

I’m of the opposite ilk as BobRay it seems; I typically discourage the representation of this kind of data as individual Resources, especially if the volume of data is large or is going to grow continuously. IMO, MODx Resources represent distinct views of data, and unless every data object needs a completely different layout, I do not see the benefit in having a Resource to manage in the tree for each one. I would recommend learning how to use xPDO to quickly create data tables that you can present the rows from in a single Resource. Doing otherwise is just sacrificing site efficiency and performance, as well as data reusability, for an easier initial setup.

Start with this blog post by Shaun McCormick on Using Custom Database Tables in a MODx 3rd-Party Component.

Thanks for the link to the guide, OpenGeek. I’ve actually already read some of it, and when I have time in the next few days I’ll read it more in depth.

See, I’m more in agreement with you on not use a resource for every small piece of data. I would definitely prefer having my own database table for this with a snippet to quickly get them. However, for me this is one thing, and for a client this is another. I don’t have a problem just writing a one time snippet to add the contacts to the database and some code to edit them quickly when needed, but for a client, I need a nice interface that is part of the manager. That’s why I originally proposed writing a 3rd-Party Component, and I, in fact, had that guide in mind. I think it’d be a good way for me to get acquainted with xPDO and everything.

I’ll what happens. For now I might just use documents since I only have a piece pieces of data, but I think I might start working on a component to do this, if nothing else for the experience.

Indeed, my immediate thought was to use a custom table and a module to deal with it. But then I suppose I’m prejudiced in that direction... http://www.sottwell.com/create-module.html (for Evolution); I suppose I should spend some time learning xPDO and update that tutorial

It’s good to know I’m not the only one who thinks this way. It’s great that some people disagree because disagreement gets things done!

I feel inspired to go and write this now. I’ll update you guys as I work on it.

I can understand having a catalog using documents, because usually in a catalog you’ll have a link to the individual product with more information and even pictures. So in that respect it’s not much different than a blog or news listing. Unless you wanted a Google map for each contact to show their location

But if you’re just going to have data, with no need to more closely examine each item, then as you have said, using the document arrangement is not really appropriate. And they aren’t users, either, so that would be very awkward keeping users separate from contacts (unless there were some way of displaying users by groups - I’ve been considering the idea for adding a modification to the user management page for such an optional view for some time now).

I don’t disagree, but it sounded like the OP didn’t have a lot of contacts to deal with so a handful of documents seemed like a quick and easy solution compared to creating a custom table and custom snippets to deal with it.

That’s how I feel, mainly. I don’t think of contacts as users (although sometimes they overlap), so I really don’t want to go down that route.

To be honest, for internal use only, I would never keep contact information on the web server (unless the server itself is under my control, and even then I probably wouldn’t). A web server by nature simply cannot be considered a secure storage environment. I keep all of my client data on a USB stick. Unless, of course, I use it on an infected computer, it’s kind of hard for a hacker to get into it and collect any sensitive information!

Maybe I need to clarify what I’m trying to do. For one thing, this isn’t really contact information. It’s an email address with a name and position, all publicly viewable, except for the email address for avoiding spam bots. None of it is secure info. And it has to be on the server because my contact form needs to access it so it can show a pull down box with options for who a website visitor might contact.

Ah. I had gotten the idea that you were wanting to store the data from everyone who used your contact form!