We found the simplest way to handle this situation was to let the HTML/CSS folks design and style the page in pure HTML, no Wicket tags, with sample data they made up. They then committed their changes into the shared VCS. The designers Ive worked with in the past just didn't (or didn't want to) understand the Wicket tags and their structure. We spent way too much time fixing broken markup because the designers thought it was ok to or they didnt realize they were moving tags around. The designers also dont run Java unit tests so you dont catch page rendering errors until the markup changes hit the Java devs desktops. After several attempts at explaining in what scenarios Wicket tags couldnt be moved we gave up and had them run a page or two in front of the Java devs. Converting plain HTML with sample data into a Wicket page was far simpler and easier for the Java/Wicket programmers than the other way around.
Your mileage may vary ;-) On Wed, Jan 29, 2014 at 3:54 AM, Lucio Crusca <lu...@sulweb.org> wrote: > Hello everybody, > > today I need to begin a project where, for the 1st time in my life, the > team > members won't work close to each other, and, again for the 1st time, I'm > going > to use Wicket in such a project. I'm in charge of writing all the code > (mostly > Java with Wicket being the framework of choice for the UI). The rest of the > team is located about 700km from me and they're going to take care of HTML > and > CSS development. > > Are there any recognized best practices I should suggest them in HTML/CSS > production in order to avoid problems on my side? E.g. is it usual asking > for > HTML files split into "common header for all pages", "common footer", > "common > whatever" and "page specific content" apart? Or is it more common to split > them > myself? > > How should we manage revisions? I could arrange for a bazaar server or the > like, but how are those tools understood by web designers? Or should I take > their files and manage conflicts and commits on my side without even > telling > them? But, then again, revision control works best on a line by line based > comparison, and with Wicket I suspect conflicts will be the norm. E.g. > suppose > they change anything on their side in a HTML file that I already edited > with > wicket tags and committed to bzr: > > --- Their HTML file > old: <span class="myclass"> > new: <span class="myclass2"> > > -- My HTML file > committed: <span class="myclass" wicket:id="myid"> > new: <span class="myclass2"> > > --> conflict (because they aren't aware of my edits and they can't be, > unless > they split HTML files in header, footer, whatever and use bzr themselves). > > I'm puzzled, that has to be a so common problem I hardly believe there's no > standardized solution. Please advice. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
