I know very little about Trinidad, but if the primary purpose is to provide javascript and stylesheets, then the "document" tag could just be like any other tag and put into the <HEAD> section, yes? And having multiple kinds of these tags should not be a conflict.
<trinidadResourceProvider/> <tobagoResourceProvider/> <tomahawkResourceProvider/> [Note, I'm using these three as generic component-set examples. I'm not saying that we should have three or that any of these are required] Even if these require component containers, it'd still not cause conflicts: <body> <trinidadContainer> <tobagoContainer> <tomahawkContainer> [...] </tomahawkContainer> </tobagoContainer> </trinidadContainer> </body> The problem is when you require a special kind of form renderer or similar unique html element. I think in the case of partial page rendering, maybe the end user will simply have to pick which framework they want to use and understand that the other choices are no longer available once they do this. But using a particular form renderer should be a choice, and not using it should have as small of an impact as possible. It's still not clear to me what the extension filter issue is. I understand the big issue with being unable to use JSF & portlets, but outside of portlets, what's the issue? Note that I'm not against using something like the tags above instead of a filter. I'm just trying to understand the problem better, not defending the extension filter :-) On 3/15/07, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
On 3/15/07, Mike Kienenberger <[EMAIL PROTECTED]> wrote: > One big concern I have is that we do not go to such an extreme (like > Tobago did) that we are no longer compatible with other component > sets. Once you start requiring a specific kind of form or document, > then you've just made yourself incompatible with anything else that > might require a specific kind of form or document. Trinidad also has a *need* for document, when doing PPR http://incubator.apache.org/adffaces/trinidad-api/tagdoc/tr_panelPartialRoot.html > I'm not entirely certain what the issue with the Extensions filter is > (beyond portlet-incompatiblity). Once it's configured, it seems to > work just fine, and it doesn't break compatiblity with other component > sets. -portlet (trinidad uses a servlet for resources like images, not sure if that better works in portlet land) one of the other things is, that the *filter* adds the JS (addToHeader() or what ever the syntax is) -M > > On 3/15/07, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > > Also one *target* should be getting rid of the extension filter and > > use an approach like Trinidad document or Tobago's page, where the > > components (their renderers) register themselfs and put out their > > resources, like funny javascript. > > > > also the "common fileupload" (done in Tobago Contrib, already). > > > > On 3/15/07, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > > > myfaces commons should first contain the "tomahawk non-renderkit" things. > > > putting stuff there from tobago and trinidad is a next step, to me > > > > > > -M > > > > > > On 3/15/07, Gary VanMatre <[EMAIL PROTECTED]> wrote: > > > > > > > > >From: "Mike Kienenberger" <[EMAIL PROTECTED]> > > > > > > > > > > > > Still a huge first step would be a "myfaces commons", containing stuff > > > > > > > like updateActionlistener and validators/converters. > > > > > > > > > > On 3/15/07, Gary VanMatre wrote: > > > > > > I would think that even moving the validators and converters out would > > > > be a > > > > > > big step since they provide client side support. There would need to be > > > > a > > > > > > *single* script delivery mechanism and the component renderers would > > > > need to > > > > > > have API hooks in order to act on behalf of these "components" > > > > (converters, > > > > > > validators) that don't have renderers. > > > > > > > > > > We're only talking about moving things with no renderkit dependencies > > > > > into commons. That's true for most of the Tomahawk converters and > > > > > validators. Commons would contain things that should be usable in > > > > > any JSF implementation an d with any JSF component set. > > > > > > > > Oh, I was thinking about Trinidad's Converters and Validators. > > > > > > > > Gary > > > > > > > > > > > > > -- > > > Matthias Wessendorf > > > http://tinyurl.com/fmywh > > > > > > further stuff: > > > blog: http://jroller.com/page/mwessendorf > > > mail: mwessendorf-at-gmail-dot-com > > > > > > > > > -- > > Matthias Wessendorf > > http://tinyurl.com/fmywh > > > > further stuff: > > blog: http://jroller.com/page/mwessendorf > > mail: mwessendorf-at-gmail-dot-com > > > -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
