Well, between having developers not being able to override some simple
behaviour
and keeping backwards compatibility on subclassers,
I'll choose the 2nd one.
This is the reason that some components from tomahawk,
that are less feature-enabled that thos in Trinidad,
are considered more flexible
One more thing,
Trinidad now being open-source means that it should be really open
for those advanced developers that dive into the code.
On Thu, Apr 10, 2008 at 8:11 AM, Cristi Toth [EMAIL PROTECTED] wrote:
Well, between having developers not being able to override some simple
behaviour
and
But what does the open-source mean then... ?
All the renderers are in the impl packages,
but that's the beauty of open-source...
you can customize something you need.
That's an advantage that we should not oversee.
On Thu, Apr 10, 2008 at 5:07 AM, Andrew Robinson
[EMAIL PROTECTED] wrote:
I am
Thanks, Leonardo, I appreciate this!
Paul
Leonardo Uribe (JIRA) schrieb:
[ https://issues.apache.org/jira/browse/MYFACES-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12587432#action_12587432 ]
Leonardo Uribe commented on MYFACES-1822:
If you want to here my opinion: we need Trinidad to be as customizable
as possible. People who do this customization will know what they are
doing - and will know how to handle an upgrade to a new version. It is
enough to say: this is part of the impl package - it might change from
version to
And here again, I can only support Cristi - Trinidad has clearly said
that the renderers are part of the implementation (it is even in the
package name!). People know implementation code might change its API
in the next version, so there is no sense in enforcing this on the
source level...
Hi,
I am an acquisition editor for Packt Publishing working on Apache. We are
currently planning to develop a book on Apache MyFaces.
Packt publishes a range of books, with a particular focus on Open Source tools.
We pay authors in the form of a royalty and an advance against that royalty.
I found something surprising, while working on a Tomahawk application, in
which I added Trinidad for a couple of components.
Trinidad overrides default renderers of some javax.faces.* components like
Form, HtmlCommandButton and HtmlCommandLink.
indeed.
Why is this needed?
because the JSF
whoops...
shitty Gmail...
On Thu, Apr 10, 2008 at 10:20 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
I found something surprising, while working on a Tomahawk application, in
which I added Trinidad for a couple of components.
Trinidad overrides default renderers of some javax.faces.*
Hi Gerhard,
seems the community is leaning towards a new submodule (Cagatay's -1
is only one of the many votes). But - as Mario said - let the code
speak first!
regards,
Martin
On 4/9/08, Scott O'Bryan [EMAIL PROTECTED] wrote:
I think so too. Having a sub-project of a sub-project might be a
The reason Trinidad is doing this was a bug in the early versions of
the JSF-RI - there the form and the link were interlinked, and you
could not use one without the other. The only chance Trinidad would
have got this work was by overwriting the renderers. Now, this should
not be necessary
hi, this is where I found out what happens exactly:
//
// This RenderKit decorates the standard BASIC_HTML,
// but we need to replace some renderers with our own.
//
private void _modifyBasicHTMLRenderKit()
{
// We render UIForms with our own renderer
[
https://issues.apache.org/jira/browse/MYFACES-1848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12587542#action_12587542
]
Guy Bashan commented on MYFACES-1848:
-
This bug is pretty annoying and can be
true!
On Wed, Apr 9, 2008 at 8:28 PM, Scott O'Bryan [EMAIL PROTECTED] wrote:
I think so too. Having a sub-project of a sub-project might be a little
infrastructure heavy, there is nothing to say that Sev-en couldn't become
it's own MyFaces subproject that's intended to be used in a
Christi,
yes I forgot, that I renamed the method :-)
We now *decorate* the HTML_BASIC (see log of the class)
We currently only replace these three.
I am not really sure, it it works without that...
There might be some issues...
Can you do me a favor ?
check with RI 1.2_07 ?
(they changed
Hello,
we now finally have release for our archetypes (thanks leonardo).
During ACon, I noticed that:
http://wicket.apache.org/quickstart.html
I like that. So question is ... should we borrow that idea?
Udo, Gerald and I really like that!
We not only need version, we also need a selection of
very good - we should do it.
regards,
Martin
On 4/10/08, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hello,
we now finally have release for our archetypes (thanks leonardo).
During ACon, I noticed that:
http://wicket.apache.org/quickstart.html
I like that. So question is ... should we
k
after ACon, I'll do that
-M
On Thu, Apr 10, 2008 at 3:03 PM, Martin Marinschek
[EMAIL PROTECTED] wrote:
very good - we should do it.
regards,
Martin
On 4/10/08, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hello,
we now finally have release for our archetypes (thanks
Hello all,
I'm a bit torn on that issue. On one side, I don't find it too hard to
override current renderers and actually think there's a quite formidable
amount of protected methods, but on the other side I do come across annoying
final methods every now and then and I have to use my commiter
ErrorPageWriter causes Facelets/MyFaces confusion
-
Key: MYFACES-1853
URL: https://issues.apache.org/jira/browse/MYFACES-1853
Project: MyFaces Core
Issue Type: Improvement
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).
During ACon, I noticed that:
http://wicket.apache.org/quickstart.html
I like that. So question is ... should
Dear friends,
First of all, sorry for the cross posting.
I am Antonio Petrelli, PMC Member of Apache Tiles.
We would like to integrate Dimensions with the new name of Kaolin
inside the Tiles codebase:
http://mutidimensions.sourceforge.net/
The only developers of this projects are Aaron Roller and
f:selectItems does not evaluates EL expressions
-
Key: MYFACES-1854
URL: https://issues.apache.org/jira/browse/MYFACES-1854
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.2
++1
On Thu, Apr 10, 2008 at 12:55 AM, Martin Marinschek
[EMAIL PROTECTED] wrote:
If you want to here my opinion: we need Trinidad to be as customizable
as possible. People who do this customization will know what they are
doing - and will know how to handle an upgrade to a new version. It is
I couldn't seem to understand by looking at the clay usecase example.
Can somebody post an example of using clay to generate a dynamic table
element, the equivalent of the JSF h:dataTable tag?
+1 for:
- removing most final modifiers
- going from private to protected on most renderer methods
- and adding more customization hooks in the renderers
I also think that these should not be made backwards compatible.
Basically a use at your own risk deal. That way Trinidad developers
have the
Wrong mailing list. This is for MyFaces committers only. Please send
your mail to the shale list.
On Thu, Apr 10, 2008 at 11:23 AM, Zheng, Xiahong [EMAIL PROTECTED] wrote:
I couldn't seem to understand by looking at the clay usecase example. Can
somebody post an example of using clay to
[
https://issues.apache.org/jira/browse/TOMAHAWK-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12587732#action_12587732
]
Jean-Marc Seigneur commented on TOMAHAWK-922:
-
I've also voted for this issue
Hello,
I have prepared the next release of apache-myfaces-tobago during the
ApacheCon Europe. Because of a network error I was not able to commit
the poms with the next development version. I rollback the release.
Unfortunatley the continuus integration server already deployed 1.0.16
to the rsync
On Thu, Apr 10, 2008 at 1:36 PM, Andrew Robinson
[EMAIL PROTECTED] wrote:
+1 for:
- removing most final modifiers
- going from private to protected on most renderer methods
Not sure how much my opinion counts, since I am a new face around
here, but I am -1 on blindly removing most final
I completely agree with Andy, so I am -1 for removing protected
on most renderer methods as well.
Max
Andy Schwartz wrote:
On Thu, Apr 10, 2008 at 1:36 PM, Andrew Robinson
[EMAIL PROTECTED] wrote:
+1 for:
- removing most final modifiers
- going from private to protected on
I wasn't suggesting blind removal. IMO final should rarely ever be
used, for open source it almost never does anyone any good. I would
suggest a renderer-by-renderer approach though, not method-by-method
as that would take too long to file that many bugs.
Right now Trinidad and facelets are by
[
https://issues.apache.org/jira/browse/TOMAHAWK-1226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12587779#action_12587779
]
Ernst Fastl commented on TOMAHAWK-1226:
---
In order to resolve this issue, I suggest
-1 - I agree with Andy and Max for the reasons Matthias stated. Classes
in the Trinidad impl are not to be used outside of trinidad itself.
Only items in the API need to worry about extension outside of the
renderkit. As such, I think leaving things status quo is probably
prudent. Because
Hi Andrew -
On Thu, Apr 10, 2008 at 4:36 PM, Andrew Robinson
[EMAIL PROTECTED] wrote:
I wasn't suggesting blind removal.
Okay. The use of the word most gave me that impression. :-)
IMO final should rarely ever be used, for open source it almost never does
anyone any good.
Final should be
The overuse of final is largely irrelevant in impl packages. The reason
is that removing a final allows the class to remain binary compatible
and only items inside of the impl package should be extending the class.
In some cases, final helps ensure an implied contract. In other words,
if
final should only be used if extending a function would cause it to
break. Forcing someone to call the super method is something that
should be in JavaDoc, not as a final keyword. Final's true purpose is
to create unchangeable member vars and also protect code. For example,
if I have commercial
Well I think we don't see the problem in the same way.
What does good design mean in this case ...!?
Making some methods protected and remove the final for others doesn't hurt
Trinidad itself at all.
So you can't say this is bad design.
If the bad design refers to what we offer the clients, than
Ok, so if you are pro, which solution do you prefer?
And if the configurable one (1st) than what kind of implementation do you
think of?
On Thu, Apr 10, 2008 at 7:17 PM, Andrew Robinson
[EMAIL PROTECTED] wrote:
++1
On Thu, Apr 10, 2008 at 12:55 AM, Martin Marinschek
[EMAIL PROTECTED] wrote:
Andrew Robinson said the following On 4/10/2008 1:36 PM PT:
I wasn't suggesting blind removal. IMO final should rarely ever be
used, for open source it almost never does anyone any good.
Really. Why would good programming practice in the closed source world
be bad programming practice in open
But that is my point precisely. We don't offer the impl classes to
clients to extend. Only the classes in the API.
Scott
Scott
Cristi Toth wrote:
Well I think we don't see the problem in the same way.
What does good design mean in this case ...!?
Making some methods protected and remove
#2, getter / factory-style methods for obtaining delegate renderers.
On Thu, Apr 10, 2008 at 4:02 PM, Cristi Toth [EMAIL PROTECTED] wrote:
Ok, so if you are pro, which solution do you prefer?
And if the configurable one (1st) than what kind of implementation do you
think of?
On Thu, Apr
The String package in Java is final. It's like this because it's a
fundimental non-mutable class and not having it final would cause headaches.
Below you mentioned not being able to create a good looking professional
application with Trinidad. If this is the case then perhaps we should
fix
So if this is the case (ie- people who extend impl expect things to
break and know what they are doing), why is it so hard for these people
to submit a patch to add a protected or remove a final? Again,
everything will remain binary compatible.
Scott
Cristi Toth wrote:
Ok, so if you are
Andrew Robinson said the following On 4/10/2008 2:55 PM PT:
final should only be used if extending a function would cause it to
break. Forcing someone to call the super method is something that
should be in JavaDoc, not as a final keyword.
Andy already listed other uses of final.
Final's true
Sorry, this went to the wrong thread. Please disregard.
Scott
Scott O'Bryan wrote:
So if this is the case (ie- people who extend impl expect things to
break and know what they are doing), why is it so hard for these
people to submit a patch to add a protected or remove a final? Again,
hello,
as mentioned: sev-en started as feasibility study. so there are some topics
i haven't cared about so far.
to keep it short: i would like to finish some tasks before we discuss
details. it's much more efficient to discuss the intermediate result after
this process.
(at the moment the
[
https://issues.apache.org/jira/browse/MYFACES-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12587812#action_12587812
]
Leonardo Uribe commented on MYFACES-1854:
-
Maybe if you try to load the bundle
[
https://issues.apache.org/jira/browse/MYFACES-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12587813#action_12587813
]
Leonardo Uribe commented on MYFACES-1854:
-
Maybe if you try to load the bundle
Andy is right in that we haven't nixed the XSS files yet because they
have features in it that the base skins are using that the CSS
format does not yet support.
Andy's list looks good.
Another one is @imports. XSS does that. There's already an open JIRA
issue on this.
Andy Schwartz wrote,
The thing is, is not what is the strive for the perfect architecture,
but what is the best way make Trinidad the easiest to use to develop
business applications with (not saying the architecture should not be
solid, just that trying to make an architecture that provides
everyones needs for every
Okay, I have yet another approach that I thought of while walking my
dogs that is much more JSF-ish and goes along with Christi's email on
sub-renderers.
Instead creating a whole bloody wrapper API framework that would make
the API hard to change, what about breaking the renderers down even
more
[
https://issues.apache.org/jira/browse/MYFACES-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12587828#action_12587828
]
Leonardo Uribe commented on MYFACES-1842:
-
I have modified the helloworld
[
https://issues.apache.org/jira/browse/MYFACES-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12587846#action_12587846
]
Leonardo Uribe commented on MYFACES-1842:
-
I will move the problem of hidden
h:commandLink with target=_blank does not work
Key: MYFACES-1856
URL: https://issues.apache.org/jira/browse/MYFACES-1856
Project: MyFaces Core
Issue Type: Bug
Reporter: Leonardo
55 matches
Mail list logo
