[API] new api on Skin

[Jeanne Waldman <je...@oracle.com>]

I'm close to checking in the code regarding adding the Skin's 
styleSheetDocument's id to
the generated css file instead of the version so it will changed when 
the skin's styles
change.. I created  a JIRA issue to track it.
http://issues.apache.org/jira/browse/ADFFACES-439
ALSO:
I would like to propose an API on the Skin class to get the Skin's 
StyleSheetDocument's id.
This is so a portal can tell us not to render our stylesheet if they 
have a matching one.
They can use this api to get their stylesheet document id and send it to 
us, along with a
suppressStylesheet flag, and we can suppress the stylesheet if they 
match, otherwise,
we'll default to the portlet skin.
 
  /**
   * Returns the id of the Skin's stylesheet document. This is the 
StyleSheetDocument's
   * id.
   */
  public String getStyleSheetDocumentId(RenderingContext arc);

Thanks,
Jeanne

Jeanne Waldman wrote:
> Hello,
>
> I'm proposing putting a hashcode value in the generated css file 
> instead of a version string.
> Let me explain why:
>
> Now your generated css file will be something like this
> "purple-desktop-incubator-1_2-07-mar-SNAPSHOT-en-ltr-ie-6.css"
> where the version is 1_2-07-mar-SNAPSHOT
>
> The version # was in the css file name originally so that when a new 
> version
> was released the css file name would change and thus
> the user will get the new css file instead of the old one that is 
> cached in the browser.
>
> A person that creates a skin might update his skin more often than 
> Trinidad releases
> and so he'll want the generated css filename to change to match his 
> release, not Trinidad's.
> One way to work around the problem is to add the version to the skin 
> file and use that
> in the generated filename.
> But that is one more file that has to get updated when someone changes 
> the skin and/or
> releases a new release, so I don't like that idea. I've also discussed 
> with some coworkers using
> a timestamp, but that got nixed because of the complexities that might 
> occur in load-balanced
> environments.
>
> I think a better way is to create a hashcode of the Skin's 
> StyleSheetDocument and
> write this in the file. So far people seem to like this idea, and I 
> want to know what you think.
>
> Creating a hashcode on StyleSheetDocument
> also solves another problem I must solve for the portal project I'm 
> working on.
> They want to tell me to use a particular skin and suppress my 
> stylesheet so that their stylesheet
> can be used instead - this is for performance reasons.
> I can do that ok, but only if the skin's StyleSheetDocument's hashcode
> matches, otherwise the portlet may very well not work with the outer 
> page's (portal's) stylesheet if
> they don't match exactly.
> So I need the portal to tell me their skin's StyleSheetDocument's 
> 'id/hashcode' and I will compare it
> to the portlet's and if they are not the same I will render the 
> portlet skin instead of the skin they requested.
>
> Anyway, let me know what you think about adding the hashcode to the 
> filename or if you have any questions about this
> proposal.
> Also, for the portal part of the problem, I'll need to add an api to 
> the Skin class to getStyleSheetDocumentId
> or something like that.
>
> Thanks,
> Jeanne
>
>
>
>
>

Re: [API] new api on Skin

[Matthias Wessendorf <ma...@apache.org>]

+1

On 4/5/07, Jeanne Waldman <je...@oracle.com> wrote:
> I'm close to checking in the code regarding adding the Skin's
> styleSheetDocument's id to
> the generated css file instead of the version so it will changed when
> the skin's styles
> change.. I created  a JIRA issue to track it.
> http://issues.apache.org/jira/browse/ADFFACES-439
> ALSO:
> I would like to propose an API on the Skin class to get the Skin's
> StyleSheetDocument's id.
> This is so a portal can tell us not to render our stylesheet if they
> have a matching one.
> They can use this api to get their stylesheet document id and send it to
> us, along with a
> suppressStylesheet flag, and we can suppress the stylesheet if they
> match, otherwise,
> we'll default to the portlet skin.
>
>   /**
>    * Returns the id of the Skin's stylesheet document. This is the
> StyleSheetDocument's
>    * id.
>    */
>   public String getStyleSheetDocumentId(RenderingContext arc);
>
> Thanks,
> Jeanne
>
> Jeanne Waldman wrote:
> > Hello,
> >
> > I'm proposing putting a hashcode value in the generated css file
> > instead of a version string.
> > Let me explain why:
> >
> > Now your generated css file will be something like this
> > "purple-desktop-incubator-1_2-07-mar-SNAPSHOT-en-ltr-ie-6.css"
> > where the version is 1_2-07-mar-SNAPSHOT
> >
> > The version # was in the css file name originally so that when a new
> > version
> > was released the css file name would change and thus
> > the user will get the new css file instead of the old one that is
> > cached in the browser.
> >
> > A person that creates a skin might update his skin more often than
> > Trinidad releases
> > and so he'll want the generated css filename to change to match his
> > release, not Trinidad's.
> > One way to work around the problem is to add the version to the skin
> > file and use that
> > in the generated filename.
> > But that is one more file that has to get updated when someone changes
> > the skin and/or
> > releases a new release, so I don't like that idea. I've also discussed
> > with some coworkers using
> > a timestamp, but that got nixed because of the complexities that might
> > occur in load-balanced
> > environments.
> >
> > I think a better way is to create a hashcode of the Skin's
> > StyleSheetDocument and
> > write this in the file. So far people seem to like this idea, and I
> > want to know what you think.
> >
> > Creating a hashcode on StyleSheetDocument
> > also solves another problem I must solve for the portal project I'm
> > working on.
> > They want to tell me to use a particular skin and suppress my
> > stylesheet so that their stylesheet
> > can be used instead - this is for performance reasons.
> > I can do that ok, but only if the skin's StyleSheetDocument's hashcode
> > matches, otherwise the portlet may very well not work with the outer
> > page's (portal's) stylesheet if
> > they don't match exactly.
> > So I need the portal to tell me their skin's StyleSheetDocument's
> > 'id/hashcode' and I will compare it
> > to the portlet's and if they are not the same I will render the
> > portlet skin instead of the skin they requested.
> >
> > Anyway, let me know what you think about adding the hashcode to the
> > filename or if you have any questions about this
> > proposal.
> > Also, for the portal part of the problem, I'll need to add an api to
> > the Skin class to getStyleSheetDocumentId
> > or something like that.
> >
> > Thanks,
> > Jeanne
> >
> >
> >
> >
> >
>


-- 
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com