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]
