Hi simon,
On Nov 22, 2007 4:07 PM, Simon Kitching <[EMAIL PROTECTED]> wrote:
> Hi Matthias,
>
> Sorry but this isn't clear to me.
>
> Is exactly one stylesheet rendered, or one per component that wants one?
there is one "global" CSS file, that contains all selectors for the components.
That is generated, based on the XSS file (like base-desktip.xss)
these XSS files contain the selectors, like:
af|selectManyShuttle::box-content
af|selectOrderShuttle::box-content
> * If only one stylesheet, then isn't that rather clumsy? It must be a rather
> large stylesheet, and adding a new component means updating the global
> stylesheet.
no. you can add your selectors for the custom components to your own skinning.
That allows you also to actually change skinning behavior of the
*default* (like if you don't like the icon for the calendar).
> * If one stylesheet per component, then how does trinidad know what
> components are in the page at the time the trh:head component is rendered?
> For JSF1.1+jsp, the components may not yet have been created..
well... inside the XSS file, you skin the components on a component base,
BUT when the parser figures out, that two (or more) selector are
similar (for instance the two mentioned shuttle box-content areas are
the same), it groups the selectors like:
.af_selectOrderShuttle_box-content, .af_selectManyShuttle_box-content
{
blah;
}
>
> And does Trinidad allow components to depend on javascript files?
yes!
The Renderer does something like:
...
writer.writeAttribute(XhtmlConstants.ONCLICK_ATTRIBUTE,
"TrPanelPopup.hidePopup(event); return false;",
null);
...
And....
you register your custom JS in a ResourceLoader, like we do it in our
"CoreCommonScriptsResourceLoader".
BTW. [1] has more on skinning.
HTH,
Matthias
[1] http://myfaces.apache.org/trinidad/devguide/skinning.html
>
> Regards,
>
> Simon
>
> ---- Matthias Wessendorf <[EMAIL PROTECTED]> schrieb:
>
> > Hi Simon,
> >
> > usually you use <tr:document> (or <trh:html>, <trh:head>, <trh:body>).
> > The TrDocument uses the HeadRender to render something like this:
> >
> > <link rel="stylesheet" charset="UTF-8" type="text/css"
> > href="/trinidad/adf/styles/cache/minimal-desktop-ne8suk-en-gecko-cmp.css">
> >
> > the truth is here, that HeadREnderer uses the StyleSheetRenderer
> > (accessable via <trh:styleSheet> as well) to render the lines above.
> >
> > The StyleSheetRenderer get's the URL (like here to the cache-folder)
> > via a StyleProvider implementation.
> >
> > HTH,
> > Matthias
> >
> > On Nov 22, 2007 1:38 PM, Simon Kitching <[EMAIL PROTECTED]> wrote:
> > > Hi All,
> > >
> > > Tomahawk's ExtensionsFilter allows components to cause data to be
> > > inserted into the HEAD section of a generated HTML page, even when they
> > > occur in the body. In particular, this allows components to output
> > > references to javascript and css that they need. This is extremely
> > > useful, but the implementation is rather ugly.
> > >
> > > I know almost nothing about Trinidad, but it presumably has something
> > > similar, in order to provide default skins for its components. Would
> > > someone be kind enough to give a very brief summary of how Trinidad
> > > achieves this? I'm hoping that there is something there I can steal to
> > > improve Tomahawk's approach.
> > >
> > > Currently, tomahawk ExtensionFilter's standard approach is to buffer the
> > > entire output. As each component renders itself, it can register
> > > resources it needs in a request-scoped variable. After rendering is
> > > complete, the ExtensionFilter scans the buffered output for the closing
> > > </head> tag and similar bits, and inserts and registered resources into
> > > the buffer. This is inefficient due to the buffering, and the code is
> > > complex (a simple HTML parser is needed!).
> > >
> > > Thanks,
> > >
> > > Simon
> > >
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > further stuff:
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > mail: matzew-at-apache-dot-org
>
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
