You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Lucio Crusca <lu...@sulweb.org> on 2014/01/29 09:54:45 UTC
Teaming up remotely
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Teaming up remotely
Posted by Steve <sh...@gmail.com>.
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-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: Teaming up remotely
Posted by Nick Pratt <nb...@gmail.com>.
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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Teaming up remotely
Posted by th...@jarnot.de.
Sorry that my attemp to explain misled you thinking, that everything
should be one file.
Trying again...
Taking the case of a panel. I still think working on different aspects
of the file (design and logic) can be a non-conflicting business. From a
desinger's point of view, the markup file, that corresponds to the
panel's Java class, is a well-formed and completely self-contained HTML
page with all resources included to make the panel appear the way it
should and can be statically opened in a browser as it is (not only at
runtime).
Next, the developer adds the <wicket:panel> tag just around the section,
Wicket should apply the logic.
So you as a developer have not necessarily anything to do with what is
changed aside/inside/around the <wicket:panel>. So design and logic
should evolve (virtually) independent from each other.
I admit, this may lead to an amount of redundant markup code in the
repo. But it will be stripped of at runtime and the page wicket delivers
is as compact as it is needed.
Am 29.01.2014 11:47, schrieb Steve:
> I'm not sure how the MarkupParser would handle multiple <wicket:panel>
> tags in one file? How would it identify which instance of
> <wicket:panel> belonged to which java Panel?
>
> On 29/01/14 20:44, Lucio Crusca wrote:
>> In data mercoledì 29 gennaio 2014 10:57:59, thomas@jarnot.de ha
>> scritto:
>>> Is there really a need of splitting up the markup files?
>> Well, I don't know, I mean, I've always split them up because a Wicket
>> webapp
>> is typically a collection of {1 java file, 1 html file by the same
>> name} tuples.
>>
>> However I have to admit that I had already broke that pattern over
>> time and it
>> actually worked (e.g. derived java class but html file only for the
>> base
>> class).
>>
>> Do you think it's feasible to drive that practice to the extreme of
>> having
>> only 1 html file per page and several derived java classes? I'm afraid
>> that
>> model would suffer from a serious impedance mismatch against the OOP
>> pattern,
>> because you can't have one single MyAppPage java base class, but you
>> are
>> forced to create several java classes for each HTML page and use just
>> panels
>> inclusion in each one. I'm not saying that's not possible, but seems
>> to me
>> it's not very OOP-ish. Am i wrong?
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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: Teaming up remotely
Posted by Steve <sh...@gmail.com>.
I'm not sure how the MarkupParser would handle multiple <wicket:panel>
tags in one file? How would it identify which instance of
<wicket:panel> belonged to which java Panel?
On 29/01/14 20:44, Lucio Crusca wrote:
> In data mercoledì 29 gennaio 2014 10:57:59, thomas@jarnot.de ha scritto:
>> Is there really a need of splitting up the markup files?
> Well, I don't know, I mean, I've always split them up because a Wicket webapp
> is typically a collection of {1 java file, 1 html file by the same name} tuples.
>
> However I have to admit that I had already broke that pattern over time and it
> actually worked (e.g. derived java class but html file only for the base
> class).
>
> Do you think it's feasible to drive that practice to the extreme of having
> only 1 html file per page and several derived java classes? I'm afraid that
> model would suffer from a serious impedance mismatch against the OOP pattern,
> because you can't have one single MyAppPage java base class, but you are
> forced to create several java classes for each HTML page and use just panels
> inclusion in each one. I'm not saying that's not possible, but seems to me
> it's not very OOP-ish. Am i wrong?
>
>
>
> ---------------------------------------------------------------------
> 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: Teaming up remotely
Posted by Lucio Crusca <lu...@sulweb.org>.
In data mercoledì 29 gennaio 2014 10:57:59, thomas@jarnot.de ha scritto:
> Is there really a need of splitting up the markup files?
Well, I don't know, I mean, I've always split them up because a Wicket webapp
is typically a collection of {1 java file, 1 html file by the same name} tuples.
However I have to admit that I had already broke that pattern over time and it
actually worked (e.g. derived java class but html file only for the base
class).
Do you think it's feasible to drive that practice to the extreme of having
only 1 html file per page and several derived java classes? I'm afraid that
model would suffer from a serious impedance mismatch against the OOP pattern,
because you can't have one single MyAppPage java base class, but you are
forced to create several java classes for each HTML page and use just panels
inclusion in each one. I'm not saying that's not possible, but seems to me
it's not very OOP-ish. Am i wrong?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Teaming up remotely
Posted by th...@jarnot.de.
Am 29.01.2014 10:22, schrieb Lucio Crusca:
> In data mercoledì 29 gennaio 2014 19:06:09, Steve ha scritto:
>> The difficulty I would think is when you start to split up html files
>> to
>> seperate sections into their own panels. If the designer only has a
>> view of the markup it may not be obvious to them where the subsection
>> of
>> the html has gone. Sure you can explain the concept of Panels to them
>> but to be certain that a certain wicked:id equates to particular panel
>> type and find the right markup file you need to look at the java code.
>
> The problem is actually even worse than that: the moment I start
> splitting up
> HTML files, their web design suite stops recognizing them (I think this
> is
> common to every web design suite out there, no matter which one).
> So they are somewhat forced to work without my revision control system,
> because they just can't use the files anymore after my edits (unless
> someone
> suggests a better solution).
>
> Maybe I should impose a rigid deadline on HTML modifications, after
> which they
> must ask me to edit anything? E.g. they must work on HTML before giving
> it to
> me. After that they can work only on CSS and ask me to edit class="..."
> attributes as needed. Is this a reasonable solution? Is that even
> acceptable
> for designers?
Just one thought. Wouldn't it be possible with Wicket, to leave all
markup files as entirely "standalone" working (with all resources
included) and just add your wicket:tags to the sections Wicket should
work on?
Is there really a need of splitting up the markup files?
Eg. if you want to define a Wicket panel, just add your <wicket:panel>
ignoring all the other HTML stuff, where the designer builds the panel
ignoring all the Wicket stuff (?)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Teaming up remotely
Posted by Lucio Crusca <lu...@sulweb.org>.
In data mercoledì 29 gennaio 2014 19:06:09, Steve ha scritto:
> The difficulty I would think is when you start to split up html files to
> seperate sections into their own panels. If the designer only has a
> view of the markup it may not be obvious to them where the subsection of
> the html has gone. Sure you can explain the concept of Panels to them
> but to be certain that a certain wicked:id equates to particular panel
> type and find the right markup file you need to look at the java code.
The problem is actually even worse than that: the moment I start splitting up
HTML files, their web design suite stops recognizing them (I think this is
common to every web design suite out there, no matter which one).
So they are somewhat forced to work without my revision control system,
because they just can't use the files anymore after my edits (unless someone
suggests a better solution).
Maybe I should impose a rigid deadline on HTML modifications, after which they
must ask me to edit anything? E.g. they must work on HTML before giving it to
me. After that they can work only on CSS and ask me to edit class="..."
attributes as needed. Is this a reasonable solution? Is that even acceptable
for designers?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Teaming up remotely
Posted by Steve <sh...@gmail.com>.
I would think that using common version control and just telling them to
ignore any wicket tags or wicket attributes they see after you've
modified the markup. That part is not too hard for them to get their
head around.
The difficulty I would think is when you start to split up html files to
seperate sections into their own panels. If the designer only has a
view of the markup it may not be obvious to them where the subsection of
the html has gone. Sure you can explain the concept of Panels to them
but to be certain that a certain wicked:id equates to particular panel
type and find the right markup file you need to look at the java code.
I'm also very interested in answers to this problem.
On 29/01/14 18:54, Lucio Crusca 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-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