<blockquote>
  <p>I just started using Craft, so I still don't understand 100% the core, that's why I cannot decide which would be the best approach.</p>
</blockquote>

<p>Welcome to the community! You're asking a lot here! </p>

<p>Someone more knowledgeable about plugin-development will want to chime in here but in my experience, Craft is quite flexible and can handle a lot of things out of the box, even without writing a plugin. It's awesome when you have to relate content to and from each other, like you're wanting to do here.</p>

<p>I don't quite know all the requirements but if I were spec'ing this job, it sounds like you could do a lot of this by using most of Craft's entry types.</p>

<ul>
<li><strong>Jobs</strong> (section)</li>
<li><strong>Companies</strong> (section)</li>
<li><strong>Skills</strong> (Category / Source )</li>
<li><strong>Industry</strong> (Category / Source)</li>
<li>...</li>
</ul>

<p>I would deal with ATS import as a separate plugin.</p>

<p>You'd create entries in the Jobs section. Create fields that relate the job back to an entry in the company section as well as categorize it using those categories. Like entries, categories can have custom fields so you can put assets field on a skills category and upload logos so every job that has, say, jQuery in it, could have that logo appear. </p>

<p>Depending on your requirements, your Jobs section could have multiple entry types. So if you have specific fields that need to appear on certain jobs categories and what not, you can do that. </p>

<p>I see Matrix being an MVP here, too. When a regular set of fields doesn't cover what you need (you mentioned "custom settings that apply to each job"), you can mix and match a ton of different combinations with Matrix. </p>

<p>Bottom line: I would play more with Craft before you get into plugin development. If you're new to Craft, how many sites have you built with it before you started plugin development? Is there something that led you to know you actually need to use a plugin or is it just a programmer scratching an itch? (We've all been there!)</p>

<p>When it comes to programming and web design in general, to paraphrase <em>The Matrix</em>, "there is a difference between knowing when to reinvent the wheel and not." That only comes with experience.</p>

