Re: Rare Style disabling and Ajax Panel Replacement Question
Hi again,
I have come to the following conclusion so far:
-Use detailed CSS specifications is the way to avoid #id clashing.
-We will also keep some automatic disabling of CSSs that are no longer in
use... we will try not to rely on this mechanism though, and still use what
i said in the line above. The disabling of not used CSS will not hurt
anyway, and perhaps avoid some unexpected clashing, so why not keeping it
too, as a backup mechanism. We could discard it later too... we will see,
the main solution is the full detailed css as said above.
Thanks all for the help,
German
2008/6/18 Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED]:
German Morales wrote:
Hi,
I'm here with Francisco, discussing this subject.
The main difference between the approach is the amount of stuff to write
in
CSS: With the detailed naming of styles (.DetailPanel-A fieldPersonName)
you have to write a lot more in the CSS. That is, for each field in
DetailPanelA, you have to go with .DetailPanelA #fieldWhatever1,
.DetailPanelA #fieldWhatever2, .DetailPanelA #fieldWhateverN instead
of
the shorter versions #fieldWhatever1, #fieldWhatever2,
#fieldWhateverN. Therefore, the shorter versions should be, in theory,
easier to write and maintain.
Yeah I see the point. But could'nt at least try to hit the fields by
selectors: .DetailPanelA fieldsettextarea {color:black}.
But on the otherhand you can have one stylesheet that fits all, that could
be handy if you ever want todo skinning, by css only(which actually can do
alot see css zen garden).
On the other hand, producing this #fieldWhatever1 allows the conflict
between fieldWhatever1 in DetailPanelA and DetailPanelB, which means that
we
must introduce some trick to avoid it.
Yup popular called clashing.
Someone here has found this
disabling of CSSs.
I think this approach are okay doing simple static pages. But once you
mixin ajax trouble begin to rise, and what happens if you have two of the
panels clashing in the same page who should win?
It is nice because it could be handled in a somehow
generic way (allowing producers of DetailPanelN to be un-aware of all this
complication), but also we must consider that it adds some extra
complexity.
Yes it does, but on the other hand, it lessen the burden on the css
designer, so it's a tradoff.
I'm not completely in favor of one or another approach. The detailed style
version is in fact our current solution, and it has the benefit of being
simple. But we are trying also the CSS disabling because it has some
not-that-bad benefits (CSS simplification, and perhaps the possibility of
forget about the CSS conflicts altogether).
That's why we would like to hear opinions, and perhaps even more
importantly, hear about different approaches, or about hidden traps in our
current attempts.
Understandable.. I too are looking forward to hear different opinions:)
Thanks in advance,
German
2008/6/18 Francisco Diaz Trepat - gmail [EMAIL PROTECTED]:
That was my approach exactly but I lack the arguments to convince them.
I
managed to send this mail and see if I'll get better ones :-), or at
least
community consensus.
Maybe if I started a thread I could get some other experiences and
opinions
on the matter.
Thanks Nino.
f(t)
On Wed, Jun 18, 2008 at 1:49 PM, Nino Saturnino Martinez Vazquez Wael
[EMAIL PROTECTED] wrote:
Hi Francisco
I'd much rather go with more detailed naming of your styles, instead of
doing complex stuff with dom? Like
.DetailPanel-A-fieldPersonName{
position:absolute;
left:50px;
top: 50px;
}
Or maybe the problem are more complex than this..?
Francisco Diaz Trepat - gmail wrote:
Hi all, its been a while.
Finally we started migrating other applications from swing to wicket
thanks
to all your help provided last year.
Having said that, I have some colleagues that are looking to develop a
way
to disable style sheets that are loaded as part of panel replacement.
Here is the Scenario:
we have a classic web structure: left menu, top header, and center to
right
Detail area.
The detail area is replaced by wicket-ajax functions and each panel
usually
has an overriden renderHead with code similar to this one:
cHtmlHeaderContainer.getHeaderResponse().renderCSSReference(new
ResourceReference(
this.getClass(),
this.getClass().getSimpleName() + .css,
getLocale(),
getStyle()));
Because on more than one detail panel they use a same field but with
different position (lets say person.name) they are experiencing some
style
collision.
Lets say that DetailPanel-A and DetailPanel-B show a text-field with
the
person.name and displays them in different locations. Surely now we
have
the
same style name (by class (.) or by id (#) in some versions).
So we have two .css files.
*DetailPanel-A.css* with:
.fieldPersonName{
position:
Rare Style disabling and Ajax Panel Replacement Question
Hi all, its been a while.
Finally we started migrating other applications from swing to wicket thanks
to all your help provided last year.
Having said that, I have some colleagues that are looking to develop a way
to disable style sheets that are loaded as part of panel replacement.
Here is the Scenario:
we have a classic web structure: left menu, top header, and center to right
Detail area.
The detail area is replaced by wicket-ajax functions and each panel usually
has an overriden renderHead with code similar to this one:
cHtmlHeaderContainer.getHeaderResponse().renderCSSReference(new
ResourceReference(
this.getClass(),
this.getClass().getSimpleName() + .css,
getLocale(),
getStyle()));
Because on more than one detail panel they use a same field but with
different position (lets say person.name) they are experiencing some style
collision.
Lets say that DetailPanel-A and DetailPanel-B show a text-field with the
person.name and displays them in different locations. Surely now we have the
same style name (by class (.) or by id (#) in some versions).
So we have two .css files.
*DetailPanel-A.css* with:
.fieldPersonName{
position:absolute;
left:50px;
top: 50px;
}
*DetailPanel-B.css* with:
.fieldPersonName{
background-color: yellow;
}
Now we navigate from DetailPanel-A to DetailPanel-B or viceversa. And
ofcourse the problem is that on the DetailPanel-B my field gets moved if I
don't specify otherwise. And some times although we specify it, it will
depend on order and other matters as well. This are the rules of the game
and web development has been fine with them.
But my colleages are proposing a disabling of previously loaded styles,
living DOM with disabled style objects.
I haven't heard of that kind of practice. And IMHO instead of building a
complex javascript function to disable the style object (link
rel=stylesheet type=text/css charset=utf-8 media=all
href=someWicketResourceUrl) on the pages DOM object, we could share this
with wicket community and find out if we are on the right path. I don't feel
we are in it.
Could some please comment on this, or ask anything you need to comment on
this desing issue.
Thanks,
f(t)
Re: Rare Style disabling and Ajax Panel Replacement Question
Hi Francisco
I'd much rather go with more detailed naming of your styles, instead of
doing complex stuff with dom? Like
.DetailPanel-A-fieldPersonName{
position:absolute;
left:50px;
top: 50px;
}
Or maybe the problem are more complex than this..?
Francisco Diaz Trepat - gmail wrote:
Hi all, its been a while.
Finally we started migrating other applications from swing to wicket thanks
to all your help provided last year.
Having said that, I have some colleagues that are looking to develop a way
to disable style sheets that are loaded as part of panel replacement.
Here is the Scenario:
we have a classic web structure: left menu, top header, and center to right
Detail area.
The detail area is replaced by wicket-ajax functions and each panel usually
has an overriden renderHead with code similar to this one:
cHtmlHeaderContainer.getHeaderResponse().renderCSSReference(new
ResourceReference(
this.getClass(),
this.getClass().getSimpleName() + .css,
getLocale(),
getStyle()));
Because on more than one detail panel they use a same field but with
different position (lets say person.name) they are experiencing some style
collision.
Lets say that DetailPanel-A and DetailPanel-B show a text-field with the
person.name and displays them in different locations. Surely now we have the
same style name (by class (.) or by id (#) in some versions).
So we have two .css files.
*DetailPanel-A.css* with:
.fieldPersonName{
position:absolute;
left:50px;
top: 50px;
}
*DetailPanel-B.css* with:
.fieldPersonName{
background-color: yellow;
}
Now we navigate from DetailPanel-A to DetailPanel-B or viceversa. And
ofcourse the problem is that on the DetailPanel-B my field gets moved if I
don't specify otherwise. And some times although we specify it, it will
depend on order and other matters as well. This are the rules of the game
and web development has been fine with them.
But my colleages are proposing a disabling of previously loaded styles,
living DOM with disabled style objects.
I haven't heard of that kind of practice. And IMHO instead of building a
complex javascript function to disable the style object (link
rel=stylesheet type=text/css charset=utf-8 media=all
href=someWicketResourceUrl) on the pages DOM object, we could share this
with wicket community and find out if we are on the right path. I don't feel
we are in it.
Could some please comment on this, or ask anything you need to comment on
this desing issue.
Thanks,
f(t)
--
-Wicket for love
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rare Style disabling and Ajax Panel Replacement Question
That was my approach exactly but I lack the arguments to convince them. I
managed to send this mail and see if I'll get better ones :-), or at least
community consensus.
Maybe if I started a thread I could get some other experiences and opinions
on the matter.
Thanks Nino.
f(t)
On Wed, Jun 18, 2008 at 1:49 PM, Nino Saturnino Martinez Vazquez Wael
[EMAIL PROTECTED] wrote:
Hi Francisco
I'd much rather go with more detailed naming of your styles, instead of
doing complex stuff with dom? Like
.DetailPanel-A-fieldPersonName{
position:absolute;
left:50px;
top: 50px;
}
Or maybe the problem are more complex than this..?
Francisco Diaz Trepat - gmail wrote:
Hi all, its been a while.
Finally we started migrating other applications from swing to wicket
thanks
to all your help provided last year.
Having said that, I have some colleagues that are looking to develop a way
to disable style sheets that are loaded as part of panel replacement.
Here is the Scenario:
we have a classic web structure: left menu, top header, and center to
right
Detail area.
The detail area is replaced by wicket-ajax functions and each panel
usually
has an overriden renderHead with code similar to this one:
cHtmlHeaderContainer.getHeaderResponse().renderCSSReference(new
ResourceReference(
this.getClass(),
this.getClass().getSimpleName() + .css,
getLocale(),
getStyle()));
Because on more than one detail panel they use a same field but with
different position (lets say person.name) they are experiencing some
style
collision.
Lets say that DetailPanel-A and DetailPanel-B show a text-field with the
person.name and displays them in different locations. Surely now we have
the
same style name (by class (.) or by id (#) in some versions).
So we have two .css files.
*DetailPanel-A.css* with:
.fieldPersonName{
position:absolute;
left:50px;
top: 50px;
}
*DetailPanel-B.css* with:
.fieldPersonName{
background-color: yellow;
}
Now we navigate from DetailPanel-A to DetailPanel-B or viceversa. And
ofcourse the problem is that on the DetailPanel-B my field gets moved if
I
don't specify otherwise. And some times although we specify it, it will
depend on order and other matters as well. This are the rules of the game
and web development has been fine with them.
But my colleages are proposing a disabling of previously loaded styles,
living DOM with disabled style objects.
I haven't heard of that kind of practice. And IMHO instead of building a
complex javascript function to disable the style object (link
rel=stylesheet type=text/css charset=utf-8 media=all
href=someWicketResourceUrl) on the pages DOM object, we could share
this
with wicket community and find out if we are on the right path. I don't
feel
we are in it.
Could some please comment on this, or ask anything you need to comment on
this desing issue.
Thanks,
f(t)
--
-Wicket for love
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rare Style disabling and Ajax Panel Replacement Question
Hi,
I'm here with Francisco, discussing this subject.
The main difference between the approach is the amount of stuff to write in
CSS: With the detailed naming of styles (.DetailPanel-A fieldPersonName)
you have to write a lot more in the CSS. That is, for each field in
DetailPanelA, you have to go with .DetailPanelA #fieldWhatever1,
.DetailPanelA #fieldWhatever2, .DetailPanelA #fieldWhateverN instead of
the shorter versions #fieldWhatever1, #fieldWhatever2,
#fieldWhateverN. Therefore, the shorter versions should be, in theory,
easier to write and maintain.
On the other hand, producing this #fieldWhatever1 allows the conflict
between fieldWhatever1 in DetailPanelA and DetailPanelB, which means that we
must introduce some trick to avoid it. Someone here has found this
disabling of CSSs. It is nice because it could be handled in a somehow
generic way (allowing producers of DetailPanelN to be un-aware of all this
complication), but also we must consider that it adds some extra complexity.
I'm not completely in favor of one or another approach. The detailed style
version is in fact our current solution, and it has the benefit of being
simple. But we are trying also the CSS disabling because it has some
not-that-bad benefits (CSS simplification, and perhaps the possibility of
forget about the CSS conflicts altogether).
That's why we would like to hear opinions, and perhaps even more
importantly, hear about different approaches, or about hidden traps in our
current attempts.
Thanks in advance,
German
2008/6/18 Francisco Diaz Trepat - gmail [EMAIL PROTECTED]:
That was my approach exactly but I lack the arguments to convince them. I
managed to send this mail and see if I'll get better ones :-), or at least
community consensus.
Maybe if I started a thread I could get some other experiences and opinions
on the matter.
Thanks Nino.
f(t)
On Wed, Jun 18, 2008 at 1:49 PM, Nino Saturnino Martinez Vazquez Wael
[EMAIL PROTECTED] wrote:
Hi Francisco
I'd much rather go with more detailed naming of your styles, instead of
doing complex stuff with dom? Like
.DetailPanel-A-fieldPersonName{
position:absolute;
left:50px;
top: 50px;
}
Or maybe the problem are more complex than this..?
Francisco Diaz Trepat - gmail wrote:
Hi all, its been a while.
Finally we started migrating other applications from swing to wicket
thanks
to all your help provided last year.
Having said that, I have some colleagues that are looking to develop a
way
to disable style sheets that are loaded as part of panel replacement.
Here is the Scenario:
we have a classic web structure: left menu, top header, and center to
right
Detail area.
The detail area is replaced by wicket-ajax functions and each panel
usually
has an overriden renderHead with code similar to this one:
cHtmlHeaderContainer.getHeaderResponse().renderCSSReference(new
ResourceReference(
this.getClass(),
this.getClass().getSimpleName() + .css,
getLocale(),
getStyle()));
Because on more than one detail panel they use a same field but with
different position (lets say person.name) they are experiencing some
style
collision.
Lets say that DetailPanel-A and DetailPanel-B show a text-field with the
person.name and displays them in different locations. Surely now we
have
the
same style name (by class (.) or by id (#) in some versions).
So we have two .css files.
*DetailPanel-A.css* with:
.fieldPersonName{
position:absolute;
left:50px;
top: 50px;
}
*DetailPanel-B.css* with:
.fieldPersonName{
background-color: yellow;
}
Now we navigate from DetailPanel-A to DetailPanel-B or viceversa. And
ofcourse the problem is that on the DetailPanel-B my field gets moved
if
I
don't specify otherwise. And some times although we specify it, it will
depend on order and other matters as well. This are the rules of the
game
and web development has been fine with them.
But my colleages are proposing a disabling of previously loaded styles,
living DOM with disabled style objects.
I haven't heard of that kind of practice. And IMHO instead of building a
complex javascript function to disable the style object (link
rel=stylesheet type=text/css charset=utf-8 media=all
href=someWicketResourceUrl) on the pages DOM object, we could share
this
with wicket community and find out if we are on the right path. I don't
feel
we are in it.
Could some please comment on this, or ask anything you need to comment
on
this desing issue.
Thanks,
f(t)
--
-Wicket for love
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
Re: Rare Style disabling and Ajax Panel Replacement Question
what happens if you ever need to use both panels on the page
simultaneously. personally i would stick with the .panela selector
stylesheets
-igor
On Wed, Jun 18, 2008 at 11:28 AM, German Morales
[EMAIL PROTECTED] wrote:
Hi,
I'm here with Francisco, discussing this subject.
The main difference between the approach is the amount of stuff to write in
CSS: With the detailed naming of styles (.DetailPanel-A fieldPersonName)
you have to write a lot more in the CSS. That is, for each field in
DetailPanelA, you have to go with .DetailPanelA #fieldWhatever1,
.DetailPanelA #fieldWhatever2, .DetailPanelA #fieldWhateverN instead of
the shorter versions #fieldWhatever1, #fieldWhatever2,
#fieldWhateverN. Therefore, the shorter versions should be, in theory,
easier to write and maintain.
On the other hand, producing this #fieldWhatever1 allows the conflict
between fieldWhatever1 in DetailPanelA and DetailPanelB, which means that we
must introduce some trick to avoid it. Someone here has found this
disabling of CSSs. It is nice because it could be handled in a somehow
generic way (allowing producers of DetailPanelN to be un-aware of all this
complication), but also we must consider that it adds some extra complexity.
I'm not completely in favor of one or another approach. The detailed style
version is in fact our current solution, and it has the benefit of being
simple. But we are trying also the CSS disabling because it has some
not-that-bad benefits (CSS simplification, and perhaps the possibility of
forget about the CSS conflicts altogether).
That's why we would like to hear opinions, and perhaps even more
importantly, hear about different approaches, or about hidden traps in our
current attempts.
Thanks in advance,
German
2008/6/18 Francisco Diaz Trepat - gmail [EMAIL PROTECTED]:
That was my approach exactly but I lack the arguments to convince them. I
managed to send this mail and see if I'll get better ones :-), or at least
community consensus.
Maybe if I started a thread I could get some other experiences and opinions
on the matter.
Thanks Nino.
f(t)
On Wed, Jun 18, 2008 at 1:49 PM, Nino Saturnino Martinez Vazquez Wael
[EMAIL PROTECTED] wrote:
Hi Francisco
I'd much rather go with more detailed naming of your styles, instead of
doing complex stuff with dom? Like
.DetailPanel-A-fieldPersonName{
position:absolute;
left:50px;
top: 50px;
}
Or maybe the problem are more complex than this..?
Francisco Diaz Trepat - gmail wrote:
Hi all, its been a while.
Finally we started migrating other applications from swing to wicket
thanks
to all your help provided last year.
Having said that, I have some colleagues that are looking to develop a
way
to disable style sheets that are loaded as part of panel replacement.
Here is the Scenario:
we have a classic web structure: left menu, top header, and center to
right
Detail area.
The detail area is replaced by wicket-ajax functions and each panel
usually
has an overriden renderHead with code similar to this one:
cHtmlHeaderContainer.getHeaderResponse().renderCSSReference(new
ResourceReference(
this.getClass(),
this.getClass().getSimpleName() + .css,
getLocale(),
getStyle()));
Because on more than one detail panel they use a same field but with
different position (lets say person.name) they are experiencing some
style
collision.
Lets say that DetailPanel-A and DetailPanel-B show a text-field with the
person.name and displays them in different locations. Surely now we
have
the
same style name (by class (.) or by id (#) in some versions).
So we have two .css files.
*DetailPanel-A.css* with:
.fieldPersonName{
position:absolute;
left:50px;
top: 50px;
}
*DetailPanel-B.css* with:
.fieldPersonName{
background-color: yellow;
}
Now we navigate from DetailPanel-A to DetailPanel-B or viceversa. And
ofcourse the problem is that on the DetailPanel-B my field gets moved
if
I
don't specify otherwise. And some times although we specify it, it will
depend on order and other matters as well. This are the rules of the
game
and web development has been fine with them.
But my colleages are proposing a disabling of previously loaded styles,
living DOM with disabled style objects.
I haven't heard of that kind of practice. And IMHO instead of building a
complex javascript function to disable the style object (link
rel=stylesheet type=text/css charset=utf-8 media=all
href=someWicketResourceUrl) on the pages DOM object, we could share
this
with wicket community and find out if we are on the right path. I don't
feel
we are in it.
Could some please comment on this, or ask anything you need to comment
on
this desing issue.
Thanks,
f(t)
--
-Wicket
Re: Rare Style disabling and Ajax Panel Replacement Question
Igor,
Yes, in such case the only solution is the full detailed style info.
In our case, however, we talk about panels that always replace each other.
Or at least that is the common case. Perhaps finding cases that does not
follow this rule helps to solve this dilemma.
Thanks for the new point of view,
German
2008/6/18 Igor Vaynberg [EMAIL PROTECTED]:
what happens if you ever need to use both panels on the page
simultaneously. personally i would stick with the .panela selector
stylesheets
-igor
On Wed, Jun 18, 2008 at 11:28 AM, German Morales
[EMAIL PROTECTED] wrote:
Hi,
I'm here with Francisco, discussing this subject.
The main difference between the approach is the amount of stuff to write
in
CSS: With the detailed naming of styles (.DetailPanel-A
fieldPersonName)
you have to write a lot more in the CSS. That is, for each field in
DetailPanelA, you have to go with .DetailPanelA #fieldWhatever1,
.DetailPanelA #fieldWhatever2, .DetailPanelA #fieldWhateverN instead
of
the shorter versions #fieldWhatever1, #fieldWhatever2,
#fieldWhateverN. Therefore, the shorter versions should be, in theory,
easier to write and maintain.
On the other hand, producing this #fieldWhatever1 allows the conflict
between fieldWhatever1 in DetailPanelA and DetailPanelB, which means that
we
must introduce some trick to avoid it. Someone here has found this
disabling of CSSs. It is nice because it could be handled in a somehow
generic way (allowing producers of DetailPanelN to be un-aware of all
this
complication), but also we must consider that it adds some extra
complexity.
I'm not completely in favor of one or another approach. The detailed
style
version is in fact our current solution, and it has the benefit of being
simple. But we are trying also the CSS disabling because it has some
not-that-bad benefits (CSS simplification, and perhaps the possibility of
forget about the CSS conflicts altogether).
That's why we would like to hear opinions, and perhaps even more
importantly, hear about different approaches, or about hidden traps in
our
current attempts.
Thanks in advance,
German
2008/6/18 Francisco Diaz Trepat - gmail [EMAIL PROTECTED]
:
That was my approach exactly but I lack the arguments to convince
them. I
managed to send this mail and see if I'll get better ones :-), or at
least
community consensus.
Maybe if I started a thread I could get some other experiences and
opinions
on the matter.
Thanks Nino.
f(t)
On Wed, Jun 18, 2008 at 1:49 PM, Nino Saturnino Martinez Vazquez Wael
[EMAIL PROTECTED] wrote:
Hi Francisco
I'd much rather go with more detailed naming of your styles, instead
of
doing complex stuff with dom? Like
.DetailPanel-A-fieldPersonName{
position:absolute;
left:50px;
top: 50px;
}
Or maybe the problem are more complex than this..?
Francisco Diaz Trepat - gmail wrote:
Hi all, its been a while.
Finally we started migrating other applications from swing to wicket
thanks
to all your help provided last year.
Having said that, I have some colleagues that are looking to develop
a
way
to disable style sheets that are loaded as part of panel replacement.
Here is the Scenario:
we have a classic web structure: left menu, top header, and center to
right
Detail area.
The detail area is replaced by wicket-ajax functions and each panel
usually
has an overriden renderHead with code similar to this one:
cHtmlHeaderContainer.getHeaderResponse().renderCSSReference(new
ResourceReference(
this.getClass(),
this.getClass().getSimpleName() + .css,
getLocale(),
getStyle()));
Because on more than one detail panel they use a same field but
with
different position (lets say person.name) they are experiencing some
style
collision.
Lets say that DetailPanel-A and DetailPanel-B show a text-field with
the
person.name and displays them in different locations. Surely now we
have
the
same style name (by class (.) or by id (#) in some versions).
So we have two .css files.
*DetailPanel-A.css* with:
.fieldPersonName{
position:absolute;
left:50px;
top: 50px;
}
*DetailPanel-B.css* with:
.fieldPersonName{
background-color: yellow;
}
Now we navigate from DetailPanel-A to DetailPanel-B or viceversa. And
ofcourse the problem is that on the DetailPanel-B my field gets
moved
if
I
don't specify otherwise. And some times although we specify it, it
will
depend on order and other matters as well. This are the rules of the
game
and web development has been fine with them.
But my colleages are proposing a disabling of previously loaded
styles,
living DOM with disabled style
Re: Rare Style disabling and Ajax Panel Replacement Question
One extrathing though! you could take a look at the scriptacoulus
toaster I added last week. I do some dynamic styling there if. Because
if you have more than one popup window on your page you do not want them
to clash, so it's sort of the same. But it has some extra work though,
since I use a texttemplate. But it could actually work! Please say if
you help trying it out?
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-scriptaculous/src/java/org/wicketstuff/scriptaculous/fx/ToasterCSSHeaderContributor.java
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-scriptaculous/src/java/org/wicketstuff/scriptaculous/fx/Toaster.css
Nino Saturnino Martinez Vazquez Wael wrote:
German Morales wrote:
Hi,
I'm here with Francisco, discussing this subject.
The main difference between the approach is the amount of stuff to
write in
CSS: With the detailed naming of styles (.DetailPanel-A
fieldPersonName)
you have to write a lot more in the CSS. That is, for each field in
DetailPanelA, you have to go with .DetailPanelA #fieldWhatever1,
.DetailPanelA #fieldWhatever2, .DetailPanelA #fieldWhateverN
instead of
the shorter versions #fieldWhatever1, #fieldWhatever2,
#fieldWhateverN. Therefore, the shorter versions should be, in theory,
easier to write and maintain.
Yeah I see the point. But could'nt at least try to hit the fields by
selectors: .DetailPanelA fieldsettextarea {color:black}.
But on the otherhand you can have one stylesheet that fits all, that
could be handy if you ever want todo skinning, by css only(which
actually can do alot see css zen garden).
On the other hand, producing this #fieldWhatever1 allows the conflict
between fieldWhatever1 in DetailPanelA and DetailPanelB, which means
that we
must introduce some trick to avoid it.
Yup popular called clashing.
Someone here has found this
disabling of CSSs.
I think this approach are okay doing simple static pages. But once you
mixin ajax trouble begin to rise, and what happens if you have two of
the panels clashing in the same page who should win?
It is nice because it could be handled in a somehow
generic way (allowing producers of DetailPanelN to be un-aware of all
this
complication), but also we must consider that it adds some extra
complexity.
Yes it does, but on the other hand, it lessen the burden on the css
designer, so it's a tradoff.
I'm not completely in favor of one or another approach. The detailed
style
version is in fact our current solution, and it has the benefit of being
simple. But we are trying also the CSS disabling because it has some
not-that-bad benefits (CSS simplification, and perhaps the
possibility of
forget about the CSS conflicts altogether).
That's why we would like to hear opinions, and perhaps even more
importantly, hear about different approaches, or about hidden traps
in our
current attempts.
Understandable.. I too are looking forward to hear different opinions:)
Thanks in advance,
German
2008/6/18 Francisco Diaz Trepat - gmail
[EMAIL PROTECTED]:
That was my approach exactly but I lack the arguments to convince
them. I
managed to send this mail and see if I'll get better ones :-), or at
least
community consensus.
Maybe if I started a thread I could get some other experiences and
opinions
on the matter.
Thanks Nino.
f(t)
On Wed, Jun 18, 2008 at 1:49 PM, Nino Saturnino Martinez Vazquez Wael
[EMAIL PROTECTED] wrote:
Hi Francisco
I'd much rather go with more detailed naming of your styles,
instead of
doing complex stuff with dom? Like
.DetailPanel-A-fieldPersonName{
position:absolute;
left:50px;
top: 50px;
}
Or maybe the problem are more complex than this..?
Francisco Diaz Trepat - gmail wrote:
Hi all, its been a while.
Finally we started migrating other applications from swing to wicket
thanks
to all your help provided last year.
Having said that, I have some colleagues that are looking to
develop a
way
to disable style sheets that are loaded as part of panel replacement.
Here is the Scenario:
we have a classic web structure: left menu, top header, and center to
right
Detail area.
The detail area is replaced by wicket-ajax functions and each panel
usually
has an overriden renderHead with code similar to this one:
cHtmlHeaderContainer.getHeaderResponse().renderCSSReference(new
ResourceReference(
this.getClass(),
this.getClass().getSimpleName() + .css,
getLocale(),
getStyle()));
Because on more than one detail panel they use a same field but
with
different position (lets say person.name) they are experiencing some
style
collision.
Lets say that DetailPanel-A and DetailPanel-B show a text-field
with the
person.name and displays them in different locations. Surely now we
have
the
same style name (by class (.) or by id (#) in some versions).
So we have two .css files.
Re: Rare Style disabling and Ajax Panel Replacement Question
German Morales wrote:
Hi,
I'm here with Francisco, discussing this subject.
The main difference between the approach is the amount of stuff to write in
CSS: With the detailed naming of styles (.DetailPanel-A fieldPersonName)
you have to write a lot more in the CSS. That is, for each field in
DetailPanelA, you have to go with .DetailPanelA #fieldWhatever1,
.DetailPanelA #fieldWhatever2, .DetailPanelA #fieldWhateverN instead of
the shorter versions #fieldWhatever1, #fieldWhatever2,
#fieldWhateverN. Therefore, the shorter versions should be, in theory,
easier to write and maintain.
Yeah I see the point. But could'nt at least try to hit the fields by
selectors: .DetailPanelA fieldsettextarea {color:black}.
But on the otherhand you can have one stylesheet that fits all, that
could be handy if you ever want todo skinning, by css only(which
actually can do alot see css zen garden).
On the other hand, producing this #fieldWhatever1 allows the conflict
between fieldWhatever1 in DetailPanelA and DetailPanelB, which means that we
must introduce some trick to avoid it.
Yup popular called clashing.
Someone here has found this
disabling of CSSs.
I think this approach are okay doing simple static pages. But once you
mixin ajax trouble begin to rise, and what happens if you have two of
the panels clashing in the same page who should win?
It is nice because it could be handled in a somehow
generic way (allowing producers of DetailPanelN to be un-aware of all this
complication), but also we must consider that it adds some extra complexity.
Yes it does, but on the other hand, it lessen the burden on the css
designer, so it's a tradoff.
I'm not completely in favor of one or another approach. The detailed style
version is in fact our current solution, and it has the benefit of being
simple. But we are trying also the CSS disabling because it has some
not-that-bad benefits (CSS simplification, and perhaps the possibility of
forget about the CSS conflicts altogether).
That's why we would like to hear opinions, and perhaps even more
importantly, hear about different approaches, or about hidden traps in our
current attempts.
Understandable.. I too are looking forward to hear different opinions:)
Thanks in advance,
German
2008/6/18 Francisco Diaz Trepat - gmail [EMAIL PROTECTED]:
That was my approach exactly but I lack the arguments to convince them. I
managed to send this mail and see if I'll get better ones :-), or at least
community consensus.
Maybe if I started a thread I could get some other experiences and opinions
on the matter.
Thanks Nino.
f(t)
On Wed, Jun 18, 2008 at 1:49 PM, Nino Saturnino Martinez Vazquez Wael
[EMAIL PROTECTED] wrote:
Hi Francisco
I'd much rather go with more detailed naming of your styles, instead of
doing complex stuff with dom? Like
.DetailPanel-A-fieldPersonName{
position:absolute;
left:50px;
top: 50px;
}
Or maybe the problem are more complex than this..?
Francisco Diaz Trepat - gmail wrote:
Hi all, its been a while.
Finally we started migrating other applications from swing to wicket
thanks
to all your help provided last year.
Having said that, I have some colleagues that are looking to develop a
way
to disable style sheets that are loaded as part of panel replacement.
Here is the Scenario:
we have a classic web structure: left menu, top header, and center to
right
Detail area.
The detail area is replaced by wicket-ajax functions and each panel
usually
has an overriden renderHead with code similar to this one:
cHtmlHeaderContainer.getHeaderResponse().renderCSSReference(new
ResourceReference(
this.getClass(),
this.getClass().getSimpleName() + .css,
getLocale(),
getStyle()));
Because on more than one detail panel they use a same field but with
different position (lets say person.name) they are experiencing some
style
collision.
Lets say that DetailPanel-A and DetailPanel-B show a text-field with the
person.name and displays them in different locations. Surely now we
have
the
same style name (by class (.) or by id (#) in some versions).
So we have two .css files.
*DetailPanel-A.css* with:
.fieldPersonName{
position:absolute;
left:50px;
top: 50px;
}
*DetailPanel-B.css* with:
.fieldPersonName{
background-color: yellow;
}
Now we navigate from DetailPanel-A to DetailPanel-B or viceversa. And
ofcourse the problem is that on the DetailPanel-B my field gets moved
if
I
don't specify otherwise. And some times although we specify it, it will
depend on order and other matters as well. This are the rules of the
game
and web development has been fine with them.
But my colleages are proposing a disabling of previously loaded styles,
living DOM with disabled style objects.
I haven't heard of that kind of practice. And IMHO instead of building a
complex
