2012-10-11 18 views
7

Estamos escribiendo un proyecto de Grails (Grails 2.1.1) donde, para algunas de nuestras vistas, queremos utilizar el uso de markdown en lugar de archivos gsp.Usando Markdown como una Vista de Grails

En este momento podemos hacer esto usando el markdown plugin en un diseño especial. Esto permite que podamos prestarle vistas de rebajas de este modo:

render(layout: 'docs', view: 'markdown')

Sin embargo, esto requiere la página de reducción del precio de tener una extensión .gsp, cuando, por razones prácticas, que se necesita tener una extensión .md.

¿Alguien sabe una mejor manera de utilizar el descuento como una vista de Grails? Sería genial si podemos evitar el uso de la extensión .gsp.

+1

Creo que hay alguna manera de asignar otros archivos como archivos gsp, por ejemplo, mira el complemento GSP-ass, asigna archivos .js como gsp para que los archivos js se procesen como si fuera un archivo gsp. Puede ser la solución. –

+0

Gracias. Voy a ver cómo implementan eso y ver si es algo que podemos usar. Informará de nuevo! – River

+0

revisa este proyecto: https://github.com/edvinasbartkus/grails-mustache – moskiteau

Respuesta

2

La respuesta corta

No podrá hacerlo sin algunas modificaciones importantes. El GrailsViewResolver distribuido está estrictamente ligado a las extensiones .gsp y .jsp.

Consulte grails-core on github para la verificación.

La respuesta Largo

Es posible que pueda dar forma a su propia tarea Ant para engancharlo en el ciclo de compilación de la aplicación Grails de manera que, como mínimo, se puede compilar sus archivos * .MD a través de la GroovyPageCompiler .

Ese proceso puede parecerse a this (aunque no exactamente, ya que estoy confiando en el taglib del plugin para hacer el renderizado en este caso, para simplificar).

Pero esto no resuelve todos sus problemas. También necesitaría registrar un nuevo sistema de resolución de vistas, y para hacerlo inevitablemente iría por el camino de la reescritura del GrailsDispatcherServlet.

Parece que su solución para almacenar los archivos en el directorio conf podría ser su mejor (aunque sucia) apuesta por ahora. Tal vez alguien se tome el tiempo para permitir extensiones de archivo GSP configurables en el futuro, y eso podría resolver su problema más adelante.

Espero que encuentre útil esta información.

+0

Oh, gracias, echaré un vistazo a esas clases durante la semana. Me pregunto qué tan fácil será utilizar Spring para intercambiarlos con subclases especializadas. Aunque estoy muy contento con nuestra solución actual, creo que esta podría ser una gran parte de la respuesta a la pregunta (lo decidiremos en breve). – River

+0

Sí, eso es factible, pero deberá subclasificar cada parte del marco de aplicación que define estáticamente la extensión .gsp. Esto puede irse rápidamente de las manos y volverse inmanejable. Una solución mejor sería agregar una tarea a la fase de compilación que copie sus archivos .md a una extensión .gsp antes de compilar el gsp (tal vez el hook eventCompileStart), y luego limpiar los .gsp en los directorios del proyecto. Eso es lo que hice en el pasado por un objetivo similar. –

+0

Gracias por la respuesta. Creo que si decidimos utilizar esta técnica de documentación para un proyecto más grande, probablemente buscaremos crear un complemento para cambiar el nombre de los archivos .md o algo similar. Por el momento, ¡creo que estamos contentos con el método del directorio conf! – River

0

Hice casi lo mismo pero con otro enfoque hoy. Quería publicar el archivo Léame del proyecto, así que no podía moverlo a ninguna parte. Terminé vincularlo desde readme.md a grails-app/views/readme/readme.gsp. I posted sobre todo el asunto.

Y sí, los enlaces suaves funcionan si usted y todos sus compañeros de trabajo están en * -nix, por lo que no es una forma segura de hacerlo.

Cuestiones relacionadas