CC BY-SA 3.0
2015-09-15T20:39:27.173Z
It seems like I will have to try first to handle all my requirements by native types, and extend it using some custom plugins if needed. Thank you very much for clarifying this.
balazscsaba2006
CC BY-SA 3.0
2015-09-15T23:00:36.803Z
Sure thing. I forgot to mention, the [Happy Lager demo site](https://demo.buildwithcraft.com) is a good way to examine all Craft's features in practice... things like Matrix, relating content, sections, assets, etc. You'll start to *get* it after awhile, the light bulb will go off, especially if you're used to another system...
RitterKnight
CC BY-SA 3.0
2015-09-14T16:47:45.060Z
2015-09-14T16:53:32.867Z
2015-09-14T16:53:32.867Z
RitterKnight
<p>I have to integrate a jobs feed into our website and I've been digging in the documentation, reading the core's code for a while now, and I am in a dilemma trying to figure out if in out use case I should write a plugin or just try to build everything on top Craft's core types?</p>

<p>It's important to know that each job will belong to a company, and will have a lot of custom settings that apply to each job. I've started developing a plugin for it, based on the Brandon's events plugin, which until now is working fine, however I's still not convinces if I'm doing things rights, since the Elements API is a little under-documented.</p>

<p>The questions that I have now are:</p>

<ol>
<li>Should I base the Company on the Sections type, if I want the jobs to be translatable?</li>
<li>Should I base the Job on the Entry type, and write custom field types for every custom setting a job has to be translatable? (eg. Benefits and Requirements blocks, Many-to-Many relationships between job's industry, employment type, etc.)</li>
<li>Should I handle the saving of Many-to-Many relationships on my own, or Craft handles these if I choose the right core type?</li>
<li>Should I save all these custom fields a job has in the content table or in a custom table?</li>
<li>I will also import jobs from out ATS system, would it be enough to write a plugin just for this, and integrate all the aforementioned requirements into Craft's code types, without developing a plugin?</li>
<li>I would like to tag every job with the technologies a job requires, and assign custom logos of these technology tags. How would I handle this using a custom plugin, extending the core tags?</li>
<li>The jobs will have an advanced search and filtering based on the Many-to-Many relationships with industries, experience level, employment type; what would be the best approach to achieve this? using custom queries in a plugin with a custom element type or building on top of core types?</li>
</ol>

<p>I just started using Craft, so I still don't understand 100% the core, that's why I cannot decide which would be the best approach. </p>

<plugin-development><plugins><fieldtypes><elementtype><craft-features>
Use-case: custom plugin or extended use of entries/categories/tags
# Use-case: custom plugin or extended use of entries/categories/tags

(Asked by: username_0 on 2015-09-14)

I have to integrate a jobs feed into our website and I've been digging in the documentation, reading the core's code for a while now, and I am in a dilemma trying to figure out if in out use case I should write a plugin or just try to build everything on top Craft's core types?

It's important to know that each job will belong to a company, and will have a lot of custom settings that apply to each job. I've started developing a plugin for it, based on the Brandon's events plugin, which until now is working fine, however I's still not convinces if I'm doing things rights, since the Elements API is a little under-documented.

The questions that I have now are:

1. Should I base the Company on the Sections type, if I want the jobs to be translatable?
2. Should I base the Job on the Entry type, and write custom field types for every custom setting a job has to be translatable? (eg. Benefits and Requirements blocks, Many-to-Many relationships between job's industry, employment type, etc.)
3. Should I handle the saving of Many-to-Many relationships on my own, or Craft handles these if I choose the right core type?
4. Should I save all these custom fields a job has in the content table or in a custom table?
5. I will also import jobs from out ATS system, would it be enough to write a plugin just for this, and integrate all the aforementioned requirements into Craft's code types, without developing a plugin?
6. I would like to tag every job with the technologies a job requires, and assign custom logos of these technology tags. How would I handle this using a custom plugin, extending the core tags?
7. The jobs will have an advanced search and filtering based on the Many-to-Many relationships with industries, experience level, employment type; what would be the best approach to achieve this? using custom queries in a plugin with a custom element type or building on top of core types?

I just started using Craft, so I still don't understand 100% the core, that's why I cannot decide which would be the best approach.

**Tags:** plugin-development, plugins, fieldtypes, elementtype, craft-features

---

## 1 answers

### Answer by username_1 on 2015-09-14. Score: 0 | Accepted answer

> I just started using Craft, so I still don't understand 100% the core, that's why I cannot decide which would be the best approach.

Welcome to the community! You're asking a lot here!

Someone more knowledgeable about plugin-development will want to chime in here but in my experience, Craft is quite flexible and can handle a lot of things out of the box, even without writing a plugin. It's awesome when you have to relate content to and from each other, like you're wanting to do here.

I don't quite know all the requirements but if I were spec'ing this job, it sounds like you could do a lot of this by using most of Craft's entry types.

* **Jobs** (section)
* **Companies** (section)
* **Skills** (Category / Source )
* **Industry** (Category / Source)
* ...

I would deal with ATS import as a separate plugin.

You'd create entries in the Jobs section. Create fields that relate the job back to an entry in the company section as well as categorize it using those categories. Like entries, categories can have custom fields so you can put assets field on a skills category and upload logos so every job that has, say, jQuery in it, could have that logo appear.

Depending on your requirements, your Jobs section could have multiple entry types. So if you have specific fields that need to appear on certain jobs categories and what not, you can do that.

I see Matrix being an MVP here, too. When a regular set of fields doesn't cover what you need (you mentioned "custom settings that apply to each job"), you can mix and match a ton of different combinations with Matrix.

Bottom line: I would play more with Craft before you get into plugin development. If you're new to Craft, how many sites have you built with it before you started plugin development? Is there something that led you to know you actually need to use a plugin or is it just a programmer scratching an itch? (We've all been there!)

When it comes to programming and web design in general, to paraphrase *The Matrix*, "there is a difference between knowing when to reinvent the wheel and not." That only comes with experience.

> **Comments:**
> **username_0**: It seems like I will have to try first to handle all my requirements by native types, and extend it using some custom plugins if needed. Thank you very much for clarifying this.  
> **username_1**: Sure thing. I forgot to mention, the [Happy Lager demo site](https://demo.buildwithcraft.com) is a good way to examine all Craft's features in practice... things like Matrix, relating content, sections, assets, etc. You'll start to *get* it after awhile, the light bulb will go off, especially if you're used to another system...  

---

