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.sulli...@oracle.com <mailto: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 <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
