Marco web liviano de Java: requisitos específicos

Question

La primera vez que me encontré, p. El framework Sinatra de Ruby o Zend Framework de PHP, me preguntaba si hay algo adecuado en Java, todo parece tan hinchado aquí. Aunque hay miles de marcos alrededor, hasta ahora no he encontrado ninguno que considere perfecto para el tipo de arquitectura que me gustaría implementar.

Quería diseñar una aplicación web que fuera pesada en el Javascript con la mayoría de la lógica de la aplicación implementada en el cliente, el back-end de Java serviría más o menos como un almacén de datos o realizar cálculos complejos.

Revisé las preguntas relacionadas aquí pero no pude encontrar la respuesta perfecta, cada una de las soluciones sugeridas tenía una peculiaridad que no coincidía con los requisitos.

Así que esto es lo que estoy buscando, un marco de código abierto con las siguientes características:

• convención sobre configuración
• ninguna configuración XML excepción de web.xml
• Java puro (sin Scala , sin maravilloso, ...)
• URL de estilo REST naturales tales como/news/2011/julio (sin .DO, sin .jsp, ...)
• REST-conscientes
• no debería obligarme a implementar en un servidor de aplicaciones (p. EJB debe ser opcional)
• soporte para sesiones sería bueno, pero no es obligatorio
• generación de código como en los carriles sería impresionante, pero no es obligatorio
• mínimo de dependencias, pequeño en tamaño total
• MVC sería bueno, pero
  • Me gustaría poder elegir la parte M, elegir las bibliotecas de persistencia por mi cuenta (sin agrupar).
  • Código generado Sin automáticamente para la vista, ni HTML, Javascript, ni CSS
  • Un lenguaje de plantillas integrado sería bueno, pero debería ser minimalista (simple flujo de control, el acceso a variables de plantilla)
  • apoyo Layout (es decir, que son capaces de especificar un modelo común de puntos de vista similares)
  • libre elección de JavaScript marco de las opiniones

Básicamente esto significaría un framework MVC que hace el enrutamiento para mí y ofrece soporte de plantilla para las vistas, pero el resto es completamente modular, no mágico. ¿Hay algún marco minimalista que proporcione esto (o al menos sea lo suficientemente modular como para configurarse de esa manera)?

Answer 1

¿Qué tal Play Framework?

Convención

sobre configuración

Juego solamente tiene unos archivos de configuración. La mayor parte de su estructura es por convención. Por ejemplo, la estructura básica dice así:

| 
+---/app - All executable artifacts go here (java files, conf files and view templates). 
|  | 
|  +---/model - Your model Java classes. 
|  | 
|  +---/view - Your view templates. 
|  | 
|  +---/controller - Your controller classes 
|  
|---/conf - Contains all configuration files for the application. Initially contains application configuration and routing table. 
|  
|---/lib - Libraries your appliaction needs. Added automatically to classpath. 
|  
|---/log 
|  
|---/public - Public stuff are your static assets that your server gives directly 
|  
|---/test 
|  
|---/tmp - All your temporarily compiled .class files are here 

ninguna configuración XML excepción de web.xml

Play tiene ninguna configuración XML, incluyendo sin web.xml. Tiene un archivo de Ruteo en su lugar. Vea el ejemplo a continuación sobre lo que usa para el enrutamiento.

Java puro (sin Scala, sin maravilloso, ...)

Es Java puro, pero se puede usar Scala o maravilloso a través de un plugin.

• URL de estilo REST natural como/news/2011/julio (sin .do, sin .jsp, ...)
• REST-conscientes

Desde el sitio:
Play is a real "Share nothing" system. Ready for REST, it is easily scaled by running multiple instances of the same application on several servers.

de hecho enrutamiento en un descanso de igual manera es muy fácil:

# Play 'routes' configuration file… 

# Method URL path   Controller 

GET  /    Application.index 
GET  /about   Application.about 
POST  /item   Item.addItem 
GET  /item/{id}  Item.getItem 
GET  /item/{id}.pdf Item.getItemPdf 

No es difícil adivinar qué pasa una vez que te acostumbras a jugar un poco.

• no me debería obligar a desplegar en un servidor de aplicaciones (por ejemplo EJB debe ser opcional)

No lo hace. De hecho, implementas guardando tus archivos. EJB son completamente opcionales y también lo son .war, .ear y otras formas de implementación.

generación de código como en los carriles sería impresionante, pero no es obligatorio

No creo que lo hace mucho más la generación de código, pero no estoy 100% en eso. Crea automáticamente todas las carpetas requeridas y crea una instancia de una página de ejemplo básica. No sé si Rails genera algo más ...

MVC sería bueno, pero
- Me gustaría ser capaz de elegir la parte M, seleccione las bibliotecas de persistencia en mi propia (sin agrupación).
- Sin automáticamente el código generado para la vista, ni HTML, Javascript, ni CSS
- Un lenguaje de plantillas integrado sería bueno, pero debería ser minimalista flujo de control simple (,

Ver MVC in Play

• que este es un punto de venta libre menor. Juego modelos deben usar JPA o extender cierta clase de modelo que viene con el juego. Ver Play framework-model para obtener más información.
• no genera HTML aunque puede hacerlo use su lenguaje de plantilla dentro de su .html, .css, .js y otros archivos para crear páginas dinámicas.

• I tiene un lenguaje de plantillas incorporado basado en el lenguaje de plantillas de Groovy, p.

  You have ${emails.unread ?: 'no'} ${emails.unread?.pluralize('email')} !

Otras ventajas:

• Es bastante divertido Programm en
• ¿Mencioné el intercambio en caliente que le permite volver a implementar la aplicación por el ahorro de archivos de origen.?
• Grandes registros de errores.

Contras:

• Es 51MB no estoy seguro si esto califica como ligera:/

Answer 2

Spring Roo: Me pareció fácil comenzar con. Puede generar código de UI, pero depende de usted el usarlo.

Answer 3

He utilizado el marco Stripes en varios proyectos en el pasado, y parece que cumple con todos/la mayoría de sus criterios, especialmente la convención sobre la configuración. No hay configuración XML: hay un archivo stripes.properties que tiene una configuración de comportamiento general (es una adición única a su classpath). Se necesita una edición única de web.xml para configurar el "Dispensador de franjas", que es un filtro que enruta las solicitudes a sus beans de acción apropiados.Los ActionBeans se descubren automáticamente, por lo que no tiene que actualizar siquiera su web.xml cuando agrega más Action Beans. Sus URL están todas configuradas mediante anotaciones en los beans de acción, apoyos en reposo, enlaces dinámicos ActionBean, validación del lado del servidor y conversión a través de anotaciones integradas para tipos simples, con la capacidad de crear sus propios manejadores y convertidores de validación para tipos complejos. Funciona con JSP y sus bibliotecas JS/CSS personalizadas. Los foros de documentación y soporte son geniales. Es rápido aprender si sigues su tutorial.