Re: The best way for designers and Wicket developers to collaborate
i apply the same practice as igor. it works great for both sides, dev and des. once des already has the html model, dev creates the first integration to the object-tree, providing feedback to des, so dom-tree follows the same coherence (in case needed to correct some parts), and following are just test-error-correct cycles done by des at local environments running the app. . On Tue, Feb 19, 2013 at 11:18 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: they do not need to restart their local server to see changes. wicket automatically reloads html/css/js/etc. only changes to java files that cannot be hot-swapped require a server restart. but your designers wont be changing java files will they? -igor On Tue, Feb 19, 2013 at 12:44 PM, eugenebalt eugeneb...@yahoo.com wrote: Our designers say they don't want to run on the server. It's a lot of effort to restart the server to test every tweak; also, they're not familiar with the intricacies of our IDE and server. It's a lot more productive for them to have a direct set of files they can test in IE, which is how they've been working all along. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/The-best-way-for-designers-and-Wicket-developers-to-collaborate-tp4656560p4656570.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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: The best way for designers and Wicket developers to collaborate
Hej Eugene, In practice the wicket frontend development is interrupted by frequent small changes to the HTML, Javascript or CSS. Changes to these markups are very expensive because they effort a new software release followed by a software rollout. This depends on the fact, that the markup is delivered with the web application. We separate the markup and the corresponding java code physically during development, and unites both parts during runtime. Thus it is possible to release and deploy markup out of the software life cycle. The markup-dev environment consists of a unix/windows system (which is not the developers local system!!!) with a running wicket application and a mounted WebDav. The WebDav mirrors the subversion/git and is used as template base path for the wicket application. Within the markup-dev environment, every modification to the markup is visible after a page reload. Deployments to the dev system are triggered via a jenkins job. However, developing markup directly on a customer-frontend and not with static dummies reduces the time-to-failure to a minimum and requires no further handover to the software development. In the past, there was a similar question, perhaps this could help you: http://apache-wicket.1842946.n4.nabble.com/Syncing-files-with-designers-td4654450.html best regards, Jan On 02/20/2013 11:14 AM, manuelbarzi wrote: It's a lot of effort to restart the server to test every tweak; also, they're not familiar with the intricacies of our IDE and server. It's a lot more productive for them to have a direct set of files they can test in IE, which is how they've been working all along.
The best way for designers and Wicket developers to collaborate
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
Re: The best way for designers and Wicket developers to collaborate
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.comwrote: 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/
