He leído mucho sobre las cosas buenas de Apache Wicket, pero es difícil encontrar las cosas malas. Como ningún marco es siempre la solución adecuada para cada problema, ¿cuáles son las desventajas de Wicket y en qué tipo de proyectos no lo usaría?¿Cuáles son las desventajas de Apache Wicket?
Quizás no sea una pregunta popular, pero creo que una importante.
Wicket exige unas prácticas de codificación bastante sólidas. Por ejemplo, si almacena un IModel en su Componente, pero no lo usa como modelo del componente, no se desprenderá automáticamente y puede hacer explotar el tamaño de su sesión. Este tipo de gestión no es algo a lo que la mayoría de los usuarios de Java están acostumbrados.
Wicket está activo y se actualiza con frecuencia.Esto es bueno, pero cada vez que actualizo una nueva versión, me doy cuenta de que necesito hacer muchas refactorizaciones para pasar a mejores prácticas de codificación (1.4 introdujo los genéricos, 1.4.x presentó enConfigure(), 1.5 tiene algunas estrategias de recursos diferentes) De nuevo, todas son buenas actualizaciones y te empujan hacia un mejor código, pero envidio a la gente que viene a Wicket AHORA en lugar de hace dos años :)
Combinando ambos arriba, creo que Wicket asume alguna habilidad real de programación una vez que superas los requisitos básicos conjunto de características. Si eres un buen desarrollador, te encantará lo que Wicket puede hacer por ti (y el código está bastante bien documentado en JavaDoc). Si eres un principiante, puedes frustrarte a medida que te vuelves más profundo.
Además, aunque "funciona" en Google App Engine, encontré varios problemas que le impedían trabajar cómodamente en ese entorno. Eso es para una discusión diferente.
Mi descargo de responsabilidad es que no he usado nada más, por lo que quizás otros marcos sean peores.
@Martin - ¿en serio? Encontré que la precisión de la codificación de wicket es su mayor beneficio.Claro que si estás atrapado en un mundo JSP donde te gusta incrustar el código Java dentro de los artefactos de la capa de presentación, probablemente no te gustará Wicket y no entenderás por qué otros lo hacen. – Volksman
@Volksman Estaba comparando con los enfoques modernos (REST + cliente web) donde la separación de servidor y cliente existe de manera real. –
Wicket and Wickman –
me parece portillo realmente útil, pero éstas serían las desventajas que he encontrado hasta ahora:
Descubrí que Wicket in Action es lo más definitivo que necesita. ¿Qué es lo que sientes que falta desde allí? Las estrategias de codificación de URL son, hasta ahora, la solución más fácil que he visto para imponer URL sensibles en todos los ámbitos y, por supuesto, puede definir árboles de componentes dinámicos mediante la implementación de sus propios componentes. Aunque realmente no debería, ya que no hay una necesidad real de ellos. – biziclop
La documentación no es tan buena, pero los libros llenan ese agujero; Las URL son feas por defecto, pero se pueden embellecer muy fácilmente; Puede definir dinámicamente árboles de componentes, simplemente no puede hacerlo tan ad hoc como lo haría en un marco de plantillas tipo JSP. – tetsuo
Wicket tiene desde hace un par de años una impresionante e integral guía de usuario en línea sin tener que pagar nada, mantenida para todas las versiones recientes: http://wicket.apache.org/learn/#guide –
Hay dos cosas que me pareció molesto con Wicket:
llamadas Ajax se llevan a cabo de forma sincrónica (que están en la cola del lado del cliente para evitar problemas de concurrencia), Ajax Así es única JAX, en realidad. EDITAR: aparentemente estaba equivocado sobre esto, ver el comentario de marting-g a continuación.
La API parece que no les importa mucho acerca de encapsulación, por lo que encontrarás un montón de métodos públicos documentados como "Esto no es parte de la API pública. No invoque este método." (o algo similar).
Las llamadas AJAX están en cola del lado del cliente nombre de canal/cola. Es decir. puede volverlos asincrónicos de nuevo anulando AbstractAjaxBehavior # getChannelName(). –
+1 para la sugerencia :). Pero ese método está realmente en AbstractDefaultAjaxBehavior y está completamente indocumentado. –
Esto NO ES PARTE DEL NEGOCIO DE API PUBLIC es probablemente porque están dividiendo el código en varios paquetes, y la única forma de que las clases en diferentes paquetes hablen entre sí es a través de métodos públicos, aunque sean colaboradores. Es un problema común en proyectos grandes. Realmente, esto se debe a la pobreza del mecanismo de control de acceso de Java. Tienes razón en que es molesto, sin embargo. –
No he usado Wicket, así que adelante y abajo, vótame si es necesario, pero Wicket está basado en componentes. Si prefiere una solución basada en componentes, entonces eso no será una desventaja para usted, pero encontré un marco basado en componentes competitivos restrictivos.
Viniendo de un par de años de JSF (también un modelo basado en componentes) a Spring MVC (más basado en la acción) sentí que se habían levantado los grilletes. El tercer punto en la respuesta de mgv, "No se pueden definir dinámicamente árboles de componentes, ya que hay que definirlos tanto en el diseño HTML como en el código Java", resume gran parte de la causa de mi frustración.
Me han obligado a usar JSF una vez y lo he odiado, siempre me ha gustado Spring MVC y al principio era muy escéptico con respecto a Wicket. Ahora, wicket se convirtió en la primera opción definitiva para mí como framework web de Java, aunque todavía soy un gran fanático de Spring. Así que olvídate de las similitudes entre JSF y Wicket. –
JSF! = Wicket. ¿Diría que Spring MVC es lo mismo que Struts 1, simplemente porque ambos son marcos basados en la acción? – tetsuo
Sí, entiendo de dónde vienen ustedes dos, y es por eso que comencé mi publicación con "No he usado wicket" y estaba basando en mi única experiencia con un marco basado en componentes. Tu punto en Spring MVC vs. Struts 1 es muy válido, y ahora que dices eso, he jugado con Struts 1 hace muchos años y fue una experiencia horrible, basada en la acción. – digitaljoel
Véase mi respuesta aquí:
Por supuesto, yo los que figuran como ventajas, pero es fácil ver por qué alguien podría sentir lo contrario.
Si bien no hay nada que no puedas hacer absolutamente en Wicket, hay ciertos conceptos subyacentes (no lo llamaría filosofía porque odio el uso excesivo de esta palabra) que debes seguir. Cuanto más te alejas de ese concepto, más difícil es meterlo en Wicket.
En el mundo real, la velocidad de desarrollo es muy lenta con Wicket. Si no tiene un componente prelacado para usar como un trabajador de fábrica en una cadena de montaje, la productividad se detiene hasta que pueda crear un nuevo panel. La complejidad del código aumenta y es difícil leer el código porque está duplicando efectivamente las líneas de código que tiene que escribir. Constantemente buscas cómo hacer cosas triviales en internet y en libros. Por ejemplo, un simple botón de reinicio es una línea de HTML, pero en Wicket se requiere buscar en Google cómo hacerlo. Hace que las cosas simples sean difíciles y difíciles.
Todavía tengo que ver una interfaz de usuario realmente complicada construida con Wicket. Solo son posibles IU simples compuestas de componentes pre-enlatados con Wicket. Cada interfaz de usuario que he visto construir con Wicket podría haber tenido una base de código más limpia si no se hubiera hecho en Wicket y escalaría mejor al eliminar Wicket. Wicket tampoco te compra nada como buenos widgets UI. Incluso las implementaciones de jQuery UI de Wicket son inferiores a solo usar jQuery UI directamente.
Después de leer decenas de miles de líneas de código de Wicket en mi trabajo, puedo decir que el código de Wicket es básicamente código de espagueti. Si te gusta el código ultrafino, poco elegante, detallado, con genéricos y clases internas anónimas, Wicket es lo tuyo. La cantidad de ruido en la línea es muy alta. La base del código se vuelve menos sostenible debido a esto. Esto es especialmente cierto si utiliza la implementación Wicket AJAX defectuosa.
¿Qué marco recomiendas entonces? – greenoldman
Creo que podrían ser shortsights en esto. "Aún no he visto una interfaz de usuario realmente complicada construida en wicket" Sabes que la interfaz de usuario suele ser HTML y Javascript. Podrías tener wicket poblar eso de varias maneras. Todavía soy un principiante para postularme, pero su actitud hacia esto es la de una persona obstinada que pone excusas. Código de espagueti? No en el proyecto de código abierto, parece ser una herramienta muy bien estructurada y muy desacoplada, bien documentada. Si alguien está haciendo el código de spaghetti, eres tú. – HaMMeReD
Uso wicket mucho, y estamos construyendo una interfaz de usuario más compleja con él. con complejo quiero decir que arrastramos y soltamos componentes externos, tenemos elementos de interfaz ricos como listas infinitas de desplazamiento perezoso, gráficos SVG y demás. La curva de aprendizaje de Wicket es bastante empinada, para este tipo de cosas también debes saber cómo funciona. Encuentro Wicket muy elegante, y el árbol de componentes, combinado con los eventos y cómo Wicket encapsula Ajax (actualmente basado en el muy popular framework jQuery), lo convierten en una herramienta muy poderosa para construir UI complejas. – RobAu
Varias respuestas declaran que wicket es no se ha podido crear dinámicamente un árbol de componentes. En serio, creo que ustedes están trabajando con un wicket diferente allí;)
En primer lugar: Wicket se basa en componentes, no es un generador de HTML aleatorio.
En realidad es bastante maldito fácil conseguir un árbol de componentes dinámicos:
desea reemplazar un componente con otro? Usar Component.replaceWith (Component) (bastante útil junto con un MarkupContainer vacío)
¿Necesita una lista de paneles dinámicamente cambiante? Colóquelos en un repetidor.
Hacer que un componente desaparezca? Usar Componente.setVisible()
Y muchas más formas de hacerlo.
Por lo tanto, aquellos que piensan que no se pueden hacer árboles de componentes dinámicos, den algunos ejemplos y me complace hablar de ellos.
(Si realmente necesita para ser aún más flexible puede hacer Wicket marcado de carga de diferentes fuentes. Algo que nunca hice en aras de la construcción de árboles dinámicos pero para ser capaz de recuperar de marcado de una base de datos oa través de la red)
Estoy de acuerdo en que hacer un árbol de componentes dinámicos se puede hacer muy bien, pero es mucho más complicado que con otros marcos. Mantener la identificación del componente diferente y direccionable puede hacer que su diseño sea un desastre si no se hace correctamente. Pero para todas las demás tareas, Wicket es realmente genial. Especialmente cuando tienes una buena base de código de componentes. –
Mi principal problema con Apache Wicket es la falta de un buen material de referencia en línea. He realizado búsquedas exhaustivas en Google para encontrar ejemplos de cosas simples como cuadros de selección, y tuve un momento muy difícil para encontrar algo que me ayudaría no solo a trabajar en una casilla de selección, sino a entender por qué lo hago de esa manera. Además, he buscado mucho y no he encontrado una buena descripción básica de los conceptos clave sobre cómo crear una aplicación Wicket.
En este día y edad, no debería tener que comprar un libro para aprender un marco de programación web. Cada otra pregunta de programación web que he tenido ha sido respondida con algunas búsquedas de Google. En contraste, todavía hay algunas partes de Wicket que no entiendo porque no he encontrado ninguna documentación decente, y hacer preguntas en los foros es limitado porque no tengo lo que creo que es una sólida comprensión de Wicket después de leer solo en línea. documentación.
por qué no, él está aclarando que no hay mucha ayuda en línea. Eso para mí es una desventaja y def a una respuesta relacionada con la pregunta – user373201
Wicket tiene desde hace un par de años una impresionante e integral guía de usuario en línea sin tener que pagar nada, mantenida para todas las versiones recientes: http://wicket.apache.org/learn/# guide –
¿Por qué sería impopular? Como con cada herramienta de desarrollo, es de vital importancia ver y analizar sin emociones. – biziclop