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 fieldset>textarea {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 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]
--
-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]
