Hi, I'm a happy user of https://github.com/42Lines/wicket-source with a small improvement from https://github.com/cleiter/wicketsource-contextmenu (provides an item in the context menu instead of an entry in the Dev Tools -> Markup -> Style -> ...)
Maybe this can be extended to look for the html comments generated by setOutputMarkupContainerClassName() and open the respective .html for me. @Jenny, @Christoph: are you interested to extend Wicket-Source ? On Tue, Feb 19, 2013 at 8:13 PM, Igor Vaynberg <igor.vaynb...@gmail.com>wrote: > this is how we work, may or may not work for you: > > our designers run the app on their machines. we have a simple bash > scripts that runs a start class similar to the one shipped with the > quickstart. this is the same start class developers run from their > IDE. > > when in dev mode we enable this setting: > getDebugSettings().setOutputMarkupContainerClassName(true); > > which, in the comments of the page's html defines where html comes > from - panels, borders, etc. > this allows our designers to start the app, make a change, press > refresh, see how it renders. make another change, refresh, etc. > > this allows them to work in the same exact source tree as the devs, > which makes life a lot simpler for everyone involved. > > when a dev breaks up html into panels this change is pulled to the > designers when they update their source tree. and when they need to > tweak some html they can use the comments to locate the file where it > now lives. > > -igor > > On Tue, Feb 19, 2013 at 8:20 AM, eugenebalt <eugeneb...@yahoo.com> wrote: > > We have a Web design team and a Java development team on our project. > We're > > using Wicket for our pages. > > > > I know Wicket was designed to make it easy for designers and developers > to > > work together, but we're actually finding the opposite -- it's difficult > to > > communicate changes back and forth. We're finding that the developers > > increasingly have their own code tree, and the designers their own. > > > > As a result, for every major change, someone has to "translate" the > > designer's change into the actual HTML that the developers are using, > which > > is not the same. > > > > The developers sometimes break pages into subpages/Panels which doesn't > get > > communicated back to the designers, who are still working with their own > > complete pages. Should designers be actually involved in Panel > > restructuring? If so, how can they work with sub-pages? Should they use > an > > Include tag? If they need to demo or test something, should they actually > > run the real app on the server, rather than work with their own set of > HTML > > files? Should they check their files into the "real" folders, or their > > "sandbox" template folders? > > > > The main issue has been Panels, but there are also some other tweaks the > > developers are making to "make it work" while the designers aren't aware > and > > are working in their own sandbox. > > > > Just wondering, what's the best practice, the way things are supposed to > > work in Wicket? > > > > > > > > -- > > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/The-best-way-for-designers-and-Wicket-developers-to-collaborate-tp4656560.html > > Sent from the Users forum mailing list archive at Nabble.com. > > > > --------------------------------------------------------------------- > > 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 > > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com <http://jweekend.com/>
