You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Blake Sullivan <bl...@oracle.com> on 2010/10/04 18:16:23 UTC
Re: [jira] Created: (TRINIDAD-1930) Ability to easily create a meta
tag
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.html or 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
>
Re: [jira] Created: (TRINIDAD-1930) Ability to easily create a meta
tag
Posted by Blake Sullivan <bl...@oracle.com>.
On 10/4/10 2:07 PM, Matt Cooper wrote:
> 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 think that Gabrielle's comments about using skinning properties might
be the correct solution for the app-specific part of this, though that
begs the question of whether similar support should be available for all
component attributes, which might be a good reason for tabling the
discussion.
> 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.
As I said in my original e-mail, there are two classes of meta-data
attributes:
1) Attributes that we think are generally applicable across rendering
technologies
2) Those that we think are very-specific to HTTP or for which we haven't
implemented a solution for 1) yet
For attributes in 1), we should be adding actual attributes (potentially
expert) to the document component. For attributes in 2), supporting a
separate Map of metadata attributes on the document component does a
significantly better job of supporting the component abstraction than
using <tr:group> with a metada-specific child tag.
-- Blake Sullivan
>
> -Matt
>
> On Mon, Oct 4, 2010 at 2:39 PM, Blake Sullivan
> <blake.sullivan@oracle.com <ma...@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.sullivan@oracle.com <ma...@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.sullivan@oracle.com
>>>> <ma...@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.html
>>>> or
>>>> 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
>>>>
>>>>
>>>>
>>>
>>
>>
>
>
Re: [jira] Created: (TRINIDAD-1930) Ability to easily create a meta tag
Posted by Matt Cooper <mc...@apache.org>.
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 <bl...@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.sullivan@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.sullivan@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
>>>>
>>>>
>>>
>>
>>
>>
>
>
Re: [jira] Created: (TRINIDAD-1930) Ability to easily create a meta
tag
Posted by Blake Sullivan <bl...@oracle.com>.
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.sullivan@oracle.com <ma...@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.sullivan@oracle.com <ma...@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.html
>>> or
>>> 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
>>>
>>>
>>>
>>
>
>
Re: [jira] Created: (TRINIDAD-1930) Ability to easily create a meta tag
Posted by Matt Cooper <mc...@apache.org>.
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
<bl...@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.sullivan@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
>>>
>>>
>>
>
>
>
Re: [jira] Created: (TRINIDAD-1930) Ability to easily create a meta
tag
Posted by Blake Sullivan <bl...@oracle.com>.
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.sullivan@oracle.com <ma...@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.html
>> or
>> 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
>>
>>
>>
>
Re: [jira] Created: (TRINIDAD-1930) Ability to easily create a meta tag
Posted by Matt Cooper <mc...@apache.org>.
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
<bl...@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
>>
>>
>