system/src/sc/lang/html/Element.java
public boolean needsObject() {
      if (tagObject != null)
         return true;

      Template template = getEnclosingTemplate();
      if (template == null || tagName == null)
         return false;

      AbstractMethodDefinition methDef = getEnclosingMethod();
      if (methDef != null)
         return false;

      // When we are generating the server, if this says only put this tag on the client, we just omit the object.
      // If we are doing the client though, we need the object to tell us this is a server tag (so we include it properly when we render the parent)
      if (execOmitObject())
         return false;

      // Annotation layers do not generate types - they can be used in extends though
      Layer templLayer = template.getLayer();
      if (templLayer != null && templLayer.annotationLayer)
         return false;

      boolean needsObject = needsObjectDef();

      // When not part of a top-level tag, we currently can't define the object structure.  We'll have to treat this case as elements having no state - just do normal string processing on the templates and print an error
      // if any features are used that are not compatible with that behavior.  To support normal tag objects here, we could use inner types which are created, output and then destroyed
      // TODO: Do we need to do anything to tags nested inside of TemplateStatements?  I.e. those that would be theoretically created/destroyed in the outputBody method.  We could do it perhaps
      // with inner types and an inline-destroy method?
      if (!getContextSupportsObjects()) {
         if (!allowBehaviorTagsInContent) {
            if (needsObject) {
               displayTypeError("Tag object is inside of a statement or expression - this case is not yet supported: ");
            }
         }
         return false;
      }

      boolean res = needsObject || getSpecifiedExtendsTypeDeclaration() != null;
      /*
       TODO: should <p/> render as <p> or with the self-close.  Right now, needsBody=true by default which means we ignore the self-close if it's there when rendering
       for tags like iframe, the browser ignores that self-close anyway because it's "illegal" that just confuses things when debugging.  Maybe we should flag it as an error if you add
       a self-close and 'needsBody' is true - then accurately set this flag based on the tagName.
      if (!res && selfClose != null && selfClose)
         needsBody = false;
      */
      return res;
   }
/** Returns true if this tag needs an object definition */
Returns true if this tag needs an object definition
Returns true if this tag needs an object definition
public boolean needsObject() {
      if (tagObject != null)
         return true;
      Template template = getEnclosingTemplate();
      if (template == null || tagName == null)
         return false;
      AbstractMethodDefinition methDef = getEnclosingMethod();
      if (methDef != null)
         return false;
      if (execOmitObject())
         return false;
      Layer templLayer = template.getLayer();
      if (templLayer != null && templLayer.annotationLayer)
         return false;
      boolean needsObject = needsObjectDef();
      if (!getContextSupportsObjects()) {
         if (!allowBehaviorTagsInContent) {
            if (needsObject) {
               displayTypeError("Tag object is inside of a statement or expression - this case is not yet supported: ");
            }
         }
         return false;
      }
      boolean res = needsObject || getSpecifiedExtendsTypeDeclaration() != null;
      /*
       TODO: should <p/> render as <p> or with the self-close.  Right now, needsBody=true by default which means we ignore the self-close if it's there when rendering
       for tags like iframe, the browser ignores that self-close anyway because it's "illegal" that just confuses things when debugging.  Maybe we should flag it as an error if you add
       a self-close and 'needsBody' is true - then accurately set this flag based on the tagName.
      if (!res && selfClose != null && selfClose)
         needsBody = false;
      */
      return res;
   }
public boolean needsObject ( ) { if ( tagObject != null ) return true ; Template template = getEnclosingTemplate ( ) ; if ( template == null || tagName == null ) return false ; AbstractMethodDefinition methDef = getEnclosingMethod ( ) ; if ( methDef != null ) return false ; if ( execOmitObject ( ) ) return false ; Layer templLayer = template . getLayer ( ) ; if ( templLayer != null && templLayer . annotationLayer ) return false ; boolean needsObject = needsObjectDef ( ) ; if ( ! getContextSupportsObjects ( ) ) { if ( ! allowBehaviorTagsInContent ) { if ( needsObject ) { displayTypeError ( "Tag object is inside of a statement or expression - this case is not yet supported: " ) ; } } return false ; } boolean res = needsObject || getSpecifiedExtendsTypeDeclaration ( ) != null ; /*
       TODO: should <p/> render as <p> or with the self-close.  Right now, needsBody=true by default which means we ignore the self-close if it's there when rendering
       for tags like iframe, the browser ignores that self-close anyway because it's "illegal" that just confuses things when debugging.  Maybe we should flag it as an error if you add
       a self-close and 'needsBody' is true - then accurately set this flag based on the tagName.
      if (!res && selfClose != null && selfClose)
         needsBody = false;
      */ return res ; }
Returns true if this tag needs an object definition
Returns true if this tag needs an object definition
// When we are generating the server, if this says only put this tag on the client, we just omit the object. // If we are doing the client though, we need the object to tell us this is a server tag (so we include it properly when we render the parent) // Annotation layers do not generate types - they can be used in extends though // When not part of a top-level tag, we currently can't define the object structure.  We'll have to treat this case as elements having no state - just do normal string processing on the templates and print an error // if any features are used that are not compatible with that behavior.  To support normal tag objects here, we could use inner types which are created, output and then destroyed // TODO: Do we need to do anything to tags nested inside of TemplateStatements?  I.e. those that would be theoretically created/destroyed in the outputBody method.  We could do it perhaps // with inner types and an inline-destroy method?