Directorio de plantilla de proyecto del desarrollador web

Question

IMPORTANTE: La respuesta aceptada fue aceptada después de la recompensa, no necesariamente porque sentí que era la mejor respuesta.

---

Me encuentro haciendo cosas una y otra vez al iniciar nuevos proyectos. Creo una carpeta, con subcarpetas y luego copio algunos elementos estándar como un archivo de restablecimiento de css, iconos de famfamfam, jquery, etc.

Esto me hizo pensar cuál sería la plantilla de partida ideal. La razón por la que estoy preguntando es por lo que estoy pasando nuevamente y me pregunto qué debo incluir en mi plantilla para no tener que volver atrás en el futuro y volver a hacer esto con cada sitio nuevo que empiece. .

Lo que tengo actualmente de la siguiente manera:

carpeta de plantillas de proyecto

• index.html - XHTML 1.0 Estricto Doctype. Meta Tags. Archivos CSS/js a los que se hace referencia.
• css/
  • default.css - Vacío. Reservado para estilos de usuario.
  • 960/- 960 Sistema de cuadrícula para diseños CSS.
    • 960.css
    • reset.css
    • text.css
• JS/
  • Default.js - vacías. Reservado para guiones de usuario.
  • jQuery/- Ligero marco de JavaScript
    • jquery-1.3.1.min.js
• img/
  • famfamfam/- Excelente colección de iconos png
    • iconos/
      • accept.png
      • add.png
      • ...etc

Answer 1

tengo una estructura similar y convención de nomenclatura, pero para CSS, utilizo BluePrint que encuentro es más extensible. También prefieren que jQuery haya cambiado recientemente de prototipo. Además, tengo un archivo common.js que es una extensión con funciones personalizadas para jQuery.

A/db/carpeta con archivos .sql que contienen definiciones de esquema. Una carpeta/lib/para bibliotecas comunes de nivel medio.

también tendrá un src/carpeta/que a veces tienen los archivos RAW como las plantillas de Photoshop, readme, listas de tareas pendientes, etc.

Answer 2

Creo que la estructura es buena. La adición de algunas otras carpetas depende del tipo de trabajo que esté completando.

Para trabajar independientemente y cosas por el estilo, la adición de carpetas PSD, comentarios de los clientes sería una buena adición.

Answer 3

Una muy EM sesgada visión, pero mi SOP en este momento está en la línea de:

• documentación/
  • Arquitectura/(lo que podríamos llamar la documentación del código)
  • comunicaciones/(importantes documentos de cliente)
  • spec/
  • whitepapers/
• gráficos/
  • * .psd

• fuente/

  • com.mycompany.projectname.solutionA/
  • com.mycompany.projectname.solutionB/
  • com.mycompany.projectname.solutionC/

  • com.mycompany.projectname.solutionX/(proyecto en el sentido de los negocios aquí)

    • BusinessLogic/
      • * .cs (o lo que sea)
    • (más proyectos - en el sentido de Visual Studio)

    • sitio/

      • manipuladores/(rara vez uso real.html estos días)
      • módulos/

      • recursos/

        • img/(PNG JPEG, gifs lo que sea)

          • piel/
            • iconos/
            • fondos/

        • js/(comprimido cuando publicado)

          • biblioteca/(código estándar)
          • /(código específico app) común
          • * .js (código específico de la aplicación, con suerte cero)
        • css/
          • skinX/(incluso si sólo hay "default")
            • extension.css
          • base.css
        • transformaciones/(al formas ocultas a la pública por config o construir procesos)
          • * .xslt
    • unittests/
      • burla/
      • testmain.cs (o lo que sea)
• de terceros/
  • dependencias

Answer 4

Si usted tiene una gran cantidad de proyectos con una gran cantidad de contenido estático en común (por ejemplo, jquery, css framework, etc.) hazte un servidor de medios para servir a todos estos. Entonces, en lugar de crear una gran cantidad de estructura de carpetas desde una "plantilla", todo lo que debe hacer es incluir los archivos correctos en el html de su proyecto.Si realmente desea una plantilla, su plantilla se convierte en un archivo html en lugar de una estructura de directorio.

Esto también le ofrece una manera fácil de actualizar los medios estáticos para sus sitios (por ejemplo, pasar a la próxima versión de 960). solo tienes que hacerlo en un solo lugar. ¡Por supuesto, aún debe asegurarse de que sus actualizaciones no rompan los sitios existentes! :)

Puede hacer que el esquema sea un poco más complicado si ciertos proyectos tienen necesidades superpuestas, pero son diferentes de los demás. Solo tiene un directorio en el nivel superior del servidor para cada configuración y para cada configuración corresponde una "plantilla" html. La idea principal es tener que lidiar con una sola copia de todo lo que es común.

Sin duda puede hacer esto en una pequeña máquina virtual (por ejemplo, linode) por $ 20/mes o un servidor web virtual en su servidor web actual. Realmente no necesitas un servidor, para el caso, solo necesitas una carpeta. Sin embargo, creo que puede obtener importantes mejoras de rendimiento al tener un servidor de medios dedicado. Recomiendo usar un apache afinado o nginx para este propósito.

En cuanto a los archivos estáticos específicos del sitio, también es una buena idea que vivan en el servidor de medios y la estructura del directorio probablemente sea exactamente la que usted tiene, pero deberían/​​deberían ser directorios vacíos.

Answer 5

Definitivamente me encanta la idea de tener una carpeta de plantilla esqueleto como esta, pero si usa algunas tecnologías diferentes, definitivamente preste mucha atención a la estructura. Mi estructura de carpetas VB.net tiene una configuración totalmente diferente en comparación con PHP. Suena como el sentido común, pero he visto personas acercarse a ambos de la misma manera.

