Na, it all depends on your process and the nature of the project.
Changes never go live without testing, but if you have the constraint
given by your customer that html changes, if they do not break the
wicket hierarchy, must be deployable without a redeployment of the web
application, you have to live with that. That does not mean these
changes can't be tested, and no matter where you pull the html files
from, if you break them, you break them.
Also, 90% of html changes (in our case) are pure content changes like
correct some spelling and phrases, and we do not want to redeploy for
such things.
Thomas Mäder wrote:
Yeah, but such a policy is complete crap if you'll excuse my french.
You can break a wicket applicaion as easily by changing the html files
as by changing code. A html change IS a code change.
Thomas
I hope this doesn't mean it is considered a "hack"...In some projects of
mine I have the demand to pull html resources from the file system in order
to allow editing them without redeployment (and having them in a different
place so the editor has no access to the deploy directories).
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
