[
https://issues.apache.org/jira/browse/TRINIDAD-1217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12631564#action_12631564
]
Scott O'Bryan commented on TRINIDAD-1217:
-----------------------------------------
Yeah, Jeanne, I see what you are talking about. The unfortunate part is that
the caching of the stylesheet object is largely based off the stylesheet file.
In other words, the two are inseparable. I do think we'll need another JIRA to
fix this for portals in general, but right now we have a number of problems
with multiple portlets on a page at the same time.
The base issue with this, from what I'm hearing, is NOT that the cached file is
getting created, rather it's that once cached, hitting the code from a portlet
environment first causes the destktop stylesheets to have the wonkey portlet
url's. I think I'd like to take the perfomance hit for now and fix the
"broken" behavior. Not generating these cached CSS files in the future would
be an improvement but could be handled by another issue.
I'm going to upload a patch soon which essentially handles the issue we're
seeing, but none of the performance concerns. I'll also file a JIRA ticket to
redo how some of the stylesheet caching works in case someone has time to get
to it. For now, here is what I'd like to do:
* Add an isPortletMode method to the StyleContext and StyleContextImpl which
tells if the current stylesheet is being rendered in the PortletMode or not.
This allows us to encode our stylesheet entries and stylesheet cache files with
a special key saying they were rendered in stylesheet mode.
* Enhance FileSystemStyleCache to keep track of whether a particular skin was
generated in a portlet or not. Current criteria is based off compression,
direction, browser and version, platform, locale, and accessibility profile. I
would add portlet mode to this criteria so that a simple.desktop skin generate
by a portlet is cached differently then a simple.desktop skin generated by a
servlet.
* For saved stylesheets, any stylesheets which are cached on the server would
be saved with an "_prtl" prefix. This ensures that servlet generated
stylesheets do not interfere with portlet generated ones.
* I'm also going to add some performance enhancements to the stylesheet cache
because, well, I can. :)
Then a future enhancement would be to address the fundamental issue with the
cache and that is that stylesheets should only written on an as-needed basis.
Probably some sort of lazy initialization when the resource servlet tried to
actually fetch the file url or something.
> in portals stylesheet generated in the producer even when skin matches and
> suppress is true
> -------------------------------------------------------------------------------------------
>
> Key: TRINIDAD-1217
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1217
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Skinning
> Affects Versions: 1.0.9-core, 1.2.9-core
> Reporter: Jeanne Waldman
> Assignee: Jeanne Waldman
>
> Remember that the same web-app is used in both portlet and servlet
> environment. So say we run this web-app as portlet first and the producer
> skin matches the consumer, so the producer shares the css generated by the
> consumer (ie the producer css is not being used by the producer, but it's
> generated anyway because of this bug - note that the url in the css is one of
> the funny portlet url (starts with wsrp_rewrite)). So far so good here.
> Now access the web-app as servlet. Since the css was already generated by the
> producer (when accessed as portlet), adfv doesn't generate a new stylesheet -
> but the urls to the icons are wrong.
> e.g.,
> .x1n
> {...;background-image:url(wsrp_rewrite?wsrp-urlType=resource&wsrp-url=http%3A%2F%2F
> localhost%3A8988%2Fdiv%2Fportletresource%2FC%253A130.35.95.52%253A2cb0f
> 9b5%253A11ac1ce2de8%253A-7ffb%2FS%253A130.35.95.52%253A-2cbc5940%25
> 3A11ac6466884%253A-7fff%253AE%253Aiadf_jsf__untitled1_jspx%253A130.35.95.5
> 2%253A2cb0f9b5%253A11ac
> 1ce2de8%253A-7ffa%2Fadf%2Fimages%2Fclose.gif&wsrp-requiresRewrite=false/wsrp_rewrite)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
