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 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]
> >> >
> >> >
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
