In this case, look into using properties files and localization. You can edit the properties files, and (almost) no worries about breaking anything.
-- Jeremy Thomerson http://www.wickettraining.com On Mon, Jul 21, 2008 at 10:15 AM, Martin Voigt <[EMAIL PROTECTED]> wrote: > 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] > >
