[jira] Commented: (MYFACES-1855) hidden fields created when using h:commandLink and f:param should be created and removed using javascript
[ 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 could externalize the javascript too. Currently it is simply inlined into the source, which looks not very professional I think. 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/jira/browse/MYFACES-1855 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.2 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Myfaces render the hidden fields before the end of the form, which cause compatibility problems when someone does not use h:form to encapsulate a form. Mojarra or jsf ri does not, instead create the hidden fields before submit (including the hidden fields for params), submit the form an then remove the hidden fields to avoid unwanted effects. Myfaces set the hidden fields (if it is not rendered on the form creates it), submit the form and then set the values of the hidden fields to null. I have noted that autoscroll feature available when using tomahawk + myfaces uses oamSetHiddenInput instead render the hidden autoscroll part. After thinking a lot (A LOT!!) about this problem, the best for solve this problem is do not render hidden fields for this case, but let the code for hidden fields (compatibility with tomahawk, since jscookmenu use this feature, this should change in a future release). Instead, for h:commandLink, set and remove the hidden fields using javascript. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Trinidad] private / protected final methods in renderers
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 accepted by more people than just Oracle clients, you will need to allow them (if they find out the behaviour of the existing renderers does not fit their use-case well enough) to extend and override the existing behaviour. You can certainly tell them that they are not in a safe land if they do this, but you should not prohibit it. It is much like the time of the Prohibition in the US - what is better - telling people it is not safe to override renderers (=drink alcohol), but allowing them to do so still, and most people will do it appropriately (=drink in moderation) and just fix a problem in the upgrade when it arises, or prohibit it by making everything final and private (=prohibition of drinking alcohol completely), which overly restricts what people may want to do and will lead to something close to a revolution. I can certainly accept Andy's and Blake's statements - let us not open everything, but decide on a case-by-case base what to open up (in reality, we did the same in Tomahawk, in the beginning, most of our methods where private as well, now a lot of hooks have been changed to be protected - where clients actually felt the need to override something), but I cannot accept your statement - this is dangerous for Trinidad and its community. You should change your opinion in this case! Once again: I can accept that renderers are not _meant_ to be overriden, but I cannot accept that it is completely _prohibited_ to do so. Now I know that Cristi is actually working with Trinidad, and that he has a problem, namely he would need to be able to override/replace sub-renderers for a clients design-issue. This is a concrete problem, and if he wants to address it, we should allow him so - and I definitely feel it should be addressed, if you take the general spirit of JSF, which allows a lot of flexibility. regards, Martin On 4/11/08, Scott O'Bryan [EMAIL PROTECTED] wrote: 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 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 this is definitely wrong. Because a quite a lot of clients that me or some of my collaborators have interacted with, have complained a lot about Trinidad code that's so CLOSED !!! Many said that instead of trying a small feature to the trinidad table, you better take the Tomahawk one, and add all the feature you need on it. It's easier and cleaner. The faces-config allows you to override any renderer for any component, right !? So renderers are meant to be overriden. (by the JSF spec) This is the beauty of JSF, because it's so flexible and customizable. How do you expect to override Trinidad renderers? Copying all the code and make some small changes? Imagine that overriding some behaviour of some larger renderers, you have to override the whole renderer hierarchy (i.w. LabelAndMessageRenderer). Between duplicating the whole renderer code and just having some protected renderer methods, which sounds better in design? If we talk about backwards compatibilty, then imagine a whole duplicated renderer which isn't aware of any other updated renderers... And if a custom renderer developer gets a compile error after an update, I assume it won't take him to much time to fix it... If a renderer is not in the API, this means that it shouldn't be overriden !? Let's think a bit out of the box and try to figure what's best for the client. Because that's what matters most... regards, On Thu, Apr 10, 2008 at 11:34 PM, Scott O'Bryan [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: 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 something is final, you know it's implemented nowhere else. In API's I agree with Andy, final should be used only to enforce a contract that should not (can not) change. Most commonly this is used on immutable classes/api but it has some other uses. Scott Andy Schwartz wrote: Hi Andrew - On Thu, Apr 10, 2008 at 4:36 PM, Andrew Robinson [EMAIL
Re: [Trinidad] private / protected final methods in renderers
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 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 into subclasses.
Take the tr:panelPopup for example again. It has:
Outer container
Trigger
Popup
Title bar
Close button
Body
So lets say this is how the renderer could be built:
First, create a bunch of renderer types:
org.apache.myfaces.trinidad.Popup
org.apache.myfaces.trinidad.Popup.Trigger
org.apache.myfaces.trinidad.Popup.PopupShell
org.apache.myfaces.trinidad.Popup.TitleBar
org.apache.myfaces.trinidad.Popup.ButtonArea
org.apache.myfaces.trinidad.Popup.Body
Then register a default renderer for each of these types.
Then the PanelPopupRenderer would in encodeAll:
render outer DIV (ppr stuff)
call a render utils method to get the renderer for the trigger and encode it
call a render utils method to get the renderer for the popup shell and
encode it
in the popup shell renderer:
encode the outer HTML
call a render utils method to get the renderer for the title bar and encode
it
call a render utils method to get the renderer for the popup body and encode
it
in the title bar renderer:
encode the outer HTML
encode the title
call a render utils method to get the renderer for the button area and
encode it
in the body renderer:
encode the outer HTML
encode the children components
This way there are many renderers to one component. The renderers
would be registered in the faces-config.xml just like any ordinary
renderers. Since the FacesBean allows renderers to encode any
component that has certain property keys, this is ideal.
Take for example the close button on the popup, we could have a faces
bean alias wrapper. What I mean by this is something like this:
public class PopupTitleBarRenderer extends XhtmlRenderer {
protected void encodeAll(FacesContext context, RenderingContext rc,
UIComponent component, FacesBean bean) throws IOException {
FacesBean wrapped = new AliasedFacesBean(bean);
wrapped.map(text, title);
...
This way a command button renderer could be used to render the close
button using the title from the dialog as the text of the button.
Using this way, the only exposed API are the sub-renderer types that
can be defined in the faces config. New types can be added and old
ones removed without breaking Java interfaces or abstract class APIs
(although it would have to be controlled to not break custom code too
badly).
-Andrew
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [proposal] jsf validation with annotations
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 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 concepts of the core are pretty stable.) in the mean time i would suggest to open a vote concerning the myfaces sub-project topic. furthermore, some of you don't like the original/internal code-name. is it enough to omit the hyphen? (sev-en - seven) or do you have some fancy names in mind? regards, gerhard 2008/4/10, Matthias Wessendorf [EMAIL PROTECTED]: 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 MyFaces/Orchestra type environment. I also agree it should my a MyFaces wide decision because it impacts expectations on the renderkits. Scott Kito D. Mann wrote: I think Mario has made some very good points... -Original Message- From: Mario Ivankovits [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 09, 2008 5:14 AM To: MyFaces Development Subject: Re: [proposal] jsf validation with annotations Hi! my position on this is we could make sev-en part of orchestra, if the orchestra crew really, really wants it. If not, this should just be a separate sub-module in MyFaces. It is interesting enough to stand on its own. First, Orchestra is part of the MyFaces community, so it really, really should be a decision the MyFaces community felt, and not a Orchestra Team only one. Anyway, I think this is a question on how we position Orchestra. If it is a strong position against JBoss Seam, then it probably might make sense to include everything which makes life easier for the developer into Orchestra - just as Seam tries to do. However, then we loose one of the strongest arguments pro Orchestra: Being a lightweight Conversation-Centric Library. If, we could add it as sub-module to Orchestra, but I think the best place for sev-en (would like to see a new name anyway) is to be a submodule of MyFaces. But first I'd like to see the technical details of how the sev-en core works. e.g. in the examples I've seen a lot of converter wrapper stuff ... Building an official MyFaces Maven Artifact which bootup a development environment (MyFaces Fullstack) with what we think on need for development of any-range-sized applications would be more approriate then. Such a project could include sev-en too. Ciao, Mario -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [proposal] jsf validation with annotations
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 Petracek [EMAIL PROTECTED] wrote: 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 concepts of the core are pretty stable.) in the mean time i would suggest to open a vote concerning the myfaces sub-project topic. furthermore, some of you don't like the original/internal code-name. is it enough to omit the hyphen? (sev-en - seven) or do you have some fancy names in mind? regards, gerhard 2008/4/10, Matthias Wessendorf [EMAIL PROTECTED]: 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 MyFaces/Orchestra type environment. I also agree it should my a MyFaces wide decision because it impacts expectations on the renderkits. Scott Kito D. Mann wrote: I think Mario has made some very good points... -Original Message- From: Mario Ivankovits [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 09, 2008 5:14 AM To: MyFaces Development Subject: Re: [proposal] jsf validation with annotations Hi! my position on this is we could make sev-en part of orchestra, if the orchestra crew really, really wants it. If not, this should just be a separate sub-module in MyFaces. It is interesting enough to stand on its own. First, Orchestra is part of the MyFaces community, so it really, really should be a decision the MyFaces community felt, and not a Orchestra Team only one. Anyway, I think this is a question on how we position Orchestra. If it is a strong position against JBoss Seam, then it probably might make sense to include everything which makes life easier for the developer into Orchestra - just as Seam tries to do. However, then we loose one of the strongest arguments pro Orchestra: Being a lightweight Conversation-Centric Library. If, we could add it as sub-module to Orchestra, but I think the best place for sev-en (would like to see a new name anyway) is to be a submodule of MyFaces. But first I'd like to see the technical details of how the sev-en core works. e.g. in the examples I've seen a lot of converter wrapper stuff ... Building an official MyFaces Maven Artifact which bootup a development environment (MyFaces Fullstack) with what we think on need for development of any-range-sized applications would be more approriate then. Such a project could include sev-en too. Ciao, Mario -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [proposal] jsf validation with annotations
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 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 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 concepts of the core are pretty stable.) in the mean time i would suggest to open a vote concerning the myfaces sub-project topic. furthermore, some of you don't like the original/internal code-name. is it enough to omit the hyphen? (sev-en - seven) or do you have some fancy names in mind? regards, gerhard 2008/4/10, Matthias Wessendorf [EMAIL PROTECTED]: 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 MyFaces/Orchestra type environment. I also agree it should my a MyFaces wide decision because it impacts expectations on the renderkits. Scott Kito D. Mann wrote: I think Mario has made some very good points... -Original Message- From: Mario Ivankovits [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 09, 2008 5:14 AM To: MyFaces Development Subject: Re: [proposal] jsf validation with annotations Hi! my position on this is we could make sev-en part of orchestra, if the orchestra crew really, really wants it. If not, this should just be a separate sub-module in MyFaces. It is interesting enough to stand on its own. First, Orchestra is part of the MyFaces community, so it really, really should be a decision the MyFaces community felt, and not a Orchestra Team only one. Anyway, I think this is a question on how we position Orchestra. If it is a strong position against JBoss Seam, then it probably might make sense to include everything which makes life easier for the developer into Orchestra - just as Seam tries to do. However, then we loose one of the strongest arguments pro Orchestra: Being a lightweight Conversation-Centric Library. If, we could add it as sub-module to Orchestra, but I think the best place for sev-en (would like to see a new name anyway) is to be a submodule of MyFaces. But first I'd like to see the technical details of how the sev-en core works. e.g. in the examples I've seen a lot of converter wrapper stuff ... Building an official MyFaces Maven Artifact which bootup a development environment (MyFaces Fullstack) with what we think on need for development of any-range-sized applications would be more approriate then. Such a project could include sev-en too. Ciao, Mario -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Resolved: (TOMAHAWK-1214) allow to process form submits in a queue for high-speed input handling
[ 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 would be an interesting feature anyway, so resolved with later to get it out of line, but to keep the idea too. allow to process form submits in a queue for high-speed input handling -- Key: TOMAHAWK-1214 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1214 Project: MyFaces Tomahawk Issue Type: New Feature Components: PPRPanelGroup Reporter: Mario Ivankovits Assignee: Ernst Fastl Enhance the PPR stuff in a way which allows to process form input asynchron in a queue for high-speed input handling. Probably by adding a new attribute to the PPRPanelGroup called queued=true|false. With true the form data should be collected and held in a queue on client side. The client then checks that queue at given intervalls (queueCheckInterval=) if there is data in the queue and transmit that data to the server like a normal ppr request. Between each transmit a queueWaitInterval= should be waited. A status component (queueShowStatus=true|false) should show the success of each transmit. A client side javascript should be used to extract the status text information from the form data (queueShowStatusInfoBuilder=javascript-method-name(formData)) The PprPanelGroup should also be enhanced to being able to point to the messages component (messages=component-id) the queueStatus information should then be able to visualize that text and show e.g. a red-cross if there were errors (=messages) For this first version the status info can be a simple table created client-side using some css to allow to format it according to the application skin. A simple table with two columns status-info|return-visualization status-info is the text returned by the queueShowStatusInfoBuilder javascript method and return-visualization might be an icon. Only waiting requests and those with errors should be shown, correctly finished requests can be removed from the list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Trinidad] why does Trinidad override javax.faces.* renderers?
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 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 something on renderKit loading etc. there)
If it works fine for you there, I'll check again with our internal things,
and I'll finally remove that code.
Thanks!
-M
On Thu, Apr 10, 2008 at 10:57 AM, [EMAIL PROTECTED] wrote:
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.COMPONENT_FAMILY,
javax.faces.Form,
new HtmlFormRenderer());
// And we render UICommandLink with our own renderer
addRenderer(UICommand.COMPONENT_FAMILY,
javax.faces.Link,
new HtmlCommandLinkRenderer());
// In jsf 1.1_02 the ri FormRenderer writes out script used by
// h:commandButton. Since we override the RI FormRenderer, we also
// need to override the commandButton renderer:
addRenderer(UICommand.COMPONENT_FAMILY,
javax.faces.Button,
new HtmlCommandButtonRenderer());
}
If you say now it should work, can we remove it ?
at least for 1.2 version.
thanks for the support
On 4/10/08, Matthias Wessendorf [EMAIL PROTECTED] wrote:
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.*
components
like
Form, HtmlCommandButton and HtmlCommandLink.
indeed.
Why is this needed?
because the JSF spec is poor ?
Well... :) These component details know to much abo
they know to much about the other details (at least in the past).
like the way they render.
Perhaps solved now, but I never looked at that.
Perhaps you may check in CoreRenderKit's _addHtmlBasic() ?
Thx
I noticed it adds some custom scripts.
BUT why should it be so intrusive in the default renderers?
The problem that made me find this was that I got some exceptions
in
the
tomahawk PPR.
Except on some pages, the only Trinidad component I use is
tr:document
to
have the skinning enabled.
I definitely expect for the Tomahawk PPR within a h:form and
containing
an
h:commandButton to work.
i got this stack trace on a PPR submit:
javax.faces.FacesException: Exception while calling encodeEnd on
component :
{Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId:
/pages/configuration/configAssessmentModuleEdit.xhtml][Class:
org.apache.myfaces.trinidad.component.core.CoreDocument,Id:
j_id1][Class:
javax.faces.component.html.HtmlForm,Id: mform][Class:
org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane,Id:
moduleEditTab][Class:
org.apache.myfaces.custom.tabbedpane.HtmlPanelTab,Id:
childrenTab][Class:
org.apache.myfaces.custom.ppr.PPRPanelGroup,Id:
pprQuestionEdit][Class:
javax.faces.component.html.HtmlPanelGroup,Id:
j_id174]}
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:559)
at
org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.renderChild(RendererUtils.java:420)
at
org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.renderChildren(RendererUtils.java:401)
at
org.apache.myfaces.custom.ppr.PPRPanelGroupRenderer.encodeChildren(PPRPanelGroupRenderer.java:93)
at
javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:543)
at
org.apache.myfaces.custom.ppr.PPRPhaseListener.encodeTriggeredComponents(PPRPhaseListener.java:288)
at
org.apache.myfaces.custom.ppr.PPRPhaseListener.processPartialPageRequest(PPRPhaseListener.java:169)
at
org.apache.myfaces.custom.ppr.PPRPhaseListener.beforePhase(PPRPhaseListener.java:94)
at
org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersBefore(PhaseListenerManager.java:73)
Re: [Trinidad] why does Trinidad override javax.faces.* renderers?
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] wrote:
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 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 something on renderKit loading etc. there)
If it works fine for you there, I'll check again with our internal things,
and I'll finally remove that code.
Thanks!
-M
On Thu, Apr 10, 2008 at 10:57 AM, [EMAIL PROTECTED] wrote:
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.COMPONENT_FAMILY,
javax.faces.Form,
new HtmlFormRenderer());
// And we render UICommandLink with our own renderer
addRenderer(UICommand.COMPONENT_FAMILY,
javax.faces.Link,
new HtmlCommandLinkRenderer());
// In jsf 1.1_02 the ri FormRenderer writes out script used by
// h:commandButton. Since we override the RI FormRenderer, we also
// need to override the commandButton renderer:
addRenderer(UICommand.COMPONENT_FAMILY,
javax.faces.Button,
new HtmlCommandButtonRenderer());
}
If you say now it should work, can we remove it ?
at least for 1.2 version.
thanks for the support
On 4/10/08, Matthias Wessendorf [EMAIL PROTECTED] wrote:
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.*
components
like
Form, HtmlCommandButton and HtmlCommandLink.
indeed.
Why is this needed?
because the JSF spec is poor ?
Well... :) These component details know to much abo
they know to much about the other details (at least in the past).
like the way they render.
Perhaps solved now, but I never looked at that.
Perhaps you may check in CoreRenderKit's _addHtmlBasic() ?
Thx
I noticed it adds some custom scripts.
BUT why should it be so intrusive in the default renderers?
The problem that made me find this was that I got some
exceptions
in
the
tomahawk PPR.
Except on some pages, the only Trinidad component I use is
tr:document
to
have the skinning enabled.
I definitely expect for the Tomahawk PPR within a h:form and
containing
an
h:commandButton to work.
i got this stack trace on a PPR submit:
javax.faces.FacesException: Exception while calling encodeEnd on
component :
{Component-Path : [Class:
javax.faces.component.UIViewRoot,ViewId:
/pages/configuration/configAssessmentModuleEdit.xhtml][Class:
org.apache.myfaces.trinidad.component.core.CoreDocument,Id:
j_id1][Class:
javax.faces.component.html.HtmlForm,Id: mform][Class:
org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane,Id:
moduleEditTab][Class:
org.apache.myfaces.custom.tabbedpane.HtmlPanelTab,Id:
childrenTab][Class:
org.apache.myfaces.custom.ppr.PPRPanelGroup,Id:
pprQuestionEdit][Class:
javax.faces.component.html.HtmlPanelGroup,Id:
j_id174]}
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:559)
at
org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.renderChild(RendererUtils.java:420)
at
org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.renderChildren(RendererUtils.java:401)
at
org.apache.myfaces.custom.ppr.PPRPanelGroupRenderer.encodeChildren(PPRPanelGroupRenderer.java:93)
at
javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:543)
at
Re: [Trinidad] private / protected final methods in renderers
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 take for example some not so trivial scripts that are generated
in a private method,
which is called from a larger protected method.
If somebody wants to override the protected method,
it has to duplicate the script rendering method because he can't call it.
IMO it's not so hard to think of a stable method signature for that
kind of cases.
On 4/11/08, 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 direction.
regards,
Martin
On 4/11/08, Andrew Robinson [EMAIL PROTECTED] wrote:
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 into subclasses.
Take the tr:panelPopup for example again. It has:
Outer container
Trigger
Popup
Title bar
Close button
Body
So lets say this is how the renderer could be built:
First, create a bunch of renderer types:
org.apache.myfaces.trinidad.Popup
org.apache.myfaces.trinidad.Popup.Trigger
org.apache.myfaces.trinidad.Popup.PopupShell
org.apache.myfaces.trinidad.Popup.TitleBar
org.apache.myfaces.trinidad.Popup.ButtonArea
org.apache.myfaces.trinidad.Popup.Body
Then register a default renderer for each of these types.
Then the PanelPopupRenderer would in encodeAll:
render outer DIV (ppr stuff)
call a render utils method to get the renderer for the trigger and encode
it
call a render utils method to get the renderer for the popup shell and
encode it
in the popup shell renderer:
encode the outer HTML
call a render utils method to get the renderer for the title bar and
encode
it
call a render utils method to get the renderer for the popup body and
encode
it
in the title bar renderer:
encode the outer HTML
encode the title
call a render utils method to get the renderer for the button area and
encode it
in the body renderer:
encode the outer HTML
encode the children components
This way there are many renderers to one component. The renderers
would be registered in the faces-config.xml just like any ordinary
renderers. Since the FacesBean allows renderers to encode any
component that has certain property keys, this is ideal.
Take for example the close button on the popup, we could have a faces
bean alias wrapper. What I mean by this is something like this:
public class PopupTitleBarRenderer extends XhtmlRenderer {
protected void encodeAll(FacesContext context, RenderingContext rc,
UIComponent component, FacesBean bean) throws IOException {
FacesBean wrapped = new AliasedFacesBean(bean);
wrapped.map(text, title);
...
This way a command button renderer could be used to render the close
button using the title from the dialog as the text of the button.
Using this way, the only exposed API are the sub-renderer types that
can be defined in the faces config. New types can be added and old
ones removed without breaking Java interfaces or abstract class APIs
(although it would have to be controlled to not break custom code too
badly).
-Andrew
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
Cristi Toth
-
Codebeat
www.codebeat.ro
Re: Quickstart + Archetypes...
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). 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 our projects (that currently support archetypes). Or do you think is the current description in our wiki enough ? -M -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Grant Smith -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
[jira] Commented: (MYFACES-1854) f:selectItems does not evaluates EL expressions
[
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 not supported. Maybe I am using an
older dtd?
The one I am using is: http://java.sun.com/dtd/web-facesconfig_1_1.dtd
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
Reporter: Guy Bashan
f:selectItems does not evaluates EL expressions. This, for example, makes
impossible to create multi-language dynamic drop down items.
Example:
-
SelectItem selectItem = new SelectItem(-1,
#{bundle['dropdown.advertiser.select']})
This EL expression will not be evaluated.
In JSP value is evaluated:
h:selectOneMenu
f:selectItem itemValue=-1
itemLabel=#{bundle['dropdown.advertiser.select'']} /
/h:selectOneMenu
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [Trinidad] why does Trinidad override javax.faces.* renderers?
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 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] wrote:
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 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 something on renderKit loading etc. there)
If it works fine for you there, I'll check again with our internal
things,
and I'll finally remove that code.
Thanks!
-M
On Thu, Apr 10, 2008 at 10:57 AM, [EMAIL PROTECTED] wrote:
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.COMPONENT_FAMILY,
javax.faces.Form,
new HtmlFormRenderer());
// And we render UICommandLink with our own renderer
addRenderer(UICommand.COMPONENT_FAMILY,
javax.faces.Link,
new HtmlCommandLinkRenderer());
// In jsf 1.1_02 the ri FormRenderer writes out script used by
// h:commandButton. Since we override the RI FormRenderer, we also
// need to override the commandButton renderer:
addRenderer(UICommand.COMPONENT_FAMILY,
javax.faces.Button,
new HtmlCommandButtonRenderer());
}
If you say now it should work, can we remove it ?
at least for 1.2 version.
thanks for the support
On 4/10/08, Matthias Wessendorf [EMAIL PROTECTED] wrote:
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.*
components
like
Form, HtmlCommandButton and HtmlCommandLink.
indeed.
Why is this needed?
because the JSF spec is poor ?
Well... :) These component details know to much abo
they know to much about the other details (at least in the past).
like the way they render.
Perhaps solved now, but I never looked at that.
Perhaps you may check in CoreRenderKit's _addHtmlBasic() ?
Thx
I noticed it adds some custom scripts.
BUT why should it be so intrusive in the default renderers?
The problem that made me find this was that I got some
exceptions
in
the
tomahawk PPR.
Except on some pages, the only Trinidad component I use is
tr:document
to
have the skinning enabled.
I definitely expect for the Tomahawk PPR within a h:form and
containing
an
h:commandButton to work.
i got this stack trace on a PPR submit:
javax.faces.FacesException: Exception while calling encodeEnd
on
component :
{Component-Path : [Class:
javax.faces.component.UIViewRoot,ViewId:
/pages/configuration/configAssessmentModuleEdit.xhtml][Class:
org.apache.myfaces.trinidad.component.core.CoreDocument,Id:
j_id1][Class:
javax.faces.component.html.HtmlForm,Id: mform][Class:
org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane,Id:
moduleEditTab][Class:
org.apache.myfaces.custom.tabbedpane.HtmlPanelTab,Id:
childrenTab][Class:
org.apache.myfaces.custom.ppr.PPRPanelGroup,Id:
pprQuestionEdit][Class:
javax.faces.component.html.HtmlPanelGroup,Id:
j_id174]}
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:559)
at
[jira] Commented: (TRINIDAD-989) InputListOfValues limitations
[ 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 work too: e.g. tr:inputListOfValues autoSubmit=true/false(doesn't matter) id=test / tr:tableLayout partialTriggers=test .. /tr:tableLayout does not work(note:left out the everywhere) InputListOfValues limitations - Key: TRINIDAD-989 URL: https://issues.apache.org/jira/browse/TRINIDAD-989 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.0.6-core Reporter: Tomas Havelka It should be good to improve and fix component inputListOfValues behavior, because some limitations make it unusable. Below is list of these limitations: 1) Not supported LaunchListener - in many cases it is recommended to initialize LOV dialog with several parameters 2) Not used convertor for returned values - when value is returned from dialog, component does not use convertor to convert it to String value; it simply calls toString() method on that value to apply it to component 3) Custom ReturnListener problem - when custom ReturnListener is registered, it cannot manipulate with component value; it could be useful to process some additional logic on return value before setting it to component -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [OT] IP Clearance for Tiles-Kaolin: seeking a volunteer
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, 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 me. Aaron is willing to give his software grant to donate it to ASF. Currently I am in search of a volunteer for the IP clerance processing. I already asked Tiles' PMC Chair (Greg Reddin) but he is too busy to help. I already asked the Incubator mailing list, with no answer. If anybody can help me, I will appreciate it much :-) Thanks in advance Antonio -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [OT] IP Clearance for Tiles-Kaolin: seeking a volunteer
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 developers mailing list? http://tiles.apache.org/mail-lists.html Thanks again Antonio
Re: [Trinidad] delegated sub-renderers
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 regards, On 4/11/08, Scott O'Bryan [EMAIL PROTECTED] wrote: 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, everything will remain binary compatible. Scott Cristi Toth 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 10, 2008 at 7:17 PM, Andrew Robinson [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: ++1 On Thu, Apr 10, 2008 at 12:55 AM, Martin Marinschek [EMAIL PROTECTED] mailto:[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 enough to say: this is part of the impl package - it might change from version to version, your own fault, if you extend it and it breaks! IMHO, Adam is wrong in this regard. regards, Martin On 4/10/08, Cristi Toth [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: 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] mailto:[EMAIL PROTECTED] wrote: I am not sure if you will get much support as Trinidad has all the renderers in the impl package, and therefore should not be considered part of its api and also should not be extended. Fighting this and asking for more APIs in the past was fruitless for me, but then again that was when Adam Winer was the constant one to veto all improvements. On Wed, Apr 9, 2008 at 6:14 PM, Cristi Toth [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, As you probably know, there are a lot of composed renderers in Trinidad which delegate to other subrenderers to render parts of the component. i.e. Table renderer delegates to: - NavBar(subclass of SelectRangeChoiceBarRenderer), - AllDetails (subclass of ShowDetailRenderer) - DetailColumnRenderer input fields renderers (subclasses of InputLabelAndMessageRenderer) delegate to: - one renderer that renders the input field (subclass of FormInputRenderer) - Label (subclass of OutputLabelRenderer) - Message (subclass of MessageRenderer) and many more... As this may look like good practice, it makes life hell for the developers that want to customize/override these renderers. I have 2 possible solutions: 1. make some xml config file that maps a sub-renderer type to a renderer class I know this might look like the old uix practice, but it's for a differernt reason. With a small xsd and some docs, this will be much more transparent. 2. at least have protected getters that return a renderer instance either for using the default defined sub-renderer in an overriden method or just for overriding that sub-renderer itself I personally like the 1st solution more, because it's easier to override sub-renderers defined in a super class of more renderers (LabelAndMessageRenderer) Opinions, suggestions, other solutions? regards -- Cristi Toth - Codebeat www.codebeat.ro http://www.codebeat.ro -- Cristi Toth - Codebeat www.codebeat.ro http://www.codebeat.ro -- http://www.irian.at Your
[VOTE] Release Tobago 1.0.16
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 number of the release is 647113 and tagged as tobago-1.0.16. Staging distribution: http://people.apache.org/~bommel/repo Staging repository: http://people.apache.org/~bommel/repo The Vote is open for 72h. [ ] +1 [ ] +0 [ ] -1
Re: [VOTE] Release Tobago 1.0.16
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 available at the staging location and the revision number of the release is 647113 and tagged as tobago-1.0.16. Staging distribution: http://people.apache.org/~bommel/repo Staging repository: http://people.apache.org/~bommel/repo The Vote is open for 72h. [ ] +1 [ ] +0 [ ] -1
Re: [Trinidad] private / protected final methods in renderers
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 classes are entirely private/off-limits, however, if there is functionality here that our users legitimately need to extend, then we should try to facilitate that by promoting the functionality in question over to the public API (trinidadapi package), accepting the burden that this is, now, from here on out, part of our public API. 3. Hey, well, we all know that these classes are off-limits in spirit, but guess what, people are going to extend them, not for malicious purposes but because they are trying to solve a real problem. While moving functionality to the public API is the correct solution, we also recognize that this requires significantly more effort, and requires us to sacrifice future flexibility. Instead of paying this price, we prefer live with the fact that, yes, some small set of users might extend these, and that we might even need to make some tweaks in order to facilitate that, though we aren't willing to claim that these APIs are officially supported, and we make no guarantee that we won't break things in a future release. 4. The APIs in trinidadinternal should be part of our public API, officially supported, guaranteed not to change. I don't think that anyone is lobbying for #1 or #4. I think that Scott is in favor of #2. Note that this doesn't mean no love for Christi and the problems that he is trying to solve. Just that Scott's preferred way to solve these problems is by defining public APIs rather than have people depend on unofficial/unsupported/internal APIs. It sounds like several people are in favor of #3. I am somewhere on the fence between #2 and #3. I think that #2 is the correct thing to do, but I also believe that this is a significant burden, so I am tempted by #3 as a way to ease some of the frustration. Before we discuss questions like whether we should be breaking out renderers into smaller sub-renderers, or whether particular methods should be final/private/protected/whatever, I think we need to agree as a community what our stance is on on the question of how we view trinidadinternal. Andy
Re: [Trinidad] private / protected final methods in renderers
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 ask for the equivalent functionality to be promoted to the API in a later release. If people do not mind being broken by new releases, why should we try to prevent them from being able to do what they need to do to be able to write their products? Saying #2 only is a sure way to stop the myfaces community from using Trinidad. On 4/11/08, 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 want to extend one of these tough luck. No love for you. Go away. 2. These classes are entirely private/off-limits, however, if there is functionality here that our users legitimately need to extend, then we should try to facilitate that by promoting the functionality in question over to the public API (trinidadapi package), accepting the burden that this is, now, from here on out, part of our public API. 3. Hey, well, we all know that these classes are off-limits in spirit, but guess what, people are going to extend them, not for malicious purposes but because they are trying to solve a real problem. While moving functionality to the public API is the correct solution, we also recognize that this requires significantly more effort, and requires us to sacrifice future flexibility. Instead of paying this price, we prefer live with the fact that, yes, some small set of users might extend these, and that we might even need to make some tweaks in order to facilitate that, though we aren't willing to claim that these APIs are officially supported, and we make no guarantee that we won't break things in a future release. 4. The APIs in trinidadinternal should be part of our public API, officially supported, guaranteed not to change. I don't think that anyone is lobbying for #1 or #4. I think that Scott is in favor of #2. Note that this doesn't mean no love for Christi and the problems that he is trying to solve. Just that Scott's preferred way to solve these problems is by defining public APIs rather than have people depend on unofficial/unsupported/internal APIs. It sounds like several people are in favor of #3. I am somewhere on the fence between #2 and #3. I think that #2 is the correct thing to do, but I also believe that this is a significant burden, so I am tempted by #3 as a way to ease some of the frustration. Before we discuss questions like whether we should be breaking out renderers into smaller sub-renderers, or whether particular methods should be final/private/protected/whatever, I think we need to agree as a community what our stance is on on the question of how we view trinidadinternal. Andy
Re: [VOTE] Release Tobago 1.0.16
+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: http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273styleName=Htmlversion=12312966 The version is available at the staging location and the revision number of the release is 647113 and tagged as tobago-1.0.16. Staging distribution: http://people.apache.org/~bommel/repo Staging repository: http://people.apache.org/~bommel/repo The Vote is open for 72h. [ ] +1 [ ] +0 [ ] -1 -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [Trinidad] private / protected final methods in renderers
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 can live with this. 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 haphazardly. If people do not mind being broken by new releases, why should we try to prevent them from being able to do what they need to do to be able to write their products? Because: 1. No matter what is said here and now in this thread, nobody likes it when things unexpectedly break when they pick up a new release. 2. There is another solution available. The other solution is to open things up in response to need. Since there is already a clear path for dealing with missing functionality (open an issue, submit a patch), I think we should use that. Of course, this means that if people go to the trouble of logging issues/submitting patches for changes in the Renderer code base, we have to be willing to take the time to think through/accept the proposed changes. Oh, and, that's not to say that if people have time to go through the Renderers and clean up the existing contracts, we shouldn't do that too. Just that while doing this some level of critical thinking needs to be applied. Andy
Re: [VOTE] Release Tobago 1.0.16
+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 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 number of the release is 647113 and tagged as tobago-1.0.16. Staging distribution: http://people.apache.org/~bommel/repohttp://people.apache.org/%7Ebommel/repo Staging repository: http://people.apache.org/~bommel/repohttp://people.apache.org/%7Ebommel/repo The Vote is open for 72h. [ ] +1 [ ] +0 [ ] -1 -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Grant Smith
Re: [Trinidad] private / protected final methods in renderers
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 haphazardly. My point is that protected in the trinidad-impl.jar is not an API that is exposed. Since it is not an API, therefore it does not have to be designed as such. Let me give you a valid use case (valid as it has happened to me while working on a project, not Trinidad, but similar open source issue): 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 me to do it if it were protected 5) So assuming #3, the method is protected and in the trinidad-impl.jar 6) I extend the method, hacking the renderer and get the code to work as required by my company and my customers. 7) We ship on this code to get it out the door 8) In the meantime, I create a JIRA issue to expose the functionality I require 9) It goes through weeks of debate (operating on recent Trinidad experience on this comment) and finally 2 days to 5 months later makes it into a SNAPSHOT build 10) My company has a policy to only use released versions, so I wait and wait for the release (which is much better for Trinidad users that Tomahawk which has less than yearly release cycles) 11) When it finally becomes API, I port my code from the hack of subclassing the code to the new API So as you can see, it was never my intention to treat the usage of the protected method as a solution, but a temporary way to get my code to work. Asking users to log bugs and wait for discussion and then implementation and then a release is simply not feasible for many companies that need to get software out the door. So when I say #3 then #2, I mean to allow people to get their code out quickly and then go through the proper channels to improve the code. Saying #2 only is just not feasible for companies to meet deadlines and many companies will not permit you to change open source code and ship the changed versions (some afraid of licenses, some afraid of maintenance). I fully agree that #2 is the solution though and even that we need to make some part of the trinidad rendering in the API, because I strongly feel that only having components in the API is just not customizable enough, and I don't think that components with 300 attributes and facets is the way to go.
Re: [Trinidad] private / protected final methods in renderers
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 Trinidad, I think #3 is a requirement for short term usage and #2 as the goal. I can live with this. 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 haphazardly. If people do not mind being broken by new releases, why should we try to prevent them from being able to do what they need to do to be able to write their products? Because: 1. No matter what is said here and now in this thread, nobody likes it when things unexpectedly break when they pick up a new release. 2. There is another solution available. The other solution is to open things up in response to need. Since there is already a clear path for dealing with missing functionality (open an issue, submit a patch), I think we should use that. Of course, this means that if people go to the trouble of logging issues/submitting patches for changes in the Renderer code base, we have to be willing to take the time to think through/accept the proposed changes. Oh, and, that's not to say that if people have time to go through the Renderers and clean up the existing contracts, we shouldn't do that too. Just that while doing this some level of critical thinking needs to be applied. Andy
Re: [Trinidad] private / protected final methods in renderers
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 is a really big issue, and I believe that you and others think it is, then take the time to make it right. Think through the api's, clean them up, and put them in the api package. The Trinidad framework does offer a lot of flexibility for custom component development, it's just not at the granularity that some people want them to be. We don't expose specific renderers, just the rendering infrastructure. If there are components that people need to enhance/override then we should look at making those public, but really, how hard is it to write a renderer or (better yet IMO) make the renderers do what you want them to do though the use of attributes and better skinning? Scott Andrew Robinson wrote: 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 haphazardly. My point is that protected in the trinidad-impl.jar is not an API that is exposed. Since it is not an API, therefore it does not have to be designed as such. Let me give you a valid use case (valid as it has happened to me while working on a project, not Trinidad, but similar open source issue): 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 me to do it if it were protected 5) So assuming #3, the method is protected and in the trinidad-impl.jar 6) I extend the method, hacking the renderer and get the code to work as required by my company and my customers. 7) We ship on this code to get it out the door 8) In the meantime, I create a JIRA issue to expose the functionality I require 9) It goes through weeks of debate (operating on recent Trinidad experience on this comment) and finally 2 days to 5 months later makes it into a SNAPSHOT build 10) My company has a policy to only use released versions, so I wait and wait for the release (which is much better for Trinidad users that Tomahawk which has less than yearly release cycles) 11) When it finally becomes API, I port my code from the hack of subclassing the code to the new API So as you can see, it was never my intention to treat the usage of the protected method as a solution, but a temporary way to get my code to work. Asking users to log bugs and wait for discussion and then implementation and then a release is simply not feasible for many companies that need to get software out the door. So when I say #3 then #2, I mean to allow people to get their code out quickly and then go through the proper channels to improve the code. Saying #2 only is just not feasible for companies to meet deadlines and many companies will not permit you to change open source code and ship the changed versions (some afraid of licenses, some afraid of maintenance). I fully agree that #2 is the solution though and even that we need to make some part of the trinidad rendering in the API, because I strongly feel that only having components in the API is just not customizable enough, and I don't think that components with 300 attributes and facets is the way to go.
Re: [Trinidad] private / protected final methods in renderers
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 wrong for someone (using a TABLE instead of a DIV...). If you ever tried to write an application using Trinidad you may understand ;) . Having huge amounts of attributes to make all the little things customizable would make (1) a really bad and hard to use API and (2) would have performance that sucked. If I want all my table components to render in a certain way, it is much better for me to customize the renderer than to have the renderer do if or switch statements on attributes all the time to customize how it does the rendering. On Fri, Apr 11, 2008 at 10:25 AM, Scott O'Bryan [EMAIL PROTECTED] wrote: 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 is a really big issue, and I believe that you and others think it is, then take the time to make it right. Think through the api's, clean them up, and put them in the api package. The Trinidad framework does offer a lot of flexibility for custom component development, it's just not at the granularity that some people want them to be. We don't expose specific renderers, just the rendering infrastructure. If there are components that people need to enhance/override then we should look at making those public, but really, how hard is it to write a renderer or (better yet IMO) make the renderers do what you want them to do though the use of attributes and better skinning? Scott Andrew Robinson wrote: 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 haphazardly. My point is that protected in the trinidad-impl.jar is not an API that is exposed. Since it is not an API, therefore it does not have to be designed as such. Let me give you a valid use case (valid as it has happened to me while working on a project, not Trinidad, but similar open source issue): 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 me to do it if it were protected 5) So assuming #3, the method is protected and in the trinidad-impl.jar 6) I extend the method, hacking the renderer and get the code to work as required by my company and my customers. 7) We ship on this code to get it out the door 8) In the meantime, I create a JIRA issue to expose the functionality I require 9) It goes through weeks of debate (operating on recent Trinidad experience on this comment) and finally 2 days to 5 months later makes it into a SNAPSHOT build 10) My company has a policy to only use released versions, so I wait and wait for the release (which is much better for Trinidad users that Tomahawk which has less than yearly release cycles) 11) When it finally becomes API, I port my code from the hack of subclassing the code to the new API So as you can see, it was never my intention to treat the usage of the protected method as a solution, but a temporary way to get my code to work. Asking users to log bugs and wait for discussion and then implementation and then a release is simply not feasible for many companies that need to get software out the door. So when I say #3 then #2, I mean to allow people to get their code out quickly and then go through the proper channels to improve the code. Saying #2 only is just not feasible for companies to meet deadlines and many companies will not permit you to change open source code and ship the changed versions (some afraid of licenses, some afraid of maintenance). I fully agree that #2 is the solution though and even that we need to make some part of the trinidad rendering in the API, because I strongly feel that only having components in the API is just not customizable enough, and I don't think that components with 300 attributes and facets is the way to go.
[jira] Commented: (MYFACES-1855) hidden fields created when using h:commandLink and f:param should be created and removed using javascript
[ 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 account, but for now my objective is correct the javascript part of h:commandLink, so probably I will try this later. 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/jira/browse/MYFACES-1855 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.2 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Myfaces render the hidden fields before the end of the form, which cause compatibility problems when someone does not use h:form to encapsulate a form. Mojarra or jsf ri does not, instead create the hidden fields before submit (including the hidden fields for params), submit the form an then remove the hidden fields to avoid unwanted effects. Myfaces set the hidden fields (if it is not rendered on the form creates it), submit the form and then set the values of the hidden fields to null. I have noted that autoscroll feature available when using tomahawk + myfaces uses oamSetHiddenInput instead render the hidden autoscroll part. After thinking a lot (A LOT!!) about this problem, the best for solve this problem is do not render hidden fields for this case, but let the code for hidden fields (compatibility with tomahawk, since jscookmenu use this feature, this should change in a future release). Instead, for h:commandLink, set and remove the hidden fields using javascript. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Trinidad] private / protected final methods in renderers
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 renderers, then +1. But big -1 from me for exposing APIs haphazardly. My point is that protected in the trinidad-impl.jar is not an API that is exposed. Since it is not an API, therefore it does not have to be designed as such. Let me give you a valid use case (valid as it has happened to me while working on a project, not Trinidad, but similar open source issue): 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 me to do it if it were protected 5) So assuming #3, the method is protected and in the trinidad-impl.jar 6) I extend the method, hacking the renderer and get the code to work as required by my company and my customers. 7) We ship on this code to get it out the door 8) In the meantime, I create a JIRA issue to expose the functionality I require 9) It goes through weeks of debate (operating on recent Trinidad experience on this comment) and finally 2 days to 5 months later makes it into a SNAPSHOT build 10) My company has a policy to only use released versions, so I wait and wait for the release (which is much better for Trinidad users that Tomahawk which has less than yearly release cycles) Rhetorical question--why would a company have such a policy? Because they want some guarantee that new Trinidad releases have gone through some set of testing and won't break their code. A pragmatic company would say sure, ship the hacked version. A less pragmatic company would say--just copy the code in the Renderer and then hack that. A few more comments. What happens if the code doesn't already have exactly the hook point you need? What are you going to do--hack in the hook point so that you can override it? One of the points that I believe that Cristi touched on is that deep inheritance hierarchies with large numbers of hooks and lots of delegation to other private code make it difficult to both figure out what is going on and difficult to actually copy the code for modification. One of the solutions is to make sure that we have enough public rendering utilities and that possibly some of the important aspects of delegating renderers and that it is possible to use the labeling renderer support without needing direct access to that Renderer. 11) When it finally becomes API, I port my code from the hack of subclassing the code to the new API So as you can see, it was never my intention to treat the usage of the protected method as a solution, but a temporary way to get my code to work. Asking users to log bugs and wait for discussion and then implementation and then a release is simply not feasible for many companies that need to get software out the door. As noted above, this is by the company's choice. They could have shipped the hacked version. The could have copied the code and then modified it. They did neither. So when I say #3 then #2, I mean to allow people to get their code out quickly and then go through the proper channels to improve the code. Saying #2 only is just not feasible for companies to meet deadlines and many companies will not permit you to change open source code and ship the changed versions (some afraid of licenses, There is no problem with the Apache license here, so the companies are being silly with Regards to Trinidad some afraid of maintenance). Your proposal that we make everything protected and tell the consumers to hope for the best on upgrades does not decrease their maintenance burden. -- Blake Sullivan I fully agree that #2 is the solution though and even that we need to make some part of the trinidad rendering in the API, because I strongly feel that only having components in the API is just not customizable enough, and I don't think that components with 300 attributes and facets is the way to go.
Re: [Trinidad] private / protected final methods in renderers
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 is a requirement for short term usage and #2 as the goal. I can live with this. 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 haphazardly. If people do not mind being broken by new releases, why should we try to prevent them from being able to do what they need to do to be able to write their products? Because: 1. No matter what is said here and now in this thread, nobody likes it when things unexpectedly break when they pick up a new release. 2. There is another solution available. An important point is that there is no practical difference between a customer of Trinidad hacking a private method to be protected and our taking a private method and making it protected with no thought or guarantee that it will be supported in the future. OK, they is a difference. In the case where the customer hacked the function, he had to do more work and knows that he will have to rehack the function in order to pick up a new version and knows that he might be hosed if the superclass code changed (which he should recheck when he reapplies his hack). -- Blake Sullivan The other solution is to open things up in response to need. Since there is already a clear path for dealing with missing functionality (open an issue, submit a patch), I think we should use that. Of course, this means that if people go to the trouble of logging issues/submitting patches for changes in the Renderer code base, we have to be willing to take the time to think through/accept the proposed changes. Oh, and, that's not to say that if people have time to go through the Renderers and clean up the existing contracts, we shouldn't do that too. Just that while doing this some level of critical thinking needs to be applied. Andy
Re: [Trinidad] private / protected final methods in renderers
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 touching the code even more. What happens if the code doesn't already have exactly the hook point you need? Well if nothing was private or final this would never be the case would it? Unless the code was written badly and each function was too long. As noted above, this is by the company's choice. They could have shipped the hacked version. The could have copied the code and then modified it. They did neither. As I mention, this is a real world solution and your workaround is not viable. ...and many companies will not permit you to change open source code and ship the changed versions (some afraid of licenses, There is no problem with the Apache license here, so the companies are being silly with Regards to Trinidad Not silly, it is actually a problem with liability. I don't agree with it really, but trust me, there are extremely good arguments for not modifying open source in a commercial product. Your proposal that we make everything protected and tell the consumers to hope for the best on upgrades does not decrease their maintenance burden. Why is it that this keeps coming back on hope and counting on the best? I keep saying that as a user, we *EXPECT* that it WILL break. The idea is a *temporary* solution until an API is available.
Re: [Trinidad] private / protected final methods in renderers
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 policy. They hate using open source for liability reasons, and hate you touching the code even more. And things would be better if they were told that any time they picked up a patch, it might blow up their code? What happens if the code doesn't already have exactly the hook point you need? Well if nothing was private or final this would never be the case would it? Unless the code was written badly and each function was too long. Unless there is a hook between every line in every function. There is no guarantee that the hooks are in the right place. As noted above, this is by the company's choice. They could have shipped the hacked version. The could have copied the code and then modified it. They did neither. As I mention, this is a real world solution and your workaround is not viable. It is viable. It may not be convenient. ...and many companies will not permit you to change open source code and ship the changed versions (some afraid of licenses, There is no problem with the Apache license here, so the companies are being silly with Regards to Trinidad Not silly, it is actually a problem with liability. I don't agree with it really, but trust me, there are extremely good arguments for not modifying open source in a commercial product. Your proposal that we make everything protected and tell the consumers to hope for the best on upgrades does not decrease their maintenance burden. Why is it that this keeps coming back on hope and counting on the best? I keep saying that as a user, we *EXPECT* that it WILL break. The idea is a *temporary* solution until an API is available. Which we said is fine. They are free to modify the function to make it protected and ship the code. You have come up with an artificial reason for why they can not do this. This has definitely ceased being a productive discussion. -- Blake Sullivan
Re: [Trinidad] private / protected final methods in renderers
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 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 touching the code even more. And things would be better if they were told that any time they picked up a patch, it might blow up their code? What happens if the code doesn't already have exactly the hook point you need? Well if nothing was private or final this would never be the case would it? Unless the code was written badly and each function was too long. Unless there is a hook between every line in every function. There is no guarantee that the hooks are in the right place. As noted above, this is by the company's choice. They could have shipped the hacked version. The could have copied the code and then modified it. They did neither. As I mention, this is a real world solution and your workaround is not viable. It is viable. It may not be convenient. ...and many companies will not permit you to change open source code and ship the changed versions (some afraid of licenses, There is no problem with the Apache license here, so the companies are being silly with Regards to Trinidad Not silly, it is actually a problem with liability. I don't agree with it really, but trust me, there are extremely good arguments for not modifying open source in a commercial product. Your proposal that we make everything protected and tell the consumers to hope for the best on upgrades does not decrease their maintenance burden. Why is it that this keeps coming back on hope and counting on the best? I keep saying that as a user, we *EXPECT* that it WILL break. The idea is a *temporary* solution until an API is available. Which we said is fine. They are free to modify the function to make it protected and ship the code. You have come up with an artificial reason for why they can not do this. This has definitely ceased being a productive discussion. -- Blake Sullivan
Re: [Trinidad] private / protected final methods in renderers
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 trinidad-impl being non-API and enforce that code in this package be backward-compatible 2) somehow move some of the burden of parts of renderers out of trinidad-impl and into trinidad-api 3) introduce some configurable way to override default behavior for rendering certain areas of components. 4) removing some final modifiers after discussion and make extending Trinidad renderers accepted, aka not tabu 5) promoting private members to protected or public after discussion and make extending Trinidad renderers accepted, aka not tabu Christi, could you please share more of your needs and give further legitimate reasons why this is needed? 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. Thank you, Andrew On Wed, Apr 9, 2008 at 6:23 PM, Cristi Toth [EMAIL PROTECTED] wrote: Hi guys, A lot of Trinidad renderers have some override useful methods as private or protected final. This makes customizing renderers a nasty job. - first these methods obviously can't be overriden - then when trying to override some public/protected methods, it's hard because they use other private methods that you can't use in your overriden method I assume this come from the fact that Trinidad wasn't open-source in its origins... or? Do we still have reasons to keep it this way? IMO we could make those protected final override useful methods to protected and the private methods used in those methods, make them protected final. What's you opinion on this? Regards, -- Cristi Toth - Codebeat www.codebeat.ro
Re: [Trinidad] private / protected final methods in renderers
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 they need correctly bu are not necessarily as good as they should be (including some of mine) 2) somehow move some of the burden of parts of renderers out of trinidad-impl and into trinidad-api I would be +1 to move resolveProperty and findTypeConstants to CoreRenderer; I would be +1 to move XhtmlRenderer to trinidad-api IF we were to clean it up first, it's the base renderer and there's some strangeness with it like some static methods that shouldn't really be static, has some redundant methods and/or parameters. There's also TypedRenderer interface that doesn't seem to be used anymore which is in the api that XhtmlRenderer implements. I don't think much more should be moved to api. Maybe we could create a enums or constant classes for XhtmlElement and XhtmlAttribute based on W3C, that would help save typos for renderer writer. Other than that, I don't see anything that semantically fit to be in api. When you want to redo a room decoration to make it more functional, it's often useful to start by cleaning it up. 3) introduce some configurable way to override default behavior for rendering certain areas of components. I don't think anyone would be against that as long as we don't have to ensure backward compatibility, but a simple, serious redesign of every component would probably do better than hooks. I kind of liked the reduced multiple renderers idea. It would complexify the delegation structure, but would also improve modularity and readability imho. 4) removing some final modifiers after discussion and make extending Trinidad renderers accepted, aka not tabu Not taboo, but I think we should maintain the API may change without warning from a version to another notification in the doc. Again, rethinking (or simply thinking) the current renderer class structure and the method contract would probably do better than just ditching the final modifier. I think we need to create some rules and always follow them. One example is the main issue I get on when working with renderer extension, which is the parent renderer failing to call a non-final protected getter method to get an attribute value, either calling it directly from the bean and the property key, resulting in a NullPointerException if my component doesn't support that attribute or calling a protected method that I cannot override, under which case I do ditch the final modifier. 5) promoting private members to protected or public after discussion and make extending Trinidad renderers accepted, aka not tabu. Idem as 4. Regards, ~ Simon On Fri, Apr 11, 2008 at 3:04 PM, Andrew Robinson [EMAIL PROTECTED] 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) remove the restriction of trinidad-impl being non-API and enforce that code in this package be backward-compatible 2) somehow move some of the burden of parts of renderers out of trinidad-impl and into trinidad-api 3) introduce some configurable way to override default behavior for rendering certain areas of components. 4) removing some final modifiers after discussion and make extending Trinidad renderers accepted, aka not tabu 5) promoting private members to protected or public after discussion and make extending Trinidad renderers accepted, aka not tabu Christi, could you please share more of your needs and give further legitimate reasons why this is needed? 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. Thank you, Andrew On Wed, Apr 9, 2008 at 6:23 PM, Cristi Toth [EMAIL PROTECTED] wrote: Hi guys, A lot of Trinidad renderers have some override useful methods as private or protected final. This makes customizing renderers a nasty job. - first these methods obviously can't be overriden - then when trying to override some public/protected methods, it's hard because they use other private methods that you can't use in your overriden method I assume this come from the fact that Trinidad wasn't open-source in its origins... or? Do we still have reasons to keep it this way? IMO we could make those protected final override useful methods to protected and the private methods used in those methods, make them protected final. What's you opinion on this? Regards, -- Cristi Toth - Codebeat www.codebeat.ro
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 fit for my requirement. I just downloaded trinidad examples war file and apache trinidad, and run it from tomcat. The application, is very big got clubbed with many examples. I'm struggling to segregate, a piece from such a large code, and test it in web sphere. Can you guy suggest me the approach, to segregate a specific sample from trinidad examples. What I need are as follows. A)Trinidad PanalRadio.jspx.. B)Trinidad Table selction. Your help in both of the issues is appreciated. Thanks Krishna.
[jira] Created: (MYFACES-1858) Resource bundle values are not evaluated properly in java code
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
Affects Versions: 1.2.2
Reporter: Guy Bashan
It seems like there is a general problem in resource bundle evaluation in java
code.
It seems like when ever loaded page is being reloaded (post back) the resource
bundle in java code is not evaluated.
I use two methods:
1)
public static FacesContext getFacesContext()
{
return FacesContext.getCurrentInstance();
}
private static Application getApplication()
{
ApplicationFactory appFactory = (ApplicationFactory) FactoryFinder.
getFactory(FactoryFinder.APPLICATION_FACTORY);
return appFactory.getApplication();
}
private static ValueBinding getValueBinding(String el)
{
return getApplication().createValueBinding(el);
}
public static Object getElValue(String el)
{
return getValueBinding(el).getValue(getFacesContext());
}
then I do: getElValue(#{bundle['some.resource.value']});
In this case, for example, when I want to fill dropdown with multi-laguage
values and convert them to the proper data from the bundle I get this exception
(Note: when comming to the page, it loads ok, it happens only on the postback
call):
javax.faces.FacesException: Exception while validating component with path :
{Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId:
/cmp_new.jsp][Class: javax.faces.component.html.HtmlForm,Id:
frmNewCampaign][Class: javax.faces.component.html.HtmlInputText,Id: po]}
at javax.faces.component.UIInput.validate(UIInput.java:346)
at javax.faces.component.UIInput.processValidators(UIInput.java:144)
at javax.faces.component.UIForm.processValidators(UIForm.java:74)
at
javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:658)
at javax.faces.component.UIViewRoot.access$101(UIViewRoot.java:43)
at javax.faces.component.UIViewRoot$2.process(UIViewRoot.java:97)
at javax.faces.component.UIViewRoot.process(UIViewRoot.java:205)
at
javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:93)
at
org.apache.myfaces.lifecycle.ProcessValidationsExecutor.execute(ProcessValidationsExecutor.java:32)
at
org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103)
at
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:148)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
com.todacell.ui.view.filter.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:149)
at
com.todacell.ui.view.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:61)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:147)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.NullPointerException
at
com.todacell.ui.view.util.ViewUtil.collectionToSelectItemList(ViewUtil.java:89)
at
com.todacell.ui.view.util.ViewUtil.collectionToSelectItemList(ViewUtil.java:98)
at
com.todacell.ui.view.bean.campaign.CampaignNewBean.init(CampaignNewBean.java:43)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
Re: [Trinidad] private / protected final methods in renderers
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 movement. Just thought an apology was deserved. Thank you Simon for your constructive feedback. -Andrew On Wed, Apr 9, 2008 at 6:23 PM, Cristi Toth [EMAIL PROTECTED] wrote: Hi guys, A lot of Trinidad renderers have some override useful methods as private or protected final. This makes customizing renderers a nasty job. - first these methods obviously can't be overriden - then when trying to override some public/protected methods, it's hard because they use other private methods that you can't use in your overriden method I assume this come from the fact that Trinidad wasn't open-source in its origins... or? Do we still have reasons to keep it this way? IMO we could make those protected final override useful methods to protected and the private methods used in those methods, make them protected final. What's you opinion on this? Regards, -- Cristi Toth - Codebeat www.codebeat.ro
Re: [Trinidad] private / protected final methods in renderers
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) remove the restriction of trinidad-impl being non-API and enforce that code in this package be backward-compatible I think the current code it to immature to allow this 2) somehow move some of the burden of parts of renderers out of trinidad-impl and into trinidad-api +1, We should look at this on a library by library basis and scrutinize the code 3) introduce some configurable way to override default behavior for rendering certain areas of components. +1 +1, that's been my point all along 4) removing some final modifiers after discussion and make extending Trinidad renderers accepted, aka not tabu -0 for the reasons I stated. Trinidad is OpenSource, we've already given people enough rope to hang themselves with, no need to tie the noose for them as well. I would support this on an as-needed basis if that's what you mean by after discussion but these should be exceptions and SHOULD be hard to pass though in order to get people to think before they extend Impl classes. Not even in Regular Faces are the renderer's public which is why I think this discussion largely academic. 5) promoting private members to protected or public after discussion and make extending Trinidad renderers accepted, aka not tabu See comment to number 4 Christi, could you please share more of your needs and give further legitimate reasons why this is needed? Yeah, I mean we have in the past made things protected and non-final when it was needed for extensions, but it's always been by people who are not afraid to make commits. I would certainly be open to loosening API's for specific usecases, I was meerly against changing them carte-blanche. The *right* answer IMO though is #2 and #3. Scott 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. Thank you, Andrew On Wed, Apr 9, 2008 at 6:23 PM, Cristi Toth [EMAIL PROTECTED] wrote: Hi guys, A lot of Trinidad renderers have some override useful methods as private or protected final. This makes customizing renderers a nasty job. - first these methods obviously can't be overriden - then when trying to override some public/protected methods, it's hard because they use other private methods that you can't use in your overriden method I assume this come from the fact that Trinidad wasn't open-source in its origins... or? Do we still have reasons to keep it this way? IMO we could make those protected final override useful methods to protected and the private methods used in those methods, make them protected final. What's you opinion on this? Regards, -- Cristi Toth - Codebeat www.codebeat.ro
New to Trinidad Please help
-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 fit for my requirement. I just downloaded trinidad examples war file and apache trinidad, and run it from tomcat. The application, is very big got clubbed with many examples. I'm struggling to segregate, a piece from such a large code, and test it in web sphere. Can you guy suggest me the approach, to segregate a specific sample from trinidad examples. What I need are as follows. A)Trinidad PanalRadio.jspx.. B)Trinidad Table selction. Your help in both of the issues is appreciated. Thanks Krishna.
Re: New to Trinidad Please help
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- 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 fit for my requirement. I just downloaded trinidad examples war file and apache trinidad, and run it from tomcat. The application, is very big got clubbed with many examples. I'm struggling to segregate, a piece from such a large code, and test it in web sphere. Can you guy suggest me the approach, to segregate a specific sample from trinidad examples. What I need are as follows. A)Trinidad PanalRadio.jspx.. B)Trinidad Table selction. Your help in both of the issues is appreciated. Thanks Krishna.
Re: [Trinidad] private / protected final methods in renderers
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 unexpected way. I'm fine with making it easier to subclass renderers for those that want to take the risk, but I'm -1 on any scheme that restricts our ability to make changes when the need arises. Other comments inline: 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) remove the restriction of trinidad-impl being non-API and enforce that code in this package be backward-compatible -1, the renderers have to be able to change without worrying about backwards compatibility. 2) somehow move some of the burden of parts of renderers out of trinidad-impl and into trinidad-api Maybe I've misunderstood, but this sounds like it's basically the same as 1 but for pieces of a renderer, -1. 3) introduce some configurable way to override default behavior for rendering certain areas of components. That would be fine, as long as there's not a perf issue, and there's an understanding that things may break at the next release - hopefully rare, but possible. 4) removing some final modifiers after discussion and make extending Trinidad renderers accepted, aka not tabu I think removing final modifiers AFTER discussion is fine, and I think if people want to risk extending renderers then fine, but we make no promises they will not break at the next release. Same for 5 below. Thanks, Gab 5) promoting private members to protected or public after discussion and make extending Trinidad renderers accepted, aka not tabu Christi, could you please share more of your needs and give further legitimate reasons why this is needed? 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. Thank you, Andrew On Wed, Apr 9, 2008 at 6:23 PM, Cristi Toth [EMAIL PROTECTED] wrote: Hi guys, A lot of Trinidad renderers have some override useful methods as private or protected final. This makes customizing renderers a nasty job. - first these methods obviously can't be overriden - then when trying to override some public/protected methods, it's hard because they use other private methods that you can't use in your overriden method I assume this come from the fact that Trinidad wasn't open-source in its origins... or? Do we still have reasons to keep it this way? IMO we could make those protected final override useful methods to protected and the private methods used in those methods, make them protected final. What's you opinion on this? Regards, -- Cristi Toth - Codebeat www.codebeat.ro
[jira] Updated: (TRINIDAD-1037) Trinidad tree/treeTable expand all handling
[ 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) 1.2.8-core Status: Resolved (was: Patch Available) Committed changes, thanks Kamran. I wouldn't mind revisiting this whole infrastructure to even make it more efficient or, perhaps, more modular. But this is an improvement over what is there. Trinidad tree/treeTable expand all handling --- Key: TRINIDAD-1037 URL: https://issues.apache.org/jira/browse/TRINIDAD-1037 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 1.2.7-core Environment: All Reporter: Kamran Kashanian Assignee: Scott O'Bryan Fix For: 1.2.8-core Attachments: trunk_1.2.x.patch Original Estimate: 1h Remaining Estimate: 1h The Trinidad tree/treeTable components include logic to protect against an unbounded expand all action. The expand all action can be expensive for large trees. The method org.apache.myfaces.trinidad.component.HierarchyUtils.__handleBroadcast() checks for a RowDisclosure event, and tries to determine the # of expanded nodes by looping over the newly expanded row keys. However, looping over the RowKeySet, which is bound to the tree model, can be expensive. Instead, the method should call getSize() on the expanded row key set, and loop only if an unknown size (size = -1) is returned. Providing a patch for this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1859) Optimize javascript following good practices
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 Uribe Optimize some parts of oam using practices described in: http://www.devwebpro.com/devwebpro-39-20030514OptimizingJavaScriptforExecutionSpeed.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1049) XmlHttpConfigurator is implemented incorrectly
XmlHttpConfigurator is implemented incorrectly -- Key: TRINIDAD-1049 URL: https://issues.apache.org/jira/browse/TRINIDAD-1049 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.7-core Reporter: Scott O'Bryan Assignee: Scott O'Bryan Although it functions, the code in XmlHttpConfigurator is implemented correctly. To fix this issue, we must put the code currently in beginRequest into the getExternalContext method. Then remove the explicit reference from the Trinidad phase listener. This will make everything work as part of the configurator system. Also, this need to be added to the META-INF/services. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1842) commandLink with parameters behaves differently in Firefox and IE
[ 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 solve it, I come to the conclusion of this bug should be resolved on firefox, and no workaround on oamSubmitForm could work. Any suggestions are welcome. commandLink with parameters behaves differently in Firefox and IE - Key: MYFACES-1842 URL: https://issues.apache.org/jira/browse/MYFACES-1842 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.0 Environment: Windows XP, MyFaces 1.2.0, Jetty, Firefox 2.0.0.12, IE 7.0.570.11 Reporter: Neil Curzon Assignee: Leonardo Uribe When I have a commandLink element with a parameter, and double click on the link, I get different behavior in IE and Firefox. IE submits the expected query string on the first click, but on the second click generates a query string with the parameter listed twice, both times with the correct value, in its name value pairs. Firefox submits the expected query string on both clicks. The culprit may be the oamSubmitForm javascript. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1691) beforeUnload event handler breaks form submission
[
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 and it's a specific bug for IE.
So, the solution for avoid this is as suggested, surround submit call with a
try catch.
beforeUnload event handler breaks form submission
-
Key: MYFACES-1691
URL: https://issues.apache.org/jira/browse/MYFACES-1691
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 1.1.5, 1.2.0, 1.2.2
Environment: Windows XP, IE7
Reporter: John Singleton
Assignee: Leonardo Uribe
I am using the onBeforeUnload event to prevent the user leaving the page
without first saving their work.
If the user cancels the page navigation, further navigation in the page
fails. I tracked this down to this call in oamSubmitForm
document.forms[formName].submit();
In IE when the user cancels navigation of the page the form.submit method
throws an exception. This isn't caught in oamSubmitForm and so it doesn't
complete cleanly.
I fixed this by changing the 2 calls to form.submit too:
try { document.forms[formName].submit(); } catch (e) {}
oamSubmitForm now completes cleanly and further navigation in the page
succeeds.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1726) IE7 - AutoComplete Does Not Work When You Use Script to Submit a Form
[ 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: http://support.microsoft.com/kb/329156/en-us there is a workaround. Should we apply this (we need to define or copy from trinidad a function to detect browser)?. IE7 - AutoComplete Does Not Work When You Use Script to Submit a Form - Key: MYFACES-1726 URL: https://issues.apache.org/jira/browse/MYFACES-1726 Project: MyFaces Core Issue Type: Improvement Environment: Internet Explorer 7 Reporter: Mario Ivankovits Assignee: Leonardo Uribe AutoComplete Does Not Work When You Use Script to Submit a Form see http://support.microsoft.com/kb/329156/en-us Simon said in IE6 this is true as well, at least time by time -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [All MyFaces] Local properties vs. ValueExpression/Binding
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 issue however: setting some property in the component tree is not
currently _meant_ to update the backing beans. So this will also need
to be considered in the context of the lifecycle (when and how to do
it - validation?). Generally, models are only updated from an
EditableValueHolder component, and there it is only the value
attribute which changes stuff in the model.
regards,
Martin
On Wed, Apr 9, 2008 at 4:14 AM, Martin Marinschek
[EMAIL PROTECTED] wrote:
I would slightly lean to this solution:
Solution two:
Check if EL is set and ValueExpression.isReadOnly(ELContext context)
returns false
set EL
else set local
and fix the el-implementation if it doesn't do what it is expected to do.
Second problem (resetting) is nothing we can do generally; we'd have
to do it case-by-case.
regards,
Martin
On Mon, Mar 24, 2008 at 7:04 PM, Andrew Robinson
[EMAIL PROTECTED] wrote:
The bug https://issues.apache.org/jira/browse/TOMAHAWK-858 has made me
want to bring this up for discussion of the entire team. I really
don't like the solution they are posing as it will cause backward
compatibility problems and is not a full solution. This problem is not
unique to the Tomahawk tabbed pane, so I would love to see a MyFaces
wide (and maybe a JSF 2.0) fix (or approach) to the problem.
The issue is that several components use a setXxx(...) method to
update components. This typically is done in renderer code. Here is a
short list of components that I know are affected:
Tomahawk data scroller / data table and the first attribute
Tomahawk tabbed pane
Trinidad UIXShowDetail (I checked in a one component fix for this one,
but I am not 100% happy with it)
I am sure there are more. The problem is that if I have this code (I
am picking on the data table it is the easiest example):
t:dataTable first=#{bean.firstRowIndex}...
t:dataScroller ...
...
The data scroller has the code UIData.setFirst(...) when the event is
broadcast.
Typically all MyFaces getter code is written as:
if there is a local value
return it
if not, get the value binding / value expression
if set, evaluate it
if the value is null or there was no EL, then return a default value
if available, or else null
The setter code is:
set the local value
Even with Trinidad using a FacesBean, it still suffers from the local
vs. EL problem. What ends up being the major issue is that the local
value always takes precedence over the EL value. This is very rarely
the desired behavior. The local value is only really useful when
component binding is being used and the page author is not using EL to
set attributes.
The solution is more complex. In issue TOMAHAWK-858, someone has
proposed to use EL if it is set, but they did not examine the problem
domain. For example:
t:dataTable first=#{bean.condition ? 0 : bean.firstRowIndex} ...
In this crude example, perhaps the hard-coded 0 is to reset the table
to the first record on another link (please do not over analyze the
example, I know it is far from perfect). The problem with this is that
in using a conditional EL expression, this is no longer set-able! So
if the data scroller code attempts to assign 20 (the next page lets
say) to the first EL, it will throw an exception, because a
conditional statement cannot be set.
One solution to this is:
if EL is set,
try to set the EL
if that throws an exception, set the local value
This would technically work, but I hate the code. It is unpredictable
and bad for performance (exceptions are expensive and should be
avoided).
Solution two:
Check if EL is set and ValueExpression.isReadOnly(ELContext context)
returns false
set EL
else set local
Problem is that I do not think that this is always accurate.
The other problem is that once the local value is set, it cannot
always be cleared:
private Integer _first;
public int getFirst() {
if (_first != null) return _first.intValue();
ValueBinding ...
}
public int setFirst(int first) { _first = new Integer(first); }
Here, there is no way to set _first back to null. We could change the
APIs drastically of Tomahawk and Trinidad so that the generation
plugin always has to use objects and not primitives, but that would
break a lot of code and is not a nice API when null
