Hi,
2008/6/20 Scott O'Bryan [EMAIL PROTECTED]:
[...]
The old
code line gets bug fixes and nothing more and the active development is
always on the latest and greatest. Why can't we do something similar?
The active development is done where needed, which in my case is jsf1.1.
Regards,
Server-side validation does not work when using Sun JSF implementation
--
Key: TRINIDAD-1129
URL: https://issues.apache.org/jira/browse/TRINIDAD-1129
Project: MyFaces Trinidad
On Fri, 2008-06-20 at 09:06 +0200, Volker Weber wrote:
Hi,
2008/6/20 Scott O'Bryan [EMAIL PROTECTED]:
[...]
The old
code line gets bug fixes and nothing more and the active development is
always on the latest and greatest. Why can't we do something similar?
The active development
I changed to the old menu system and still experience the same problem.
I upgraded an existing application to the 1.0.8 trinidad jars and the
menu system worked on the existing app. The difference between the two
applications is one is using facelets and the other is not. Possibly a
facelets
Gary,
I found this in the help docs,
If both attributes are set on an itemNode, the destination attribute
takes precedence and a GET is done.
However, when I add the destination attribute to the
commandNavigationItem my menu navigation stops working regardless of
whether I specify destination
simon schrieb:
In other words, keeping one line of code makes sense (less
maintenance) even if we lose some JSF1.2/JSF2.0-specific features or
performance boosts.
While I second the rest of your mail, I wont do so with the sentence above.
We are developers, and, at least in your younger years
Hi,
you may now IRIAN Solutions from our direct involvement in JSF
development and especially into the Apache MyFaces project.
We are currently searching for experienced JSF- developers and
architects for some projects located in Zürich, Vienna or Frankfurt.
The place of work will be in one of
On Thu, 2008-06-19 at 16:06 -0500, Leonardo Uribe wrote:
Hi
I have fixed the problems. Now, everything works fine. There was a fix
on QdoxModelBuilder (validators also have hierarchy), and on myfaces
core 1.2 (UIColumn has missing annotations).
Great.
I have my tld comparator running,
JSR 252 (JSF 1.2) was finalized on 2006-05-11
Java 1.5 released 2004-09-30
I don't mind people maintaining JSF 1.1, but I do think that there is
very good cause to have 1.1 moved to branches and the latest JSF
specification as the trunk for each project. Over 2 years is plenty of
time to adopt
Hi all,
I have to agree with Andrew here. One year ago, JEE5 server were still
scarce or underused, thus supporting the maintained two branches argument,
but now is no longer the case and splitting efforts between two code bases
doesn't sound most efficient.
Regards
~ Simon
On Fri, Jun 20,
Messages not maintained in insertion order as per JSF 1.2 spec
--
Key: PORTLETBRIDGE-38
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-38
Project: MyFaces Portlet Bridge
Bridge should retain/resuse redirected viewId when redirected during render
---
Key: PORTLETBRIDGE-39
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-39
Project: MyFaces
I am one who is using JSF 1.1 for some applications. This is because
the applications are running software/hardware environments which do not
support JSF 1.2. For applications in environment that will support JSF
1.2, I use JSF 1.2.
Future JSF version are inevitable, thus a solution must
Paul, why do the CF versions have to be different. This is no different
(IMO) then what I was talking about except that we could not FORCE
people to backport everything.
I don't see why libraries for older JSF's HAVE to be functionally
equivalent. That is not to say that API's started in
Partially ignore this.. :) Let me clairify now that I understand your
proposal..
I think projects need to be in charge of their own destiny based off of
need/usage.. :) Indeed Trinidad has a 1.0.8 branch and a 1.2.8 branch
which is (mostly) functionally equivalent. But I wouldn't say that
Let's not forget that working on open source software is quite
different than working on proprietary software. For open source, you
work on what you need and you share what you've done with others.
Some people need JSF 1.1 and will be working there. Some people need
JSF 1.2 and will be working
Scott O'Bryan wrote:
Partially ignore this.. :) Let me clairify now that I understand your
proposal..
I think projects need to be in charge of their own destiny based off of
need/usage.. :) Indeed Trinidad has a 1.0.8 branch and a 1.2.8 branch
which is (mostly) functionally equivalent.
Yeah, I would accept that... At least until there is basically NO
active development happening on a branch. Maybe when the corresponding
JSF branch goes End of Cycle?
Paul Spencer wrote:
Scott O'Bryan wrote:
Partially ignore this.. :) Let me clairify now that I understand
your proposal..
Mike, the problem with this approach is one of forward compatibility.
Let me explain. The ExternalContextUtils in the MyFaces commons, when
it existed in Trinidad, had api's for handling request input streams and
whatnot because the ExternalContext did not. If someone used that API
and then
On Fri, 2008-06-20 at 15:45 +0200, simon wrote:
I have my tld comparator running, and have compared myfaces_core.tld
for versions 1.1.5 and 1.1.6-SNAPSHOT (ie the current output).
The following differences were detected:
* missing xmlns on taglib element
And the following classes are
[
https://issues.apache.org/jira/browse/TRINIDAD-1124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12606900#action_12606900
]
Ed Burns commented on TRINIDAD-1124:
Hello Matthias,
I made the change you
Can you please send me your menu metadata file? your node should
have destination attribute in your node (.e.g. ItemNode) that has a
URL to the page you want to go to directly. So your menu metadata
should look like this for the itemNode you want to use to navigate
outside your
Hello everyone,
You may have seen my earlier announcement about the JSFOne
(http://www.jsfone.com) show, hosted by JSFCentral and the No Fluff Just
Stuff Symposiums, September 4th-6th near Washington, DC.
If you're interested in speaking, we're now accepting proposals. We're
particularly
[
https://issues.apache.org/jira/browse/TOMAHAWK-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12606951#action_12606951
]
Leonardo Uribe commented on TOMAHAWK-1005:
--
Checking some tomahawk issues, this
[
https://issues.apache.org/jira/browse/TRINIDAD-1124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12606956#action_12606956
]
Matthias Weßendorf commented on TRINIDAD-1124:
--
Hi Ed,
the testcase
[
https://issues.apache.org/jira/browse/TOMAHAWK-1280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12606967#action_12606967
]
Leonardo Uribe commented on TOMAHAWK-1280:
--
The problem is that f:loadBundle
[
https://issues.apache.org/jira/browse/TOMAHAWK-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12606970#action_12606970
]
Leonardo Uribe commented on TOMAHAWK-1034:
--
The attached patch is not in diff
27 matches
Mail list logo
