You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by eugenebalt <eu...@yahoo.com> on 2013/02/19 17:20:09 UTC
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: The best way for designers and Wicket developers to collaborate
Posted by Jan Riehn <Ja...@1und1.de>.
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.
Re: The best way for designers and Wicket developers to collaborate
Posted by manuelbarzi <ma...@gmail.com>.
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 <ig...@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 <eu...@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: The best way for designers and Wicket developers to collaborate
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <eu...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: The best way for designers and Wicket developers to collaborate
Posted by eugenebalt <eu...@yahoo.com>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: The best way for designers and Wicket developers to collaborate
Posted by Martin Grigorov <mg...@apache.org>.
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 <ig...@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 <eu...@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-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com <http://jweekend.com/>
Re: The best way for designers and Wicket developers to collaborate
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <eu...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org