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 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]
>
>