Answer 6

Mi marco de desarrollo web se encuentra en un repositorio de git. El código común, como las clases PHP de propósito general, se desarrolla en la rama principal. Todo el trabajo para un sitio web particular se realiza en una sucursal, y luego los cambios que ayudarán en el trabajo futuro se fusionan nuevamente en el máster.

Este enfoque funciona bien para mí porque tengo control de revisión completo de todos los sitios web, y si soluciono un error o implemento una nueva función mientras trabajo en una sucursal, puedo fusionar y todo se beneficia.

Esto es lo que se ve mi plantilla como:

/ 
|-.htaccess   //mod_rewrite skeleton 
|-admin/    //custom admin frontend to the CMS 
|-classes/    //common PHP classes 
|-dwoo/    //template system 
|-config/    //configuration files (database, etc) 
|-controllers/   //PHP scripts that handle particular URLs 
|-javascript/ 
     |-tinyMCE/ 
     |-jquery/ 
|-modules    //these are modules for our custom CMS 
     |-news/ 
     |-mailing_list/ 
     |-others 
|-private/    //this contains files that won't be uploaded (.fla, .psd, etc) 
     |-.htaccess  //just in case it gets uploaded, deny all 
|-templates/   //template source files for dwoo 

Answer 7

En el trabajo usamos CodeIgniter como un marco de PHP para nuestras aplicaciones web y hemos creado una nueva plantilla de proyecto que hace exactamente eso: estructura de directorios simple, Blueprint CSS , jQuery y la carpeta de la aplicación Code Igniter, llena con un par de bibliotecas de uso común (Autenticación, algunos modelos especiales para bases de datos de uso frecuente ...).

El lema principal aquí es: Siempre es más fácil eliminar componentes que agregarlos. Así que llena tu plantilla.

(Y cuando estoy empezando un nuevo proyecto en mi tiempo libre me profundamente de menos esa plantilla ...)

Answer 8

Creo que lo que tenemos aquí es grande .... Lo que ha enumerado es por supuesto, todo sobre el front-end público de su aplicación. Mi única adición a esto es mantener todo el código de back-end y la fuente fuera del espacio web público si es posible, ya que mientras menos cosas tenga en el espacio público, más segura será su aplicación.

Así que me gustaría sugerir que se toma toda su árbol, y lo puse en:

httpdocs/(all you had in your project template folder) 

continuación, poner todo su código de fondo (por ejemplo, las bibliotecas de php, archivos SQL, etc.) en los subdirectorios adyacentes:

httpdocs/(all you had in your project template folder) 
phplibs/ 
sql/ 

etc.

Y, aun para sus cosas frontal, asegúrese de no copiar en los archivos de ejemplo que pueden venir con sus bibliotecas de front-end, como muestran los ejemplos en sí mismos pueden tener problemas de seguridad que permitan a las personas a XSS o comprometer su sitio de otra manera.

Answer 9

He estado usando la siguiente configuración desde hace un tiempo con grandes resultados:

• /sitio: Aquí es donde mi página web real de trabajo vivirá. Instalaré mi CMS o plataforma en este directorio después de que se creen las plantillas.
  • .htaccess (ajustes básicos por lo general me encuentro que permite de todos modos)
  • robots.txt (por lo que no se olviden de rechazar partidas como/admin más adelante)

• /fuente: Contiene cualquier comps, notas, documentos, especificaciones, etc.

• /templates: ¡Comience aquí! Cree todas las plantillas estáticas que eventualmente necesitarán ser portadas al CMS o framework de/site.

  • /comportamiento
    • global.js (site-specific código; se puede romper a cabo en varios archivos según sea necesario)

  • /media: imágenes, archivos descargables, etc. Organizado según sea necesario

  • /style: Prefiero el desarrollo de CSS modular, así que normalmente termino con muchas hojas de estilo para cada sección única de el sitio web. Esto se limpia mucho con Blender - ¡Recomiendo esta herramienta!

    • behavior.css (cualquier estilo que requiere un navegador habilitado para JS)
    • print.css (esto finalmente se mezcló, a fin de utilizar @media impresión)
    • reset.css (Eric Meyer's)
    • screen.css (por @media pantalla, de mano)

  • /proveedor: todos los códigos de terceros (jQuery, shadowbox, etc.)

  • Blendfile.yaml (por Blender; véase más arriba)

  • template.html (plantilla de partida básico; puede ser copiado y renombrado para cada plantilla única)

Answer 10

Uso un diseño similar, pero con una gran excepción: todos estos directorios viven bajo un medio/directorio de nivel superior. Esto es por algunas razones:

1. Este directorio está sincronizado con otros dos servidores que manejan todas las solicitudes de medios estáticos.
2. Tener varios hosts permite que algunos navegadores realicen más solicitudes paralelas de archivos de soporte.
3. El medio/directorio tiene su propio archivo .htaccess que elimina un directorio psuedo de la ruta que es la fecha y la última modificación de la imagen (o lo que sea).

Una etiqueta de plantilla personalizada (he usado esto con 2 proyectos de Django, pero puedes hacerlo en PHP, etc.) genera direcciones URL que a) eligen semi-aleatoriamente uno de los servidores de medios, b) agregan pseudodirectorio basado en el tiempo para la ruta, yc) darle al objeto un tiempo de caducidad de + 10 años.

Answer 11

Me gustan los OP como punto de inicio predeterminado. su plantilla estándar debe errar por la simplicidad, con la capacidad de agregar complejidad solo si es necesaria.

una adición:

/robots.txt