Sure!
regards,
Martin
On 4/19/07, Paul McMahan [EMAIL PROTECTED] wrote:
Cycle reference check should be fixed now in r530517. thanks again for the
peer review.
Best wishes,
Paul
On Apr 19, 2007, at 10:25 AM, Martin Marinschek wrote:
But still - you are short-circuiting the cyclic
MyFaces build doesn't work offline - validation of TLDs fails
-
Key: MYFACES-1590
URL: https://issues.apache.org/jira/browse/MYFACES-1590
Project: MyFaces Core
Issue Type: Bug
[
https://issues.apache.org/jira/browse/MYFACES-1591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Marinschek resolved MYFACES-1591.
Resolution: Fixed
Improved error handling in config management
[
https://issues.apache.org/jira/browse/TOMAHAWK-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Marinschek updated TOMAHAWK-966:
---
Resolution: Fixed
Status: Resolved (was: Patch Available)
PPR examples
Hy,
a short update from my side:
MYFACES-1204 - patch available.
MYFACES-1434 - was allready done.
MYFACES-1221 - tests available.
Regards,
Martin
On 4/18/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hey Martin,
any updates here ?
(any patches that are still sitting in jira ?)
-M
On
Matze,
You can't always get what you want! ;-)
(Rolling Stones: Wise men...)
AND: There are sources and javadoc artifacts for all examples in Maven
repo. This isn't nothing!
Ok, no kidding. It's just a matter of doing (TOMAHAWK-944). There are
only binary assembly definitions yet for the
[
https://issues.apache.org/jira/browse/MYFACES-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Haimberger updated MYFACES-1221:
---
Status: Patch Available (was: Open)
JSR-252 Issue #50: Allow an application to
Hey Manfred,
I don't care :-) Trinidad and Tobago have the same issues.
I haven't voted -1 ;-)
The licensing is much much more critical. There is always SVN.
See you in London
-Matthias
On 4/20/07, Manfred Geiler [EMAIL PROTECTED] wrote:
Matze,
You can't always get what you want! ;-)
I verified that the new 1.2.0 snapshots are available in the snapshot
repository. Thanks Mathias!
Best wishes,
Paul
On Apr 19, 2007, at 6:51 PM, Mathias Brökelmann wrote:
I fixed the continuum setup.
The problem where some orphan lock files of the embedded derby
database:
rm
On 4/19/07, Mathias Brökelmann [EMAIL PROTECTED] wrote:
I fixed the continuum setup.
The problem where some orphan lock files of the embedded derby database:
rm /local/continuum-1.1-SNAPSHOT/data/continuum/database/*.lck
and restarted continuum.
Thanks! Can someone please update the
Hello everyone,
This thread is a follow-up for [EMAIL PROTECTED] thread about
HTML 4.01compliance. As mentioned in that thread, JSF spec requires
implementor to
provide a HTML 4.01 compliant renderkit (Section 8.5). However, both JSF RI
and MyFaces cannot currently ensure that. One of the reason
Also, this issue is important for some clients, especially governments since
they sometimes have politics about W3C standard compliance. Therefore, a
very small issue like the generated id can be enough to put an end to a
proposed JSF solution on its own. Of course, I know this is not the only
I did a quick search, and this issue has come up at least twice
before, but the responses to keeping the current behavior were
unconvincing.
5/20/2005 Serious problems with MyFaces ID allocation which is not
conform to XHTML!
7/12/2006 w3c Markup validator does not like generated ID's after
Helllo,
In order 'choose' an unique prefix, why not re-use a common way to
create unique names in Java: Use a package-structure.
There for until it can be configured in the web.xml how about using
org_apache_myfaces_ as the clientID-prefix.
I know it's not as short as _id, but I seriously doubt
Hi!
Belen, Marco wrote:
In order 'choose' an unique prefix, why not re-use a common way to
create unique names in Java: Use a package-structure.
There for until it can be configured in the web.xml how about using
org_apache_myfaces_ as the clientID-prefix.
My first reaction on this was:
@ client id values:
I would also be against using a client id more than a few characters.
Too much of a performance hit.
@ configuring:
static is easy. If it were just public static, then in the config parser,
UIViewRoot.UNIQUE_ID_PREFIX = new_prefix;
A system property isn't a bad
On Apr 20, 2007, at 12:24 PM, Mario Ivankovits wrote:
Belen, Marco wrote:
In order 'choose' an unique prefix, why not re-use a common way to
create unique names in Java: Use a package-structure.
There for until it can be configured in the web.xml how about using
org_apache_myfaces_ as the
For sites that implement testing, like Selenium, and use the generated Ids
their should
be an option to maintain the current prefix. This option need not be the
default, but
it must be documented
Paul Spencer
Mike Kienenberger wrote:
@ client id values:
I would also be against using a
Hmmm what about a prefix of the same length than currently to prevent page
size increase, but a bit strange to prevent most potential clashes? Maybe
i_d?
On 4/20/07, Paul McMahan [EMAIL PROTECTED] wrote:
On Apr 20, 2007, at 12:24 PM, Mario Ivankovits wrote:
Belen, Marco wrote:
In order
Interaction with inputCalendar component causes proliferation of commandLinks
if running under ICEFaces.
Key: TOMAHAWK-968
URL:
Hi,
Maybe i_d?
this was also my first thought.
Regards,
Volker
[
https://issues.apache.org/jira/browse/TOMAHAWK-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12490413
]
Mike Kienenberger commented on TOMAHAWK-968:
Sounds good.
I've seen at least one other related
[
https://issues.apache.org/jira/browse/TOMAHAWK-968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adnan Durrani updated TOMAHAWK-968:
---
Status: Patch Available (was: Open)
Interaction with inputCalendar component causes
+1 to use 1.2 as trunk because I believe it'll speed up the development.
Also +1 to Manfred's suggestion.
Regards,
Cagatay
24 matches
Mail list logo
