¿Número máximo de tipos de entrada?
¿Existe un límite en el número de tipos de entrada diferentes que puede tener una sección? Para este proyecto, podría necesitar 50+.
Creo que necesito más contenido para cumplir con los estándares de calidad, así que explicaré: mi cliente quiere crear varios informes para que los completen sus clientes. Mi cliente se siente cómodo con el backend artesanal y sabe cómo crear campos / secciones / etc. Quiero mantener todas las entradas del informe juntas. Ergo una sección de Informes con un tipo de entrada diferente para cada informe.
Respuestas
Brad menciona que no hay limitaciones en los tipos de entrada, aunque si es una buena idea a largo plazo para fines de mantenimiento y UI es otra historia.
Los tipos de entrada son los más útiles cuando su contenido es bastante diferente entre ellos, pero aún desea mantener las entradas juntas en la misma sección.
Por ejemplo, en una sección de Noticias, es posible que tenga un Link to Pagetipo de entrada en el que se vincule a diferentes sitios web y un Blog Entrytipo en el que solo sean entradas normales. (El sitio Daring Fireball de John Gruber es un buen ejemplo de esto.
En mi experiencia, cuando un usuario comienza a ver una docena de tipos de entrada, puede comenzar a ser bastante abrumador ... así es como se verían 50 de ellos mirándote a la cara:
Los tipos de entrada son útiles porque cada uno tiene su propio conjunto de campos.
Sin embargo, desde el punto de vista de la capacidad de mantenimiento, digamos que desea agregar o mover un campo en cada informe. Hacerlo con 2 o 3 tipos de entrada es bastante sencillo, pero ¿hacerlo de manera constante con 50? Mucho más difícil, ya sea que esté utilizando archivos YAML o la GUI.
La regla 80/20 podría ser útil aquí: supongo que el 80% de los informes generados probablemente caerán en el 20% de sus tipos. Eso solo redujo el número de tipos de entrada a 10. Tal vez agregue algunos otros más comunes más un tipo de entrada general "Otro ..." o algo así.
A menos que su cliente también sea un desarrollador / diseñador colega, no querrán agregar campos y secciones al backend a menos que sea absolutamente necesario.
Si yo fuera usted, podría preguntarle a su cliente: ¿qué hay de diferente en cada informe? ¿Lo que es lo mismo? Encontrará algunas buenas respuestas que pueden ayudarlo a usted y a su cliente a modelar esto bien.
Eso podría llevarlo a usar algo como Categorías, donde es muy fácil agregar nuevas. Si los tipos de informes se parecen más a filtros, también se mostrarán mucho mejor en la GUI.
Y tal vez necesite algunos tipos de informes para ocultar y mostrar diferentes campos, pero por lo demás son bastante similares. Podría considerar hacer esto con, digamos, el complemento Reasons .
¡Comida para el pensamiento!
No hay un límite codificado para el contenido de Craft (secciones, tipos de entrada, entradas, campos, etc.).
Dependerá en gran medida de cómo esté usando ese contenido en sus plantillas y en qué tipo de entorno se está ejecutando la instalación (recursos del servidor físico, estrategias de almacenamiento en caché, etc.)
Hemos visto instalaciones con algunas arquitecturas de información bastante complejas repartidas en más de 50 "sitios" y decenas de millones de elementos (entradas, usuarios, activos, categorías, etc.)