That makes sense for the hard-coded/constant configuration pieces. However, the missing piece is the support for page-specific or even app-specific agent settings. I don't want to add new behavior to an agent with the risk of breaking applications or pages that are expecting a different behavior.
For example in the case of the viewport configuration, only pages that were specifically designed for a device-width viewport should get it; other pages that weren't specifically designed for a device-width size could end up getting truncated undesirably. I suppose f:attribute tags could be added inside of tr:document for these agent-specific configurations but that's not much different or better than trh:meta. -Matt On Mon, Oct 4, 2010 at 2:39 PM, Blake Sullivan <blake.sulli...@oracle.com>wrote: > They worked mostly like the Agents in Trinidad do, since that's where the > Trinidad Agents come from. I think that in this case, we actually had > per-agent DocumentRenderer subclasses to handle agents that needed to output > specific content. However, at least for XHTML content, I think we either > want to delegate the optional rendering of this content directly to the > agent instance from the document renderer, or we want the Agent to cough up > the name/value pairs for the DocumentRenderer to output. > > -- Blake Sullivan > > > > On 10/4/10 12:17 PM, Matt Cooper wrote: > > I'd like to learn more about configuring Agents in UIX, is there any good > documentation that you would recommend? (My quick searches for information > about UIX or Trinidad Agent configuration has come up empty.) > > Thanks, > Matt > > On Mon, Oct 4, 2010 at 12:43 PM, Blake Sullivan <blake.sulli...@oracle.com > > wrote: > >> Trying again, since I got an error from the mail server. >> >> -- Blake >> >> On 10/4/10 11:25 AM, Blake Sullivan wrote: >> >> The document renderer should be delegating to the Agent implementation. >> This is essentially what happened in UIX, which is where the idea of the >> metacontainer facet came from (in fact as part of handling exactly this >> problem, outputting meta tags for mobile devices, in that case for Palm) >> >> -- Blake Sullivan >> >> >> >> On 10/4/10 9:41 AM, Matt Cooper wrote: >> >> Hi Blake, >> >> How would you recommend exposing the configuration of the viewport >> metadata since it is agent-specific to iOS, Android, and Windows Mobile 7 >> agents? >> >> Thanks, >> Matt >> >> On Mon, Oct 4, 2010 at 10:16 AM, Blake Sullivan < >> blake.sulli...@oracle.com> wrote: >> >>> I'm not sure that I'm a fan of this approach. Actually, I'm not a fan >>> at all. >>> >>> 1) Our first choice should be for any agent-specific meta attributes to >>> be generated by the document renderer >>> 2) Any standard attributes that happen to be rendered as meta attributes >>> should be exposed as document attributes >>> 3) Support for weird meta attributes should be tag children of the >>> document tag and should not require the use of a tr:group. >>> >>> -- Blake Sullivan >>> >>> >>> >>> >>> On 9/29/10 4:30 PM, Matt Cooper (JIRA) wrote: >>> >>>> Ability to easily create a meta tag >>>> ----------------------------------- >>>> >>>> Key: TRINIDAD-1930 >>>> URL: >>>> https://issues.apache.org/jira/browse/TRINIDAD-1930 >>>> Project: MyFaces Trinidad >>>> Issue Type: Improvement >>>> Components: Components >>>> Affects Versions: 1.2.14-core , 2.0.0.2-core >>>> Reporter: Matt Cooper >>>> Assignee: Matt Cooper >>>> >>>> >>>> Ability to easily create a meta tag (e.g. >>>> http://developer.apple.com/library/safari/#documentation/appleapplications/reference/safarihtmlref/articles/MetaTags.htmlor >>>> http://www.webmarketingnow.com/tips/meta-tags-uncovered.html ) via a >>>> new trh:meta tag. >>>> >>>> Currently it is quite tedious to create a meta tag out of a component: >>>> >>>> <tr:document ...> >>>> <f:facet name="metaContainer"> >>>> <tr:group id="metaContainer"> >>>> <tr:outputText escape="false" >>>> value='<meta name="viewport" >>>> content="width=device-width">' >>>> id="metaTag1"/> >>>> <tr:outputText escape="false" >>>> value='<meta name="apple-mobile-web-app-capable" >>>> content="yes">' >>>> id="metaTag2"/> >>>> <tr:outputText escape="false" >>>> value='<meta http-equiv="refresh" >>>> content="2;url=./test/index.jspx">' >>>> id="metaTag3"/> >>>> </tr:group> >>>> </f:facet> >>>> </tr:document> >>>> >>>> It would be much better if we had a trh:meta component that looked like >>>> this: >>>> >>>> <tr:document ...> >>>> <f:facet name="metaContainer"> >>>> <tr:group id="metaContainer"> >>>> <trh:meta name="viewport" content="width=device-width"/> >>>> <trh:meta name="apple-mobile-web-app-capable" content="yes"/> >>>> <trh:meta name="refresh" nameType="http-equiv" >>>> content="2;url=./test/index.jspx"/> >>>> </tr:group> >>>> </f:facet> >>>> </tr:document> >>>> >>>> So I would like to see a new trh:meta component that has an API like >>>> this: >>>> >>>> Tag name:<trh:meta> >>>> UIComponent class: org.apache.myfaces.trinidad.component.core.CoreMeta >>>> Component type: org.apache.myfaces.trinidad.CoreMeta >>>> The meta component generates an HTML meta tag and is intended to be used >>>> inside either the trh:head tag or the document component's metaContainer >>>> facet. >>>> >>>> Events >>>> Type Phases Description >>>> org.apache.myfaces.trinidad.event.AttributeChangeEvent Invoke >>>> Application, Apply Request Values Event delivered to describe an >>>> attribute change. Attribute change events are not delivered for any >>>> programmatic change to a property. They are only delivered when a renderer >>>> changes a property without the application's specific request. An example >>>> of >>>> an attribute change events might include the width of a column that >>>> supported client-side resizing. >>>> >>>> Attributes >>>> Name Type Supports EL? Description >>>> attributeChangeListener javax.el.MethodExpression Only EL >>>> a method reference to an attribute change listener. Attribute >>>> change >>>> events are not delivered for any programmatic change to a property. They >>>> are >>>> only delivered when a renderer changes a property without the application's >>>> specific request. An example of an attribute change events might include >>>> the >>>> width of a column that supported client-side resizing. >>>> binding org.apache.myfaces.trinidad.component.core.CoreMeta >>>> Only EL an EL reference that will store the component instance on a >>>> bean. This can be used to give programmatic access to a component from a >>>> backing bean, or to move creation of the component to a backing bean. >>>> id String No the identifier for the component. The identifier >>>> must follow a subset of the syntax allowed in HTML: >>>> >>>> * Must not be a zero-length String. >>>> * First character must be an ASCII letter (A-Za-z) or an underscore >>>> ('_'). >>>> * Subsequent characters must be an ASCII letter or digit >>>> (A-Za-z0-9), an underscore ('_'), or a dash ('-'). >>>> >>>> rendered boolean Yes whether the component is >>>> rendered. When set to false, no output will be delivered for this component >>>> (the component will not in any way be rendered, and cannot be made visible >>>> on the client). >>>> name String Yes the name or http-equiv attribute of the meta >>>> attribute (see nameType) >>>> nameType String Yes "name" or "http-equiv" indicating which >>>> kind of name attribute is desired ("name" is the most common attribute but >>>> some older meta tags need "http-equiv") >>>> content String Yes the content of the meta attribute >>>> >>>> >>> >> >> >> > >
