----- Ursprüngliche Mail -----
>> >
>> Could you make a quickstart example use case and we could maybe brainstorm
>> about it together, what would actually be the leanest solution?
>>
>
> http://wicketinaction.com/2014/07/build-resources-with-node.js/
> https://github.com/davidB/livereload-jvm
> Someone did this 7 years ago ...
>
I'm a bit short on time currently but what I meant with the fewer redeploys is
not anywhere near this livereload jvm. Why? well, I dont think wicket is used
that much in "small" projects but in rather larger ones.
(I know DHL uses it for the GK-Portal - the solution any smaller customer uses
to print labels and do shipments, thats no way a single server setup or trivial
by the kind of forms they are having there)
Even our own apps require a complete application server with EJB, JNDI etc. -
like payara.
If I would do a small app that has no need for outer things or is in the
microservice area I would go with micronaut or quarkus already.
No, what I mean was something that tapestry had included some time ago (
https://tapestry.apache.org/class-reloading.html ) - I must admit that I never
used it, just read about it some time ago. I didnt think much of this feature
to be honest till I got it for free when using micronaut.
Regarding the quickstart: Its hard to demonstrate what can go wrong with
erratic include positions of javascript when you only have 2 or 3 panels.... as
long as you dont let them insert in a loop in random order each time the page
is generated.
Example: when we started our main brix app we had 10 tiles. Easy to compose
pages and all ok.. now, years later we have over 60 different tiles that can be
composed on the page in realtime by an author - and this complexetiy is it that
can break things fast when you add to the header and cant give it any kind of
positioning or prioritization.
KB
>
>>
>> **
>> Martin
>>
>>
