You are viewing a plain text version of this content. The canonical link for it is here.
Posted to adffaces-dev@incubator.apache.org by Jeanne Waldman <je...@oracle.com> on 2007/01/20 00:03:01 UTC
unknown-version in generated css file
Hi,
I see that when I run a demo jspx file, the generated css file has
"unknown-version" in the name.
The reason, I believe, is that the 'implPkg.getImplementationVersion()'
in the below code is returning null.
Why is this? Where are we setting (or supposed to be setting) the
implementation version exactly?
Does anyone else see this problem?
I think this code was added in this JIRA issue:
http://issues.apache.org/jira/browse/ADFFACES-147.
Thanks,
Jeanne
// If the document version is ${trinidad-version}, replace it
// with the version number right out of our manifest
if ("${trinidad-version}".equals(_documentVersion))
{
Class<StyleSheetDocumentParser> implClass =
StyleSheetDocumentParser.class;
Package implPkg = implClass.getPackage();
if ((implPkg != null) && (implPkg.getImplementationVersion() != null))
{
_documentVersion =
implPkg.getImplementationVersion().replace('.','_');
}
else
{
_documentVersion = "unknown-version";
}
}
Re: [Skinning] CSS selector limit hit in IE
Posted by Jeanne Waldman <je...@oracle.com>.
Hi there,
I've changed my mind and instead added this to FileSystemStyleCache. It
is cleaner. I didn't do this in the first place
because I needed the RenderingContext, and I didn't think I had it. But
then I noticed that I have it with the getCurrentInstance method.
Map skinsStyleClassMap = context.getSkin().getStyleClassMap(
RenderingContext.getCurrentInstance());
String disableContentCompression =
FacesContext.getCurrentInstance().getExternalContext().
getInitParameter(StyleSheetRenderer.DISABLE_CONTENT_COMPRESSION);
boolean compressStyles = (skinsStyleClassMap == shortStyleClassMap) &&
!"true".equals(disableContentCompression);
Jeanne Waldman wrote:
> This is what I've done:
> Added a getSkin() on the StyleContext object which I think is a fine
> thing to do, since the StyleContext
> gives us information we need to be able to output the stylesheet.
>
> Then I can do this to see if I need to output the compressed
> styleclasses or the uncompressed styleclasses:
> String disableContentCompression =
> FacesContext.getCurrentInstance().getExternalContext().
> getInitParameter(StyleSheetRenderer.DISABLE_CONTENT_COMPRESSION);
> // we do not compress if it is a portlet skin
> boolean isPortletSkin =
>
> CoreRenderKit.OUTPUT_MODE_PORTLET.equals(context.getSkin().getRenderKitId());
>
>
> boolean compressStyles =
> (!"true".equals(disableContentCompression)) &&
> !isPortletSkin;
>
> Simon Lessard wrote:
>> That works, true.
>>
>> On 2/1/07, Jeanne Waldman <je...@oracle.com> wrote:
>>>
>>>
>>>
>>>
>>> Simon Lessard wrote:
>>> > 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.
>>> Like we have desktop skins,
>>> pda skins, we can now also have portlet skins.
>>> This way we don't change the skin-family.
>>> We we have a SimpleDesktop skin, a SimplePda skin, we
>>> now also have a SimplePortlet skin.
>>> >
>>> >
>>> > Regards,
>>> >
>>> > ~ Simon
>>> >
>>> > On 2/1/07, Jeanne Waldman <je...@oracle.com> 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 <si...@gmail.com> wrote:
>>> >> >>
>>> >> >> I agree, only one version compressed or uncompressed should be
>>> enough
>>> >> >> for
>>> >> >> a
>>> >> >> while.
>>> >> >>
>>> >> >> On 1/31/07, Jeanne Waldman <je...@oracle.com> wrote:
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> > Simon Lessard wrote:
>>> >> >> > > On 1/31/07, Matt Cooper <ma...@gmail.com> wrote:
>>> >> >> > >>
>>> >> >> > >> On 1/31/07, Jeanne Waldman <je...@oracle.com>
>>> 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
>>> >> >> >
>>> >> >> >
>>> >> >>
>>> >> >>
>>> >> >
>>> >>
>>> >>
>>> >
>>>
>>>
>>
>
>
Re: [Skinning] CSS selector limit hit in IE
Posted by Jeanne Waldman <je...@oracle.com>.
This is what I've done:
Added a getSkin() on the StyleContext object which I think is a fine
thing to do, since the StyleContext
gives us information we need to be able to output the stylesheet.
Then I can do this to see if I need to output the compressed
styleclasses or the uncompressed styleclasses:
String disableContentCompression =
FacesContext.getCurrentInstance().getExternalContext().
getInitParameter(StyleSheetRenderer.DISABLE_CONTENT_COMPRESSION);
// we do not compress if it is a portlet skin
boolean isPortletSkin =
CoreRenderKit.OUTPUT_MODE_PORTLET.equals(context.getSkin().getRenderKitId());
boolean compressStyles = (!"true".equals(disableContentCompression)) &&
!isPortletSkin;
Simon Lessard wrote:
> That works, true.
>
> On 2/1/07, Jeanne Waldman <je...@oracle.com> wrote:
>>
>>
>>
>>
>> Simon Lessard wrote:
>> > 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.
>> Like we have desktop skins,
>> pda skins, we can now also have portlet skins.
>> This way we don't change the skin-family.
>> We we have a SimpleDesktop skin, a SimplePda skin, we
>> now also have a SimplePortlet skin.
>> >
>> >
>> > Regards,
>> >
>> > ~ Simon
>> >
>> > On 2/1/07, Jeanne Waldman <je...@oracle.com> 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 <si...@gmail.com> wrote:
>> >> >>
>> >> >> I agree, only one version compressed or uncompressed should be
>> enough
>> >> >> for
>> >> >> a
>> >> >> while.
>> >> >>
>> >> >> On 1/31/07, Jeanne Waldman <je...@oracle.com> wrote:
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > Simon Lessard wrote:
>> >> >> > > On 1/31/07, Matt Cooper <ma...@gmail.com> wrote:
>> >> >> > >>
>> >> >> > >> On 1/31/07, Jeanne Waldman <je...@oracle.com> 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
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >
>>
>>
>
Re: [Skinning] CSS selector limit hit in IE
Posted by Simon Lessard <si...@gmail.com>.
That works, true.
On 2/1/07, Jeanne Waldman <je...@oracle.com> wrote:
>
>
>
>
> Simon Lessard wrote:
> > 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.
> Like we have desktop skins,
> pda skins, we can now also have portlet skins.
> This way we don't change the skin-family.
> We we have a SimpleDesktop skin, a SimplePda skin, we
> now also have a SimplePortlet skin.
> >
> >
> > Regards,
> >
> > ~ Simon
> >
> > On 2/1/07, Jeanne Waldman <je...@oracle.com> 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 <si...@gmail.com> wrote:
> >> >>
> >> >> I agree, only one version compressed or uncompressed should be
> enough
> >> >> for
> >> >> a
> >> >> while.
> >> >>
> >> >> On 1/31/07, Jeanne Waldman <je...@oracle.com> wrote:
> >> >> >
> >> >> >
> >> >> >
> >> >> > Simon Lessard wrote:
> >> >> > > On 1/31/07, Matt Cooper <ma...@gmail.com> wrote:
> >> >> > >>
> >> >> > >> On 1/31/07, Jeanne Waldman <je...@oracle.com> 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
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >
> >>
> >>
> >
>
>
Re: [Skinning] CSS selector limit hit in IE
Posted by Jeanne Waldman <je...@oracle.com>.
Simon Lessard wrote:
> 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.
Like we have desktop skins,
pda skins, we can now also have portlet skins.
This way we don't change the skin-family.
We we have a SimpleDesktop skin, a SimplePda skin, we
now also have a SimplePortlet skin.
>
>
> Regards,
>
> ~ Simon
>
> On 2/1/07, Jeanne Waldman <je...@oracle.com> 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 <si...@gmail.com> wrote:
>> >>
>> >> I agree, only one version compressed or uncompressed should be enough
>> >> for
>> >> a
>> >> while.
>> >>
>> >> On 1/31/07, Jeanne Waldman <je...@oracle.com> wrote:
>> >> >
>> >> >
>> >> >
>> >> > Simon Lessard wrote:
>> >> > > On 1/31/07, Matt Cooper <ma...@gmail.com> wrote:
>> >> > >>
>> >> > >> On 1/31/07, Jeanne Waldman <je...@oracle.com> 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
>> >> >
>> >> >
>> >>
>> >>
>> >
>>
>>
>
Re: [Skinning] CSS selector limit hit in IE
Posted by Simon Lessard <si...@gmail.com>.
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 <je...@oracle.com> 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 <si...@gmail.com> wrote:
> >>
> >> I agree, only one version compressed or uncompressed should be enough
> >> for
> >> a
> >> while.
> >>
> >> On 1/31/07, Jeanne Waldman <je...@oracle.com> wrote:
> >> >
> >> >
> >> >
> >> > Simon Lessard wrote:
> >> > > On 1/31/07, Matt Cooper <ma...@gmail.com> wrote:
> >> > >>
> >> > >> On 1/31/07, Jeanne Waldman <je...@oracle.com> 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
> >> >
> >> >
> >>
> >>
> >
>
>
Re: [Skinning] CSS selector limit hit in IE
Posted by Jeanne Waldman <je...@oracle.com>.
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 <si...@gmail.com> wrote:
>>
>> I agree, only one version compressed or uncompressed should be enough
>> for
>> a
>> while.
>>
>> On 1/31/07, Jeanne Waldman <je...@oracle.com> wrote:
>> >
>> >
>> >
>> > Simon Lessard wrote:
>> > > On 1/31/07, Matt Cooper <ma...@gmail.com> wrote:
>> > >>
>> > >> On 1/31/07, Jeanne Waldman <je...@oracle.com> 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
>> >
>> >
>>
>>
>
Re: [Skinning] CSS selector limit hit in IE
Posted by Matt Cooper <ma...@gmail.com>.
That sounds like a reasonable first step to me since that would reduce the
size the most.
Thanks
On 1/31/07, Simon Lessard <si...@gmail.com> wrote:
>
> I agree, only one version compressed or uncompressed should be enough for
> a
> while.
>
> On 1/31/07, Jeanne Waldman <je...@oracle.com> wrote:
> >
> >
> >
> > Simon Lessard wrote:
> > > On 1/31/07, Matt Cooper <ma...@gmail.com> wrote:
> > >>
> > >> On 1/31/07, Jeanne Waldman <je...@oracle.com> 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
> >
> >
>
>
Re: [Skinning] CSS selector limit hit in IE
Posted by Simon Lessard <si...@gmail.com>.
I agree, only one version compressed or uncompressed should be enough for a
while.
On 1/31/07, Jeanne Waldman <je...@oracle.com> wrote:
>
>
>
> Simon Lessard wrote:
> > On 1/31/07, Matt Cooper <ma...@gmail.com> wrote:
> >>
> >> On 1/31/07, Jeanne Waldman <je...@oracle.com> 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
>
>
Re: [Skinning] CSS selector limit hit in IE
Posted by Jeanne Waldman <je...@oracle.com>.
Simon Lessard wrote:
> On 1/31/07, Matt Cooper <ma...@gmail.com> wrote:
>>
>> On 1/31/07, Jeanne Waldman <je...@oracle.com> 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
Re: [Skinning] CSS selector limit hit in IE
Posted by Simon Lessard <si...@gmail.com>.
On 1/31/07, Matt Cooper <ma...@gmail.com> wrote:
>
> On 1/31/07, Jeanne Waldman <je...@oracle.com> 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).
Re: [Skinning] CSS selector limit hit in IE
Posted by Matt Cooper <ma...@gmail.com>.
On 1/31/07, Jeanne Waldman <je...@oracle.com> 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;
}
Re: [Skinning] CSS selector limit hit in IE
Posted by Simon Lessard <si...@gmail.com>.
Hello Jeanne,
On 1/31/07, Jeanne Waldman <je...@oracle.com> wrote:
>
> Hi Simon, Adam,
>
> Simon Lessard wrote:
> > Wow, another IE nasticity...
> >
> > 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.
> >
> > As for not generating either compressed or uncompressed version
> > depending on
> > a context parameter value, I think it's a good idea as well.
> Me, too. We could tie in debug mode to automatically not compress...
> something I would
> like to do anyway, because right now we have this 'internal' key to
> disable compression,
> although it is such a useful feature for people who are creating skins.
>
> In the case where we don't compress, then we can't combined selectors.
> Well, technically we can, but I'm sure you all already know that would
> be too strange to do to
> the skinning person.
> >
> > I would also encourage a major reduction of private selectors usage as
> in
> > real world you always have to overload them anyway.
> What do you mean?
Mainly get rid of .OraLink classes and such, or at lease rename them and no
longer define them as private. In my last project I had to redefine
selectors like button.OraLink:active to prevent some really strange behavior
when clicking on a button. There's only about 10 of those selectors but if a
skinners has to override all combinations around those selectors (OraLink is
present in 6 selectors for my last skin mainly to make different behavior
between buttons and links) then the total amount of selectors present in the
final CSS might get higher than that.
>
> > Finally, does that restriction applies to IE 7 as well?
> yes, it does. I primarily use IE7 now at work. I did try this on my IE6
> on my home machine, and it occurs there, too.
> >
> >
> > Regards,
> >
> > ~ Simon
> >
> > On 1/31/07, Adam Winer <aw...@gmail.com> wrote:
> >>
> >> Having magic insider knowledge of the scenario where this
> >> problem occurs :), one of the major causes of it is
> >> using different keys for the same CSS rules. For example,
> >> we use af|selectManyShuttle and af|selectOrderShuttle,
> >> but they're basically the same thing. Merging the
> >> compressed versions of those keys would be a major
> >> win.
> >>
> >> This is tricky for classes that are used in complex
> >> selectors, but for classes that only show up in simple
> >> selectors, we could potentially detect the match,
> >>
> >> -- Adam
> >>
> >>
> >>
> >>
> >> On 1/30/07, Jeanne Waldman <je...@oracle.com> wrote:
> >> > Hi,
> >> >
> >> > Well, it turns out that IE has a limit to the size of a CSS file.
> It's
> >> > not the actual size of the file, but rather it is the
> >> > # of CSS selectors. I did a test and found out that the limit is 4095
> >> > CSS selectors.
> >> > Firefox doesn't appear to have a limit.
> >> >
> >> > As you may know, the CSS file we generate contains both compressed
> and
> >> > uncompressed styles, like this:
> >> > .af_inputText_content, .x01 {background-color: blue}
> >> >
> >> > Our renderers render a shortened styleclass, unless
> >> > the DISABLE_CONTENT_COMPRESSION flag is set to true in web.xml,
> >> then it
> >> > renders the long styleclass.
> >> > <input class="x01...>
> >> >
> >> > Ok, that's the background.
> >> >
> >> > *The problem* is that because we have a lot of custom components that
> >> > we've built on top of Trinidad, and our customers
> >> > have built custom components, etc, and these all have skinning,
> >> > we have bumped up against the 4095 selector limit in IE. All
> selectors
> >> > after the 4095th one are ignored.
> >> >
> >> > *A quick fix*, and probably a good one for a long time, is to
> >> render the
> >> > styles in compressed mode when compression is on,
> >> > or in uncompressed mode when compression if off. That will reduce our
> >> > style selectors by 1/2, and will help performance to boot. :)
> >> > I can also add a warning if we go past 4095 selectors for IE.
> >> >
> >> > Another solution is to break up the file into multiple files when
> I've
> >> > reached the limit in one file, and include
> >> > all the css files into the rendered page. I can do this in addition
> to
> >> > the quick fix when I have more time.
> >> > Or, I'll be forced to do this solution if the above solution can't be
> >> > done for some reason.
> >> >
> >> > Anyway, let me know what you think about the fixes. I'll start
> >> > investigating it to make sure it is possible and won't break
> >> > anything. My main concern was if people were using our public style
> >> > classes, like styleClass=".AFInstructionText", but
> >> > it looks like we compress these when we are in compressed mode.
> >> >
> >> > Let me know if there are other things I should check.
> >> >
> >> > Thanks,
> >> > Jeanne
> >> >
> >> >
> >>
> >
>
>
Re: [Skinning] CSS selector limit hit in IE
Posted by Jeanne Waldman <je...@oracle.com>.
Hi Simon, Adam,
Simon Lessard wrote:
> Wow, another IE nasticity...
>
> 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.
>
> As for not generating either compressed or uncompressed version
> depending on
> a context parameter value, I think it's a good idea as well.
Me, too. We could tie in debug mode to automatically not compress...
something I would
like to do anyway, because right now we have this 'internal' key to
disable compression,
although it is such a useful feature for people who are creating skins.
In the case where we don't compress, then we can't combined selectors.
Well, technically we can, but I'm sure you all already know that would
be too strange to do to
the skinning person.
>
> I would also encourage a major reduction of private selectors usage as in
> real world you always have to overload them anyway.
What do you mean?
>
> Finally, does that restriction applies to IE 7 as well?
yes, it does. I primarily use IE7 now at work. I did try this on my IE6
on my home machine, and it occurs there, too.
>
>
> Regards,
>
> ~ Simon
>
> On 1/31/07, Adam Winer <aw...@gmail.com> wrote:
>>
>> Having magic insider knowledge of the scenario where this
>> problem occurs :), one of the major causes of it is
>> using different keys for the same CSS rules. For example,
>> we use af|selectManyShuttle and af|selectOrderShuttle,
>> but they're basically the same thing. Merging the
>> compressed versions of those keys would be a major
>> win.
>>
>> This is tricky for classes that are used in complex
>> selectors, but for classes that only show up in simple
>> selectors, we could potentially detect the match,
>>
>> -- Adam
>>
>>
>>
>>
>> On 1/30/07, Jeanne Waldman <je...@oracle.com> wrote:
>> > Hi,
>> >
>> > Well, it turns out that IE has a limit to the size of a CSS file. It's
>> > not the actual size of the file, but rather it is the
>> > # of CSS selectors. I did a test and found out that the limit is 4095
>> > CSS selectors.
>> > Firefox doesn't appear to have a limit.
>> >
>> > As you may know, the CSS file we generate contains both compressed and
>> > uncompressed styles, like this:
>> > .af_inputText_content, .x01 {background-color: blue}
>> >
>> > Our renderers render a shortened styleclass, unless
>> > the DISABLE_CONTENT_COMPRESSION flag is set to true in web.xml,
>> then it
>> > renders the long styleclass.
>> > <input class="x01...>
>> >
>> > Ok, that's the background.
>> >
>> > *The problem* is that because we have a lot of custom components that
>> > we've built on top of Trinidad, and our customers
>> > have built custom components, etc, and these all have skinning,
>> > we have bumped up against the 4095 selector limit in IE. All selectors
>> > after the 4095th one are ignored.
>> >
>> > *A quick fix*, and probably a good one for a long time, is to
>> render the
>> > styles in compressed mode when compression is on,
>> > or in uncompressed mode when compression if off. That will reduce our
>> > style selectors by 1/2, and will help performance to boot. :)
>> > I can also add a warning if we go past 4095 selectors for IE.
>> >
>> > Another solution is to break up the file into multiple files when I've
>> > reached the limit in one file, and include
>> > all the css files into the rendered page. I can do this in addition to
>> > the quick fix when I have more time.
>> > Or, I'll be forced to do this solution if the above solution can't be
>> > done for some reason.
>> >
>> > Anyway, let me know what you think about the fixes. I'll start
>> > investigating it to make sure it is possible and won't break
>> > anything. My main concern was if people were using our public style
>> > classes, like styleClass=".AFInstructionText", but
>> > it looks like we compress these when we are in compressed mode.
>> >
>> > Let me know if there are other things I should check.
>> >
>> > Thanks,
>> > Jeanne
>> >
>> >
>>
>
Re: [Skinning] CSS selector limit hit in IE
Posted by Simon Lessard <si...@gmail.com>.
Wow, another IE nasticity...
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.
As for not generating either compressed or uncompressed version depending on
a context parameter value, I think it's a good idea as well.
I would also encourage a major reduction of private selectors usage as in
real world you always have to overload them anyway.
Finally, does that restriction applies to IE 7 as well?
Regards,
~ Simon
On 1/31/07, Adam Winer <aw...@gmail.com> wrote:
>
> Having magic insider knowledge of the scenario where this
> problem occurs :), one of the major causes of it is
> using different keys for the same CSS rules. For example,
> we use af|selectManyShuttle and af|selectOrderShuttle,
> but they're basically the same thing. Merging the
> compressed versions of those keys would be a major
> win.
>
> This is tricky for classes that are used in complex
> selectors, but for classes that only show up in simple
> selectors, we could potentially detect the match,
>
> -- Adam
>
>
>
>
> On 1/30/07, Jeanne Waldman <je...@oracle.com> wrote:
> > Hi,
> >
> > Well, it turns out that IE has a limit to the size of a CSS file. It's
> > not the actual size of the file, but rather it is the
> > # of CSS selectors. I did a test and found out that the limit is 4095
> > CSS selectors.
> > Firefox doesn't appear to have a limit.
> >
> > As you may know, the CSS file we generate contains both compressed and
> > uncompressed styles, like this:
> > .af_inputText_content, .x01 {background-color: blue}
> >
> > Our renderers render a shortened styleclass, unless
> > the DISABLE_CONTENT_COMPRESSION flag is set to true in web.xml, then it
> > renders the long styleclass.
> > <input class="x01...>
> >
> > Ok, that's the background.
> >
> > *The problem* is that because we have a lot of custom components that
> > we've built on top of Trinidad, and our customers
> > have built custom components, etc, and these all have skinning,
> > we have bumped up against the 4095 selector limit in IE. All selectors
> > after the 4095th one are ignored.
> >
> > *A quick fix*, and probably a good one for a long time, is to render the
> > styles in compressed mode when compression is on,
> > or in uncompressed mode when compression if off. That will reduce our
> > style selectors by 1/2, and will help performance to boot. :)
> > I can also add a warning if we go past 4095 selectors for IE.
> >
> > Another solution is to break up the file into multiple files when I've
> > reached the limit in one file, and include
> > all the css files into the rendered page. I can do this in addition to
> > the quick fix when I have more time.
> > Or, I'll be forced to do this solution if the above solution can't be
> > done for some reason.
> >
> > Anyway, let me know what you think about the fixes. I'll start
> > investigating it to make sure it is possible and won't break
> > anything. My main concern was if people were using our public style
> > classes, like styleClass=".AFInstructionText", but
> > it looks like we compress these when we are in compressed mode.
> >
> > Let me know if there are other things I should check.
> >
> > Thanks,
> > Jeanne
> >
> >
>
Re: [Skinning] CSS selector limit hit in IE
Posted by Simon Lessard <si...@gmail.com>.
I agree that the uncompressed version is useful to debug with Firebug, but
you can achieve just the same by setting compression to false, so I don't
see the need for a new debug option.
On 1/31/07, Adam Winer <aw...@gmail.com> wrote:
>
> One more thing: what I really like about having
> both the compressed and uncompressed style
> classes is that when I see a class in the source,
> I can figure out what the real .css style is.
>
> Is there any way we could - at least in debug mode -
> leave behind a .css comment with the original
> class name?
>
> -- Adam
>
>
> On 1/31/07, Adam Winer <aw...@gmail.com> wrote:
> > Having magic insider knowledge of the scenario where this
> > problem occurs :), one of the major causes of it is
> > using different keys for the same CSS rules. For example,
> > we use af|selectManyShuttle and af|selectOrderShuttle,
> > but they're basically the same thing. Merging the
> > compressed versions of those keys would be a major
> > win.
> >
> > This is tricky for classes that are used in complex
> > selectors, but for classes that only show up in simple
> > selectors, we could potentially detect the match,
> >
> > -- Adam
> >
> >
> >
> >
> > On 1/30/07, Jeanne Waldman <je...@oracle.com> wrote:
> > > Hi,
> > >
> > > Well, it turns out that IE has a limit to the size of a CSS file. It's
> > > not the actual size of the file, but rather it is the
> > > # of CSS selectors. I did a test and found out that the limit is 4095
> > > CSS selectors.
> > > Firefox doesn't appear to have a limit.
> > >
> > > As you may know, the CSS file we generate contains both compressed and
> > > uncompressed styles, like this:
> > > .af_inputText_content, .x01 {background-color: blue}
> > >
> > > Our renderers render a shortened styleclass, unless
> > > the DISABLE_CONTENT_COMPRESSION flag is set to true in web.xml, then
> it
> > > renders the long styleclass.
> > > <input class="x01...>
> > >
> > > Ok, that's the background.
> > >
> > > *The problem* is that because we have a lot of custom components that
> > > we've built on top of Trinidad, and our customers
> > > have built custom components, etc, and these all have skinning,
> > > we have bumped up against the 4095 selector limit in IE. All selectors
> > > after the 4095th one are ignored.
> > >
> > > *A quick fix*, and probably a good one for a long time, is to render
> the
> > > styles in compressed mode when compression is on,
> > > or in uncompressed mode when compression if off. That will reduce our
> > > style selectors by 1/2, and will help performance to boot. :)
> > > I can also add a warning if we go past 4095 selectors for IE.
> > >
> > > Another solution is to break up the file into multiple files when I've
> > > reached the limit in one file, and include
> > > all the css files into the rendered page. I can do this in addition to
> > > the quick fix when I have more time.
> > > Or, I'll be forced to do this solution if the above solution can't be
> > > done for some reason.
> > >
> > > Anyway, let me know what you think about the fixes. I'll start
> > > investigating it to make sure it is possible and won't break
> > > anything. My main concern was if people were using our public style
> > > classes, like styleClass=".AFInstructionText", but
> > > it looks like we compress these when we are in compressed mode.
> > >
> > > Let me know if there are other things I should check.
> > >
> > > Thanks,
> > > Jeanne
> > >
> > >
> >
>
Re: [Skinning] CSS selector limit hit in IE
Posted by Adam Winer <aw...@gmail.com>.
One more thing: what I really like about having
both the compressed and uncompressed style
classes is that when I see a class in the source,
I can figure out what the real .css style is.
Is there any way we could - at least in debug mode -
leave behind a .css comment with the original
class name?
-- Adam
On 1/31/07, Adam Winer <aw...@gmail.com> wrote:
> Having magic insider knowledge of the scenario where this
> problem occurs :), one of the major causes of it is
> using different keys for the same CSS rules. For example,
> we use af|selectManyShuttle and af|selectOrderShuttle,
> but they're basically the same thing. Merging the
> compressed versions of those keys would be a major
> win.
>
> This is tricky for classes that are used in complex
> selectors, but for classes that only show up in simple
> selectors, we could potentially detect the match,
>
> -- Adam
>
>
>
>
> On 1/30/07, Jeanne Waldman <je...@oracle.com> wrote:
> > Hi,
> >
> > Well, it turns out that IE has a limit to the size of a CSS file. It's
> > not the actual size of the file, but rather it is the
> > # of CSS selectors. I did a test and found out that the limit is 4095
> > CSS selectors.
> > Firefox doesn't appear to have a limit.
> >
> > As you may know, the CSS file we generate contains both compressed and
> > uncompressed styles, like this:
> > .af_inputText_content, .x01 {background-color: blue}
> >
> > Our renderers render a shortened styleclass, unless
> > the DISABLE_CONTENT_COMPRESSION flag is set to true in web.xml, then it
> > renders the long styleclass.
> > <input class="x01...>
> >
> > Ok, that's the background.
> >
> > *The problem* is that because we have a lot of custom components that
> > we've built on top of Trinidad, and our customers
> > have built custom components, etc, and these all have skinning,
> > we have bumped up against the 4095 selector limit in IE. All selectors
> > after the 4095th one are ignored.
> >
> > *A quick fix*, and probably a good one for a long time, is to render the
> > styles in compressed mode when compression is on,
> > or in uncompressed mode when compression if off. That will reduce our
> > style selectors by 1/2, and will help performance to boot. :)
> > I can also add a warning if we go past 4095 selectors for IE.
> >
> > Another solution is to break up the file into multiple files when I've
> > reached the limit in one file, and include
> > all the css files into the rendered page. I can do this in addition to
> > the quick fix when I have more time.
> > Or, I'll be forced to do this solution if the above solution can't be
> > done for some reason.
> >
> > Anyway, let me know what you think about the fixes. I'll start
> > investigating it to make sure it is possible and won't break
> > anything. My main concern was if people were using our public style
> > classes, like styleClass=".AFInstructionText", but
> > it looks like we compress these when we are in compressed mode.
> >
> > Let me know if there are other things I should check.
> >
> > Thanks,
> > Jeanne
> >
> >
>
Re: [Skinning] CSS selector limit hit in IE
Posted by Adam Winer <aw...@gmail.com>.
Having magic insider knowledge of the scenario where this
problem occurs :), one of the major causes of it is
using different keys for the same CSS rules. For example,
we use af|selectManyShuttle and af|selectOrderShuttle,
but they're basically the same thing. Merging the
compressed versions of those keys would be a major
win.
This is tricky for classes that are used in complex
selectors, but for classes that only show up in simple
selectors, we could potentially detect the match,
-- Adam
On 1/30/07, Jeanne Waldman <je...@oracle.com> wrote:
> Hi,
>
> Well, it turns out that IE has a limit to the size of a CSS file. It's
> not the actual size of the file, but rather it is the
> # of CSS selectors. I did a test and found out that the limit is 4095
> CSS selectors.
> Firefox doesn't appear to have a limit.
>
> As you may know, the CSS file we generate contains both compressed and
> uncompressed styles, like this:
> .af_inputText_content, .x01 {background-color: blue}
>
> Our renderers render a shortened styleclass, unless
> the DISABLE_CONTENT_COMPRESSION flag is set to true in web.xml, then it
> renders the long styleclass.
> <input class="x01...>
>
> Ok, that's the background.
>
> *The problem* is that because we have a lot of custom components that
> we've built on top of Trinidad, and our customers
> have built custom components, etc, and these all have skinning,
> we have bumped up against the 4095 selector limit in IE. All selectors
> after the 4095th one are ignored.
>
> *A quick fix*, and probably a good one for a long time, is to render the
> styles in compressed mode when compression is on,
> or in uncompressed mode when compression if off. That will reduce our
> style selectors by 1/2, and will help performance to boot. :)
> I can also add a warning if we go past 4095 selectors for IE.
>
> Another solution is to break up the file into multiple files when I've
> reached the limit in one file, and include
> all the css files into the rendered page. I can do this in addition to
> the quick fix when I have more time.
> Or, I'll be forced to do this solution if the above solution can't be
> done for some reason.
>
> Anyway, let me know what you think about the fixes. I'll start
> investigating it to make sure it is possible and won't break
> anything. My main concern was if people were using our public style
> classes, like styleClass=".AFInstructionText", but
> it looks like we compress these when we are in compressed mode.
>
> Let me know if there are other things I should check.
>
> Thanks,
> Jeanne
>
>
Re: [Skinning] CSS selector limit hit in IE
Posted by Jeanne Waldman <je...@oracle.com>.
Hi Matt,
Matt Cooper wrote:
> Hi Jeanne,
>
> That example of setting styleClass="AFInstructionText" (or
> styleClass="foo
> bar") was the case I was thinking about too and think it should be
> okay to
> have all compressed and all uncompressed.
To be on the safe side, I just decided that what I can do is if there is
not a '|' in the
name, I will output both compressed/non-compressed. Otherwise, one or
the other.
Having a '|' in the name won't work in css without our preprocessing it,
so no one
would ever use that name outright. But they might use a styleclass like,
.Foo, that
they added to their skin.
>
> If there are any cases where a component developer is writing a
> JavaScript
> counterpart to their renderer, he or she can send down the resolved style
> class along with the rendered content, otherwise they'd just be
> hard-coding
> a style class which already is bad practice.
>
> In short, it seems like your suggested change wouldn't be a problem
> from the
> use cases I've seen.
>
> Like you say, in the long term, it would be nice to split it up into
> multiple files automatically as an added measure--who knows how many
> components Trinidad or customers will have in 5 years or more.
>
> Also, I do prefer to have the generated CSS file be a one or the other
> (compressed or not compressed) file rather than both.
ok
>
> As part of this change, can you also add a counter? If the number of
> selectors exceeds the limit when generating the IE CSS file, an error or
> warning gets logged so that if people are seeing strange behavior,
> we'd know
> pretty quickly that this is the cause. I think that would be a friendly
> thing to do for future developers.
Yes, I was planning to do that as part of the 'quick fix'.
Thanks!
Jeanne
>
> Thank you,
> Matt
>
> On 1/30/07, Jeanne Waldman <je...@oracle.com> wrote:
>>
>> Hi,
>>
>> Well, it turns out that IE has a limit to the size of a CSS file. It's
>> not the actual size of the file, but rather it is the
>> # of CSS selectors. I did a test and found out that the limit is 4095
>> CSS selectors.
>> Firefox doesn't appear to have a limit.
>>
>> As you may know, the CSS file we generate contains both compressed and
>> uncompressed styles, like this:
>> .af_inputText_content, .x01 {background-color: blue}
>>
>> Our renderers render a shortened styleclass, unless
>> the DISABLE_CONTENT_COMPRESSION flag is set to true in web.xml, then it
>> renders the long styleclass.
>> <input class="x01...>
>>
>> Ok, that's the background.
>>
>> *The problem* is that because we have a lot of custom components that
>> we've built on top of Trinidad, and our customers
>> have built custom components, etc, and these all have skinning,
>> we have bumped up against the 4095 selector limit in IE. All selectors
>> after the 4095th one are ignored.
>>
>> *A quick fix*, and probably a good one for a long time, is to render the
>> styles in compressed mode when compression is on,
>> or in uncompressed mode when compression if off. That will reduce our
>> style selectors by 1/2, and will help performance to boot. :)
>> I can also add a warning if we go past 4095 selectors for IE.
>>
>> Another solution is to break up the file into multiple files when I've
>> reached the limit in one file, and include
>> all the css files into the rendered page. I can do this in addition to
>> the quick fix when I have more time.
>> Or, I'll be forced to do this solution if the above solution can't be
>> done for some reason.
>>
>> Anyway, let me know what you think about the fixes. I'll start
>> investigating it to make sure it is possible and won't break
>> anything. My main concern was if people were using our public style
>> classes, like styleClass=".AFInstructionText", but
>> it looks like we compress these when we are in compressed mode.
>>
>> Let me know if there are other things I should check.
>>
>> Thanks,
>> Jeanne
>>
>>
>
Re: [Skinning] CSS selector limit hit in IE
Posted by Matt Cooper <ma...@gmail.com>.
Hi Jeanne,
That example of setting styleClass="AFInstructionText" (or styleClass="foo
bar") was the case I was thinking about too and think it should be okay to
have all compressed and all uncompressed.
If there are any cases where a component developer is writing a JavaScript
counterpart to their renderer, he or she can send down the resolved style
class along with the rendered content, otherwise they'd just be hard-coding
a style class which already is bad practice.
In short, it seems like your suggested change wouldn't be a problem from the
use cases I've seen.
Like you say, in the long term, it would be nice to split it up into
multiple files automatically as an added measure--who knows how many
components Trinidad or customers will have in 5 years or more.
Also, I do prefer to have the generated CSS file be a one or the other
(compressed or not compressed) file rather than both.
As part of this change, can you also add a counter? If the number of
selectors exceeds the limit when generating the IE CSS file, an error or
warning gets logged so that if people are seeing strange behavior, we'd know
pretty quickly that this is the cause. I think that would be a friendly
thing to do for future developers.
Thank you,
Matt
On 1/30/07, Jeanne Waldman <je...@oracle.com> wrote:
>
> Hi,
>
> Well, it turns out that IE has a limit to the size of a CSS file. It's
> not the actual size of the file, but rather it is the
> # of CSS selectors. I did a test and found out that the limit is 4095
> CSS selectors.
> Firefox doesn't appear to have a limit.
>
> As you may know, the CSS file we generate contains both compressed and
> uncompressed styles, like this:
> .af_inputText_content, .x01 {background-color: blue}
>
> Our renderers render a shortened styleclass, unless
> the DISABLE_CONTENT_COMPRESSION flag is set to true in web.xml, then it
> renders the long styleclass.
> <input class="x01...>
>
> Ok, that's the background.
>
> *The problem* is that because we have a lot of custom components that
> we've built on top of Trinidad, and our customers
> have built custom components, etc, and these all have skinning,
> we have bumped up against the 4095 selector limit in IE. All selectors
> after the 4095th one are ignored.
>
> *A quick fix*, and probably a good one for a long time, is to render the
> styles in compressed mode when compression is on,
> or in uncompressed mode when compression if off. That will reduce our
> style selectors by 1/2, and will help performance to boot. :)
> I can also add a warning if we go past 4095 selectors for IE.
>
> Another solution is to break up the file into multiple files when I've
> reached the limit in one file, and include
> all the css files into the rendered page. I can do this in addition to
> the quick fix when I have more time.
> Or, I'll be forced to do this solution if the above solution can't be
> done for some reason.
>
> Anyway, let me know what you think about the fixes. I'll start
> investigating it to make sure it is possible and won't break
> anything. My main concern was if people were using our public style
> classes, like styleClass=".AFInstructionText", but
> it looks like we compress these when we are in compressed mode.
>
> Let me know if there are other things I should check.
>
> Thanks,
> Jeanne
>
>
[Skinning] CSS selector limit hit in IE
Posted by Jeanne Waldman <je...@oracle.com>.
Hi,
Well, it turns out that IE has a limit to the size of a CSS file. It's
not the actual size of the file, but rather it is the
# of CSS selectors. I did a test and found out that the limit is 4095
CSS selectors.
Firefox doesn't appear to have a limit.
As you may know, the CSS file we generate contains both compressed and
uncompressed styles, like this:
.af_inputText_content, .x01 {background-color: blue}
Our renderers render a shortened styleclass, unless
the DISABLE_CONTENT_COMPRESSION flag is set to true in web.xml, then it
renders the long styleclass.
<input class="x01...>
Ok, that's the background.
*The problem* is that because we have a lot of custom components that
we've built on top of Trinidad, and our customers
have built custom components, etc, and these all have skinning,
we have bumped up against the 4095 selector limit in IE. All selectors
after the 4095th one are ignored.
*A quick fix*, and probably a good one for a long time, is to render the
styles in compressed mode when compression is on,
or in uncompressed mode when compression if off. That will reduce our
style selectors by 1/2, and will help performance to boot. :)
I can also add a warning if we go past 4095 selectors for IE.
Another solution is to break up the file into multiple files when I've
reached the limit in one file, and include
all the css files into the rendered page. I can do this in addition to
the quick fix when I have more time.
Or, I'll be forced to do this solution if the above solution can't be
done for some reason.
Anyway, let me know what you think about the fixes. I'll start
investigating it to make sure it is possible and won't break
anything. My main concern was if people were using our public style
classes, like styleClass=".AFInstructionText", but
it looks like we compress these when we are in compressed mode.
Let me know if there are other things I should check.
Thanks,
Jeanne
Re: unknown-version in generated css file
Posted by Jeanne Waldman <je...@oracle.com>.
Yes, that is a better way.
I'll add this to our impl pom.xml and our api pom.xml files.
Thanks,
Jeanne
Adam Winer wrote:
> Jeanne,
>
> There's a better way. See:
>
> http://maven.apache.org/plugins/maven-jar-plugin/examples/manifest-customization.html
>
>
> "Starting with version 2.1, the maven-jar-plugin no longer creates the
> Specification and Implementation details in the manifest by default.
> If you want them you have to say so explicitly in your plugin
> configuration:
>
> <project>
> ...
> <build>
> <plugins>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-jar-plugin</artifactId>
> ...
> <configuration>
> <archive>
> <manifest>
>
> <addDefaultSpecificationEntries>true</addDefaultSpecificationEntries>
>
> <addDefaultImplementationEntries>true</addDefaultImplementationEntries>
> </manifest>
> </archive>
> </configuration>
> ...
> </plugin>
> </plugins>
> </build>
> ...
> </project>"
>
> -- Adam
>
>
>
> On 1/29/07, Jeanne Waldman <je...@oracle.com> wrote:
>> Ok, I figured out what is going on.
>>
>> If we want our manifest.mf file in our jar to show the implementation
>> version, then we need to:
>> 1. Add a manifest.mf file in the META-INF directory that has the
>> implementation-version in it.
>> 2. Add this configuration element to the pom.xml file:
>> <plugin>
>> <groupId>org.apache.maven.plugins</groupId>
>> <artifactId>maven-jar-plugin</artifactId>
>> * <configuration>
>> <archive>
>>
>> <manifestFile>src/main/resources/META-INF/MANIFEST.MF</manifestFile>
>> </archive>
>> </configuration>*
>> <executions>
>> <execution>
>> <goals>
>> <goal>test-jar</goal>
>> </goals>
>> </execution>
>> </executions>
>> </plugin>
>>
>> We are missing both of these.
>>
>> Does anyone object to my adding this to get our version in the
>> manifest.mf that's in the jar?
>> Should I do this for the api jar as well?
>> What should the version string be? This string will be in the generated
>> css file, at least for now. I plan to raise
>> another issue regarding the version string in the filename, but that can
>> wait.
>>
>> Thanks,
>>
>> - Jeanne
>>
>>
>> Jeanne Waldman wrote:
>> >
>> > I know how this could work (is supposed to work?), because we are
>> > doing something similar in our internal project . We have a
>> > MANIFEST.MF file in the impl's META-INF directory that defines
>> > implementation-version, and I think mvn automatically appends this
>> > information into the impl jar's MANIFEST.MF file.
>> > In Trinidad, though, I don't see this MANIFEST.MF file in the impl's
>> > META-INF directory. If I add it myself, do mvn clean install, it still
>> > doesn't work. But then after looking into it for our internal project,
>> > I found that it stopped working recently there, too.
>> >
>> > Anyway, Bud and I are looking into it, and I'll keep you posted. If
>> > you know something that I am missing, let me know. :)
>> >
>> > Thanks,
>> > Jeanne
>> >
>> > Jeanne Waldman wrote:
>> >
>> >> Hi Adam,
>> >> That's what I figured based, but I don't see the implementation
>> >> version in the manifest.mf.
>> >> So I should have asked, how does it get in the manifest.mf file?
>> >> Maybe I'm not building the jars with the correct flag.
>> >> I'm using "mvn install jdev:jdev".
>> >>
>> >> - Jeanne
>> >>
>> >> Adam Winer wrote:
>> >>
>> >>> The implementation version is defined in the manifest;
>> >>> since we're going from the StyleSheetDocumentParser's
>> >>> Package object, that should be the trinidad-impl.jar's
>> >>> MANIFEST.MF file.
>> >>>
>> >>> -- Adam
>> >>>
>> >>>
>> >>> On 1/19/07, Jeanne Waldman <je...@oracle.com> wrote:
>> >>>
>> >>>> Hi,
>> >>>>
>> >>>> I see that when I run a demo jspx file, the generated css file has
>> >>>> "unknown-version" in the name.
>> >>>> The reason, I believe, is that the
>> >>>> 'implPkg.getImplementationVersion()'
>> >>>> in the below code is returning null.
>> >>>> Why is this? Where are we setting (or supposed to be setting) the
>> >>>> implementation version exactly?
>> >>>> Does anyone else see this problem?
>> >>>> I think this code was added in this JIRA issue:
>> >>>> http://issues.apache.org/jira/browse/ADFFACES-147.
>> >>>>
>> >>>> Thanks,
>> >>>> Jeanne
>> >>>>
>> >>>> // If the document version is ${trinidad-version}, replace it
>> >>>> // with the version number right out of our manifest
>> >>>> if ("${trinidad-version}".equals(_documentVersion))
>> >>>> {
>> >>>> Class<StyleSheetDocumentParser> implClass =
>> >>>> StyleSheetDocumentParser.class;
>> >>>> Package implPkg = implClass.getPackage();
>> >>>> if ((implPkg != null) && (implPkg.getImplementationVersion()
>> >>>> != null))
>> >>>> {
>> >>>> _documentVersion =
>> >>>> implPkg.getImplementationVersion().replace('.','_');
>> >>>> }
>> >>>> else
>> >>>> {
>> >>>> _documentVersion = "unknown-version";
>> >>>> }
>> >>>> }
>> >>>>
>> >>>>
>> >>>
>> >>
>> >>
>> >
>> >
>>
>>
>
Re: unknown-version in generated css file
Posted by Adam Winer <aw...@gmail.com>.
Jeanne,
There's a better way. See:
http://maven.apache.org/plugins/maven-jar-plugin/examples/manifest-customization.html
"Starting with version 2.1, the maven-jar-plugin no longer creates the
Specification and Implementation details in the manifest by default.
If you want them you have to say so explicitly in your plugin
configuration:
<project>
...
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
...
<configuration>
<archive>
<manifest>
<addDefaultSpecificationEntries>true</addDefaultSpecificationEntries>
<addDefaultImplementationEntries>true</addDefaultImplementationEntries>
</manifest>
</archive>
</configuration>
...
</plugin>
</plugins>
</build>
...
</project>"
-- Adam
On 1/29/07, Jeanne Waldman <je...@oracle.com> wrote:
> Ok, I figured out what is going on.
>
> If we want our manifest.mf file in our jar to show the implementation
> version, then we need to:
> 1. Add a manifest.mf file in the META-INF directory that has the
> implementation-version in it.
> 2. Add this configuration element to the pom.xml file:
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-jar-plugin</artifactId>
> * <configuration>
> <archive>
>
> <manifestFile>src/main/resources/META-INF/MANIFEST.MF</manifestFile>
> </archive>
> </configuration>*
> <executions>
> <execution>
> <goals>
> <goal>test-jar</goal>
> </goals>
> </execution>
> </executions>
> </plugin>
>
> We are missing both of these.
>
> Does anyone object to my adding this to get our version in the
> manifest.mf that's in the jar?
> Should I do this for the api jar as well?
> What should the version string be? This string will be in the generated
> css file, at least for now. I plan to raise
> another issue regarding the version string in the filename, but that can
> wait.
>
> Thanks,
>
> - Jeanne
>
>
> Jeanne Waldman wrote:
> >
> > I know how this could work (is supposed to work?), because we are
> > doing something similar in our internal project . We have a
> > MANIFEST.MF file in the impl's META-INF directory that defines
> > implementation-version, and I think mvn automatically appends this
> > information into the impl jar's MANIFEST.MF file.
> > In Trinidad, though, I don't see this MANIFEST.MF file in the impl's
> > META-INF directory. If I add it myself, do mvn clean install, it still
> > doesn't work. But then after looking into it for our internal project,
> > I found that it stopped working recently there, too.
> >
> > Anyway, Bud and I are looking into it, and I'll keep you posted. If
> > you know something that I am missing, let me know. :)
> >
> > Thanks,
> > Jeanne
> >
> > Jeanne Waldman wrote:
> >
> >> Hi Adam,
> >> That's what I figured based, but I don't see the implementation
> >> version in the manifest.mf.
> >> So I should have asked, how does it get in the manifest.mf file?
> >> Maybe I'm not building the jars with the correct flag.
> >> I'm using "mvn install jdev:jdev".
> >>
> >> - Jeanne
> >>
> >> Adam Winer wrote:
> >>
> >>> The implementation version is defined in the manifest;
> >>> since we're going from the StyleSheetDocumentParser's
> >>> Package object, that should be the trinidad-impl.jar's
> >>> MANIFEST.MF file.
> >>>
> >>> -- Adam
> >>>
> >>>
> >>> On 1/19/07, Jeanne Waldman <je...@oracle.com> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> I see that when I run a demo jspx file, the generated css file has
> >>>> "unknown-version" in the name.
> >>>> The reason, I believe, is that the
> >>>> 'implPkg.getImplementationVersion()'
> >>>> in the below code is returning null.
> >>>> Why is this? Where are we setting (or supposed to be setting) the
> >>>> implementation version exactly?
> >>>> Does anyone else see this problem?
> >>>> I think this code was added in this JIRA issue:
> >>>> http://issues.apache.org/jira/browse/ADFFACES-147.
> >>>>
> >>>> Thanks,
> >>>> Jeanne
> >>>>
> >>>> // If the document version is ${trinidad-version}, replace it
> >>>> // with the version number right out of our manifest
> >>>> if ("${trinidad-version}".equals(_documentVersion))
> >>>> {
> >>>> Class<StyleSheetDocumentParser> implClass =
> >>>> StyleSheetDocumentParser.class;
> >>>> Package implPkg = implClass.getPackage();
> >>>> if ((implPkg != null) && (implPkg.getImplementationVersion()
> >>>> != null))
> >>>> {
> >>>> _documentVersion =
> >>>> implPkg.getImplementationVersion().replace('.','_');
> >>>> }
> >>>> else
> >>>> {
> >>>> _documentVersion = "unknown-version";
> >>>> }
> >>>> }
> >>>>
> >>>>
> >>>
> >>
> >>
> >
> >
>
>
Re: unknown-version in generated css file
Posted by Jeanne Waldman <je...@oracle.com>.
Ok, I figured out what is going on.
If we want our manifest.mf file in our jar to show the implementation
version, then we need to:
1. Add a manifest.mf file in the META-INF directory that has the
implementation-version in it.
2. Add this configuration element to the pom.xml file:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
* <configuration>
<archive>
<manifestFile>src/main/resources/META-INF/MANIFEST.MF</manifestFile>
</archive>
</configuration>*
<executions>
<execution>
<goals>
<goal>test-jar</goal>
</goals>
</execution>
</executions>
</plugin>
We are missing both of these.
Does anyone object to my adding this to get our version in the
manifest.mf that's in the jar?
Should I do this for the api jar as well?
What should the version string be? This string will be in the generated
css file, at least for now. I plan to raise
another issue regarding the version string in the filename, but that can
wait.
Thanks,
- Jeanne
Jeanne Waldman wrote:
>
> I know how this could work (is supposed to work?), because we are
> doing something similar in our internal project . We have a
> MANIFEST.MF file in the impl's META-INF directory that defines
> implementation-version, and I think mvn automatically appends this
> information into the impl jar's MANIFEST.MF file.
> In Trinidad, though, I don't see this MANIFEST.MF file in the impl's
> META-INF directory. If I add it myself, do mvn clean install, it still
> doesn't work. But then after looking into it for our internal project,
> I found that it stopped working recently there, too.
>
> Anyway, Bud and I are looking into it, and I'll keep you posted. If
> you know something that I am missing, let me know. :)
>
> Thanks,
> Jeanne
>
> Jeanne Waldman wrote:
>
>> Hi Adam,
>> That's what I figured based, but I don't see the implementation
>> version in the manifest.mf.
>> So I should have asked, how does it get in the manifest.mf file?
>> Maybe I'm not building the jars with the correct flag.
>> I'm using "mvn install jdev:jdev".
>>
>> - Jeanne
>>
>> Adam Winer wrote:
>>
>>> The implementation version is defined in the manifest;
>>> since we're going from the StyleSheetDocumentParser's
>>> Package object, that should be the trinidad-impl.jar's
>>> MANIFEST.MF file.
>>>
>>> -- Adam
>>>
>>>
>>> On 1/19/07, Jeanne Waldman <je...@oracle.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I see that when I run a demo jspx file, the generated css file has
>>>> "unknown-version" in the name.
>>>> The reason, I believe, is that the
>>>> 'implPkg.getImplementationVersion()'
>>>> in the below code is returning null.
>>>> Why is this? Where are we setting (or supposed to be setting) the
>>>> implementation version exactly?
>>>> Does anyone else see this problem?
>>>> I think this code was added in this JIRA issue:
>>>> http://issues.apache.org/jira/browse/ADFFACES-147.
>>>>
>>>> Thanks,
>>>> Jeanne
>>>>
>>>> // If the document version is ${trinidad-version}, replace it
>>>> // with the version number right out of our manifest
>>>> if ("${trinidad-version}".equals(_documentVersion))
>>>> {
>>>> Class<StyleSheetDocumentParser> implClass =
>>>> StyleSheetDocumentParser.class;
>>>> Package implPkg = implClass.getPackage();
>>>> if ((implPkg != null) && (implPkg.getImplementationVersion()
>>>> != null))
>>>> {
>>>> _documentVersion =
>>>> implPkg.getImplementationVersion().replace('.','_');
>>>> }
>>>> else
>>>> {
>>>> _documentVersion = "unknown-version";
>>>> }
>>>> }
>>>>
>>>>
>>>
>>
>>
>
>
Re: unknown-version in generated css file
Posted by Jeanne Waldman <je...@oracle.com>.
I know how this could work (is supposed to work?), because we are doing
something similar in our internal project . We have a MANIFEST.MF file
in the impl's META-INF directory that defines implementation-version,
and I think mvn automatically appends this information into the impl
jar's MANIFEST.MF file.
In Trinidad, though, I don't see this MANIFEST.MF file in the impl's
META-INF directory. If I add it myself, do mvn clean install, it still
doesn't work. But then after looking into it for our internal project, I
found that it stopped working recently there, too.
Anyway, Bud and I are looking into it, and I'll keep you posted. If you
know something that I am missing, let me know. :)
Thanks,
Jeanne
Jeanne Waldman wrote:
> Hi Adam,
> That's what I figured based, but I don't see the implementation
> version in the manifest.mf.
> So I should have asked, how does it get in the manifest.mf file? Maybe
> I'm not building the jars with the correct flag.
> I'm using "mvn install jdev:jdev".
>
> - Jeanne
>
> Adam Winer wrote:
>
>> The implementation version is defined in the manifest;
>> since we're going from the StyleSheetDocumentParser's
>> Package object, that should be the trinidad-impl.jar's
>> MANIFEST.MF file.
>>
>> -- Adam
>>
>>
>> On 1/19/07, Jeanne Waldman <je...@oracle.com> wrote:
>>
>>> Hi,
>>>
>>> I see that when I run a demo jspx file, the generated css file has
>>> "unknown-version" in the name.
>>> The reason, I believe, is that the 'implPkg.getImplementationVersion()'
>>> in the below code is returning null.
>>> Why is this? Where are we setting (or supposed to be setting) the
>>> implementation version exactly?
>>> Does anyone else see this problem?
>>> I think this code was added in this JIRA issue:
>>> http://issues.apache.org/jira/browse/ADFFACES-147.
>>>
>>> Thanks,
>>> Jeanne
>>>
>>> // If the document version is ${trinidad-version}, replace it
>>> // with the version number right out of our manifest
>>> if ("${trinidad-version}".equals(_documentVersion))
>>> {
>>> Class<StyleSheetDocumentParser> implClass =
>>> StyleSheetDocumentParser.class;
>>> Package implPkg = implClass.getPackage();
>>> if ((implPkg != null) && (implPkg.getImplementationVersion()
>>> != null))
>>> {
>>> _documentVersion =
>>> implPkg.getImplementationVersion().replace('.','_');
>>> }
>>> else
>>> {
>>> _documentVersion = "unknown-version";
>>> }
>>> }
>>>
>>>
>>
>
>
Re: unknown-version in generated css file
Posted by Jeanne Waldman <je...@oracle.com>.
Hi Adam,
That's what I figured based, but I don't see the implementation version
in the manifest.mf.
So I should have asked, how does it get in the manifest.mf file? Maybe
I'm not building the jars with the correct flag.
I'm using "mvn install jdev:jdev".
- Jeanne
Adam Winer wrote:
> The implementation version is defined in the manifest;
> since we're going from the StyleSheetDocumentParser's
> Package object, that should be the trinidad-impl.jar's
> MANIFEST.MF file.
>
> -- Adam
>
>
> On 1/19/07, Jeanne Waldman <je...@oracle.com> wrote:
>
>> Hi,
>>
>> I see that when I run a demo jspx file, the generated css file has
>> "unknown-version" in the name.
>> The reason, I believe, is that the 'implPkg.getImplementationVersion()'
>> in the below code is returning null.
>> Why is this? Where are we setting (or supposed to be setting) the
>> implementation version exactly?
>> Does anyone else see this problem?
>> I think this code was added in this JIRA issue:
>> http://issues.apache.org/jira/browse/ADFFACES-147.
>>
>> Thanks,
>> Jeanne
>>
>> // If the document version is ${trinidad-version}, replace it
>> // with the version number right out of our manifest
>> if ("${trinidad-version}".equals(_documentVersion))
>> {
>> Class<StyleSheetDocumentParser> implClass =
>> StyleSheetDocumentParser.class;
>> Package implPkg = implClass.getPackage();
>> if ((implPkg != null) && (implPkg.getImplementationVersion() !=
>> null))
>> {
>> _documentVersion =
>> implPkg.getImplementationVersion().replace('.','_');
>> }
>> else
>> {
>> _documentVersion = "unknown-version";
>> }
>> }
>>
>>
>
Re: unknown-version in generated css file
Posted by Adam Winer <aw...@gmail.com>.
The implementation version is defined in the manifest;
since we're going from the StyleSheetDocumentParser's
Package object, that should be the trinidad-impl.jar's
MANIFEST.MF file.
-- Adam
On 1/19/07, Jeanne Waldman <je...@oracle.com> wrote:
> Hi,
>
> I see that when I run a demo jspx file, the generated css file has
> "unknown-version" in the name.
> The reason, I believe, is that the 'implPkg.getImplementationVersion()'
> in the below code is returning null.
> Why is this? Where are we setting (or supposed to be setting) the
> implementation version exactly?
> Does anyone else see this problem?
> I think this code was added in this JIRA issue:
> http://issues.apache.org/jira/browse/ADFFACES-147.
>
> Thanks,
> Jeanne
>
> // If the document version is ${trinidad-version}, replace it
> // with the version number right out of our manifest
> if ("${trinidad-version}".equals(_documentVersion))
> {
> Class<StyleSheetDocumentParser> implClass =
> StyleSheetDocumentParser.class;
> Package implPkg = implClass.getPackage();
> if ((implPkg != null) && (implPkg.getImplementationVersion() != null))
> {
> _documentVersion =
> implPkg.getImplementationVersion().replace('.','_');
> }
> else
> {
> _documentVersion = "unknown-version";
> }
> }
>
>