[
https://issues.apache.org/jira/browse/MYFACES-1855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12587862#action_12587862
]
Mario Ivankovits commented on MYFACES-1855:
---
It would be really great if you
Hi Scott,
your statement is really irrelevant - in JSF, renderers are designed
to be extended/exchanged. JSF has been built this way. Trinidad (or
where Trinidad comes from) tries to make this impossible, out of
support reasons inside Oracle. If you go into a wider space, and want
Trinidad to be
Sounds like a reasonable suggestion - I would love to be able to
replace/extend small chunks of code, not having to rewrite/copy the
renderer-code fully, so this suggestion might go into this direction.
regards,
Martin
On 4/11/08, Andrew Robinson [EMAIL PROTECTED] wrote:
Okay, I have yet
Hi Gerhard,
let's start a vote _after_ we have discussed the code - just give us a
link to a zip-file with the code in it somewhere.
regards,
Martin
On 4/11/08, Gerhard Petracek [EMAIL PROTECTED] wrote:
hello,
as mentioned: sev-en started as feasibility study. so there are some topics
i
ok - i'll upload it within the next view days.
regards,
gerhard
2008/4/11, Martin Marinschek [EMAIL PROTECTED]:
Hi Gerhard,
let's start a vote _after_ we have discussed the code - just give us a
link to a zip-file with the code in it somewhere.
regards,
Martin
On 4/11/08, Gerhard
ok - i'll upload it within the next few days.
should i also provide a list with the main todo's?
regards,
gerhard
2008/4/11, Gerhard Petracek [EMAIL PROTECTED]:
ok - i'll upload it within the next view days.
regards,
gerhard
2008/4/11, Martin Marinschek [EMAIL PROTECTED]:
Hi
[
https://issues.apache.org/jira/browse/TOMAHAWK-1214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Ivankovits resolved TOMAHAWK-1214.
Resolution: Later
Immediate need for this feature is no longer existent.
It
Hey Matthias!
Can you give me a concrete use case in
which RI could break without this?
I would test it during the week-end.
thanks,
On 4/10/08, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Christi,
yes I forgot, that I renamed the method :-)
We now *decorate* the HTML_BASIC (see log of
Try to include an h:commandLink / in a tr:form/ or the other way
round and see if you can submit the form like this - if it works, all
should be well.
It should work with RI 1.2, but also with 1.1 departing from 1.1_04, I think.
regards,
Martin
On 4/11/08, [EMAIL PROTECTED] [EMAIL PROTECTED]
I like very much Andrew's idea of having more smaller renderers
and being able to override them the standard way (via faces-config.xml)
Also maybe some of you understood me wrong.
I didn't mean that all/most of the renderer methods should be protected.
But there are cases where it's needed.
Lets
I saw it during a Wicket talk
On Thu, Apr 10, 2008 at 5:18 PM, Grant Smith [EMAIL PROTECTED] wrote:
That's very nice. Good find.
On Thu, Apr 10, 2008 at 4:12 AM, Matthias Wessendorf [EMAIL PROTECTED]
wrote:
Hello,
we now finally have release for our archetypes (thanks leonardo).
[
https://issues.apache.org/jira/browse/MYFACES-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12587921#action_12587921
]
Guy Bashan commented on MYFACES-1854:
-
The IDE tells me that these xml elements are
Yeah,
I know there was some work done, in that area,
but... I am lazy... :) so never bothered to check back
;-)
On Fri, Apr 11, 2008 at 10:15 AM, Martin Marinschek
[EMAIL PROTECTED] wrote:
Try to include an h:commandLink / in a tr:form/ or the other way
round and see if you can submit the form
[
https://issues.apache.org/jira/browse/TRINIDAD-989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12587924#action_12587924
]
Wolfgang Chico Toepfer commented on TRINIDAD-989:
-
PPR does not seem to
Antonio,
in case you don't find sb. w/ in the next week.
I'll volunteer to help (I did it some weeks ago
already for my employer)
-M
On Thu, Apr 10, 2008 at 5:42 PM, Antonio Petrelli
[EMAIL PROTECTED] wrote:
Dear friends,
First of all, sorry for the cross posting.
I am Antonio Petrelli,
2008/4/11, Matthias Wessendorf [EMAIL PROTECTED]:
Antonio,
in case you don't find sb. w/ in the next week.
I'll volunteer to help (I did it some weeks ago
already for my employer)
Wow! Thanks a lot Matthias! Im this case, when the new week has come, may I
ask you to join the Tiles
Andrew I really like you idea from the other thread (the trick one :) ).
Having new renderer types in the API and being able to override them
via faces-config
sounds much more standard and clean.
Probably we should wait and see where the other thread leads to
and then start a vote on this
Hello,
after my wlan survival I would like to release Tobago 1.0.16,
For a detail list please consult the release notes:
http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273styleName=Htmlversion=12312966
The version is available at the staging location and the
revision
Here is my
+1
Regards
Udo
Bernd Bohmann schrieb:
Hello,
after my wlan survival I would like to release Tobago 1.0.16,
For a detail list please consult the release notes:
http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273styleName=Htmlversion=12312966
The version is
Hey Martin (and all) -
It seems to me that what this comes down to is how we view classes in
trinidadinternal. There are a range of possible views here:
1. These classes are entirely private/off-limits, and if you want to
extend one of these tough luck. No love for you. Go away.
2. These
As someone who has experience in attempting to use Trinidad, I think
#3 is a requirement for short term usage and #2 as the goal.
What I mean by this is that rendereds should make an effort to expose
functionality even if it isn't thought through so that ppl can get
work done, and then have users
+1
On Fri, Apr 11, 2008 at 1:44 PM, Udo Schnurpfeil [EMAIL PROTECTED] wrote:
Here is my
+1
Regards
Udo
Bernd Bohmann schrieb:
Hello,
after my wlan survival I would like to release Tobago 1.0.16,
For a detail list please consult the release notes:
Hey Andrew -
I think we are getting closer together, but not exactly there yet. :-)
On Fri, Apr 11, 2008 at 10:10 AM, Andrew Robinson
[EMAIL PROTECTED] wrote:
As someone who has experience in attempting to use Trinidad, I think
#3 is a requirement for short term usage and #2 as the goal.
I
+1
On Fri, Apr 11, 2008 at 7:33 AM, Matthias Wessendorf [EMAIL PROTECTED]
wrote:
+1
On Fri, Apr 11, 2008 at 1:44 PM, Udo Schnurpfeil [EMAIL PROTECTED]
wrote:
Here is my
+1
Regards
Udo
Bernd Bohmann schrieb:
Hello,
after my wlan survival I would like to
What I mean by this is that rendereds should make an effort to expose
functionality even if it isn't thought through
I am not a fan of this. If people want to put in the effort to think
through APIs that they expose on their renderers, then +1. But big -1
from me for exposing APIs
I pretty much agree with everything Andy said here..
Andy Schwartz wrote:
Hey Andrew -
I think we are getting closer together, but not exactly there yet. :-)
On Fri, Apr 11, 2008 at 10:10 AM, Andrew Robinson
[EMAIL PROTECTED] wrote:
As someone who has experience in attempting to use
Andrew,
That's a fair assesment, but that same pressed for time company will
be angry when their stuff no longer works and those will turn into JIRA
tickets. I'm not saying we shouldn't make Trinidad more flexible. I'm
just saying that it's unrealistic to expose logic hap-hazardly. If this
1) the company will not be angry, as I mentioned that I would be
making the hack as a temporary solution, fully expecting that it will
need to be converted later
2) It is impossible to control renderers 100% through component
attributes and Skinning. For example, sometimes their DOM may just be
[
https://issues.apache.org/jira/browse/MYFACES-1855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12588044#action_12588044
]
Leonardo Uribe commented on MYFACES-1855:
-
I will take this suggestion into
Andrew Robinson said the following On 4/11/2008 8:53 AM PT:
What I mean by this is that rendereds should make an effort to expose
functionality even if it isn't thought through
I am not a fan of this. If people want to put in the effort to think
through APIs that they expose on their
Andy Schwartz said the following On 4/11/2008 7:45 AM PT:
Hey Andrew -
I think we are getting closer together, but not exactly there yet. :-)
On Fri, Apr 11, 2008 at 10:10 AM, Andrew Robinson
[EMAIL PROTECTED] wrote:
As someone who has experience in attempting to use Trinidad, I think
#3
Rhetorical question--why would a company have such a policy?
Companies don't usually make sense, you must be one of those people
that think Dilbert is fiction :)
I have worked for more than one company that enforces this policy.
They hate using open source for liability reasons, and hate you
Andrew Robinson said the following On 4/11/2008 11:02 AM PT:
Rhetorical question--why would a company have such a policy?
Companies don't usually make sense, you must be one of those people
that think Dilbert is fiction :)
I have worked for more than one company that enforces this
I don't necessarily agree with your last statement Blake. Some of us
like to argue for argument's sake. :)
Blake Sullivan wrote:
Andrew Robinson said the following On 4/11/2008 11:02 AM PT:
Rhetorical question--why would a company have such a policy?
Companies don't usually make
Could we move this discussion away from a debate?
Could MyFaces Committers or PMC members _only_ please share their
thoughts on this to keep the discussion to the stake holders only?
Please share other solutions as you have them.
Here some view points to discuss:
1) remove the restriction of
Hello,
1) remove the restriction of trinidad-impl being non-API and enforce that
code in this package be backward-compatible
No, it's way too messed up still to say that we're going to be backward
compatible, ui and uinode for example and some renderer are messed up as
well, they renderer what
Hello all,
I have currently been working with JSF, SPRING, HIBERNATE WITH FACELETS.
I recently looked into apache trinidad,
And felt that it is good fit for my requirement.
I just downloaded trinidad examples war file and apache trinidad, and
run it from tomcat. The application, is very big
Resource bundle values are not evaluated properly in java code
--
Key: MYFACES-1858
URL: https://issues.apache.org/jira/browse/MYFACES-1858
Project: MyFaces Core
Issue Type: Bug
BTW, I want to apologize to making this thread out to be such a mess
and hope that I haven't damaged Christi's goal with improving the
library. I tend to get too passionate about code and get quite
bothered when only negative feedback is offered with no constructive
comments to suggest forward
Andrew Robinson wrote:
Could we move this discussion away from a debate?
Could MyFaces Committers or PMC members _only_ please share their
thoughts on this to keep the discussion to the stake holders only?
Please share other solutions as you have them.
Here some view points to discuss:
1)
-Original Message-
From: Nutulapati, Krishna
Sent: Friday, April 11, 2008 2:58 PM
To: 'MyFaces Development'
Subject: New to Trinidad
Hello all,
I have currently been working with JSF, SPRING, HIBERNATE WITH FACELETS.
I recently looked into apache trinidad, And felt that it is good
Krishna, please post to the users list for these type of questions.
The dev list is for MyFaces developers to collaborate on working on
the code, not working with the code.
Thanks,
Andrew
On Fri, Apr 11, 2008 at 2:50 PM, Nutulapati, Krishna
[EMAIL PROTECTED] wrote:
-Original Message-
Generally I really do agree with Simon that a simple, serious redesign
of every component would probably do better than hooks.
Also, I really think once you put restrictions on your renderers you run
into issues, like you have a bug or a new feature which makes you need
to reorganize in an
[
https://issues.apache.org/jira/browse/TRINIDAD-1037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott O'Bryan updated TRINIDAD-1037:
Resolution: Fixed
Fix Version/s: (was: 1.2.7-core)
Optimize javascript following good practices
Key: MYFACES-1859
URL: https://issues.apache.org/jira/browse/MYFACES-1859
Project: MyFaces Core
Issue Type: Improvement
Reporter: Leonardo
XmlHttpConfigurator is implemented incorrectly
--
Key: TRINIDAD-1049
URL: https://issues.apache.org/jira/browse/TRINIDAD-1049
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions:
[
https://issues.apache.org/jira/browse/MYFACES-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12588155#action_12588155
]
Leonardo Uribe commented on MYFACES-1842:
-
After checking the problem and try to
[
https://issues.apache.org/jira/browse/MYFACES-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12588159#action_12588159
]
Leonardo Uribe commented on MYFACES-1691:
-
I have tested this on firefox and IE
[
https://issues.apache.org/jira/browse/MYFACES-1726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12588166#action_12588166
]
Leonardo Uribe commented on MYFACES-1726:
-
On the http page mentioned before:
Could it be done in an event mechanism? Some way of letting a listener
say that it handled the event and therefore not have the property
updated on the component? I honestly cannot think of a solution at
this time that sounds good
Andrew
On 4/8/08, Martin Marinschek [EMAIL PROTECTED] wrote:
One
50 matches
Mail list logo
