In practice the wicket frontend development is interrupted by frequent
are very expensive because they effort a new software release followed
by a software rollout. This depends on the fact, that the markup is
delivered with the web application. We separate the markup and the
corresponding java code physically during development, and unites both
parts during runtime. Thus it is possible to release and deploy markup
out of the software life cycle.
The markup-dev environment consists of a unix/windows system (which is
not the developers local system!!!) with a running wicket application
and a mounted WebDav. The WebDav mirrors the subversion/git and is used
as template base path for the wicket application. Within the markup-dev
environment, every modification to the markup is visible after a page
reload. Deployments to the dev system are triggered via a jenkins job.
However, developing markup directly on a customer-frontend and not with
static dummies reduces the time-to-failure to a minimum and requires no
further handover to the software development.
In the past, there was a similar question, perhaps this could help you:
On 02/20/2013 11:14 AM, manuelbarzi wrote:
>>It's a lot of effort to restart the server to test every tweak; also,
>>they're not familiar with the intricacies of our IDE and server. It's a lot
>>more productive for them to have a direct set of files they can test in IE,
>>which is how they've been working all along.