[
https://issues.apache.org/jira/browse/TOMAHAWK-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528286
]
Matthias Weßendorf commented on TOMAHAWK-1115:
--
yes, that's right. Currently there is support for
How can to make hyperlink on tc:menu
--
Key: TOBAGO-490
URL: https://issues.apache.org/jira/browse/TOBAGO-490
Project: MyFaces Tobago
Issue Type: Wish
Reporter: adam
Dear all ;
i want to
How can to make hyperlink on tc:menu
--
Key: TOBAGO-492
URL: https://issues.apache.org/jira/browse/TOBAGO-492
Project: MyFaces Tobago
Issue Type: New Feature
Reporter: adam
Dear all ;
i
[
https://issues.apache.org/jira/browse/TOBAGO-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528306
]
Matthias Weßendorf commented on TOBAGO-490:
---
I think one ticket for this issue is enough...
How can to
First off, please pardon my intrusion. I'm a developer with the State of
Michigan, and am currently evaluating Maven as a possible build tool for any
upcoming project. My boss is determined to use JDeveloper, which concerns
me a bit, as I would prefer that we offer developers flexibility in
How can i make hyperlink on tc:menu
--
Key: TOBAGO-493
URL: https://issues.apache.org/jira/browse/TOBAGO-493
Project: MyFaces Tobago
Issue Type: Improvement
Reporter: adam
Dear all ;
i
Hi Eric,
it sounds reasonable to have the build independent from any IDE.
When you build is based on maven, you can use the JDEV-Plugin to
generate the required project files, that's right. That works good.
The plain build, you usually run by invoking mvn clean install;
afterwards, call mvn
[
https://issues.apache.org/jira/browse/TOBAGO-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528318
]
Volker Weber commented on TOBAGO-485:
-
At the development time of the menu we decided against the possiblility
[
https://issues.apache.org/jira/browse/MYFACES-1723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528368
]
Ognjen Blagojevic commented on MYFACES-1723:
Detailed explanation available in this thread:
Hello Matthias,
my current plan is to setup an continuum instance on 8080 again, for the
deploy and nightly build stuff.
Any objections?
Regards
Bernd
Matthias Wessendorf wrote:
Hi,
there was a continuum server (port 8081) on our zone, currently down.
The vmbuild, I can't deploy stuff,
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]
+1
we really need a thing like that :-)
On 9/18/07, Bernd Bohmann [EMAIL PROTECTED] wrote:
Hello Matthias,
my current plan is to setup an continuum instance on 8080 again, for the
deploy and nightly build stuff.
Any objections?
Regards
Bernd
Matthias Wessendorf wrote:
Hi,
On 9/18/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
there was a continuum server (port 8081) on our zone, currently down.
The vmbuild, I can't deploy stuff, does only build...
What is the current plan, do we want to move all our projects to
Brett's vmbuild ?
Yes please. We have a
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,
Yes, please! +1.
-- Adam
On 9/18/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
+1
we really need a thing like that :-)
On 9/18/07, Bernd Bohmann [EMAIL PROTECTED] wrote:
Hello Matthias,
my current plan is to setup an continuum instance on 8080 again, for the
deploy and nightly
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
Hi,
there was a continuum server (port 8081) on our zone, currently down.
The vmbuild, I can't deploy stuff, does only build...
What is the current plan, do we want to move all our projects to
Brett's vmbuild ?
-Matze
--
Matthias Wessendorf
further stuff:
blog:
Yes please. We have a group of volunteers to maintain vmbuild, and
the zone machine is low on resources; infra would prefer we didn't run
applications on it.
that's fine with me, but I have currently these problem:
-my account doesn't allow SSH connections
-deployment not working
I've
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
+1
Regards
Bernd
Matthias Wessendorf wrote:
Yes please. We have a group of volunteers to maintain vmbuild, and
the zone machine is low on resources; infra would prefer we didn't run
applications on it.
that's fine with me, but I have currently these problem:
-my account doesn't allow SSH
Thanks. I'll look into it and add it to the list of 2.0 items.
-roger
Matthias Wessendorf wrote:
Hi,
some of you are part of the JSF 2 EG, I noticed that there isn't a
getRealPath() on ExternalContext ([1]), but it's present on
ServletContext / PortletContext.
thx,
Matthias
[1]
Hi,
some of you are part of the JSF 2 EG, I noticed that there isn't a
getRealPath() on ExternalContext ([1]), but it's present on
ServletContext / PortletContext.
thx,
Matthias
[1]
http://java.sun.com/javaee/javaserverfaces/1.2_MR1/docs/api/javax/faces/context/ExternalContext.html
--
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
[
https://issues.apache.org/jira/browse/TOMAHAWK-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen More updated TOMAHAWK-1115:
---
Status: Patch Available (was: Open)
Adding Tiles2 support to tomahawk
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
h:commandButton and tr:commandButton cannot be interchanged
---
Key: TRINIDAD-721
URL: https://issues.apache.org/jira/browse/TRINIDAD-721
Project: MyFaces Trinidad
Issue Type: Bug
[
https://issues.apache.org/jira/browse/TOMAHAWK-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528509
]
Stephen More commented on TOMAHAWK-1115:
$ svn diff pom.xml
Index: pom.xml
...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
[
https://issues.apache.org/jira/browse/TOMAHAWK-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528497
]
Matthias Weßendorf commented on TOMAHAWK-1115:
--
cool.
what is the pom.xml change (patch) for
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.
I've created the spec issue:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=306
-roger
Matthias Wessendorf wrote:
Hi,
some of you are part of the JSF 2 EG, I noticed that there isn't a
getRealPath() on ExternalContext ([1]), but it's present on
ServletContext /
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
[
https://issues.apache.org/jira/browse/MYFACES-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528511
]
Leonardo Uribe commented on MYFACES-1729:
-
I have made a simple probe
Insteado doing this:
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:
[
https://issues.apache.org/jira/browse/TRINIDAD-718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528575
]
Jeanne Waldman commented on TRINIDAD-718:
-
Committed trunk2.patch to trunk.
svn 577069
add trinidad-skins schema
-
Key: TRINIDAD-722
URL: https://issues.apache.org/jira/browse/TRINIDAD-722
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Skinning
Reporter: Jeanne
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
[
https://issues.apache.org/jira/browse/TRINIDAD-721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Winer resolved TRINIDAD-721.
-
Resolution: Fixed
Fix Version/s: 1.0.3-core
Fixed for 1.0.3 (and 1.2.3 when we
Leonardo Uribe wrote:
[Invalid PPR response. The response-headers were:\nServer:
Apache-Coyote/1.1\nContent-Type: text/xml;ch...]
I'm facing a similar error on my page.
Tomcat 6.0.13 with Java 6 upd 2 and the newest version 1.2.2 of trinidad and
RI jsf 1.2.4.
trimmed jsf code:
html
Shuttle Component Fails to Transfer Short Description on Item Move
--
Key: TRINIDAD-723
URL: https://issues.apache.org/jira/browse/TRINIDAD-723
Project: MyFaces Trinidad
Issue
trinidad does not add javascript-ressources of tomahawk-components inside
ppr-components
Key: TRINIDAD-724
URL: https://issues.apache.org/jira/browse/TRINIDAD-724
50 matches
Mail list logo
