My best experiences have been when the designer has full reign to do
what they need on the CSS/HTML front on a blank canvas-- obviously after
doing wireframes with something like OmniGraffle, Balsamiq or Fireworks.
It helps if they add things like static error messages or a highlighted
tab so the wicket developer gets a sense of when they will probably do
some kind of onComponentTag override to change a class or HTML
attribute, etc. Things that screw up designers IMO are repeaters... it's
hard sometimes for them to know to what degree the layout structure is
created on the server side. For instance I really like the DataBrowser
component where it provides pagination, sorting, zebra stripes, etc, but
the designer just sees a <table wicket:id="sometable"> and thats it.
Obviously they can still style it but the entire structure is hidden
from them. OTOH ListViews and others expose more structure to the
designer which makes them feel closer to home. It's all a tradeoff
really. The biggest rule I give is to just know that any tag with
wicket:id in it means that behavior to some extent is controlled on the
server side so beware. I like this model as a developer since I really
enjoy taking a nice looking static page and making it come alive, as
opposed to my own crappy HTML since I can't design worth beans. I've
also found subtleties where you really want the design up front, one
concrete example was a tabbed pane. In one case the styles were applied
as
<ul>
<li class="selected"><a>one</a></li>
...
</ul>
or another as
<ul>
<li>
<a class="...">one</a>
</li>
These are subtleties that the designer can change on the fly rather
easily, but in wicket it makes a huge difference. I wouldn't want to
force the decision on the designer, this should be their choice.
But this is just my 2 cents....
Jason
Igor Vaynberg wrote:
really? because we have quiet the opposite experience.
we take a wireframe prototype, build it, and have the designer go in
afterwards and pretty it up. with only a couple of hours of
wicket-related training the designers know what to touch and what not
to touch.
-igor
On Tue, Oct 27, 2009 at 9:15 PM, John Armstrong <siber...@siberian.org> wrote:
Its amazing what designers can screw up :)
Design can have a huge impact on code. This peaceful co-existence can
really only occur if you let the designers go first. If you start with
wicket you will either A) tell your designers to go to h*ll daily or
B) spend hours and hours re-factoring to meet their 'whims'.
The separation of html/code is wonderful in wicket and a key reason I
use it and advocate for it but its no substitute for good planning and
a 'design first' mentality.
John-
On Tue, Oct 27, 2009 at 8:18 PM, Dave B <d...@davebolton.net> wrote:
While my Wicket usage is very basic at the stage, one of the
attractive parts is the code and logic is completely separate to the
layout. So your designers can do all the fine tuning and magic
without screwing up your work.
Cheers,
Dave
---------------------------------------------------------------------
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
