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.
Our
> 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 th
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.
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
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 anymore!
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
addRenderer(UIForm.COMPONE
[
https://issues.apache.org/jira/browse/MYFACES-1848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12587542#action_12587542
]
Guy Bashan commented on MYFACES-1848:
-
This bug is pretty annoying and can be simulat
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
> MyFa
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 somethi
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 o
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 ... s
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 arche
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 rig
ErrorPageWriter causes Facelets/MyFaces confusion
-
Key: MYFACES-1853
URL: https://issues.apache.org/jira/browse/MYFACES-1853
Project: MyFaces Core
Issue Type: Improvement
Components:
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 .
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
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
Repo
++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. I
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 fr
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-tabpanel&focusedCommentId=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 mo
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 far
[
https://issues.apache.org/jira/browse/TOMAHAWK-1226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 t
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 shoul
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 som
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 sof
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]>
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 so
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
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 t
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 pro
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,
every
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 concep
[
https://issues.apache.org/jira/browse/MYFACES-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12587812#action_12587812
]
Leonardo Uribe commented on MYFACES-1854:
-
Maybe if you try to load the bundle us
[
https://issues.apache.org/jira/browse/MYFACES-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12587813#action_12587813
]
Leonardo Uribe commented on MYFACES-1854:
-
Maybe if you try to load the bundle us
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, On
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 us
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 i
[
https://issues.apache.org/jira/browse/MYFACES-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12587828#action_12587828
]
Leonardo Uribe commented on MYFACES-1842:
-
I have modified the helloworld exampl
[
https://issues.apache.org/jira/browse/MYFACES-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12587846#action_12587846
]
Leonardo Uribe commented on MYFACES-1842:
-
I will move the problem of hidden fiel
hidden fields created when using h:commandLink and f:param should be created
and removed using javascript
-
Key: MYFACES-1855
URL: https://issues.apache.org/ji
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
h:commandLink with onclick="customFunction" does not do what taglib javadoc of
jsf ri suggest to do
---
Key: MYFACES-1857
URL: https://issues.apache.org/jira/browse/MY
[
https://issues.apache.org/jira/browse/MYFACES-1855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12587862#action_12587862
]
Mario Ivankovits commented on MYFACES-1855:
---
It would be really great if you co
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 a
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 ano
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
>
55 matches
Mail list logo