Blake, in general you point of view is a very theoretical one from a high
ebony tower. Do you say so in english? ;-)
In real life those private methods do make using Trinidad more cumbersome
that it needs to be.
For example it is currently not possible to make a simple change like moving
*
not sure if the thread is already over... since I was
gone for some days...
On Fri, Apr 11, 2008 at 8:45 AM, Martin Marinschek
[EMAIL PROTECTED] wrote:
Hi Scott,
your statement is really irrelevant - in JSF, renderers are designed
to be extended/exchanged. JSF has been built this way.
yes, sounds reasonable.
On Fri, Apr 11, 2008 at 8:47 AM, Martin Marinschek
[EMAIL PROTECTED] wrote:
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
On Fri, Apr 11, 2008 at 3:59 PM, Andy Schwartz
[EMAIL PROTECTED] wrote:
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
1) Company decides to adopt Trinidad for a project
2) They are either (a) crunched for time or (b) need to get a release out
3) From mgmt, they are told they have to implement a feature
4) Trinidad has no way to support this feature, but the current
renderer has a method that would allow
On Fri, Apr 11, 2008 at 9:04 PM, Andrew Robinson
[EMAIL PROTECTED] wrote:
If you are not a member of MyFaces, Committer or PMC member please
refrain from further reply to this thread as your feedback has already
been noted.
as an asf member I really don't like statements like that...
a
[
https://issues.apache.org/jira/browse/MYFACES-1726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12588521#action_12588521
]
Matthias Weßendorf commented on MYFACES-1726:
-
I fixed that for Trinidad
On Mon, Apr 14, 2008 at 2:15 AM, Cristi Toth [EMAIL PROTECTED] wrote:
Hi,
Let me add some things to what I already stated here.
There are 2 important reason for overriding renderers, that nobody mentioned
here.
1) Not all users needs are general enough to be comitted into Trinidad.
I
Error creating bean with name
'org.apache.myfaces.orchestra.conversation.AccessScopeManager'
Key: ORCHESTRA-22
URL: https://issues.apache.org/jira/browse/ORCHESTRA-22
[
https://issues.apache.org/jira/browse/TOBAGO-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12588545#action_12588545
]
Roland Asmann commented on TOBAGO-645:
--
Sorry, it appears this issue was caused by
[
https://issues.apache.org/jira/browse/TOBAGO-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12588545#action_12588545
]
malice edited comment on TOBAGO-645 at 4/14/08 4:38 AM:
---
Unification of excelExport and pdfExport components into a new (exporter)
component
---
Key: TOMAHAWK-1231
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1231
Yes, I understand, but when one mailing list member is holding up
progress by providing only negative, non-constructive feedback and
even admits that his own branch of the thread has ceased to be useful,
it is important to be able to let the other members of the community
have a say. This was the
I thought a little bit more about the renderer composition idea and there
are some things to address.
Currently, when we create a renderer using a delegation model, it often look
like the following:
public class MyMainRenderer extends XhtmlRenderer
{
private Renderer partRenderer;
protected
Hi,
On Mon, Apr 14, 2008 at 6:11 PM, Andrew Robinson
[EMAIL PROTECTED] wrote:
Have you looked at my code in the branch? I think it would be good te
not yet. I plan to get to it tomorrow.
I was out last week... and fighting through all my mails and stuff.
-M
critique that so that there is a
Ignore the component link, I messed that one up. The renderers are the
ones to have a look at.
On Mon, Apr 14, 2008 at 10:11 AM, Andrew Robinson
[EMAIL PROTECTED] wrote:
Have you looked at my code in the branch? I think it would be good te
critique that so that there is a solid example for
Hi,
the bug in [1] is pretty annoying.
Currently UploadedFileImpl.loadFile() throws an EOFException when
we hit the limits of the upload facility.
(like file is larger than allowed).
You won't see a FacesMessage for the not happened upload,
but a error page (default or a configured custom
Have you looked at my code in the branch? I think it would be good te
critique that so that there is a solid example for people to look at.
I did not attempt to make it pretty, so hopefully if such a thing is
done, we would give it a better API.
SVN Path:
Yes, I understand, but when one mailing list member is holding up
progress by providing only negative, non-constructive feedback and
even admits that his own branch of the thread has ceased to be useful,
perhaps due to my lack of English these comments didn't sound that
Simon,
Frankly I do not understand #2, sorry. Could you explain what the
problem is in a different way? Perhaps I just have not seen something
in the current code that does something that you are referring to. I
was hoping that someone besides myself would understand what you said
better and
Forgot to say that in my example, I have TestSubRendererHeader as a
renderer type. So the registered renderer for this type should have
knowledge on how to appropriately render a header for this component
type. So in this case, the contract is the FacesBean having a header
property set or having a
Hello Andrew,
Ok, let say we have a renderer that renders a custom layout with an
inputText showing the component's value and allowing to alter it. Since we
don't want to reinvent the wheel, we need to reuse the inputText renderer.
So, somewhere in the code we'll see something like :
Yes, much clearer. In a previous email on this thread, I had an idea
on creating an alias wrapper for faces beans. The idea being that I
could essentially rename the title property of the faces bean to
value so I could use the output text renderer to print the title as
it would a normal
The vote has passed with the following votes:
+1
lofwyr (binding)
matzew (binding)
grantsmith (binding)
bommel (binding)
+0
weber (binding)
I will proceed with the next steps.
Regards
Bernd
Stephan,
This would have been a good skinning feature to add, so that anyone else
that
wants to do this could use skinning to change the position of the field
label.
With a skinning property, a person that wants his * behind field
labels would
simply have to add to their skin something
[
https://issues.apache.org/jira/browse/TRINIDAD-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12588701#action_12588701
]
Jeanne Waldman commented on TRINIDAD-974:
-
Completed: At revision: 647929
on
Now flip-flopping to the other side.. :)
I disagree that well thought out extension points decrease flexibility
in the renderer. It's all about granularity. Some larger components
(such as the table) have some clearly defined pieces. I don't think
anybody is arguing about the need to
Jean, thanks for the reply.
I did create a Jira issue and went ahead and tried to see if I can understand
Trinidad well enough to supply a patch, then asked for opinions.
Looking back I now think the way I implemented it can be both improved and
simplified.
If you (or somebody else) shares her
[
https://issues.apache.org/jira/browse/MYFACES-1726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12588798#action_12588798
]
Leonardo Uribe commented on MYFACES-1726:
-
Testing if we can check if this
Stephen Friedrich said the following On 4/13/2008 11:26 PM PT:
Blake, in general you point of view is a very theoretical one from a high
ebony tower. Do you say so in english? ;-)
In English, it is usually ivory tower, but, if you think that I'm
evil, ebony tower might be more approriate.
[
https://issues.apache.org/jira/browse/TRINIDAD-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12588815#action_12588815
]
Jeanne Waldman commented on TRINIDAD-974:
-
This works in Trinidad1.2 branch, but
[
https://issues.apache.org/jira/browse/TRINIDAD-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12588816#action_12588816
]
Jeanne Waldman commented on TRINIDAD-974:
-
I should note that in trinidad's 1.2.x
[
https://issues.apache.org/jira/browse/MYFACES-1726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12588820#action_12588820
]
Leonardo Uribe commented on MYFACES-1726:
-
fixed at revision 648026
IE7 -
Duplicated ids exception for 2 controls with same id and one of them is not
rendered
Key: MYFACES-1861
URL: https://issues.apache.org/jira/browse/MYFACES-1861
On Mon, Apr 14, 2008 at 5:56 PM, Blake Sullivan
[EMAIL PROTECTED] wrote:
In English, it is usually ivory tower, but, if you think that I'm evil,
ebony tower might be more approriate.
Blake == Saruman?
;-)
Andy
Use ThreadLocal StringBuilder for create ids on getClientId, like in trinidad
-
Key: MYFACES-1862
URL: https://issues.apache.org/jira/browse/MYFACES-1862
Project: MyFaces
HTML generated with duplicate Ids when using forceId=true
---
Key: MYFACES-1863
URL: https://issues.apache.org/jira/browse/MYFACES-1863
Project: MyFaces Core
Issue Type: Bug
What's the JIRA number?
What exactly are your requirements? I wouldn't over-design it by putting
in too many hooks.
- Jeanne
Stephen Friedrich wrote, On 4/14/2008 2:22 PM PT:
Jean, thanks for the reply.
I did create a Jira issue and went ahead and tried to see if I can
understand
Trinidad
Enhance UIComponentBase.getFacetsAndChildren(), creating
_FacetsAndChildrenIterator only when it is necessary
-
Key: MYFACES-1864
URL:
39 matches
Mail list logo
