I think the lesson here is that designers will never be programmers and programmers will never be designers but each needs to have a little of the other or the end result will be functionaly useless static web pages (in the case of designers) or functional pages that look like a dogs breakfast.
Surely this issue comes up in other web frameworks. PHP for example. That would be even more broken from a designer perspective. I can't imagine trying to import a php script into dreamweaver or any other design tool? If dreamweaver can't deal with componentized markup sets something is seriously messed up. On 29/01/14 23:09, Nick Pratt wrote: > 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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
