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, e-mail: [EMAIL PROTECTED]
> >
> >
>
