Re: Public API's not part of JSF
Hi * The shared-impl is not really available in source. It's part of the shared. There is also a shared-tomahawk generation. Shared itself will not be released. I wrote a small wiki page on [1] about shared. @Martin: 434 ? if so, we (Sean, Wendy and me) just spoke to some portlet guys at the hackaton... that goes against old code etc, maybe they help us on that. btw. discussion about MyFaces's shared stuff should go to [EMAIL PROTECTED], since trinidad is not really depending on it ;) Greetings from sticky Austin. -Matthias [1] http://wiki.apache.org/myfaces/Shared_-_impl_or_tomahawk On 10/10/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Scott, we've had re-occuring discussions about a new commons-module. This would probably be good candidate for this. Additionally, I've still got to review a commit for a module by Shinsuke Sugaya, which is about portlet compatibility - maybe it would be good to put it there. regards, Martin On 10/11/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Is there a place where we could store public API's that are not part of Faces in MyFaces? Would this be the shared-impl package? We'll likely need to support an interface to handle some of our filter functionality from a portlet. This interface would need be referenced by the MyFaces Bridge Portlet (in impl) and Trinidad Impl... Scott -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
who is in charge for JSR 301?
hello who is in charge for JSR 301 here? -- Arash Rajaeeyan
Re: ADFFACES-191 - help
I fixed this issue with following:
(1) CoreRenderKit.returnFromDialog will render only close():
out.write(script);
out.write(top.close());
out.write(/script);
(2) FredJSP.service will render call of callback in onunload:
String callback = 'ADFDialogReturn[ + returnId + ]();';
frameSet.setOnunload(_checkUnload(event); window.opener.setTimeout( +
callback + ,0));
This works for me, but I'm not trinidad dialog expert. Can you review
this solution?
Btw. what does Fred mean? (FredJSP.java)
Thanks
Martin
Martin Koci píše v St 11. 10. 2006 v 13:03 +0200:
Hello,
I'm trying to fix this issue but I don't understand how is parent window
refreshed after return from dialog. Which js function is responsible ?
I found:
if (closeCallback)
{
_setDependent(parentWindow, windowName, closeCallback);
}
in Window.js.
Can you give me some ideas how and where (in code) fix this issue? It is
critical, because our customers really like alt F4.
Thanks for any info,
Martin
Re: Re: ADFFACES-191 - help
On 10/11/06, Martin Koci [EMAIL PROTECTED] wrote: I fixed this issue with following: (1) CoreRenderKit.returnFromDialog will render only close(): out.write(script); out.write(top.close()); out.write(/script); (2) FredJSP.service will render call of callback in onunload: String callback = 'ADFDialogReturn[ + returnId + ]();'; frameSet.setOnunload(_checkUnload(event); window.opener.setTimeout( + callback + ,0)); This works for me, but I'm not trinidad dialog expert. Can you review this solution? Two concerns: First would be verifying that this works across a decent set of browsers - say, Firefox, IE 6, and Safari - because this makes me apprehensive that the window will close before a submission kicked off during onunload. Second would be making sure that you're not breakign any non-dialog cases; FredJSP.java is used by inputColor and inputDate for their popups, and neither of those involve a return method. -- Adam Btw. what does Fred mean? (FredJSP.java) Fred stands for Frame REDirect... a long story, but we used to have a JSP called frameRedirect.jsp; then a new version, which I wanted to have a short name, so fred.jsp; then we got the code out of the JSPs and into Java, so FredJSP.java; then we moved this to the InternalView API but didn't change the name. ;) -- Adam
Re: Public API's not part of JSF
Yeah, I think I saw that. Now that myFaces is starting to get a number of very elaborate sub-projects, there is no real reason that we should have to keep re-inventing the wheel. Yet I can certainly respect wanting to keep the API package strictly JSF. Martin Marinschek wrote: Hi Scott, we've had re-occuring discussions about a new commons-module. This would probably be good candidate for this. Additionally, I've still got to review a commit for a module by Shinsuke Sugaya, which is about portlet compatibility - maybe it would be good to put it there. regards, Martin On 10/11/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Is there a place where we could store public API's that are not part of Faces in MyFaces? Would this be the shared-impl package? We'll likely need to support an interface to handle some of our filter functionality from a portlet. This interface would need be referenced by the MyFaces Bridge Portlet (in impl) and Trinidad Impl... Scott
Re: who is in charge for JSR 301?
I don't think we really have one yet. I can jump on that if you guys want. Michael Freedman is the Spec Lead and he is someone I work with on a regular basis. Scott Arash Rajaeeyan wrote: hello who is in charge for JSR 301 here? -- Arash Rajaeeyan
Re: [Jira] Portlet Issue
Correct. I mean it's crappy that we have to go through like 20 layers of wrappers to make this thing work right. I imagine, though, that it's going to be that way until the next Portlet Spec. Same way with Ajax. The new Portlet spec is going to have a request type specifically for Ajax. Arash Rajaeeyan wrote: Hi yes it makes sense. you know the problem is Protlet is more limited than servlet so some Portlet Classes (say PortletRequest) have less methods and properties than their counter part (say HttpServlet) so the wrapper which implements Servlet class and has wrapped a portlet related class inside should return null or throw exception in some special cases. so these wrappers behaviour is not completely same as their http servlet counter parts. I don't know if this functionality are used any where in trinidad or not. as long as I find out in the codes there is no dependency on HttpServlet classes and in most places the JSF classes are used in trinidad. for example in most places FacesContext is used and not ServletContext so there is no problem in returning PortletContext in getFacesContext
Re: Re: MyFaces 1.2 component autogeneration (was: Trinidad JSF 1.2 status update)
Alexandr, What's wrong with faces-config.xml metadata? From our perspective, this has been a very successful source of the information needed to derive things as diverse as Javadoc, code, and TLDs (and, faces-config.xml itself). The XML is bad, annotations are great line you here a lot these days is wy overblown. XML has its strengths, annotations has its strengths. -- Adam On 10/11/06, Alexandr Smirnov [EMAIL PROTECTED] wrote: Component code generation can greatly improve components creation, since in Ajax4jsf project I also have own generator with same ideas. In addition to same files as in ADF/Trinidad , we have generator for renderer's from jsp-like template ( even with same tags as Jsp/jstl, which allow to use JSP visual editor for renderer's ). For complex components , it allow avoid most of html errors and can divide work between html designer and java coders. As a next stage, I want to reduce files need for component creation to two - base abstract component class, and renderer template. For component meta information, I have plan to use Java annotations ( in current implementation, I use Java reflection to analise component and implemented interfaces methods, bean properties etc. ). As I thing, such annotations must be standardize, not proprietary API. Is Myfaces/Trinidad team will interested to use annotations for component generator meta information ? I need help to create public api for such feature. Also, we can contribute parts of existing generator to MyFaces project, at least renderer generator part - I don't see such feature in other tools. Adam Winer : Yes, they definitely could be used in that way. The basic picture is that you write up a bunch of little mini faces-config.xml files, one for each component (don't have to, actually, you could generate straight from one big faces-config), and from that we autogenerate: - Java component classes - JSP tag classes - TLD file - Tag documentation - Facelets definition file - Overall merged faces-config.xml -- Adam On 10/8/06, Bruno Aranda [EMAIL PROTECTED] wrote: That sounds really interesting. As you may know, we are working quite actively in the implementation of MyFaces 1.2. Now I am migrating the JSF core tags, but we will reach soon the point to migrate the HTML Basic components. I don't know the exact details of how this autogeneration works for Trinidad, but couldn't we have the same or similar method to generate the JSF basic html components for MyFaces? Sorry for cross-posting but I think this can be interesting, Cheers, Bruno
Re: Trinidad on JDK 1.4
-1 to having to worry about what retroweaver does and does not support, and I certainly don't want to have to check in to two branches regularly. Thanks, Gabrielle Bruno Bernard wrote: Scott, Maybe Trinidad does not work completly with Portlets but it seems to have some support. It seems to work with me. I noticed 3 things so far: 1) org.apache.myfaces.trinidad.webapp.TrinidadFilter is not being called so the user agent is set to null. This cause an exception and I did a workaround to see how the rest was working. 2) Partial trigger does not work 3) the custom skins does not seems to be loaded (maybe related to 1) As of 1.4. I modified less than 10 lines of code and used retroweaver. It worked. To keep this working we would need to just make sure that we do not use 1.5 specific code that retroweaver does not support. Would you guys consider a branch that supports this + JSF 1.1. Maybe I am not the only one interested by this. Again myself and my company would consider to contribute. Bruno Scott O'Bryan wrote: Bruno, Actually, Trinidad does not yet work with portlets. :) That being said, most of the code base was ported over from ADFFaces which was originally written from 10.1.3. If 1.4 is a hard requirement, you might want to look at ADFFaces again. I believe the 10.1.3.1 release has enhancements to work with the portal system. Hopefully we'll get Trinidad up to speed very soon. -1 to reverting the renderkit to work with 1.4. It seems to me it's taking a step backward, especially as we (or Adam rather) ramp up to supporting JSF 1.2. Scott O'Bryan Bruno Bernard wrote: I am currently working for a company that had been using Oracle ADF for a while and we are currently planning to move to portlets. Since oracle ADF does not support portlets out of the box, we decided to look more closely into Trinidad which works with Portlets. One of our requirement is to use Java 1.4. After looking at this page (http://wiki.apache.org/myfaces/ADF_Faces/ToDo) I tried to see how much it was to run Trinidad on Java 1.4. It was easy and we've made it work. We are currently thinking to go for this solution and contribute to your project if you want.
Re: Trinidad on JDK 1.4
-1 - ditto to Gabrielle's comment. Gabrielle Crawford wrote: -1 to having to worry about what retroweaver does and does not support, and I certainly don't want to have to check in to two branches regularly. Thanks, Gabrielle Bruno Bernard wrote: Scott, Maybe Trinidad does not work completly with Portlets but it seems to have some support. It seems to work with me. I noticed 3 things so far: 1) org.apache.myfaces.trinidad.webapp.TrinidadFilter is not being called so the user agent is set to null. This cause an exception and I did a workaround to see how the rest was working. 2) Partial trigger does not work 3) the custom skins does not seems to be loaded (maybe related to 1) As of 1.4. I modified less than 10 lines of code and used retroweaver. It worked. To keep this working we would need to just make sure that we do not use 1.5 specific code that retroweaver does not support. Would you guys consider a branch that supports this + JSF 1.1. Maybe I am not the only one interested by this. Again myself and my company would consider to contribute. Bruno Scott O'Bryan wrote: Bruno, Actually, Trinidad does not yet work with portlets. :) That being said, most of the code base was ported over from ADFFaces which was originally written from 10.1.3. If 1.4 is a hard requirement, you might want to look at ADFFaces again. I believe the 10.1.3.1 release has enhancements to work with the portal system. Hopefully we'll get Trinidad up to speed very soon. -1 to reverting the renderkit to work with 1.4. It seems to me it's taking a step backward, especially as we (or Adam rather) ramp up to supporting JSF 1.2. Scott O'Bryan Bruno Bernard wrote: I am currently working for a company that had been using Oracle ADF for a while and we are currently planning to move to portlets. Since oracle ADF does not support portlets out of the box, we decided to look more closely into Trinidad which works with Portlets. One of our requirement is to use Java 1.4. After looking at this page (http://wiki.apache.org/myfaces/ADF_Faces/ToDo) I tried to see how much it was to run Trinidad on Java 1.4. It was easy and we've made it work. We are currently thinking to go for this solution and contribute to your project if you want.
Re: Trinidad on JDK 1.4
Scott, Thanks for the reply and the details, this is precious information since I will need to make it work. We will not be using panelTabbed and inputFile As for the portal bridge, i am using my face. This is working for me (except that i get an exception in isIE maybe related to the bug that you are fixing). This is what i have Trinidad+jsf_facelet 1.1.6+myfaces 1.1.3+liferay 1.4.2 (with a fix i had to do) Bruno Scott O'Bryan wrote: Bruno, We also have the following other issues: tr:inputFile will not work No PPR will work panelTabbed will not work if PPR doesn't work Image references will not work correctly etc. etc. etc. The list goes on an on. The problems you are discovering now are the same problems would would have trying to run ADFFaces before the portal enhancements were added. I don't doubt that Trinidad may run in a portal in a very limited (and inconsistant) capacity, but that does not constitute Portal support. Also, Trinidad will not work with the MyFaces bridge portlet at the moment until I check in a fix. Do you mind me asking what bridge portlet you are using? Scott Bruno Bernard wrote: Scott, Maybe Trinidad does not work completly with Portlets but it seems to have some support. It seems to work with me. I noticed 3 things so far: 1) org.apache.myfaces.trinidad.webapp.TrinidadFilter is not being called so the user agent is set to null. This cause an exception and I did a workaround to see how the rest was working. 2) Partial trigger does not work 3) the custom skins does not seems to be loaded (maybe related to 1) As of 1.4. I modified less than 10 lines of code and used retroweaver. It worked. To keep this working we would need to just make sure that we do not use 1.5 specific code that retroweaver does not support. Would you guys consider a branch that supports this + JSF 1.1. Maybe I am not the only one interested by this. Again myself and my company would consider to contribute. Bruno Scott O'Bryan wrote: Bruno, Actually, Trinidad does not yet work with portlets. :) That being said, most of the code base was ported over from ADFFaces which was originally written from 10.1.3. If 1.4 is a hard requirement, you might want to look at ADFFaces again. I believe the 10.1.3.1 release has enhancements to work with the portal system. Hopefully we'll get Trinidad up to speed very soon. -1 to reverting the renderkit to work with 1.4. It seems to me it's taking a step backward, especially as we (or Adam rather) ramp up to supporting JSF 1.2. Scott O'Bryan Bruno Bernard wrote: I am currently working for a company that had been using Oracle ADF for a while and we are currently planning to move to portlets. Since oracle ADF does not support portlets out of the box, we decided to look more closely into Trinidad which works with Portlets. One of our requirement is to use Java 1.4. After looking at this page (http://wiki.apache.org/myfaces/ADF_Faces/ToDo) I tried to see how much it was to run Trinidad on Java 1.4. It was easy and we've made it work. We are currently thinking to go for this solution and contribute to your project if you want.
Re: who is in charge for JSR 301?
I really really guess that the portlet guys at apache (Carsten for instance), will hook in. I bet they will, b/c -Portlet RI is Apache (Pluto) -JSF/Portlet Bridges are Apache (subproject of portals.apache.org) On 10/11/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: I see name of Apache foundation there so there should be some one from Apache! if it is not ADF, is there any one from Myfaces ? I have requested to become a member, but I am not sure if they accept me! On 10/11/06, Scott O'Bryan [EMAIL PROTECTED] wrote: I don't think we really have one yet. I can jump on that if you guys want. Michael Freedman is the Spec Lead and he is someone I work with on a regular basis. Scott Arash Rajaeeyan wrote: hello who is in charge for JSR 301 here? -- Arash Rajaeeyan -- Arash Rajaeeyan -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: who is in charge for JSR 301?
added Carsten On 10/11/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I really really guess that the portlet guys at apache (Carsten for instance), will hook in. I bet they will, b/c -Portlet RI is Apache (Pluto) -JSF/Portlet Bridges are Apache (subproject of portals.apache.org) On 10/11/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: I see name of Apache foundation there so there should be some one from Apache! if it is not ADF, is there any one from Myfaces ? I have requested to become a member, but I am not sure if they accept me! On 10/11/06, Scott O'Bryan [EMAIL PROTECTED] wrote: I don't think we really have one yet. I can jump on that if you guys want. Michael Freedman is the Spec Lead and he is someone I work with on a regular basis. Scott Arash Rajaeeyan wrote: hello who is in charge for JSR 301 here? -- Arash Rajaeeyan -- Arash Rajaeeyan -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
