¿Cuál es el beneficio de crear nuevos tipos de entidad en lugar de crear un nuevo tipo de contenido?
Parece un poco exagerado hacer toda la codificación personalizada que se requiere para crear una nueva entidad cuando tiene todas las funciones CRUD y Vistas ya integradas en los tipos de contenido.
Respuestas:
No se trata tanto de cuáles son los beneficios, sino más bien de lo que es apropiado para una situación particular como usted ha dicho. Puede representar prácticamente cualquier cosa con un nodo y para el 99% de las situaciones (como he encontrado al menos) no necesitará implementar tipos de entidad personalizados.
Siempre pienso en el taxonomy_termtipo de entidad como un buen ejemplo de por qué no todo debería ser un tipo de nodo / contenido:
Un término de taxonomía es esencialmente para agrupar diferentes entidades y, como tal, no requiere la misma funcionalidad que un nodo. Si bien, en teoría, podría usar un tipo de contenido para realizar esta funcionalidad (quizás con un campo de referencia de nodo), un término de taxonomía no necesita hacer lo mismo que un nodo, por lo que no tiene sentido hacerlo. Lo mismo puede decirse de las usery taxonomy_vocabularyentidad tipos.
Por lo tanto, un término de taxonomía se crea como una entidad separada y se programa para hacer solo lo que necesita, al mismo tiempo que obtiene los beneficios de poder tener campos adjuntos, etc.
Creo que la respuesta simple es que cuando un tipo de nodo / contenido no hace lo que necesita, o es solo una cantidad masiva de sobrecarga / sobrecarga para muy poco beneficio, entonces debe elegir escribir una entidad personalizada.
Esto solo se basa en mi experiencia personal; Me interesaría saber lo que alguien que está directamente relacionado con el desarrollo central de Drupal tiene que decir sobre esto.
Una regla general muy simple que uso es si su contenido debe mostrarse públicamente por sí solo. Si es así, vaya al nodo, si no, elija una entidad. Entityforms ahora le permite crear una interfaz para completar sus entidades.
Por ejemplo, en un sitio web creado con D6, creamos un tipo de contenido publicitario (con su campo de imagen, fecha de inicio / finalización de visualización ...), pero luego debe hacer que no se publique de forma predeterminada y otorgar a sus editores los derechos para editar / ver estos nodos y esperar que no haya vistas / búsqueda los mostrará en el mundo exterior. Es bastante engorroso y sería más fácil tratar con entidades.
Una entidad representa un caso de uso específico .
Creo que el crédito por esta simple definición es para Fago , pero soy demasiado flojo para encontrar una referencia.
Podríamos usar Content(aka Nodes) para todos los casos de uso si quisiéramos, pero a menudo eso no tiene sentido.
Content tiene un autor y configuraciones para comentarios y ubicación de menú.
Users, representa un caso de uso lo suficientemente diferente de Contentporque en userninguno de los anteriores tiene sentido, mientras que, por otro lado, userdebe tener un correo electrónico y una contraseña.
Taxonomy terms se destacan porque tienen la funcionalidad incorporada para organizarse en una jerarquía, incluso circular.
Si su caso de uso es lo suficientemente similar a una entidad existente, use esa entidad. Sin embargo, si su entidad se rige por reglas significativamente diferentes a las existentes, cree una nueva.
También hay una Introducción a las entidades , pero desafortunadamente en realidad no responde a su pregunta.
Creo que todo se trata del contexto, un nodo se usa en gran medida para el contenido, por lo que serían blogs, artículos, preguntas frecuentes, etc. Mientras que el usuario para perfiles como personal, clientes, etc.
Si bien podría usar un nodo para algo como un ticket de soporte, podría no ser la mejor plantilla y los valores predeterminados ... Espero que eso ayude.
Las entidades se pueden crear con menos sobrecarga que los nodos, ya que no necesitan tener todas las funcionalidades de servicio pesado que tienen las entidades.
También significa que el almacenamiento puede ser más simple: puede crearlos para obtener toda la información en una consulta simple sin UNIRSE si lo desea. Todos los campos muy bien en una sola mesa ordenada.
Esto puede ser un gran beneficio si tiene muchas funciones que necesitan hacer consultas en las entidades, y está actualizando muchas entidades simultáneamente con consultas de ACTUALIZACIÓN en la base de datos. Si puede asegurarse de que los datos estén relativamente autocontenidos en una sola tabla, tiene menos preocupaciones y posibilidades de corrupción de datos.
Un tipo de contenido está diseñado para ser contenido del sitio. Es decir, cada tipo de contenido está diseñado para ser publicado y aparecer en el sitio. Por ejemplo, un artículo (listo para usar) está diseñado para aparecer en la primera página.
Ahora, supongamos que desea crear algo así como un formulario de solicitud de empleo o apartamento. Obviamente, no querrás publicar la solicitud de empleo de alguien en tu sitio web. Además, ¿qué sucede si desea crear una lista de contactos de clientes / clientes potenciales? ¿Desea arriesgarse a que esta información se publique por error en su sitio web? Personalmente, no lo haría.
Por lo tanto, el módulo de formulario de entidad que se analiza anteriormente. Le permite crear un tipo de entidad que no está diseñado para ser contenido. Sin embargo, estos tipos de entidad están disponibles para cualquier módulo que admita entidades como reglas, vistas y grupos orgánicos, por nombrar solo algunos.
Y luego ingresas a Drupal Commerce donde los productos son tipos de entidad. Básicamente, las entidades permiten a los desarrolladores extender Drupal de una manera nunca prevista por los diseñadores originales de Drupal.
Esto está sujeto a discusión y al final debes tomar tus decisiones como desarrollador.
Elijo entidades sobre nodos siempre que los datos no estén disponibles públicamente con su propia URL. Los nodos obtienen de forma predeterminada un alias de URL, estado publicado, un título, metaetiquetas, ... mientras que las entidades solo obtienen un registro en la base de datos.
"Quiero poder agregar tantos banners con texto como sea posible y luego, en una publicación de blog, elegir entre uno de ellos"
Entidad vs contenido
La entidad tiene paquetes de entidades que tienen campos
El contenido es un tipo de entidad. Entonces,
El contenido tiene paquetes de contenido (artículo, página) que tienen campos (cuerpo, imagen del artículo)
Si eres programador, seguramente eliges la ruta de creación de tu propia entidad, pero para los creadores de sitios puede que no sea la mejor opción. Nuevamente para los creadores de sitios, existe una interfaz de usuario para crear la Entidad http://drupal.org/project/eck