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 <mailto: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 <mailto: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.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
