Hello Jeanne,
I thought about skinning and portlet before and I came upon pretty much the
same conclusion. However in my idea it was more like a predefined skin
family, like "containerProvided" maybe. Then renderer would always uses
uncompressed selectors and would leave <style/> tag generation to the
container. Then again the container would need a way to produce the CSS, but
I was not yet to that point.
I guess a flag in the skin definition works as well, but it seems a bit
strange to have a skin specific for a portlet environment, I would have
preferred to be able to use any skin.
Regards,
~ Simon
On 2/1/07, Jeanne Waldman <[EMAIL PROTECTED]> wrote:
I just thought of a reason why I can't simply compress or uncompress
based on the DISABLE_CONTENT_COMPRESSION flag, and that is the new
portal skin we've introduced in the portal branch. We don't compress our
styleclasses when using the portal skin.
The way the skinning works now in the portal branch is:
1. It assumes we write out both full and compressed styleclasses in our
generated css file.
2. The Skin has a getStyleClassMap method. For all skins except portal
skins, it returns our styleclass compression map if we aren't disabling
content compression, else null; for portal skins it returns a Trinidad
styleclass to portal styleclass map.
I can see upon writing out the css file I look to see if it is a portal,
etc.
Or what do people think about a flag in the Skin that tells me if the
StyleClassMap is the compression map that we use to generate the css?
Or maybe in our css generation code we can look at the skin's styleclass
map and glean information from it? Maybe see if it is the same
compression map that we are using to generate the css file and if so,
then it's ok to just write out compression, and if not, then we don't???
I'll see what I can do, but I'll want a code review to make sure it is
the best solution.
Thanks,
Jeanne
Matt Cooper wrote:
> That sounds like a reasonable first step to me since that would reduce
> the
> size the most.
>
> Thanks
>
> On 1/31/07, Simon Lessard <[EMAIL PROTECTED]> wrote:
>>
>> I agree, only one version compressed or uncompressed should be enough
>> for
>> a
>> while.
>>
>> On 1/31/07, Jeanne Waldman <[EMAIL PROTECTED]> wrote:
>> >
>> >
>> >
>> > Simon Lessard wrote:
>> > > On 1/31/07, Matt Cooper <[EMAIL PROTECTED]> wrote:
>> > >>
>> > >> On 1/31/07, Jeanne Waldman <[EMAIL PROTECTED]> wrote:
>> > >> >
>> > >> > > As Adam suggest, we could do some runtime evaluation during
CSS
>> > >> > > generation
>> > >> > > and have many selector uses the same compressed selector, this
>> > would
>> > >> be
>> > >> > a
>> > >> > > 50% gain or so.
>> > >> > I can do this, too, if we feel we have to. The logic flow will
>> have
>> > to
>> > >> > change, of course.
>> > >> > Right now we build the shortened style class map, then we
>> generate
>> > the
>> > >> > css file.
>> > >> > I'd have to either change the shortened style class map as I
>> merge
>> > >> > styles, or create it a bit later.
>> > >> > It's no big deal, just more overhead when we create the file.
>> > >>
>> > >>
>> > >> Maybe this goes without saying but we have to be careful when
doing
>> > this
>> > >> so
>> > >> that we only use the same selector when the containment
definitions
>> are
>> > >> also
>> > >> the same.
>> > >>
>> > >> If we just have:
>> > >>
>> > >> .Foo,
>> > >> .Bar {
>> > >> color: red;
>> > >> }
>> > >>
>> > >> then this could be compressed down to:
>> > >>
>> > >> .x1 {
>> > >> color: red;
>> > >> }
>> > >>
>> > >> But if we have:
>> > >>
>> > >> .Foo,
>> > >> .Bar {
>> > >> color: red;
>> > >> }
>> > >>
>> > >> .Foo .Joe {
>> > >> color: green;
>> > >> }
>> > >>
>> > >> .Bar .Joe {
>> > >> color: blue;
>> > >> }
>> > >>
>> > >> then we cannot use the same compressed name for Foo and Bar, we'd
>> > >> compress
>> > >> to:
>> > >>
>> > >> .x1,
>> > >> .x2 {
>> > >> color: red;
>> > >> }
>> > >>
>> > >> .x1 .x3 {
>> > >> color: green;
>> > >> }
>> > >>
>> > >> .x2 .x3 {
>> > >> color: blue;
>> > >> }
>> > >>
>> > >> If we had:
>> > >>
>> > >> .Foo,
>> > >> .Bar {
>> > >> color: red;
>> > >> }
>> > >>
>> > >> .Foo .Joe,
>> > >> .Bar .Joe {
>> > >> color: green;
>> > >> }
>> > >>
>> > >> then we could compress down to:
>> > >>
>> > >> .x1 {
>> > >> color: red;
>> > >> }
>> > >>
>> > >> .x1 .x2 {
>> > >> color: green;
>> > >> }
>> > >
>> > >
>> > > Yeah that would require quite a lot of evaluation after parsing, if
>> > > that's
>> > > done maybe we should consider generating the CSS files at app.
>> startup
>> > > rather than at first request because that kind of processing would
>> > > most like
>> > > be O(n!) or O(x^n).
>> > I was thinking if a style is used anywhere else, period, we do not
>> merge
>> > that with another style. That is less processing, at least.
>> > Personally, I think doing the only-generated-compressed-styles
>> solution
>> > or (only-non-uncompressed) is enough to solve this problem for a
>> while.
>> > I think this merging solution is lower priority, and more of a
>> > nice-to-have. What does everyone else think?
>> > If there is another reason to do this, like performance, and we
>> know the
>> > impact, then that's another thing, but I'd like
>> > to focus on this issue and the solution right now -- especially since
>> > we've hit this limit.
>> > - Jeanne
>> >
>> >
>>
>>
>
