oh... I forgot to mention, that by default we compress the skinning keys,
since .af_selectManyShuttle_blah-foo-bar is much more "chatty", that .xyz
-M
On Nov 22, 2007 4:34 PM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> 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
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
