vender template plantillas plantilla para pagina mejores maquetar gratis desarrollo creativas templates performance project

templates - template - Directorio de plantillas de proyectos del desarrollador web



template pagina web 2018 (11)

En el trabajo, utilizamos Code Igniter como marco 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 aplicaciones Code Igniter, llena de 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 empiezo un nuevo proyecto en mi tiempo libre, echo de menos esa plantilla ...)

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 cuando comienzo 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 inicial 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 sigue:

Carpeta de plantilla de proyecto
  • index.html - XHTML 1.0 Strict 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ío. Reservado para guiones de usuario.
    • jQuery / - Marco ligero de Javascript
      • jquery-1.3.1.min.js
  • img /
    • famfamfam / - Excelente colección de iconos png
      • iconos /
        • accept.png
        • add.png
        • ... etc

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, los comentarios de los clientes sería una buena adición.

Tengo una estructura y convención de nombres similar, pero para CSS utilizo BluePrint, que me parece 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.

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

También tendré una carpeta / src / que algunas veces tendrá archivos en bruto como plantillas de Photoshop, Léame, listas de tareas, etc.

Si tiene muchos proyectos con mucho contenido estático en común (por ejemplo, jquery, css framework, etc.) hágase 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 brinda 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.

Ciertamente puede hacerlo 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 o nginx bien ajustado 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 lo que tienes, pero deberían / ​​deberían ser directorios vacíos.

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

  • documentación/
    • arquitectura / (lo que podría llamarse documentación de código)
    • comunicaciones / (documentos importantes del cliente)
    • especulación/
    • libros blancos/
  • gráficos/
    • * .psd

  • fuente/

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

    • com.mycompany.projectname.solutionX / (proyecto en el sentido comercial aquí)

      • lógica de negocios/
        • * .cs (o lo que sea)
      • (otros proyectos, en el sentido del estudio visual)

      • sitio/

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

        • recursos /

          • img / (pngs jpegs, gifs lo que sea)

            • piel/
              • iconos /
              • antecedentes/

          • js / (comprimido cuando se publica)

            • biblioteca / (código estándar)
            • común / (código específico de la aplicación)
            • * .js (código específico de la aplicación, con suerte nulo)
          • css /
            • skinX / (incluso si solo hay "predeterminado")
              • extension.css
            • base.css
          • transforma / (siempre oculto del público por configuración o proceso de compilación)
            • * .xslt
      • unittest /
        • burlas /
        • testmain.cs (o lo que sea)
  • tercero/
    • dependencias

Creo que lo que tienes aquí es genial ... Lo que has enumerado es, por supuesto, todo sobre el front end público de tu 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 te sugiero que tomes todo tu árbol y lo pongas en:

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

luego coloque todo su código de back-end (por ejemplo, librerías php, archivos sql, etc.) en subdirectorios adyacentes:

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

etc.

Y, incluso para su material de front-end, asegúrese de no copiar en ningún archivo de ejemplo que pueda venir con sus bibliotecas de front-end, ya que los ejemplos en sí pueden tener problemas de seguridad que permitan a las personas XSS o comprometer su sitio.

Definitivamente me encanta la idea de tener una carpeta de plantilla básica 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.

He estado utilizando la siguiente configuración por un tiempo con excelentes resultados:

  • / sitio: aquí es donde vivirá mi sitio web real de trabajo. Instalaré mi CMS o plataforma en este directorio después de que se creen las plantillas.
    • .htaccess (ajustes básicos que generalmente me encuentro habilitando de todos modos)
    • robots.txt (así que no me olvide de rechazar elementos como / admin más adelante)

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

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

    • /comportamiento
      • global.js (código específico del sitio; puede dividirse 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 del sitio web. Esto se limpia mucho con Blender . ¡Recomiendo esta herramienta!

      • behavior.css (cualquier estilo que requiera un navegador habilitado para JS)
      • print.css (esto eventualmente se mezcla, así que use @media print)
      • reset.css ( Eric Meyer''s )
      • screen.css (para @media pantalla, computadora de mano)

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

    • Blendfile.yaml (para Blender, ver arriba)

    • template.html ( plantilla básica de inicio; se puede copiar y renombrar para cada plantilla única)

Mi marco de desarrollo web se encuentra en un repositorio 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 sucede que soluciono un error o implemento una nueva función mientras trabajo en una sucursal, puedo hacer la fusión, y entonces todo se beneficia.

Así es como se ve mi plantilla:

/ |-.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

Utilizo 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 directorio / medios tiene su propio archivo .htaccess que elimina un directorio psuedo de la ruta que es la última fecha de la imagen modificada (o lo que sea).

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

Me gustan los PO como punto de partida 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