<p>You're bumping into this error because of a minor misunderstanding of how Pixel &amp; Tonic are referencing their Element Types. The problem you have is with this line of code:</p>

<pre><code>$fieldLayout-&gt;type = ElementType::MyElementType;
</code></pre>

<p>When P&amp;T use that syntax, it's because they've already pre-defined all of their element types as enums. Open up the /app folder and take a look at this file to see what they've done:</p>

<blockquote>
  <p>/craft/app/enums/ElementType.php</p>
</blockquote>

<p>This allows them to use a syntax like <code>ElementType::Asset</code>.</p>

<p>You don't have that option (unless you create your own enum). What you would do instead, simply use a normal string to specify your element type:</p>

<pre><code>$fieldLayout-&gt;type = 'MyPlugin_MyElementType';
</code></pre>

<p>This is the same string that you wrote when you defined the Model for your Element Type. It should be one of the first lines of code within your Model:</p>

<pre><code>protected $elementType = 'MyPlugin_MyElementType';
</code></pre>

<p>Setting up enums is a different topic, but just go ahead and use the string and it should resolve that error for you!</p>

CC BY-SA 3.0
2014-06-20T19:31:55.143Z
I think that I myself still call these enums and have done so incorrectly in a few CraftX hangouts that we've had but the technical term for them is actually **Class Constants**. Enum refers to special enumarated types in other languages like **Java** and they don't actually exist in PHP. I make this correction because I've been quoted on this before and wanted to make sure that I don't share false information with you guys.

Keep on rocking bro, you're a master at this!
Selvin Ortiz
CC BY-SA 3.0
2014-06-20T19:51:10.580Z
Awesome, thanks for the clarification @SelvinOrtiz! Just wondering, is it then accurate for Craft to have an "enums" directory, or is that a bit of a misnomer? (Not trying to call out P&T, just curious.)
Lindsey D
CC BY-SA 3.0
2014-06-20T19:58:05.113Z
They are using them in the same way you would use enums, with a single purpose so unless you're a purist, their convention is totally acceptable IMHO.
Selvin Ortiz
CC BY-SA 3.0
2014-06-20T20:23:39.310Z
This is great, thanks for the answer, explanation, and discussion guys. Very helpful!
Peter Tell
CC BY-SA 3.0
2015-01-20T11:18:10.977Z
Well this answer just saved me a whole lot of heartache - thanks @LindseyD! Just goes to show, always search SE first...
Josh Angell
CC BY-SA 3.0
2014-06-20T19:00:07.120Z
2014-06-20T19:00:07.120Z
Lindsey D
<p>For example: Users. You can only have one fieldlayout per ElementType user which you customize in the settings section.</p>

<p>I've got as far as abstracting out the fieldlayout to it's own view, but when I go to set the field layout in the controller I'm borrowing the following code:</p>

<pre><code>// Set the field layout
$fieldLayout = craft()-&gt;fields-&gt;assembleLayoutFromPost(false);
$fieldLayout-&gt;type = ElementType::MyElementType;
</code></pre>

<p>To which I get the following (pretty much expected) error:</p>

<pre><code> Fatal error: Undefined class constant 'MyElementType' in /controllers/MyElementTypeController.php on line 115
</code></pre>

<p>I've looked at how the plugin example "Events" is handling this and Brandon seems to be setting the fieldlayout->type to Assets:</p>

<pre><code>$fieldLayout = craft()-&gt;fields-&gt;assembleLayoutFromPost();
$fieldLayout-&gt;type = ElementType::Asset;
$calendar-&gt;setFieldLayout($fieldLayout);
</code></pre>

<p>Is this how we're supposed to be setting these up? i.e., borrowing from other elementtypes?</p>

CC BY-SA 3.0
2014-06-20T17:19:55.910Z
Quick question... Are you trying to permanently associate those fields with your plugin, or can they be different for every website which uses your plugin? (If you're not publicly releasing your plugin, then it almost doesn't matter.)
Lindsey D
CC BY-SA 3.0
2014-06-20T17:20:48.123Z
For learning purposes, I'd like them to be dynamic per install. So, different for every website which uses the plugin.
Peter Tell
<plugin-development><elementtype>
How would I setup my plugin to use a unique fieldlayout that is unique to the top level of the plugin?
# How would I setup my plugin to use a unique fieldlayout that is unique to the top level of the plugin?

(Asked by: username_0 on 2014-06-20)

For example: Users. You can only have one fieldlayout per ElementType user which you customize in the settings section.
I've got as far as abstracting out the fieldlayout to it's own view, but when I go to set the field layout in the controller I'm borrowing the following code:
// Set the field layout
$fieldLayout = craft()->fields->assembleLayoutFromPost(false);
$fieldLayout->type = ElementType::MyElementType;

To which I get the following (pretty much expected) error:
 Fatal error: Undefined class constant 'MyElementType' in /controllers/MyElementTypeController.php on line 115

I've looked at how the plugin example "Events" is handling this and Brandon seems to be setting the fieldlayout->type to Assets:
$fieldLayout = craft()->fields->assembleLayoutFromPost();
$fieldLayout->type = ElementType::Asset;
$calendar->setFieldLayout($fieldLayout);

Is this how we're supposed to be setting these up? i.e., borrowing from other elementtypes?

**Tags:** plugin-development, elementtype

> **Comments:**
> **username_1**: Quick question... Are you trying to permanently associate those fields with your plugin, or can they be different for every website which uses your plugin? (If you're not publicly releasing your plugin, then it almost doesn't matter.)  
> **username_0**: For learning purposes, I'd like them to be dynamic per install. So, different for every website which uses the plugin.  

---

## 1 answers

### Answer by username_1 on 2014-06-20. Score: 4 | Accepted answer

You're bumping into this error because of a minor misunderstanding of how Pixel & Tonic are referencing their Element Types. The problem you have is with this line of code:
$fieldLayout->type = ElementType::MyElementType;

When P&T use that syntax, it's because they've already pre-defined all of their element types as enums. Open up the /app folder and take a look at this file to see what they've done:

/craft/app/enums/ElementType.php

This allows them to use a syntax like ElementType::Asset.
You don't have that option (unless you create your own enum). What you would do instead, simply use a normal string to specify your element type:
$fieldLayout->type = 'MyPlugin_MyElementType';

This is the same string that you wrote when you defined the Model for your Element Type. It should be one of the first lines of code within your Model:
protected $elementType = 'MyPlugin_MyElementType';

Setting up enums is a different topic, but just go ahead and use the string and it should resolve that error for you!

> **Comments:**
> **username_2**: I think that I myself still call these enums and have done so incorrectly in a few CraftX hangouts that we've had but the technical term for them is actually **Class Constants**. Enum refers to special enumarated types in other languages like **Java** and they don't actually exist in PHP. I make this correction because I've been quoted on this before and wanted to make sure that I don't share false information with you guys.  Keep on rocking bro, you're a master at this!  
> **username_1**: Awesome, thanks for the clarification @SelvinOrtiz! Just wondering, is it then accurate for Craft to have an "enums" directory, or is that a bit of a misnomer? (Not trying to call out P&T, just curious.)  
> **username_2**: They are using them in the same way you would use enums, with a single purpose so unless you're a purist, their convention is totally acceptable IMHO.  
> **username_0**: This is great, thanks for the answer, explanation, and discussion guys. Very helpful!  
> **username_3**: Well this answer just saved me a whole lot of heartache - thanks @LindseyD! Just goes to show, always search SE first...  

---

