Ok I think I'll go with facet or icon since it seems to be the most accepted
scenario. I'm going to comment the component accordingly.
On 9/20/07, Adam Winer [EMAIL PROTECTED] wrote:
I'm happier if we don't add any attributes... We definitely
want default behavior where, if nothing is
Hello all and principally Jeanne,
Is there a way to use icon aliases with XSS and/or XhtmlSkin? I wanted to
create the following two aliases to enable easy use of tr:icon:
- .AFBusyIcon:alias
- .AFReadyIcon:alias
And have the following two selectors reference them:
-
In XSS they are 'named' styles:
for example:
style name="AFStartTextAlign"
property name="text-align"left/property
/style
if .AFStartTextAlign:alias
in css.
Look in base-desktop.xss for other examples, and how you include this
in other styles.
- Jenane
Simon Lessard wrote:
Hello all and
Hello Jeanne,
I'm going to try, but I thought it would be different for icon, because all
icon aliases are defined in XhtmlSkin and not in base-desktop.xss.
On 9/21/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
In XSS they are 'named' styles:
for example:
style name=AFStartTextAlign
Oh, sorry. Didn't notice the icon. You are right. You can't do it in
xss or css right now. There's a JIRA issue requesting -tr-rule-ref for
icons.
To do this in the Skin java file you would use the ReferenceIcon.
e.g.,
// tr:panelHeader header icons point to reference icon so they can
// be
Great! That's exactly what I was looking for :)
Thanks.
On 9/21/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
Oh, sorry. Didn't notice the icon. You are right. You can't do it in xss
or css right now. There's a JIRA issue requesting -tr-rule-ref for icons.
To do this in the Skin java file you
How about hideReadyIcon = "true/false"
hideBusyIcon = "true/false".
It's explicit and the user doesn't have to guess at the logic we are
using -- or read the doc.
- Jeanne
Simon Lessard wrote:
Hello Adam,
On 9/18/07, Adam Winer [EMAIL PROTECTED] wrote:
I
think it should be as simple
Hello Jeanne,
Something alike was proposed at first, but again the most common usage kicks
in. Such attributes imply, for GMail like behavior:
tr:statusIndicator hideReadyIcon=true hideBusyIcon=true
f:facet name=busy
tr:outputText value=Loading.../
/f:facet
/tr:statusIndicator
It's a
The other api I like is one you mentioned was not backwards compatible,
and that is to have them put the icon in the facet if they want an icon.
I agree that the below API is busy, but to me it is clear. No guessing
what the logic is.
Simon Lessard wrote:
Hello Jeanne,
Something alike was
I'm happier if we don't add any attributes... We definitely
want default behavior where, if nothing is specified,
the icons get shown.
-- Adam
On 9/20/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
The other api I like is one you mentioned was not backwards compatible, and
that is to have
Hello Adam,
On 9/18/07, Adam Winer [EMAIL PROTECTED] wrote:
I think it should be as simple as for each of busy and
ready, render the facet if it's present, the icon if it's not.
The only issue with that behavior is most common usage. I think the most
common usage with facets is going to be a
I see what you're saying... I think I'd be OK then with a rule
where specifying either facet gets rid of both icons. Especially
with a bit of doc explaining why it does that (exactly the example
you give).
-- Adam
On 9/19/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hello Adam,
On 9/18/07,
OK, five seconds more consideration, and now I'm torn.
It's easy enough to write:
tr:statusIndicator
f:facet name=busyLoading.../f:facet
f:facet name=readytr:outputText//f:facet
/tr:statusIndicator
... which would have the same effect. So I could really
go either way.
-- Adam
On
Yes, but why pollute the page unnecessarily with an empty outputText?
If I approach the subject from a maintainability perspective, I think
its more intuitive for the documentation to state why the icon is gone
then to have to figure out why some developer stuck an empty outputText
into a
On 9/19/07, Perkins, Nate-P63196 [EMAIL PROTECTED] wrote:
Yes, but why pollute the page unnecessarily with an empty outputText?
Indeed. (I'd probably use a tr:group, but same deal).
The flip side is wondering how much of a pain it'd be to
implement I want to change the ready icon, but not the
On the vote for set a facet = no icons, someone could easily:
tr:statusIndicator
f:facet name=busytr:outputText value=busy//f:facet
f:facet name=readtr:icon name=... //f:facet
/tr:statusIndicator
This way they can sill use the icon. Just requires more typing
On 9/19/07, Adam Winer [EMAIL
IMO, if we have a facet, we don't render the icon. No need
for an attribute at all.
Anyone that desperately needs both the facet and the icon
can render two statusIndicators.
-- Adam
On 9/18/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi,
On 9/18/07, Simon Lessard [EMAIL PROTECTED]
that sounds like the best solution.
On 9/18/07, Adam Winer [EMAIL PROTECTED] wrote:
IMO, if we have a facet, we don't render the icon. No need
for an attribute at all.
Anyone that desperately needs both the facet and the icon
can render two statusIndicators.
-- Adam
On 9/18/07,
Or put tr:icon in the facet. Yeah, that sound good too.
On 9/18/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
that sounds like the best solution.
On 9/18/07, Adam Winer [EMAIL PROTECTED] wrote:
IMO, if we have a facet, we don't render the icon. No need
for an attribute at all.
Speaking of which, I forgot to add skin documentation. I'll do that right
away.
I would also like to add a new attribute to skip the icon rendering. If it
hasn't been of backward compatibility, I would have simply removed them
since it's easily doable with a combination of facet and tr:icon, but
Hmm not as simple as I though. Before pushing a patch let decide on the
behavior for every use case:
Both facets are specified and rendered -- Don't render any icon
Both facets are specified but only one is rendered -- ?
Both facets are specified but neither are rendered -- ?
Only one facet is
I think
no facet = icon is rendered;
otherwise, no icon is rendered.
-M
On 9/18/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hmm not as simple as I though. Before pushing a patch let decide on the
behavior for every use case:
Both facets are specified and rendered -- Don't render any icon
one more,
what about changing the cursor, when statusIndicator is busy ?
-M
On 9/18/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
I think
no facet = icon is rendered;
otherwise, no icon is rendered.
-M
On 9/18/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hmm not as simple as I
Hmm I don't think this should be directly in the indicator contract. If it
is, then I think it should be a new type attribute on the status indicator
with the following values:
icon: render default icons (default value)
cursor: change the cursor on document level (requires a way to specified
the
I'm not sure a cursor will work. The cursor applies to the front-most
element underneath the cursor. The only way, that I am aware of, to
get a global cursor is to float (using absolute positioning and
z-index) an HTML element (like a DIV) over the entire page. This is
what the blocking
It's possible to set the cursor on the body node, would have to use a skin
property rather than a style property, but I'm not sure I like that.
On 9/18/07, Andrew Robinson [EMAIL PROTECTED] wrote:
I'm not sure a cursor will work. The cursor applies to the front-most
element underneath the
That does not fully work, in Firefox at least (just tried it, the
cursor still reverts to an I-Beam for input text boxes for example)
On 9/18/07, Simon Lessard [EMAIL PROTECTED] wrote:
It's possible to set the cursor on the body node, would have to use a skin
property rather than a style
BTW: this does work, but is ugly:
BODY * {
cursor: pointer !important;
}
On 9/18/07, Andrew Robinson [EMAIL PROTECTED] wrote:
That does not fully work, in Firefox at least (just tried it, the
cursor still reverts to an I-Beam for input text boxes for example)
On 9/18/07, Simon Lessard
...was just a thought ... :-)
On 9/18/07, Andrew Robinson [EMAIL PROTECTED] wrote:
BTW: this does work, but is ugly:
BODY * {
cursor: pointer !important;
}
On 9/18/07, Andrew Robinson [EMAIL PROTECTED] wrote:
That does not fully work, in Firefox at least (just tried it, the
cursor
A way to set the cursor directly would be nice. I'm sure we're going to see
users wanting that. Is there a way to directly set the current cursor?
Dunno, some obscure JavaScript function...
Also, I could use more input on the indicator behavior in case only one
facet is specified and/or rendered.
That's the div shown when there's a visible dialog I think, because
everything still works during PPR events.
On 9/18/07, Andrew Robinson [EMAIL PROTECTED] wrote:
There is already a blocking panel rendered by Trinidad. Looks like this:
div id=_pprBlockingDiv onkeypress=return false;
There is no reason to change the cursor unless you want the GUI to be
unresponsive to clicks and key presses right? The goal of a busy
cursor would be to block any user input and let them know things are
busy. In that case this works:
tr:commandLink partialSubmit=true blocking=true /
Then if
Another way would be a blocking panel component that you set in the
statusIndicator's busy facet. Blocking panel skinning could be set to
absolute positioning to cover the whole screen and apply transparency
masking. Some JavaScript could also be added to it to prevent event
bubbling. That would
There is already a blocking panel rendered by Trinidad. Looks like this:
div id=_pprBlockingDiv onkeypress=return false; onmouseup=return
false; onmousedown=return false; onkeyup=return false;
onkeydown=return false; style=position: absolute; left: 0pt; top:
0pt; width: 0pt; height: 0pt; cursor:
I think it should be as simple as for each of busy and
ready, render the facet if it's present, the icon if it's not.
-- Adam
On 9/18/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hmm not as simple as I though. Before pushing a patch let decide on the
behavior for every use case:
Both facets
IIRC, the blocking div is some ld content rendered by the
long-ago ADF PPR code, never even turned on in Trinidad.
If we're going to do any cursor manipulation, I agree that it shouldn't
be on statusIndicator. It might be a skinning property for
af|document.
-- Adam
On 9/18/07, Andrew
36 matches
Mail list logo
