Re: [process...] Trinidad moving to MyFaces
Totally agree with that... We have a lot of traffic on these lists and it would be easy for messages to get lost without the subject marker... Adam Winer wrote: I'm also reluctant to spin us off into a separate e-mail list. I do think we'll want a [Trinidad] convention for posts though. -- Adam On 4/27/07, Mike Kienenberger [EMAIL PROTECTED] wrote: I think Myfaces subprojects should be using the existing user and dev lists. Otherwise, you're getting into the situation where that Martin van den Bemt warned about where you're off in your own little world without visibility to the entire MyFaces community. On 4/27/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, one more thing I'd like to get your feedback. Regarding the mailing list, what should we do? Using users@ and dev@ myfaces , or creating new lists, like [EMAIL PROTECTED] For the Jira, only a rename is needed. ADFFACES = TRINIDAD Any comments, objections `? -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Trinidad + portletJSR168
Khaled, Much work has been done on Trinidad in a portal environment but we are not there yet. Trinidad is a very complex renderkit with a lot of functionality and the existing bridges are deficient to varying degrees. Currently Trinidad will run in a Proof of Concept using the Oracle Bridge but I suspect that Trinidad will not be fully compatible with an OpenSource bridge until the completion of JSR-301. Scott Khaled TLILI wrote: Hi, I am developping a portletJSR168 and I want to use the treeTable component. Is Trinidad compliant with portletJSR168? if yes, is there an example of portlet using trinidad? Wich jsf bridge to use (org.apache.portals.bridges.jsf.FacesPortlet or org.apache.myfaces.portlet.MyFacesGenericPortlet)? Thanks for your answers. KT,
Re: [Fwd: Re: return an Iterator vs a List]
I agree with Blake. We'll get ourselves into trouble is we begin
switching objects around, because if people need the other access
methods they'll do a cast and we'll break them.
Furthermore, if we use the generic Collections (like List, Set, etc.)
then it is more clear as to what constraints are on returned data. A
set, for instance, cannot have duplicate items, etc. etc. These are
things that we best not violate, contractually, within the API.
Scott
Blake Sullivan wrote:
Adam Winer wrote:
I don't think there's that much reason not to return
a List. All I'm saying is that if you had an API
that was Iterator, and your desire was to support
the fun SE 5 for construct, then Iterable is the
simplest change. The question then is why the
original API was ever Iterator, and if it should
have been List, or Collection, etc.
In looking at the code, it doesn't appear to have been much rhyme or
reason to when we returned Iterators or even arrays. For the methods
that currently return Iterators, my point is that the big step is
agreeing to return Iterables instead (switching from Iterators to a
factory for Iterators). Once you decide to return Iterables for
immutable objects, then you might as well return the correct
Collection classes--Collection, List, Set as returning these classes
places no additional api burden on the implementor as I believe that
even in the worst case where the implementor only had an Iterable and
not the actual Collection class in question, a simple adapter could be
written to convert an Iterable into the appropriate unmodifiable
Collection class.
-- Blake Sullivan
I'm not thrilled with exposing List if you think that
you might someday want it to be a Set - Collection
is safer in that regard.
-- Adam
On 4/9/07, Blake Sullivan [EMAIL PROTECTED] wrote:
Adam,
Actually the reason for the switch to List versus Iterable would be for
general convenience of developers consuming the api (with efficiency a
much smaller issue).
Which methods on java.util.List do you think are providing too broad of
a contract? Do you believe that returning a List is limiting the
implementations choices severely enough that it outweighs the
convenience of using a Collection class?
-- Blake Sullivan
Jeanne Waldman wrote:
three out of six
Original Message
Subject: Re: return an Iterator vs a List
Date: Wed, 4 Apr 2007 15:42:17 -0700
From: Adam Winer [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
References:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
If the only reason is to enable the fun new for syntax,
then we should change the type from Iterator to Iterable,
instead of List. List is a much larger contract.
-- Adam
On 3/28/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
Hi there,
I'm in the Skinning StyleNode code and I see that the 'get' methods
return Iterators
from the good ol' days.
It seems to me that it is better if they just return Lists so the
code
that iterates over
the values is cleaner using 5.0's for(String foo : yyy) construct.
Does anyone see why I wouldn't want these to return List instead of
Iterator?
Here's a code snippet. Thanks, Jeanne
--
public IteratorIncludePropertyNode getIncludedProperties()
{
if(_includedProperties == null)
{
ListIncludePropertyNode list = Collections.emptyList();
return list.iterator();
}
else
return (Arrays.asList(_includedProperties)).iterator();
}
/**
* Gets the properties specified by this node's parent that
should be
* ignored. This method will return an empty iterator if
* [EMAIL PROTECTED] #isInhibitingAll()} returns codetrue/code
*
* @return an iterator over the properties that should be
ignored, an
* empty iterator if all properties should be.
*/
public IteratorString getInhibitedProperties()
{
if(_inhibitedProperties == null)
{
ListString list = Collections.emptyList();
return list.iterator();
}
else
{
return _inhibitedProperties.iterator();
}
}
Re: Latest Trinidad trunk not working
Also Ven, That error, although it should never show up if everything is configured correctly, should not really effect things that badly. It it logged when something like the resource servlet tries to disable the configurators after a FacesContext has already been obtained. All it means is that configurators to handle file-uploads and whatnot will be available on the external context and may cause some performance issues. If after narrowing everything down to one version of Faces you still get this message, then write up a JIRA ticket so we can investigate why. Scott Matthias Wessendorf wrote: Hi Venk, the demo itself runs w/ MyFaces. Your stack is talking about Sun RI snip com.sun.faces.context.ExternalContextImpl. /snip You can't have two JSF impls in one app. The good news is, that JSF 1.2 removes the odd requirement for *adding* a JSF runtime to your projects, since the container ships it ! HTH, Matze On 3/30/07, venkata guddanti [EMAIL PROTECTED] wrote: Hi All, I am have issues running the latest trinidad trunk. In JDEV 10.1.3 I get the following error in console when I try to navigate to a page or click on command components: Mar 29, 2007 4:19:24 PM org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl_isDisabled WARNING: Configurator services were disabled after beginRequest was executed. Cannot disable configurator services If I deploy to tomcat 5.5, I get the following error on all component samples: *exception* javax.servlet.ServletException: org.apache.jasper.JasperException: Base is null: editor javax.faces.webapp.FacesServlet.service(FacesServlet.java:154) org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._invokeDoFilter(TrinidadFilterImpl.java:209) org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:166) org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:139) org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92) org.apache.myfaces.trinidaddemo.webapp.RedirectFilter.doFilter(RedirectFilter.java:97) *root cause* javax.faces.FacesException: org.apache.jasper.JasperException: Base is null: editor com.sun.faces.context.ExternalContextImpl.dispatch(ExternalContextImpl.java:351) org.apache.myfaces.trinidad.context.ExternalContextDecorator.dispatch(ExternalContextDecorator.java:43) org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$OverrideDispatch.dispatch(FacesContextFactoryImpl.java:258) com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:152) org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:181) org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:41) org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:132) javax.faces.webapp.FacesServlet.service(FacesServlet.java:140) org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._invokeDoFilter(TrinidadFilterImpl.java:209) org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:166) org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:139) org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92) org.apache.myfaces.trinidaddemo.webapp.RedirectFilter.doFilter(RedirectFilter.java:97) These changes issues seem to be portal related. Am I missing some configuration?
Re: @author tags
Well the community seems to have spoken. I've just had the benefit of dealing with a niche set of usecases and it helped to be able to track down the original developer of some of the code because they no longer monitor the lists. The snv blame tool (in ASF) pretty much tells you who committed the code, not who knows it. Still, I do see the compelling arguments to the contrary. I still hold though that @author does not equal owner and that a community like Apache just needs to get over that view of the world. That being said, I suppose I don't feel too strongly about it. If nobody knows about the code in general then chances are nobodies using or maintaining the code and it's probably time to develop some new expertise anyway. So I'll move to a +0 non-binding. Scott Matthias Wessendorf wrote: My personal policy is to redirect personal appeals for help to the appropriate user mailing list. I would encourage other developers who receive individual help requests to do the same. +1 doing the same. not getting 20 a day/week like you, but the pattern is a good one -M Craig On 2/26/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: * I have not worked on them for four years (but I still get 20 personal emails for Tomcat help every week). :-) but to be serious, here is something that Ted brought up on the same discussion, which I also started over in MyFaces land snip As to why, Greg Stein sums it up well here: * http://tinyurl.com/mw7t6 This issues has been discussed at length on the board and member lists, and the ASF does prefer that our code be free of author tags, but we leave the final determination to the individual PMCs. /snip
Re: Oracle Skin Release
I don't know why we couldn't have a skin repository on Trinidad personally. If for nothing else but to provide examples to help people skin the product. Scott Simon Lessard wrote: Hmm I don't know. I would have liked to see it hosted as a new Trinidad project, a bit like trinidad-demo so that Trinidad users can find everything they need at one place. If the skin feature ever become independent and used by Tobago and Tomahawk for example, it would make much sense that they host their skin as well rather than forcing users to look on Google for Trinidad skins, Yahoo groups for Tomahawk skins and so on imho. Regards, ~ Simon On 2/20/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: the donation of the Redwood Shores skin ? why not creating a code.google.com project ? java dot net ? a trinidad sandbox ? I don't have a strong feeling on that hosting plattform. -M On 2/20/07, Martin Marinschek [EMAIL PROTECTED] wrote: I guess that should be changed. Matthias, where would you think this donation should go? regards, Martin On 2/19/07, Mark Robinson [EMAIL PROTECTED] wrote: I've had some interest inside of my company for a sort of skin 'repository' for people to donate skins. Although there hasn't been much work in that sort of direction. I had to use adf/ in the jar file since trinidad looks for resources in a jar file by using adf. Mark Martin Marinschek wrote: I'd love to have it somewhere in Trinidad - but where to put it? A section on the website for the download of the jar, and a certain directory in the repository? By the way: you should probably rename the image directory to something not containing oracle/adf/... regards, Martin On 2/8/07, Mark Robinson [EMAIL PROTECTED] wrote: I've updated the skin as we've discussed. It's now available from: http://www.engr.uvic.ca/~mrobinso/RedwoodShores.jar Is there any interest in incorporating this into a central skin repository? Mark Adam Winer wrote: Thanks, I've created ADFFACES-371 to track getting rid of the old images. -- Adam On 2/2/07, Mark Robinson [EMAIL PROTECTED] wrote: Adam, I've got all the images I need packaged up in my JAR file. So you can remove the images from Trinidad. I can change the name fairly easily. I think RedwoodShores might be the best name ;) Mark Adam Winer wrote: Mark, FWIW, we probably should have deleted those images from Trinidad. Not because of licensing or anything - their license is fully transferred to Apache! - but because they're unused inside of Trinidad. I'd like to be able to delete them from Trinidad, and have them packaged with the skin that uses them. So, if there's any way you could incorporate the images you use into your skin's JAR, that would be great. Also, I'd recommend that you choose some new name for the skin, just to avoid any questions of ownership/copyright, etc., down the road. Cheers, Adam On 1/30/07, Mark Robinson [EMAIL PROTECTED] wrote: Hi Matt, I've been working on a skin which looks like the old Oracle skin from ADF. There's been some moderate interest in it on the user mailing list. It is based upon images/CSS from inside Trinidad. What this means is that it's licensed under the Apache license. So it can be freely used inside Trinidad. I've packaged into a separate deployable jar for one reason. 1) It makes distributing/managing it so very easy Drop it into your WEB-INF/lib and change your skin to oracle and off you go. Otherwise, I'm completely infavour of re-integrating it back into mainline Trinidad. Anyways, you can download it at http://www.engr.uvic.ca/~mrobinso/OracleSkin.jar Mark Matthias Wessendorf wrote: what does that mean ? finished up the packing for thje Oracle Skin ? Is it like taking the ADF Faces Skin and bundling it separate? If yes, I am pretty much sure that we cannot have it here in Trinidad, since that code belongs Oracle. Oracle donated *parts* of ADF Faces to the ASF, what is now called Trinidad. If the code is something you/your company wrote on your own which is similar to the *Oracle Skin*, I am fine with that. I'd suggest uploading it to a private homepage first. Danny Robinson does something similar with his *new* controll / component Thanks, Matthias On 1/30/07, Mark Robinson [EMAIL PROTECTED] wrote: Hi Guys, I've finished up the packing for the Oracle Skin. Is there a sandbox/upload region available? Mark
Re: Patches
Yeah, thanks anyway Jeanne. Adam is on the ball. :) Jeanne Waldman wrote: Oh, I see Adam already did this. Thanks Adam. Jeanne Waldman wrote: Scott, I'll do my best to review your patches and check them into trunk and the JSF 1.2 branch. It would be great if someone else can give their feedback, since I'm not that familiar with what you are doing here.. Thanks, - Jeanne Scott O'Bryan wrote: Can someone please take a look at the patches for the following JIRA issues and give me your feedback so that we can get these merged into the JSF 1.2 branch and trunk? ADFFACES-374 ADFFACES-379 Thanks. Scott O'Bryan
Re: [BUG] recent trouble running Trinidad
The reason I ask is that I was getting a similar error (to the StateFieldMarker markup) when using the 1.2 branch, in the Portal Proof of Concept environment, with some of my extension involved. But I tracked this down to be an issue with the bridge I was using. I did NOT see this behavior in 1.1 or when running outside of a Portal environment in 1.2. As for the RenderingContext, I didn't mess with any of this code as part of either of these patches. So it doesn't seem like the issues are related to me. Scott Scott O'Bryan wrote: Jeanne, You're not using this in a Portal POC correct? Scott Jeanne Waldman wrote: Hi, I updated my trunk and I'm having problems, and I'm wondering if it is because of one of these patches. To reproduce: - run a demo, like index.jspx --- the page comes up fine, but this renders on the page: com.sun.faces.saveStateFieldMarker I see these warnings: Feb 14, 2007 10:31:25 AM org.apache.myfaces.trinidad.context.RenderingContext attach WARNING: Trying to attach RenderingContext to a thread that already had one. Feb 14, 2007 10:31:25 AM org.apache.myfaces.trinidadinternal.context.RequestContextImpl _createChangeManager INFO: Apache Trinidad is using HTTPSession for change persistence Feb 14, 2007 10:31:26 AM org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKit encodeFinally WARNING: No AdfRenderingContext available - I click on a link on the page, and it does not navigate Does anyone know what the problem is? I doubled checked to make sure I had output-modeportlet commented out in trinidad-config.xml. Thanks, - Jeanne Scott O'Bryan wrote: Can someone please take a look at the patches for the following JIRA issues and give me your feedback so that we can get these merged into the JSF 1.2 branch and trunk? ADFFACES-374 ADFFACES-379 Thanks. Scott O'Bryan
Re: [BUG] recent trouble running Trinidad
Jeanne, You're not using this in a Portal POC correct? Scott Jeanne Waldman wrote: Hi, I updated my trunk and I'm having problems, and I'm wondering if it is because of one of these patches. To reproduce: - run a demo, like index.jspx --- the page comes up fine, but this renders on the page: com.sun.faces.saveStateFieldMarker I see these warnings: Feb 14, 2007 10:31:25 AM org.apache.myfaces.trinidad.context.RenderingContext attach WARNING: Trying to attach RenderingContext to a thread that already had one. Feb 14, 2007 10:31:25 AM org.apache.myfaces.trinidadinternal.context.RequestContextImpl _createChangeManager INFO: Apache Trinidad is using HTTPSession for change persistence Feb 14, 2007 10:31:26 AM org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKit encodeFinally WARNING: No AdfRenderingContext available - I click on a link on the page, and it does not navigate Does anyone know what the problem is? I doubled checked to make sure I had output-modeportlet commented out in trinidad-config.xml. Thanks, - Jeanne Scott O'Bryan wrote: Can someone please take a look at the patches for the following JIRA issues and give me your feedback so that we can get these merged into the JSF 1.2 branch and trunk? ADFFACES-374 ADFFACES-379 Thanks. Scott O'Bryan
Re: [BUG] recent trouble running Trinidad
Jeanne, I was looking at the trunk and it appears that ADFFACES-379 was not applied to trunk and ADFFACES-374 is 1.2 only. So no, this issue is not related being that none of the patched code is actually in the trunk. :) After you figure out the issue, can you look at applying ADFFACES-379 to trunk? Thanks, Scott Jeanne Waldman wrote: No, I'm not running in a Portal. I'll look into it some. If anyone else sees this issue, let me know. Jeanne Scott O'Bryan wrote: The reason I ask is that I was getting a similar error (to the StateFieldMarker markup) when using the 1.2 branch, in the Portal Proof of Concept environment, with some of my extension involved. But I tracked this down to be an issue with the bridge I was using. I did NOT see this behavior in 1.1 or when running outside of a Portal environment in 1.2. As for the RenderingContext, I didn't mess with any of this code as part of either of these patches. So it doesn't seem like the issues are related to me. Scott Scott O'Bryan wrote: Jeanne, You're not using this in a Portal POC correct? Scott Jeanne Waldman wrote: Hi, I updated my trunk and I'm having problems, and I'm wondering if it is because of one of these patches. To reproduce: - run a demo, like index.jspx --- the page comes up fine, but this renders on the page: com.sun.faces.saveStateFieldMarker I see these warnings: Feb 14, 2007 10:31:25 AM org.apache.myfaces.trinidad.context.RenderingContext attach WARNING: Trying to attach RenderingContext to a thread that already had one. Feb 14, 2007 10:31:25 AM org.apache.myfaces.trinidadinternal.context.RequestContextImpl _createChangeManager INFO: Apache Trinidad is using HTTPSession for change persistence Feb 14, 2007 10:31:26 AM org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKit encodeFinally WARNING: No AdfRenderingContext available - I click on a link on the page, and it does not navigate Does anyone know what the problem is? I doubled checked to make sure I had output-modeportlet commented out in trinidad-config.xml. Thanks, - Jeanne Scott O'Bryan wrote: Can someone please take a look at the patches for the following JIRA issues and give me your feedback so that we can get these merged into the JSF 1.2 branch and trunk? ADFFACES-374 ADFFACES-379 Thanks. Scott O'Bryan
Re: [BUG] recent trouble running Trinidad
Oh cool, thanks Jeanne. Unlike the 1.2 branch, the patch should apply cleanly to the trunk. Adam did all the hard work. :) Scott Jeanne Waldman wrote: I did a clean build and it works fine now. Something must have gotten corrupted. I'll apply your 379 to trunk. - Jeanne Scott O'Bryan wrote: Jeanne, I was looking at the trunk and it appears that ADFFACES-379 was not applied to trunk and ADFFACES-374 is 1.2 only. So no, this issue is not related being that none of the patched code is actually in the trunk. :) After you figure out the issue, can you look at applying ADFFACES-379 to trunk? Thanks, Scott Jeanne Waldman wrote: No, I'm not running in a Portal. I'll look into it some. If anyone else sees this issue, let me know. Jeanne Scott O'Bryan wrote: The reason I ask is that I was getting a similar error (to the StateFieldMarker markup) when using the 1.2 branch, in the Portal Proof of Concept environment, with some of my extension involved. But I tracked this down to be an issue with the bridge I was using. I did NOT see this behavior in 1.1 or when running outside of a Portal environment in 1.2. As for the RenderingContext, I didn't mess with any of this code as part of either of these patches. So it doesn't seem like the issues are related to me. Scott Scott O'Bryan wrote: Jeanne, You're not using this in a Portal POC correct? Scott Jeanne Waldman wrote: Hi, I updated my trunk and I'm having problems, and I'm wondering if it is because of one of these patches. To reproduce: - run a demo, like index.jspx --- the page comes up fine, but this renders on the page: com.sun.faces.saveStateFieldMarker I see these warnings: Feb 14, 2007 10:31:25 AM org.apache.myfaces.trinidad.context.RenderingContext attach WARNING: Trying to attach RenderingContext to a thread that already had one. Feb 14, 2007 10:31:25 AM org.apache.myfaces.trinidadinternal.context.RequestContextImpl _createChangeManager INFO: Apache Trinidad is using HTTPSession for change persistence Feb 14, 2007 10:31:26 AM org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKit encodeFinally WARNING: No AdfRenderingContext available - I click on a link on the page, and it does not navigate Does anyone know what the problem is? I doubled checked to make sure I had output-modeportlet commented out in trinidad-config.xml. Thanks, - Jeanne Scott O'Bryan wrote: Can someone please take a look at the patches for the following JIRA issues and give me your feedback so that we can get these merged into the JSF 1.2 branch and trunk? ADFFACES-374 ADFFACES-379 Thanks. Scott O'Bryan
Patches
Can someone please take a look at the patches for the following JIRA issues and give me your feedback so that we can get these merged into the JSF 1.2 branch and trunk? ADFFACES-374 ADFFACES-379 Thanks. Scott O'Bryan
Re: Oracle Skin Release
Every once in a great while I make a good suggestion. :) They are few and far between, but. Scott Mark Robinson wrote: Adam, I've got all the images I need packaged up in my JAR file. So you can remove the images from Trinidad. I can change the name fairly easily. I think RedwoodShores might be the best name ;) Mark Adam Winer wrote: Mark, FWIW, we probably should have deleted those images from Trinidad. Not because of licensing or anything - their license is fully transferred to Apache! - but because they're unused inside of Trinidad. I'd like to be able to delete them from Trinidad, and have them packaged with the skin that uses them. So, if there's any way you could incorporate the images you use into your skin's JAR, that would be great. Also, I'd recommend that you choose some new name for the skin, just to avoid any questions of ownership/copyright, etc., down the road. Cheers, Adam On 1/30/07, Mark Robinson [EMAIL PROTECTED] wrote: Hi Matt, I've been working on a skin which looks like the old Oracle skin from ADF. There's been some moderate interest in it on the user mailing list. It is based upon images/CSS from inside Trinidad. What this means is that it's licensed under the Apache license. So it can be freely used inside Trinidad. I've packaged into a separate deployable jar for one reason. 1) It makes distributing/managing it so very easy Drop it into your WEB-INF/lib and change your skin to oracle and off you go. Otherwise, I'm completely infavour of re-integrating it back into mainline Trinidad. Anyways, you can download it at http://www.engr.uvic.ca/~mrobinso/OracleSkin.jar Mark Matthias Wessendorf wrote: what does that mean ? finished up the packing for thje Oracle Skin ? Is it like taking the ADF Faces Skin and bundling it separate? If yes, I am pretty much sure that we cannot have it here in Trinidad, since that code belongs Oracle. Oracle donated *parts* of ADF Faces to the ASF, what is now called Trinidad. If the code is something you/your company wrote on your own which is similar to the *Oracle Skin*, I am fine with that. I'd suggest uploading it to a private homepage first. Danny Robinson does something similar with his *new* controll / component Thanks, Matthias On 1/30/07, Mark Robinson [EMAIL PROTECTED] wrote: Hi Guys, I've finished up the packing for the Oracle Skin. Is there a sandbox/upload region available? Mark
Re: svn commit: r500011 - /incubator/adffaces/branches/jwaldman-portal/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/CoreRenderingContext.java
Yeah sorry, I didn't notice the comment either. I updates the JIRA
ticket. You're correct Adam, and I need some advice on the ticket if
you could.
Jeanne Waldman wrote:
Adam,
I just noticed this email. I'll ping Scott.
- Jeanne
Adam Winer wrote:
Has this change been tested? I'm far from certain
that this was purely an optimization. We often
check whether there is a PartialPageContext to
see if PPR is enabled, and if this check is removed,
then a lot of code will (I think) assume that PPR
is enabled and available when it is not.
-- Adam
On 1/25/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: jwaldman
Date: Thu Jan 25 14:02:08 2007
New Revision: 500011
URL: http://svn.apache.org/viewvc?view=revrev=500011
Log:
ADFFACES-364 PartialPageContext optimization bug. Check in for Scoot
O'Bryan to jwaldman-portal branch.
Remove this optimization in _initializePPR:
// Don't bother if PPR isn't even supported
if (!CoreRendererUtils.supportsPartialRendering(this))
return;
The reason is commented in the code:
//There used to be an optimization here which would simply
return when
//the PartialRendering capabilities were disabled. This was
removed
//because it is possible for extensions to Trinidad to support
PPR in a
//container-specific way in a Portal Environment even though
such capability
//is off by default. Furthermore, the check on whether
something is a
//PPR request or not is very efficient, so there is very little
time saved
//by the optimization.
Modified:
incubator/adffaces/branches/jwaldman-portal/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/CoreRenderingContext.java
Modified:
incubator/adffaces/branches/jwaldman-portal/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/CoreRenderingContext.java
URL:
http://svn.apache.org/viewvc/incubator/adffaces/branches/jwaldman-portal/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/CoreRenderingContext.java?view=diffrev=500011r1=500010r2=500011
==
---
incubator/adffaces/branches/jwaldman-portal/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/CoreRenderingContext.java
(original)
+++
incubator/adffaces/branches/jwaldman-portal/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/CoreRenderingContext.java
Thu Jan 25 14:02:08 2007
@@ -466,9 +466,13 @@
FacesContextfContext,
RequestContext context)
{
-// Don't bother if PPR isn't even supported
-if (!CoreRendererUtils.supportsPartialRendering(this))
- return;
+//There used to be an optimization here which would simply
return when
+//the PartialRendering capabilities were disabled. This was
removed
+//because it is possible for extensions to Trinidad to support
PPR in a
+//container-specific way in a Portal Environment even though
such capability
+//is off by default. Furthermore, the check on whether
something is a
+//PPR request or not is very efficient, so there is very little
time saved
+//by the optimization.
PartialPageContext partialPageContext =
PartialPageUtils.createPartialPageContext(fContext,
Re: svn commit: r494818 - in /incubator/adffaces/trunk/trinidad/trinidad-impl/src/main: java/org/apache/myfaces/trinidadinternal/convert/ javascript/META-INF/adf/jsLibs/
I liked the comment. My portal changes should be commented as some
portal changes. :)
Matthias Wessendorf wrote:
usually I do, not here.however no bug involved.
clean up and enhancements:
I changed some code on sending down the customized messageDetailXxxx.
I also provided a hook for a possible hint framework to customize the
hint.
all messages are now send down in a map.
(same for the some vali work commit)
-M
On 1/10/07, Adam Winer [EMAIL PROTECTED] wrote:
Matthias,
Could you provide more detailed logs than some converter work?
It'd help for knowing what's up with the project - and, if a bug
gets in, very helpful for looking through the log and figuring out what
might have triggered the problem.
-- Adam
On 1/10/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: matzew
Date: Wed Jan 10 06:06:22 2007
New Revision: 494818
URL: http://svn.apache.org/viewvc?view=revrev=494818
Log:
some converter works
Modified:
incubator/adffaces/trunk/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/convert/ColorConverter.java
incubator/adffaces/trunk/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/convert/DateTimeConverter.java
incubator/adffaces/trunk/trinidad/trinidad-impl/src/main/javascript/META-INF/adf/jsLibs/ColorFormat.js
incubator/adffaces/trunk/trinidad/trinidad-impl/src/main/javascript/META-INF/adf/jsLibs/DateFormat.js
Modified:
incubator/adffaces/trunk/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/convert/ColorConverter.java
URL:
http://svn.apache.org/viewvc/incubator/adffaces/trunk/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/convert/ColorConverter.java?view=diffrev=494818r1=494817r2=494818
==
---
incubator/adffaces/trunk/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/convert/ColorConverter.java
(original)
+++
incubator/adffaces/trunk/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/convert/ColorConverter.java
Wed Jan 10 06:06:22 2007
@@ -15,20 +15,21 @@
*/
package org.apache.myfaces.trinidadinternal.convert;
+import java.io.IOException;
import java.util.Collection;
import java.util.Collections;
+import java.util.HashMap;
import java.util.Map;
-import javax.faces.application.FacesMessage;
import javax.faces.component.UIComponent;
import javax.faces.context.FacesContext;
import org.apache.myfaces.trinidad.convert.ClientConverter;
import org.apache.myfaces.trinidad.logging.TrinidadLogger;
-import org.apache.myfaces.trinidad.util.MessageFactory;
import
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.XhtmlUtils;
import org.apache.myfaces.trinidadinternal.share.text.RGBColorFormat;
import
org.apache.myfaces.trinidadinternal.ui.laf.base.xhtml.XhtmlLafUtils;
+import org.apache.myfaces.trinidadinternal.util.JsonUtils;
/**
* @author The Oracle ADF Faces Team
@@ -139,10 +140,7 @@
*/
public String getClientConversion(FacesContext context,
UIComponent component)
{
-int patternsArgSize = _getPatternsArgSize();
-
-int size = 19 + patternsArgSize + 19;
-StringBuilder sb = new StringBuilder(size);
+StringBuilder sb = new StringBuilder();
StringBuilder patterns = new StringBuilder();
String[] setPatterns = getPatterns();
@@ -168,25 +166,35 @@
sb.append(XhtmlLafUtils.escapeJS(patternsString));
+MapString, String messages = new HashMapString, String();
String convMsgDet = getMessageDetailConvert();
if(convMsgDet != null)
{
- Object[] params = new Object[] {{0}, {1}, {2}};
-
- FacesMessage msg = MessageFactory.getMessage(context,
CONVERT_MESSAGE_ID,
- convMsgDet, params);
-
- sb.append(',');
- sb.append(XhtmlLafUtils.escapeJS(msg.getDetail()));
+ messages.put(detail, convMsgDet);
}
+
+String hint = getHintFormat();
-sb.append('));
+if(hint != null)
+{
+ messages.put(hint, hint);
+}
+
+sb.append(',);
+try
+{
+ JsonUtils.writeMap(sb, messages, false);
+}
+catch (IOException e)
+{
+ sb.append(null);
+}
+sb.append(')');
return sb.toString();
}
-
public int getColumns(
FacesContext context)
{
@@ -200,26 +208,6 @@
columns = Math.max(columns, new
RGBColorFormat(patterns[i]).length());
return columns;
- }
-
- // Returns the length of the patterns argument
- private int _getPatternsArgSize()
- {
-String[] patterns = this.getPatterns();
-int count = patterns.length;
-
-if (count == 1)
- return patterns[0].length();
-
-int size = 11; // Leave room for new Array()
-
-for (int i = 0; i count; i++)
-{
- // Include room for the pattern,
Re: [PORTAL] Adamns inline questions
No, it's not just backwards compatibility; the point is that it is perfectly acceptable for a developer to write a servlet filter. Just because you or I may want to require portlet support doesn't mean everyone does, or that everyone on the planet should stop using servlet filters. So, we should support those that want to write servlet filters to the extent that it's feasible, or those that want to integrate pre-existing filters to the extent that it's feasible. Which it is, as best I can see. True, and it does. Doesn't change the fact that this needs to be supported but inside and outside of the filters. My point about backward compatibility was simple, we could allow execution of filter services without needing to do things like handle the multi-part form request. The reason the filter needs to do it is because it was done before. Going forward, things that are put into services within the Trinidad main line can and should be done with the configurator. This means that going forward the filter developer is not guarenteed to have any of these additional wrappers run by the time the filter is run. I was NOT referring to the fact that filter services themselves were there to maintain backward compatibility. Going forward we're going to continue to need this functionality certainly. I'm just saying that applying the wrappers within trinidad are specifically for this purpose and going forward we won't need to apply them in both places. In FileUploadConfiguratorImpl you added a fixme that we should clean up the handles to the files as soon as possible. I agree with this. The current implementation (ie. before configurators were added) applied these before execution of the filterchain and then was allowed to get GC'd after. I believe that doing the same logic inside of the beginRequest and endRequest has about the same lifespan. So my question is, how does this differ from what was provided by Trinidad before these enhancements? If it isn't any different, then maybe we can file a Jira ticket and handle this as part of another patch. Yep, if it's endRequest(), that's good enough (as long as our configurator code has absolute guarantees that endRequest() will be called, which it does, I think?) The contract guarantees it yes. Some enhancements will need to be made to the bridge in order to enforce this without Faces 2.0. Either way, if it's not executed, it's a bug.
[PORTAL] Adamns inline questions
Hey Adam, In your last checkin to my branch you made some comments I would like to address. In the DispatchResponseConfiguratorImpl there is an isApplied function. You were asking why it was there. The reason for this is simple.. Backward compatibility. You mentioned to me in some previous emails that the filter was needed for backward compatibility and that any wrappers which WERE handled by the filter, needed to continue to be handled by the filter. Likewise, in many instances, the use of the filter is optional and until the JSR-301 is complete, Portal environments won't have access to pre-lifecycle requests and whatnot. So the isApplied simply tells whether the wrapper has been applied or not. If it has (in the case of the filter or other wrapping mechanisms like Portlet Filters (JSR-286) or Bridge listeners (JSR-301)) then it doesn't apply it a second time when the ExternalContext is retrieved. If this hasn't been pre-initialized then it does. This code is REALLY only needed for backward compatibility and any Configurators going forward would not be dependant on the filter and therefore would not need to worry about whether it was applied or not. In FileUploadConfiguratorImpl you added a fixme that we should clean up the handles to the files as soon as possible. I agree with this. The current implementation (ie. before configurators were added) applied these before execution of the filterchain and then was allowed to get GC'd after. I believe that doing the same logic inside of the beginRequest and endRequest has about the same lifespan. So my question is, how does this differ from what was provided by Trinidad before these enhancements? If it isn't any different, then maybe we can file a Jira ticket and handle this as part of another patch. Are these acceptable or are these something that need to be changed for this patch? Scott
Re: [PORTAL] Changes and API review?
Adam, I agree with many of your points about the reflection. My comment was mainly on casting and casting was still a realitivly slow operation as of JDK 1.4 (I havn't tested 1.5). Still, you have a valid point that it's done only once per class-loader per context. My question remains, though, why do it at all when we don't, at this moment, need to cast or expose the getInstance() API. I wholeheartedly disagree that using the service loader is the correct answer so for getting the instance we can avoid this alltogether by not exposing it. As for the disable function, there are things that can certainly be done to make that more robust. The first may be to expose some methods to the API (like isInRequest) but frankly I'm reluctant to do that without a GlobalConfigurator api exposed. The other way, perhaps, is to expose a utility to the API to check to see if the base configurator is current inside of a request. The impl of the utility could exist in the impl package and the global (base) configurator would not have to be exposed at all. Both of the above, however, depend on being able to load classes which exist in the Impl package from the API and, for many of the reasons I stated in my last email, the Service Loader is completly the wrong thing. This is a challenge that is shared by, not only, the RequestContext but also the TrinidadFilter. And it's a challenge of every API factory that needs to refer to an Impl. Faces has a FactoryFinder which solves many of these problems, but I frankly think a system like that is overkill. Especially since we are expecting only one global-type configurator. Frankly, I'm not sure I really care what the mechanism is that we use and making it a constant is an implementation choice and has no bearing on the API so long as the factory method returns the proper object. I therefore don't really see the harm in using a constant for the short term and then, at a later date, look at replacing it with a more robust system that might handled this in a better fashion. I really don't think the service loader is that mechanism, however. Scott Adam Winer wrote: Scott, A few points. First, I said only that initializing with construction is more robust then separating the two, and only that. That's plainly true. Why you want to turn that around to ad hominem generalizations is beyond me and not productive. Second, it certainly is a good point that you now might disable the configurator too late, which could easily lead to inconsistencies That could be caught in a couple of ways - a good one would be warning the developer on the next request. GlobalConfiguratorImpl could easily handle this on its own, and both make sure that if you start it, it finishes, and warn (and ignore) on the next configurator invocation if someone has disabled too late. Disabling the configurator is a rare enough requirement (in the number of places that'll want to do it) that this is a sufficient improvement to deal with that legitimate issue - all we need to do is catch anyone that gets it wrong (and avoid misbehaviors when it does happen). Third, you really need to stop imagining introspection is a horribly slow operation. That was true in JDK 1.2, but hardly the case at all now. And introspection *once during initialization*, not even once per request, isn't even remotely a performance issue, and describing it as such is just plain wrong. Fourth, referring to GlobalConfiguratorImpl by name from the API is awful. (We do this for the RequestContextFactoryImpl, and I've always disliked that decision). It totally breaks API-IMPL separation and dependency order. We're talking lesser of two evils here, and it's a judgement call. That said, I'm happy with moving Configurator.getInstance() down to impl (into GlobalConfiguratorImpl), as you're right that there isn't an obvious reason why it would need to be exposed at this point. That gets rid of the need to use any introspection API (Services or otherwise) to access GlobalConfiguratorImpl. Finally, I had little choice *but* to check in code on that branch. It's version controlled, so if it breaks portlets, then svn revert is trivial. But when you repeatedly misrepresent the technical aspects of what I'm proposing, claiming everything I propose is horrific and slow and ugly and will break some ill-defined API that is still to come, how else can I show you what I want??? Now, let's work together to go forwards. My checkin isn't end-of-story, no more than yours was. FWIW, I can't believe that JSR-301 is going to somehow make this API unusable. It will obviously be a different API, but I can't believe that it'll be so different that it'll be completely impossible to use that API such that it can invoke whatever it is that we come up with. -- Adam On 12/22/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Adam, You I must have a different definition of robust. Two of the MANY examples
Re: [PORTAL] Changes and API review?
Adding getInstance() to the configurator will either force us to cast in
a bunch of different places or to expose the GlobalConfiguratorImpl's
api to the rest of the world (which I don't want to do because they are
applicable ONLY to global configurator. And it won't lock us into an
API we may have to expand later.
As for simply putting the Boolean on the request map, either I'll have
to make a protected constant on the Configurator interface (which has no
bearing on any of the configurators except the global configurator so it
shouldn't go into the ancestor) or I add a porotected (isDisabled)
method (which, again, is only applicable to the GlobalConfiguratorImpl
and therfore shouldn't do into it's Ancestor).
I've never been one to include a feature into an interface or a class
that is applicable in only one instance of that class because it
violated basics OO design principals. The only other option I see here
is to define the constant used to store the boolean in BOTH classes and
hope they remain in sync, but I've never been a big fan of that either.
Scott
Adam Winer wrote:
Scott,
What about the far simpler approach of:
public static final void disableConfiguratorService(ExternalContext
external)
{
external.getRequestMap().put(..., Boolean.TRUE);
}
public static final boolean
isConfiguratorServiceDisabled(ExternalContext external)
{
return Boolean.TRUE.equals(external.getRequestMap().get());
}
Eliminates all the introspection and ugly hidden impl dependencies.
*And*, add to Configurator:
public static Configurator getInstance(ExternalContext)
{
... use code like RequestContextFactory.getFactory(),
but instead of instantiating a hardcoded file, use
ClassLoaderUtils.getServices(org.apache.myfaces.trinidad.config.GlobalConfigurator);
and calling configurator.init(...) to boot
}
... with, of course,
META-INF/services/org.apache.myfaces.trinidad.config.GlobalConfigurator
pointing
at GlobalConfiguratorImpl. And put the onus on
GlobalConfiguratorImpl's init() to load (and initialize)
all the other Configurators.
I think this'd also eliminate any need for isInitialized() - put
the onus on the code that retrieves (and therefore might
create) the instance.
-- Adam
On 12/19/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
Adam,
EVERYTHING will have to cast to it, since the entry point does not
return this class, but it's Configurator equivalent. Reflection and
casting are among the slowest operations in the Java language. And, we
do need access to this from the API package as well as the Impl (unless
you want me to move the resource servlet to the impl). These are facts.
Can it be done? Yes. But it's really ugly. So I'll tell you what.
I'll make an additional patch for this. Take a look at both and you
decide which is superior.
Scott
Adam Winer wrote:
Scott,
You're explaining very well why you want to put this in IMPL.
And why you need a different instance that handles this on
behalf of all other configurators. You're not yet explaining
why you need a whole class to accomplish this, as opposed
to a standard decorator or CoR pattern, etc. I just don't get it.
This one global instance is going to load all other instances,
and invoke all other instances. NO ONE needs to cast to it -
it is all powerful since it is the first (and only) entry point,
and it can decide whether all the others will run or not.
(And dog slow? C'mon, you're exaggerating. Hugely.
And describing one potential implementation of one
potential design.)
Yes, I do fight against adding extra code to our
API. For good reason, ya know! Less public API is
good. And, it really worries me when I see a design
that is unlike all the other designs I've seen for this
sort of pattern. I immediately get a gut feeling that
it's not really necessary.
-- Adam
Re: [PORTAL] Changes and API review?
Adam, Well, you basically implemented one of the solutions I said I didn't like earlier, but oh well. And there are a number of places you need to cast. So the concerns are still valid. The one question I do have is why does getInstance take in an ExternalContext? I'm assuming it's because your executing the init inside of the getInstance object and I'm not sure this is the correct place for this. My hope in all of this was to be able to explicitly handle initialization of this object. Plus, nine times out of ten, the ExternalContext object is ignored in the call to this method. Either way, don't see as I really have the time to argue. So is it acceptable to everyone? Also, there is no Adam Winer wrote: Scott, OK, well, I just went ahead and implemented what I was trying to say, to see if I'd run into the problems you're describing. I didn't... (It's possible I've broken something in portlet land - I only tested the changes in a servlet environment.) On 12/21/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Adding getInstance() to the configurator will either force us to cast in a bunch of different places No, it doesn't. No casts were required at all, much less in a bunch of places, and most of the code now doesn't even have references to the impl class at all. or to expose the GlobalConfiguratorImpl's api to the rest of the world (which I don't want to do because they are applicable ONLY to global configurator. And it won't lock us into an API we may have to expand later. As for simply putting the Boolean on the request map, either I'll have to make a protected constant on the Configurator interface (which has no bearing on any of the configurators except the global configurator so it shouldn't go into the ancestor) or I add a porotected (isDisabled) method (which, again, is only applicable to the GlobalConfiguratorImpl and therfore shouldn't do into it's Ancestor). See the code checked in, which does not suffer these probems. I've never been one to include a feature into an interface or a class that is applicable in only one instance of that class because it violated basics OO design principals. The only other option I see here is to define the constant used to store the boolean in BOTH classes and hope they remain in sync, but I've never been a big fan of that either. Again, see the code checked in. -- Adam
Re: [PORTAL] Changes and API review?
BTW- There are some API inconsistencies that need to be documented. The beginRequest and endRequest methods on the Global configurator object are designed to be run at the beginning and end of each request phase (In servlet there is one and in Portlet there are two) where as the Configurator services are designed to be run at the beginning and end of the physical request. The global configurator handles this scenario but the Javadocs are writtern from an implementors standpoint. Do you want me to submit a patch to fix the Javadocs or do you want to do it? Scott Scott O'Bryan wrote: Adam, Well, you basically implemented one of the solutions I said I didn't like earlier, but oh well. And there are a number of places you need to cast. So the concerns are still valid. The one question I do have is why does getInstance take in an ExternalContext? I'm assuming it's because your executing the init inside of the getInstance object and I'm not sure this is the correct place for this. My hope in all of this was to be able to explicitly handle initialization of this object. Plus, nine times out of ten, the ExternalContext object is ignored in the call to this method. Either way, don't see as I really have the time to argue. So is it acceptable to everyone? Also, there is no Adam Winer wrote: Scott, OK, well, I just went ahead and implemented what I was trying to say, to see if I'd run into the problems you're describing. I didn't... (It's possible I've broken something in portlet land - I only tested the changes in a servlet environment.) On 12/21/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Adding getInstance() to the configurator will either force us to cast in a bunch of different places No, it doesn't. No casts were required at all, much less in a bunch of places, and most of the code now doesn't even have references to the impl class at all. or to expose the GlobalConfiguratorImpl's api to the rest of the world (which I don't want to do because they are applicable ONLY to global configurator. And it won't lock us into an API we may have to expand later. As for simply putting the Boolean on the request map, either I'll have to make a protected constant on the Configurator interface (which has no bearing on any of the configurators except the global configurator so it shouldn't go into the ancestor) or I add a porotected (isDisabled) method (which, again, is only applicable to the GlobalConfiguratorImpl and therfore shouldn't do into it's Ancestor). See the code checked in, which does not suffer these probems. I've never been one to include a feature into an interface or a class that is applicable in only one instance of that class because it violated basics OO design principals. The only other option I see here is to define the constant used to store the boolean in BOTH classes and hope they remain in sync, but I've never been a big fan of that either. Again, see the code checked in. -- Adam
Re: [PORTAL] Changes and API review?
The global configurator already treats the render and action request as a single entity. The real question comes in about what happens during subsequent render requests. Sometimes, like storing render attributes, you want the request attributes to hang around for an action request and each subsequent render. Other times, you want it to only hang around for the physical request. This is something that the Servlet container does not address. Now that being said, I didn't say the methods were not generally applicable. They are. But there is no reason, in my opinion to pad the API with these additional methods. The global configurator (and only the global configurator) should be accessed directly. It's beginRequest, and endRequest methods will be called whenever appropriate whereas the Configurators, by contract, should only be called once per physical request (the Global configurator handles state saving). I had to add a new method to disable the GlobalConfigurator for one request (to handle the ResourceServlet case. So putting all this stuff on the base configurator object is unclean in my opinion. Especially considering that all configurators should have the same functionality for these methods so it would force us to finalize them in order to PREVENT people from overriding them in one Configurator and not in another. Scott Adam Winer wrote: Scott, Why wouldn't methods that hook the start and end of the physical request be generically useful? Note that in my scheme, these'd just be empty methods, not abstract methods (or interface methods) that every configurator has to implement. For that matter, wouldn't we want to make the configurator - right off the bat - *only* hook the physical request? What's the use case for ever wanting to hook the action and render phases independently (via this API, that is)? -- Adam
Re: [PORTAL] Changes and API review?
I'm still wondering why we should bloat the API of every configurator. And not ALL of the methods I'm looking at adding here can be static. Scott Adam Winer wrote: That method could easily be a static method on Configurator in my scheme. -- Adam On 12/15/06, Scott O'Bryan [EMAIL PROTECTED] wrote: I just got one more example from your other input. I'm probably going to be adding a disableConfiguratorForRequest method (or something similar) to the global configurator to support disabling the configurator services from running. It's cleaner then an attribute me-thinks and will help if we run into scoping issues with the two part portal request. See, I'm already going to need it. Scott Scott O'Bryan wrote: Hey Adam, First off, thanks for responding. Your suggestions have been invaluable. :) Now... Adam Winer wrote: So I guess basically I'm making one last appeal on the GlobalConfigurator thing. If you still want it removed I'll get rid of it. But I honestly think we're backing ourselves into an unnecessary corner. I'll give in on everything else and make a new patch for the jwaldman portal branch. I just don't get how we're getting extra flexibility. Can you give me a hypothetical scenario where having a different global configurator class (rather than just an instance) proves a big win? I don't see it yet. As best as I can see, my proposal still allows full access to the global instance to external developers. It just doesn't require a bonus class to do that. I absolutely can but bear with be because, like many of the Portal usecases, it's kinda convoluted.. One thing currently being discussed in JSR-301 (just as an example) is the lifetime of a Request attribute. Consider, if you will, the Servlet case. A request attribute has a lifetime of the physical request. This is sufficient because the application is assumed to be the only application in the browser. This means that every physical request from the browser to the server should process the actions on the JSF lifecycle and then execute the Render. In a Portal, however, this case is different. Really, request attributes that were added during the Lifecycle.execute phases are assumed to be there during each call the the Lifecycle.render phases. And because there is more then one portlet on the screen, an action from another portlet may cause a render to happen on our JSF Application. Understanding that, the nature of the two phase request of the portal is such that the JSR-301 bridge might (TBD) execute the beginRequest and endRequest methods at the beginning and end of the action AND render phases rather then at the beginning and end of the physical request. I'm pushing for the latter, but there are people that know a lot more about Portal's then I do who are arguing the previous point. So one of the things I put on the GlobalConfigurator initially (and I might need to put it back after I'm able to test this with the Bridge enhancements I need and Pluto), was a set of methods to store and clean up these items on the physical request. There is no reason that the baggage for this should have to be carried around by each Configurator. And if we have a getGlobalConfigurator which simply returns a Configurator object now, we're going to have problems in the future if that changes. Plus, it's one class of extra bloat, there are no real debatable API's on it that lock us into anything, and there is no impact at runtime to support this this class. It does, however, provide us a needed layer of abstraction in an area that's still somewhat high risk. Scott
Re: Trinidad sandbox?
I personally like the latter.. Unfortunately very few things can be developed in a Vacuume. At the very least it should have it's own copy of impl. Scott Matthias Wessendorf wrote: Looks like all here have already agreed on that one. What do you have in mind? a *separate* project with trinidad-api/-impl as dependency, where we can test components like the popup from danny? Or a *branch* that really acts as a sandbox to play with ideas on components and when stable (or close to it) the stuff get's merged into _core_ ? -M On 12/14/06, Adam Winer [EMAIL PROTECTED] wrote: I'd like to add a new sandbox project to trinidad, as a parallel directory to trinidad and plugins. This'd give us a place to add more substantial contributions - Danny Robinson's popup, for example - and give them time to be played around with, fixed up, APIs tweaked, etc., before moving in to the main libraries. It'd also give me a chance for committers like me to add experimental features that definitely shouldn't go into the trunk immediately, or perhaps ever (some ideas I've been toying with for multi-component validation, for example). Feedback? +1 from me. ;) -- Adam
Re: [PORTAL] Changes and API review?
It's API bloat and I'm also going to have to store some extra privates
on some of these classes as well as expose some additional api's to
support this. I ran into another issue with not implementing the Global
configurator. Take a look at this code.
When used inside of GlobalConfiguratorImpl, the code looks something
like this:
public void disableConfiguratorServices(final ServletRequest request)
{
if(Boolean.TRUE.equals(request.getAttribute(_IN_REQUEST)))
{
throw new IllegalStateException(Request is already begun.);
}
request.setAttribute(_IN_REQUEST, _DISABLED);
}
Now all the IN_REQUEST stuff is basically there to handle proper cleanup
and some API enforcement when calling into the GlobalConfigurator's
getExternalContext method. It is only exposed through the
GlobalConfiguratorImpl. There is no reason for anyone to know about it
outside of the impl package and even then in only a few locations.
Really though, people should keep their hands off of this. If I have on
the normal configurator a getGlobalConfigurator method which returns a
configurator, I have to go though much hokeyness in order to tell
whether I'm in a request or not. Because API cannot depend on classes
in Impl, I'll need to use reflection to get at the private methods
unless I want to expose this as an API on the configurator in general
and I don't think we want to do that.
We can also just skip the validity checking and modify the attribute,
but I would think that if someone is trying to disable the Configurator
and the response has already begun, then they should be notified as soon
as possible before hokey little errors creep up. There is much in the
impl package that depends on the instance of the GlobalConfiguratorImpl
and it's silly in my opinion to have to cast it every time we need to
use an arbitrary function. And when we need functionality from this guy
in the API package (like with the ResourceServlets) the implementation
begins to look REAL ugly.
So my question is why should we have to go through all this reflection
and casting, making this system dog slow, rather then supporting the
proper API's. The amount of work I've had to put in simply to code
around these issues is amazing. And I still havn't heard any
compelling reason why THIS implementation is not good.
Scott
Adam Winer wrote:
Well, in this specific instance, it therefore doesn't bloat every
configurator, since it only appears in one location.
-- Adam
Re: [PORTAL] Changes and API review?
Adam Winer wrote: Scott, My big concern is with the sheer quantity of new public APIs (that is, public classes in trinidad-api). We should be avoiding making anything public unless it is absolutely, critically necessary. Configurator APIs: I'm not completely sold on the name, but anyway, I think we should: Got another name you'd rather use? - Make Configurator an abstract class, not an interface. Make most of the methods empty, not abstract. Should be a simple fix - Add getGlobalConfigurator() to the Configurator API I'm not a big fan of this. The reason is that I keep running into instances in the Portal where I may have to add a per physical request type API. Current talk in JSR-301 is that the system will hopefully provide us with before and after request hooks which are much cleaner then phase listeners because we can do stuff before and after the lifecycle executes. The main question still in everyone's mind at this juncture is whether these will be run at the beginning and end of each portal request or the beginning and end of each physical request. Current leanings are at the beginning and end of each portal request and so there is a very real possibility that people might want to store attributes or whatnot that have the lifetime of the physical request. Therefore if these or other things arise, having an API for a global cofigurator will be more flexible in the future because we'll be able to add to this API would breaking binary compatibility. If we start returning normal Configurators form these API's it will force us to cast the object or add the methods to the base configurator object. In short, I think there are (or could be) sufficient difference between the GlobalConfigurator and the normal Configurator to justify the extra class even though the API's are not currently present. - Eliminate GlobalConfigurator and GenericConfigurator classes I can get rid of Generic Configurator, see above for Global Configurator TrinidadListener: - *Definitely* should be in impl, not in api. Register it automatically by including it in tr.tld. I was mimicking what we were doing with the Trinidad filter. But moving it to the TLD is definatly cleaner. I'll do this. All of the classes in webapp/wrappers and context/external: - Why aren't these in impl? - I don't understand at all why we could or should be implementing ServletExternalContext... that's provided by the impl. And PortletExternalContext should be provided by the bridge, or the impl as well if it supports portlets. What am I missing? I suspect these come from adding TrinidadFacesContext, so... These are valid questions and I went back and forth on this myself. The main issue is that the Configurators rely on someone being able to override the ExternalContext. And while a decorator may be sufficient for the overriding part, it's kind of silly (in my opinion) to force everyone to re-implement the pieces of the external context (such as, say, the RequestParameterMap) which is why those are public. As for the ServletExternalContext and the PortletExternalContext, if you look at the API for configurators again, they require us to supply an external context. In order to maintain compatibility with the servlet usecases that previous versions of Trinidad supported, we essentially need to construct a valid ExternalContext within the filter (Sevlet or future Portlet) and supply it to the configurators. It's better to provide implementations of these rather then rely on having to make them yourself. Now that being said, I moved the external context classes over to public as a while. While I believe we need the decorators and some of the map objects public, we can probably move the full ExternalContext implementations in impl (or in the case of the Portal one which was provided for completeness, remove it since I don't think it's used anywhere currently (I'll check). - TrinidadFacesContext: why can't you just use the regular FacesContextFactory, as we're doing today? Almost any solution is better than duplicating large amounts of impl code. This is a very good question and one that I thought a lot about. First off, this class is used within the resource servlets. Faces itself is designed with the idea of allowing renderkits to extend the framework as they need to. In theory (and I know the reality is somewhat different), but someone could add two renderkits to a particular web-app and use them. The problem is that the FacesContextFactory takes all of these entensions into account when returning the context. From a renderkit perspective, this is good because you hopefully have any functionality that your renderkit provides, somewhere in the Chain of FacesContexts. The problem, however, is that our Resource servlets belong to Trinidad only. This means that there is no reason for us to have to go through all the external-context wrapping that other
Re: [OT] ri for jsr 301 (was Re: [PORTAL] Changes and API review?)
We're in the process of finding a home. It's looking like the RI is going to live at JBoss, at least for now. They are trying to fastrack the project and there was some concern that the Apache community might be too process-heavy to allow the project to be developed in a timely manner. As for liscence, I'm not sure we have that worked out either. I do know that the ASL is in the running though. Matthias Wessendorf wrote: Also, as an FYI, I am on the JSR-301 Expert Group and have tried to incorporate a design which will allow us to use that spec once it's finished. The design is still in the preliminary stages, so there is no official support just yet, but I hope to have that support soon after the release of the final draft. do you know if the RI is developed here at Apache? Or somewhere else? I am thinking about Apache because Pluto is here too. If not Apache any information on the license yet? Thx, Matthias Thanks, Scott O'Bryan
Re: [PORTAL] Changes and API review?
Further investigation: PortletExternalContext can be removed. There is a possibility that it will need to be added again for JSR-301 but that depends on interfaces which aren't defined yet so I'm cool on getting rid of it till we need it. The ServletExternalContext is used in the ResourceServlet (which is in the API package) and the TrinidadFilterImpl (which is in the Impl package). Should I do some research on how to move this to the Impl package and still allow it to be called from ResourceServlet? I know we're still discussing the need to use a custom FacesContext, but if it turns out we should keep it, we're going to need to do something for the ExternalContext. One more point about the TrinidadFacesContext. It replaces the PseudoFacesContext that is already in Trinidad. The PseudoFacesContext didn't implement the base FacesContext stuff, but most of the external context was already handled in that class. The TrinidadFacesContext is an enhanced version of the PseudoFacesContext only it's not as hokey because it's a full impl instead of a partial impl AND it can be used from the resources. Finally, I looked and there is no reason that ExternalContextUtils cannot be put into the impl package. It's mostly used for setup of the RequestContext and some other logic which happens outside of the Faces scope. So good call. Scott Scott O'Bryan wrote: All of the classes in webapp/wrappers and context/external: - Why aren't these in impl? - I don't understand at all why we could or should be implementing ServletExternalContext... that's provided by the impl. And PortletExternalContext should be provided by the bridge, or the impl as well if it supports portlets. What am I missing? I suspect these come from adding TrinidadFacesContext, so... These are valid questions and I went back and forth on this myself. The main issue is that the Configurators rely on someone being able to override the ExternalContext. And while a decorator may be sufficient for the overriding part, it's kind of silly (in my opinion) to force everyone to re-implement the pieces of the external context (such as, say, the RequestParameterMap) which is why those are public. As for the ServletExternalContext and the PortletExternalContext, if you look at the API for configurators again, they require us to supply an external context. In order to maintain compatibility with the servlet usecases that previous versions of Trinidad supported, we essentially need to construct a valid ExternalContext within the filter (Sevlet or future Portlet) and supply it to the configurators. It's better to provide implementations of these rather then rely on having to make them yourself. Now that being said, I moved the external context classes over to public as a while. While I believe we need the decorators and some of the map objects public, we can probably move the full ExternalContext implementations in impl (or in the case of the Portal one which was provided for completeness, remove it since I don't think it's used anywhere currently (I'll check). - TrinidadFacesContext: why can't you just use the regular FacesContextFactory, as we're doing today? Almost any solution is better than duplicating large amounts of impl code. This is a very good question and one that I thought a lot about. First off, this class is used within the resource servlets. Faces itself is designed with the idea of allowing renderkits to extend the framework as they need to. In theory (and I know the reality is somewhat different), but someone could add two renderkits to a particular web-app and use them. The problem is that the FacesContextFactory takes all of these entensions into account when returning the context. From a renderkit perspective, this is good because you hopefully have any functionality that your renderkit provides, somewhere in the Chain of FacesContexts. The problem, however, is that our Resource servlets belong to Trinidad only. This means that there is no reason for us to have to go through all the external-context wrapping that other renderkits might tack on through their own custom factories. This adds bloat when there really doesn't need to be. From a Portal perspectivethis is even more important. Trinidad, up until this project, has been able to limit exposure to the wrapping problem by relying on the fact that the filters are run only before and after a call to the faces servlet essentially. Being that there is no equivalent in the Portal environment, modifications have had to be made to allow Configurators to be run through a custom FacesContextFactory. This means that even within our own renderkit, things like skinning, file upload handling, and RequestContext initialization (as well as the running of additional services) all happen when these external resources retrieve the FacesContext from the factory. As far as I'm aware, there is no sure
Re: [PORTAL] Changes and API review?
I just got one more example from your other input. I'm probably going to be adding a disableConfiguratorForRequest method (or something similar) to the global configurator to support disabling the configurator services from running. It's cleaner then an attribute me-thinks and will help if we run into scoping issues with the two part portal request. See, I'm already going to need it. Scott Scott O'Bryan wrote: Hey Adam, First off, thanks for responding. Your suggestions have been invaluable. :) Now... Adam Winer wrote: So I guess basically I'm making one last appeal on the GlobalConfigurator thing. If you still want it removed I'll get rid of it. But I honestly think we're backing ourselves into an unnecessary corner. I'll give in on everything else and make a new patch for the jwaldman portal branch. I just don't get how we're getting extra flexibility. Can you give me a hypothetical scenario where having a different global configurator class (rather than just an instance) proves a big win? I don't see it yet. As best as I can see, my proposal still allows full access to the global instance to external developers. It just doesn't require a bonus class to do that. I absolutely can but bear with be because, like many of the Portal usecases, it's kinda convoluted.. One thing currently being discussed in JSR-301 (just as an example) is the lifetime of a Request attribute. Consider, if you will, the Servlet case. A request attribute has a lifetime of the physical request. This is sufficient because the application is assumed to be the only application in the browser. This means that every physical request from the browser to the server should process the actions on the JSF lifecycle and then execute the Render. In a Portal, however, this case is different. Really, request attributes that were added during the Lifecycle.execute phases are assumed to be there during each call the the Lifecycle.render phases. And because there is more then one portlet on the screen, an action from another portlet may cause a render to happen on our JSF Application. Understanding that, the nature of the two phase request of the portal is such that the JSR-301 bridge might (TBD) execute the beginRequest and endRequest methods at the beginning and end of the action AND render phases rather then at the beginning and end of the physical request. I'm pushing for the latter, but there are people that know a lot more about Portal's then I do who are arguing the previous point. So one of the things I put on the GlobalConfigurator initially (and I might need to put it back after I'm able to test this with the Bridge enhancements I need and Pluto), was a set of methods to store and clean up these items on the physical request. There is no reason that the baggage for this should have to be carried around by each Configurator. And if we have a getGlobalConfigurator which simply returns a Configurator object now, we're going to have problems in the future if that changes. Plus, it's one class of extra bloat, there are no real debatable API's on it that lock us into anything, and there is no impact at runtime to support this this class. It does, however, provide us a needed layer of abstraction in an area that's still somewhat high risk. Scott
Re: [PORTAL] Changes and API review?
Hey Adam, First off, thanks for responding. Your suggestions have been invaluable. :) Now... Adam Winer wrote: So I guess basically I'm making one last appeal on the GlobalConfigurator thing. If you still want it removed I'll get rid of it. But I honestly think we're backing ourselves into an unnecessary corner. I'll give in on everything else and make a new patch for the jwaldman portal branch. I just don't get how we're getting extra flexibility. Can you give me a hypothetical scenario where having a different global configurator class (rather than just an instance) proves a big win? I don't see it yet. As best as I can see, my proposal still allows full access to the global instance to external developers. It just doesn't require a bonus class to do that. I absolutely can but bear with be because, like many of the Portal usecases, it's kinda convoluted.. One thing currently being discussed in JSR-301 (just as an example) is the lifetime of a Request attribute. Consider, if you will, the Servlet case. A request attribute has a lifetime of the physical request. This is sufficient because the application is assumed to be the only application in the browser. This means that every physical request from the browser to the server should process the actions on the JSF lifecycle and then execute the Render. In a Portal, however, this case is different. Really, request attributes that were added during the Lifecycle.execute phases are assumed to be there during each call the the Lifecycle.render phases. And because there is more then one portlet on the screen, an action from another portlet may cause a render to happen on our JSF Application. Understanding that, the nature of the two phase request of the portal is such that the JSR-301 bridge might (TBD) execute the beginRequest and endRequest methods at the beginning and end of the action AND render phases rather then at the beginning and end of the physical request. I'm pushing for the latter, but there are people that know a lot more about Portal's then I do who are arguing the previous point. So one of the things I put on the GlobalConfigurator initially (and I might need to put it back after I'm able to test this with the Bridge enhancements I need and Pluto), was a set of methods to store and clean up these items on the physical request. There is no reason that the baggage for this should have to be carried around by each Configurator. And if we have a getGlobalConfigurator which simply returns a Configurator object now, we're going to have problems in the future if that changes. Plus, it's one class of extra bloat, there are no real debatable API's on it that lock us into anything, and there is no impact at runtime to support this this class. It does, however, provide us a needed layer of abstraction in an area that's still somewhat high risk. Scott
Re: What DevEnv do you use for Trinidad
I use eclipse with the four projects and it works just fine. I do have a suggestion though: 1. Turn off automatic compile - eclipse has trouble removing the target directories sometimes because the targets are referred to in the project as source. Comes from the automatic generation of the tags. 2. Be sure to do an mvn install before importing the projects. I suggest doing a mvn clean install eclipse:eclipse the first time. This is because some of the files in the Trinidad build are generated and without running the maven task, you don't get these generated files. 3. Either clean and build all the projects, or build them one at a time in the following order: build, api. impl, demo They only real annoying thing is that the demo project shows up as a normal java project rather then a Web Project, so hopefully the mvn eclipse plugin will be enhanced soon to support Calisto. Finally, I havn't used the mvn plugin for eclipse, so I can't speak to that but I hope this helps. Scott Adam Winer wrote: And I use Emacs and a command-line, which I imagine makes me very old-school. ;) -- Adam On 12/14/06, Matt Cooper [EMAIL PROTECTED] wrote: Hi Danny, The most common ones I've heard of are either Eclipse or Oracle JDeveloper. I use the latter and create workspace/project files by running the command mvn install jdev:jdev. I believe the expected generated workspace should have 4 projects (api, build, demo, impl) with pre-attached dependencies so you just need to run a jspx page from the demo project and automatically it will build any changes you make in the other projects. Perhaps someone else on this list can better talk to the Eclipse issues you are experiencing. Regards, Matt On 12/14/06, Danny Robinson [EMAIL PROTECTED] wrote: Guys, Are most people using Eclipse to develop the Trinidad components/code? If not, then what do people mainly use? I followed the wiki page that details the Eclipse setup for Trinidad and got a clean compile. However, I'm not certain everything's as it should be, and I certainly can't use the maven eclipse plugin to do a clean 'install'. Using a different approach, 'mvn eclipse:eclipse' command created 4 projects rather than the 2 mentioned in the wiki. However, these wouldn't cleanup compile due to dependencies. Thanks, Danny -- Chordiant Software Inc. www.chordiant.com
Re: Trinidad sandbox?
Right, but high risk projects could be committed to the sandbox first and allow them to ferment a bit without effecting the main line. I like it! +1 (non-binding) Adam Winer wrote: On 12/14/06, Danny Robinson [EMAIL PROTECTED] wrote: +1 (non binding). Q1 - Would this add more workload to those with Commit priviledge, or could we open up the commit access a little more for this project? I don't think there is any process for a less-restrictive commit access for one portion of the product. My understanding is that a committer is a committer is a committer... Someone with more detailed ASF expertise can confirm. -- Adam On 12/14/06, Adam Winer [EMAIL PROTECTED] wrote: I'd like to add a new sandbox project to trinidad, as a parallel directory to trinidad and plugins. This'd give us a place to add more substantial contributions - Danny Robinson's popup, for example - and give them time to be played around with, fixed up, APIs tweaked, etc., before moving in to the main libraries. It'd also give me a chance for committers like me to add experimental features that definitely shouldn't go into the trunk immediately, or perhaps ever (some ideas I've been toying with for multi-component validation, for example). Feedback? +1 from me. ;) -- Adam -- Chordiant Software Inc. www.chordiant.com
[PORTAL] Changes and API review?
Hey everyone, As some of you know I have been working on a bunch of enhancements in order to get Trinidad prepared to work on a portal environment. While there is still some myfaces bridge work which needs to be done in order to call this a complete success, I would like to get the work I have done merged into the trunk in order to prevent conflicts and to get everyone working with the new API's. You can find the portal code into the jwaldman-portal branch which has a combination of the following patches as well as some of the work she is working on for skinning. I am going to talk about the Patches corresponding to: ADFFACES-231, ADFFACES-232, ADFFACES-234, and ADFFACES-235. Most importantly, I would like your input on several public API's that were added as a result of this project in order to get approval from the community. Also, as an FYI, I am on the JSR-301 Expert Group and have tried to incorporate a design which will allow us to use that spec once it's finished. The design is still in the preliminary stages, so there is no official support just yet, but I hope to have that support soon after the release of the final draft. Thanks, Scott O'Bryan
[PORTAL] Launch Parameters
Hello everyone, I'm looking at supporting launch parameters for the Portal in Trinidad. To recap my understanding of them, in the TrinidadFilter, Trinidad does its filter stuff and then does a doFilter on the FilterChain. When the chain returns, the TrinidadFilter checks for the existence of LaunchParameters and, if they exist, it essentially executes the doFilter again with a modified set of parameters (and thus runs the Lifecycle again). In Portlets we really don't have this capability because this is really controlled by the bridge right now and it is unlikely we'll be able to support this without specific enhancements to the Bridge until JSR-286. So my question is, would I be able to simulate this behavior in a portal environment by sending a redirect back to the portlet with the new parameters? I know that this will cause performance issues in the short term, but it will do so only in a Portal environment and then only until filters are supported in a portal environment. I'm simply not sure how these are used, exactly, which is why I'm asking if the redirect would be functionally equivalent. Scott
Re: [PORTAL] Launch Parameters
Interesting. I see your point. Adam Winer wrote: This is part of the dialog framework, for returning from a dialog shown in-place (instead of in a popup window). I think it'd be very tough to make this a redirect, since there can be *a lot* of parameters (it's basically a full POST), and they won't all fit in a GET. -- Adam On 12/13/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Hello everyone, I'm looking at supporting launch parameters for the Portal in Trinidad. To recap my understanding of them, in the TrinidadFilter, Trinidad does its filter stuff and then does a doFilter on the FilterChain. When the chain returns, the TrinidadFilter checks for the existence of LaunchParameters and, if they exist, it essentially executes the doFilter again with a modified set of parameters (and thus runs the Lifecycle again). In Portlets we really don't have this capability because this is really controlled by the bridge right now and it is unlikely we'll be able to support this without specific enhancements to the Bridge until JSR-286. So my question is, would I be able to simulate this behavior in a portal environment by sending a redirect back to the portlet with the new parameters? I know that this will cause performance issues in the short term, but it will do so only in a Portal environment and then only until filters are supported in a portal environment. I'm simply not sure how these are used, exactly, which is why I'm asking if the redirect would be functionally equivalent. Scott
Re: [PORTAL] Launch Parameters
One more question then. Does this run two different lifecycles (ie. the dialog one runs and returns, then the base one is executed) or is there a possibility of cramming these into one lifecycle call? Scott Scott O'Bryan wrote: Interesting. I see your point. Adam Winer wrote: This is part of the dialog framework, for returning from a dialog shown in-place (instead of in a popup window). I think it'd be very tough to make this a redirect, since there can be *a lot* of parameters (it's basically a full POST), and they won't all fit in a GET. -- Adam On 12/13/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Hello everyone, I'm looking at supporting launch parameters for the Portal in Trinidad. To recap my understanding of them, in the TrinidadFilter, Trinidad does its filter stuff and then does a doFilter on the FilterChain. When the chain returns, the TrinidadFilter checks for the existence of LaunchParameters and, if they exist, it essentially executes the doFilter again with a modified set of parameters (and thus runs the Lifecycle again). In Portlets we really don't have this capability because this is really controlled by the bridge right now and it is unlikely we'll be able to support this without specific enhancements to the Bridge until JSR-286. So my question is, would I be able to simulate this behavior in a portal environment by sending a redirect back to the portlet with the new parameters? I know that this will cause performance issues in the short term, but it will do so only in a Portal environment and then only until filters are supported in a portal environment. I'm simply not sure how these are used, exactly, which is why I'm asking if the redirect would be functionally equivalent. Scott
Re: partialTriggers and naming containers
Well in that case... +1 :) Matthias Wessendorf wrote: feedback by all is welcome. a good community provides good code; that's Apache ;) -M On 12/8/06, Böhringer Jochen [EMAIL PROTECTED] wrote: I'm not a commiter, but I would also raise my hand for the :: syntax. Regards Jochen Von: venkata guddanti [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 8. Dezember 2006 18:07 An: adffaces-dev@incubator.apache.org Betreff: Re: partialTriggers and naming containers +1 to :: syntax. Can we also enhance the partialTriggers such that if we do not find a component inside the naming container, we automatically look for it using the parent component? Of course :: syntax is more predictable. Regards, Venkata On 12/8/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: So, to fix this, I'd like to support some extra syntax like .. in file paths. I'm thinking :: to go up a level. Maybe ::: to go up two, etc.? So, partialTriggers=::first:foo would work. How's this sound? Interesting idea. A .. like approach for sorta navigation inside the component tree sounds good for me. I think the problem is the same with the for attribute (like on message /) when refering to a UIComponent outside of the current NC. To make it short = +1 -M -- Adam -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: PATCH: ServerSide buttons are back
Mark, Yes, he means trinidadinternal.ui. The reason we are getting rid of this is basically a historical reason. These classes are basically a set of adapters designed to port Oracle's old UIX component base over to Faces. As the components were enhanced and expanded, we started turning these components into true Faces Components (which we'll refer to as Faces Major) on this list. While it's acceptable to make enhancements to the UI packages until all the UIX components have been ported over, it is completely wrong to add any new dependencies from outside of these. I haven't taken a look at your patch, but I would take a look at either making your dependancies FacesMajor, or moving the functionality you need from the UI package into a non-ui package and have the UI classes refer to it. Make sense? Scott Mark Robinson wrote: Adam, By myfaces.ui, do you mean trinidadinternal.ui? Is there a reason for getting rid of it? Also, is there migration documentation? Ie, class X is gone, use class Y and Z. Thanks, Mark Adam Winer wrote: Mark, It's not OK for anything in myfaces.trinidadinternal.renderkit to have dependencies on code in myfaces.ui; our goal is to kill all code in myfaces.ui. So, for example: import org.apache.myfaces.trinidadinternal.ui.UIXRenderingContext; import org.apache.myfaces.trinidadinternal.ui.laf.simple.desktop.IconInputStreamProvider ; import org.apache.myfaces.trinidadinternal.ui.laf.simple.desktop.SimpleDesktopConstants ; import org.apache.myfaces.trinidadinternal.uinode.FacesRenderingContext; ... are all off-limits. (Looking through the patch, it looks as though you've added some other imports unnecessarily.) -- Adam No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.15.9/573 - Release Date: 05/12/2006 4:07 PM
Show me the Region!!!!
Hey all, I noticed in the Trinidad tag lib documentation that an af:region tag is supported. Yet on my relatively new version of the build, the region tag does not show up in the TLD. Anyone know if Regions are supported or not? If so, what tld do I need to import to get the tag definition? Scott
Re: GoLinkRenderer calls writeURIAttribute to render name and id, why?
Right. Well it's the other cases I'm worried about. I would rather not
have the decision in the Trinidad code whether to encode the URL or
not. We should always be encoding unless we're certain they are
bookmarks. Otherwise, presumably, the app server or portal will handle
it accordingly. Is that not correct?
Scott
Matt Cooper wrote:
If the link's destination starts with # then yes; if the destination
doesn't start with http://;, https://;, mailto:;, javascript: or
anything else.
On 11/29/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
So they will basically reference bookmarks, correct?
Scott
Adam Winer wrote:
Neither; they do not need to be encoded at all, as they
are only references within a page.
-- Adam
On 11/28/06, Qiang Fan [EMAIL PROTECTED] wrote:
Adam:
I asked the question because I am working on a patch for encoding
URLs in
trinidad. I need to know whether to encode the URL as Action URL or
Resource
URL.
For the following scenarios I guess they should all be encoded as
Action
URL. But I am not sure. Just want to confirm with you.
In HeaderRenderer (in this case only name is rendered and I did not
see id
for it):
renderURIAttribute(context, NAME_ATTRIBUTE, label);
And in LinkRenderer:
protected void renderID(
UIXRenderingContext context,
UINode node
) throws IOException
{
Object id = getID(context, node);
if (id != null)
{
if (supportsID(context))
{
// For links, name and thus id is a URI attribute.
renderURIID(context, id);
}
if (supportsNameIdentification(context)
makeNameAndIDSame(context))
{
renderURIAttribute(context, name, id);
}
}
}
Are they all Action URLs?
Thanks.
John
On 11/28/06, Adam Winer [EMAIL PROTECTED] wrote:
The value of the attribute on name on GoLink will end up mapping
up to href on some other link. So it really is a URI.
E.g., you need to use % encoding, not encoding.
And id must equal name.
-- Adam
On 11/28/06, Qiang Fan [EMAIL PROTECTED] wrote:
In GoLinkRenderer class, there is the following method:
@Override
protected void renderId(
FacesContext context,
UIComponent component) throws IOException
{
if (shouldRenderId(context, component))
{
String clientId = getClientId(context, component);
// For links, these are actually URI attributes
context.getResponseWriter().writeURIAttribute(id,
clientId,
id);
context.getResponseWriter().writeURIAttribute(name,
clientId,
id);
}
}
Why are id and name rendered as URI? Are the id and name used as
URI in
javascript logic? I saw some similar code in several other
classes too.
Thanks.
John Fan
Re: GoLinkRenderer calls writeURIAttribute to render name and id, why?
Thanks Adam. That's what I was looking for. :)
Scott
Adam Winer wrote:
Guys, this is ALWAYS a # URL. It's the name attr of a link, and
can't possibly be anything more. There are zero portal implications.
-- Adam
On 11/29/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
Right. Well it's the other cases I'm worried about. I would rather not
have the decision in the Trinidad code whether to encode the URL or
not. We should always be encoding unless we're certain they are
bookmarks. Otherwise, presumably, the app server or portal will handle
it accordingly. Is that not correct?
Scott
Matt Cooper wrote:
If the link's destination starts with # then yes; if the destination
doesn't start with http://;, https://;, mailto:;, javascript: or
anything else.
On 11/29/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
So they will basically reference bookmarks, correct?
Scott
Adam Winer wrote:
Neither; they do not need to be encoded at all, as they
are only references within a page.
-- Adam
On 11/28/06, Qiang Fan [EMAIL PROTECTED] wrote:
Adam:
I asked the question because I am working on a patch for encoding
URLs in
trinidad. I need to know whether to encode the URL as Action
URL or
Resource
URL.
For the following scenarios I guess they should all be encoded as
Action
URL. But I am not sure. Just want to confirm with you.
In HeaderRenderer (in this case only name is rendered and I did
not
see id
for it):
renderURIAttribute(context, NAME_ATTRIBUTE, label);
And in LinkRenderer:
protected void renderID(
UIXRenderingContext context,
UINode node
) throws IOException
{
Object id = getID(context, node);
if (id != null)
{
if (supportsID(context))
{
// For links, name and thus id is a URI attribute.
renderURIID(context, id);
}
if (supportsNameIdentification(context)
makeNameAndIDSame(context))
{
renderURIAttribute(context, name, id);
}
}
}
Are they all Action URLs?
Thanks.
John
On 11/28/06, Adam Winer [EMAIL PROTECTED] wrote:
The value of the attribute on name on GoLink will end up
mapping
up to href on some other link. So it really is a URI.
E.g., you need to use % encoding, not encoding.
And id must equal name.
-- Adam
On 11/28/06, Qiang Fan [EMAIL PROTECTED] wrote:
In GoLinkRenderer class, there is the following method:
@Override
protected void renderId(
FacesContext context,
UIComponent component) throws IOException
{
if (shouldRenderId(context, component))
{
String clientId = getClientId(context, component);
// For links, these are actually URI attributes
context.getResponseWriter().writeURIAttribute(id,
clientId,
id);
context.getResponseWriter().writeURIAttribute(name,
clientId,
id);
}
}
Why are id and name rendered as URI? Are the id and name
used as
URI in
javascript logic? I saw some similar code in several other
classes too.
Thanks.
John Fan
Re: [Question] Copying code from MyFaces
Yay.. Thanks Martin. Martin Marinschek wrote: There is nothing offending in copying any of the classes over from MyFaces-Impl to Trinidad! regards, Martin On 11/8/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Hey Guys, All arguments about the need for a common code package aside (yes, I will continue to champion this), Trinidad has the need to create container abstractions for some of our initialization services. We're basically going to use the external context to pass into these services because it's a familiar interface. The reason this needs to be done outside of the Faces arena is that these services MAY be kicked off from a filter if one is present because there were some usecases we just couldn't resolve in order to eliminate the need for the filter in order to work in the portal. Many of the usecases, however, can be written in a container-agnostic fashion and run from the portal. So here is my question. Is it bad for to copy come of the MyFaces code (namely the ExternalContext code) and move it into our packages, changing it as we need to. We cannot be dependent on the MyFaces Impl package (which is where this code currently exists) in order to maintain compatibility with the RI. Seems silly to rewrite these containers though. I figured I'd ask since both MyFaces and Trinidad are under the Apache Liscence. And yes, when/if we get a common package, we may be able to share this code but I'm on somewhat of a time limit. Scott
[Question] Copying code from MyFaces
Hey Guys, All arguments about the need for a common code package aside (yes, I will continue to champion this), Trinidad has the need to create container abstractions for some of our initialization services. We're basically going to use the external context to pass into these services because it's a familiar interface. The reason this needs to be done outside of the Faces arena is that these services MAY be kicked off from a filter if one is present because there were some usecases we just couldn't resolve in order to eliminate the need for the filter in order to work in the portal. Many of the usecases, however, can be written in a container-agnostic fashion and run from the portal. So here is my question. Is it bad for to copy come of the MyFaces code (namely the ExternalContext code) and move it into our packages, changing it as we need to. We cannot be dependent on the MyFaces Impl package (which is where this code currently exists) in order to maintain compatibility with the RI. Seems silly to rewrite these containers though. I figured I'd ask since both MyFaces and Trinidad are under the Apache Liscence. And yes, when/if we get a common package, we may be able to share this code but I'm on somewhat of a time limit. Scott
Re: [PORTAL] Getting rid of filters
Oh yeah, and I'm moving wrapping of servlet objects out of the filters and into the ExternalContext. That does not mean we can't wrap them in filters as well, but everytime we do, those filters will not run in a portal. Scott Scott O'Bryan wrote: Two questions then: 1) Being that these won't work in a portal environment, should we move these to be executed elsewhere (like my custom lifecycle object) and change the API to be more container agnostic (ie. using the ExternalContext)? 2) If we do need to leave these in the filters, is it okay to move all the other initialization logic (like setting up the skinning and whatnot) to execute after these services or does it need to continue to execute in the same order? Scott Adam Winer wrote: On 11/3/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Hello everyone, I'm almost done implementing a custom wrapper for the life cycle which should allow us to replace a large part of the functionality of our filter (the other part being handled by FacesContext wrappers). I did have one question regarding services which are referred to in the TrinidadFilterImpl object. It appears, basically, that the TrinidadFilterImpl is responsible for kicking off a number of services. These services use a FilterChains to execute and, as such, are not compatible with a portal environment. Can anyone tell me what these services might be used for and what guarantees, if any, we make as to when they are executed? They can be used for anything that a Filter can be used for. I've used them for initialization; also, for wrapping of servlet objects. -- Adam
Re: [PORTAL] Custom lifecycle?
You know you can do that all in one phase listener, right? It's really not much code at all to implement an algorithm like this. Yes, but even the code in 10.1.3.2 which doesn't take phases into account is somewhat scary. :) Adding logic to figure out what phase is next is a lot more scary. And as you said, in 1.1, there is no guarantee that the endPhaseListener gets called. Hrm, I'm confused - I thought you were talking about implementing a custom Lifecycle object. Do you mean a custom Lifecycle, or just a custom Filter? A Filter + a PhaseListener is fine. It's just implementing Lifecycle itself that is a bit scary. I'm trying to eliminate the filter all together. I can put code in the bridge which calls a particular listener before/after the execute and render methods are executed in the bridge, or I can make a custom lifecycle which requires NO changes to the bridge and executes the initialization code at the beginning and end of the lifecycle itself. The object itself wouldn't be too scary as it would do it's initialization and then deligate to the underlying lifecycle object. Code wise, it allows us to take advantage of the JSF ExternalContext abstractions much easier and eliminates the need for special handling of the Portal usecases. -- Adam Scott Adam Winer wrote: On 10/20/06, Scott O'Bryan [EMAIL PROTECTED] wrote: My question is this, is there any reason we can't provide our own custom lifecycle object that decorates the default one and allows us to run our initialization code on the execute and render? If so, the code to manage things like the TrinidadFacesContext becomes a LOT easier and we can rely on some of the stuff already build in to the Bridge Portlets. What's the advantage of a custom lifecycle over using a phase listener? --Adam
Re: [PORTAL] Custom lifecycle?
Arash, Hey Arash, thanks for the links. The problem is that finding an AJAX solution will pretty much trump any other work we have. While certain portal implementations can be exploited to provide what is needed for AJAX, none of them are guaranteed with JSR-168. The real problem with AJAX and portletshas nothing to do with the life cycle. It more has to do with limitations of JSR-168. Let me elaborate. JSR-168 containers do not guarantee that a particular call to a resource is in the same namespace as it's parent application. This is typically the case in WSRP containers. Even assuming we could be connected to the same session as a particular portlet, the session data for a portlet instance is prefixed with a javax prefix and the portlet id. While this is SOMETIMES the same as the namespace, the JSR-168 does not guarantee this and there is no API for getting a hold of the portlet Id. Portlet 2.0 Spec is supposed to have some mechanisms for handling this, but anything we put in place in the mean time to handle AJAX will not work in all containers. Therefore, I'm of the opinion that we should get Trinidad working without AJAX first, making it the most compatible with JSR-168, and then look at possibly enhancing it to take a advantage of some specific portlet container implementations that might be exploited for AJAX. Until the portlet 2.0 specification is released, JSR-168 will not be able to support AJAX in all cases natively, or at the very least not in a fashion that is as secure as the web container. Scott Arash Rajaeeyan wrote: Hello, First let me tell, that since lifecycle of Portlets is different with Servlets, so the same implementation of the JSF life cycle for servlet is not necessarily good for portlets too. I didn't find an exact case in Trinidad sources, but there are should be some facilities similar to tomahawk immediate attributes ( http://wiki.apache.org/myfaces/How_The_Immediate_Attribute_Works) Which some time short cut the lifecycle. So I think this should be taken into account If we can find a method for handling AJAX requests at same time is also good. The problem is every AJAX call to a portlet will generate a processAction and as a result will refresh all portlets in a page unnecessarily. For more information about this you can see the following articles: http://developers.sun.com/prodtech/portalserver/reference/techart/asynch_rendering.html http://blogs.sun.com/gregz/entry/ajaxportlet_updates#comments http://developers.sun.com/prodtech/portalserver/reference/techart/ajax-portlets.html Arash Rajaeeyan On 10/23/06, Scott O'Bryan [EMAIL PROTECTED] wrote: We discussed this in 10.1.3 about how there is no guarantee that the cleanup will happen if the life cycle is short-circuited.plus we would need a bunch of touch-points. We would need listeners on the following: 1. Initialize before Restore Component Tree 2. Cleanup after Process Events only when Response Complete or Render Response is the next phase 3. Cleanup after Process Events only when Response Complete or Render Response is the next phase. 4. Cleanup after Process Events only when Response Complete or Render Response is the next phase 5. Cleanup after Process Events 2 6. Initialize before Reader Response 7. Cleanup after Reader Response It would be far easier to run the execution code at the beginning and end of the LifeCycle's execute method and at the beginning and end of the lifecycle's render method just to make sure we hit all the touch points. Also, some of the cleanup above (ie. cleaning up before Render Response and then reinitializing could be optimized, but do remember that in the portal, each portlet can recieve multiple render-requests for each action request. So the TrinidadFacesContext object should be the same between those calls to render-request. I've just added some code in 10.1.3 that was causing issues with this and process scope. Of course when dealing with servlets, this all becomes trivial. Now that being said, if you still think LifeCycle listeners are the way to go, I would be happy to explore that option. I know this is the type of stuff that LifeCycle listeners were designed for, but I also know there was a reason that Trinidad used filters instead of lifecycle listeners before. Eliminating the need for filters altogether would be a good thing. Scott Adam Winer wrote: On 10/20/06, Scott O'Bryan [EMAIL PROTECTED] wrote: My question is this, is there any reason we can't provide our own custom lifecycle object that decorates the default one and allows us to run our initialization code on the execute and render? If so, the code to manage things like the TrinidadFacesContext becomes a LOT easier and we can rely on some of the stuff already build in to the Bridge Portlets. What's the advantage of a custom lifecycle over using a phase listener? --Adam
Re: [PORTAL] Custom lifecycle?
Matthias, I think that's true as well. There is no guaranteed order for phase listeners and whatnot. Ideally our initialization needs to happen before other phase listeners run. Scott Matthias Wessendorf wrote: Just a question regarding this: -Isn't it the case that you can't specifiy a *chaining* for PhaseListeners? Only like _a.jar b.jar z_myfaces.jar So when you register 5 for Phase #1 you can have issues with that, right ? At least when one of the PhaseListeners in front your yours does something wrong/ugly? My understanding to a custom lifecycle is that it doesn't bother with the *regular* Lifecycle's PhaseListeners. Thanks, Matthias On 10/22/06, Adam Winer [EMAIL PROTECTED] wrote: On 10/20/06, Scott O'Bryan [EMAIL PROTECTED] wrote: My question is this, is there any reason we can't provide our own custom lifecycle object that decorates the default one and allows us to run our initialization code on the execute and render? If so, the code to manage things like the TrinidadFacesContext becomes a LOT easier and we can rely on some of the stuff already build in to the Bridge Portlets. What's the advantage of a custom lifecycle over using a phase listener? --Adam
[PORTAL] Custom lifecycle?
Hey everyone, I'm going to be starting the portlet work on this starting next week. Yes, they are actually paying me to fix this stuff :)... So I was going over some of my strategies for doing some of this work. One of the major problems with using Trinidad with a portal environment are filters. In Trinidad our filters do several things, among them are: * Creation of the TrinidadFacesContext object * Handling of File Uploads * Some other junk that I don't remember :) So, FileUploads and things that need request/response wrappers we're looking at handling those through extending our FacesContext. Tomahawk has some code to do this and I'm either going to try to leverage that or come up with something similar. So that badness is out of the way. For the other stuff, essentially what we need is something that executes before and after the execute and render methods on the lifecycle. In ADFFaces 10.1.3.1 (Trinidad's Portalized Predicessor) this was done by adding an enhancement to the Faces Bridge Portlet which was, essentially, a lifecycle listener that called our initialization code before and after the call to the Lifecycle methods. My question is this, is there any reason we can't provide our own custom lifecycle object that decorates the default one and allows us to run our initialization code on the execute and render? If so, the code to manage things like the TrinidadFacesContext becomes a LOT easier and we can rely on some of the stuff already build in to the Bridge Portlets. Scott
Re: who is in charge for JSR 301?
Arash, Is this the multi-part form ExternalContext or the much simplified pre/post lifecycle stuff? Scott Arash Rajaeeyan wrote: thank you Carsten, you may have seen the portlet patch of shinsuke for tomahawk, we (me and some other developers) want to do polish this patch and do similar thing for trindad and tobago. it will be great if we can have one soloution working for all components under myfaces umbrella and may be even other components. it looks like this target of JSR 301 as an exprienced member of this group, do you have any guidelines for us? On 10/12/06, Carsten Ziegeler [EMAIL PROTECTED] wrote: Yes, I'm in the spec group - but upto now I don't know who else from Apache is on. Carsten Matthias Wessendorf wrote: 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. -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Trinidad on JDK 1.4
Unfortunately I don't know the release date. Should be available fairly soon I would imagine. I can try to check for you. I ALSO believe that it'll run in 1.4 and 1.5. I know the system is built in 1.4 anyway, but oracle QA's generally test it in 1.5. Don't get me wrong, I don't want to discourage you from using Trinidad. It is, essentially, the latest and greatest. It just doesn't yet have the portal stuff in it and is and will continue to become more JDK 1.5 centric. Scott Bruno Bernard wrote: Scott, you are right, i was using com.liferay.util.jsf.apache.myfaces.context.MyFacesContextFactoryImpl. I tried to switch it to org.apache.myfaces.context.FacesContextFactoryImpl and it still worked but as soon as I switched to the Trinidad's FacesContextFactory i got the class cast exception. I guess I will need to do more investigation/learning and look at what you have plan to fix in Trinidad and try to help. As of ADFFaces 10.1.3.2. Any ideas when it will be released (even early access)? Is it going to support JDK 1.4. Thanks, Bruno
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: 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.
[Jira] Portlet Issue
I added seven issues to the Trinidad Portlet component in Jira and one to the MyFaces Portlet_Support component. That should get us started. We'll have to have MYFACES-1448, MYFACES-1383, and ADFFACES-234 done before we can start, however. I do have a fix for MYFACES-1383, but it needs some testing. Hopefully I'll be able to check it in soon. Scott
Re: [Jira] Portlet Issue
Or submit it soon rather. Scott O'Bryan wrote: I added seven issues to the Trinidad Portlet component in Jira and one to the MyFaces Portlet_Support component. That should get us started. We'll have to have MYFACES-1448, MYFACES-1383, and ADFFACES-234 done before we can start, however. I do have a fix for MYFACES-1383, but it needs some testing. Hopefully I'll be able to check it in soon. Scott
Re: [Jira] Portlet Issue
To answer Mitthias, I'm going to be testing against Pluto and Oracle's
WSRP. I *MAY* add Gridsphere to the test since it's Websphere like.
Now, Arash, you are replying to a different issue. I noticed that
Tomahawk has added support for PortletFilters and I guess I jumped the
gun on wanting to use it. By removing dependencies on the wapper
objects in the filters, we can remove any dependency we have on the
implementation of the particular portal for now. Perhaps we may even
have to depend on our own bridge portlet which (like tomahawk) is
derived off of the MyFaces Bridge. The things that concerns me is that
never will the two run together in a portal environment if we do this.
I have a requirement to allow this stuff to run in a WSRP container
which is more like type 2 of your scenario. Therefore, I am flat
against using an implied implementation (like taking advantage of the
fact that WebSphere wraps httpServletRequest/Response objects. I
*don't* mind providing an interface with various adapters (for each
portal maybe) that could implement these wrapper objects as hopefully
well have something similar in the spec in a year or so.
That being said, while LifeRay is not of the first type you recomended,
someone familiar with the system should be able to provide a wrapper
object for LifeRay's PortletRequest implementation object.
Scott
Arash Rajaeeyan wrote:
there two kind of portals
some use Servlet classes as a base for Portlet and other Portlet Classes,
and subclasses classes like PortletRequest from HttpServletRequest.
some develop Portlet classes from scratch.
lots of problems arise in second type of portlet API implementation which
the Portlet classes can not be casted to Servlet classes.
IBM websphere is from first kind.
Liferay is second type.
pluto is some thing between:
package org.apache.pluto.internal.impl;
public abstract class PortletRequestImpl extends
HttpServletRequestWrapper
implements PortletRequest, InternalPortletRequest {
as you see they have subclasses HttpServletRequestWrapper
so they have all methods of HttpServlet
so I think its better that we don't test portlet patch implementation on
pluto.
On 10/10/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Scott,
testing against Pluto (Portlet RI)?
-M
On 10/10/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
I added seven issues to the Trinidad Portlet component in Jira and one
to the MyFaces Portlet_Support component. That should get us started.
We'll have to have MYFACES-1448, MYFACES-1383, and ADFFACES-234 done
before we can start, however.
I do have a fix for MYFACES-1383, but it needs some testing.
Hopefully
I'll be able to check it in soon.
Scott
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: [Jira] Portlet Issue
Yeah, that was my origonal thought. I'll reopen MYFACES-1448 which is a
task to do just that. All we need is something simple to do the
Non-Wrapper initialization code. It would need an init and a
destroy as well as a pre-lifecycle and post-lifecycle call, but these
could be done with the PortletContext, PortletRequest/Response classes.
As for the wrappers, you get me wrong. I'm not wanting to tie myself to
HttpServlet stuff at all. Here is my theory about moving the
functionality of the wrapper objects to our existing ExternalContext
wrapper.
If we have an HttpServletRequest/Response then we can simply use the
provided wrapper objects. If we don't then we would need to get the
original request object and ExternalContext and wrap them overriding
only the functionality we need to. The wrapped external context would
return a wrapped PortletRequest/PortletResponse/PortletContext object of
the appropriate (Action or Render) type. For dispatching your wrapper
simply need to take the provided object's wrapped object and pass it
into the superclass. Therefore, the external context references a
wrapped PortletRequest and Response as well as it's underlying
implementation. We'd have to be a bit careful when the objects switch
from ActionRequests to RenderRequests, but this should be pretty easy to
do. This would allow us to create wrapper objects without actually
having them supported by JSR-168 or the need to cast to HttpServlet stuff.
Does this make sense?
Arash Rajaeeyan wrote:
Hi scott,
my post was generally about portlet support.
you are right the second type method can be fixed by a wrapper which
implements HttpServlet and wraps Portlet.
I prefer to use a method which works in all portals JSR168, or WSRP
and even
in future JSR 286, if some solution works for second type (Not Drived
Classes from HttpServlet) of portals it will work for first type (Drived
Portlet classes from HttpServlet)
I will test every thing with both kind of portals to make sure they both
work fine.
may be we can modify that MyFaces Bridge and add what ever we need to
support trinidad.
trindidad and tomahawk are both under myfaces, and many people including
myself are using both set of components.
On 10/10/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
To answer Mitthias, I'm going to be testing against Pluto and Oracle's
WSRP. I *MAY* add Gridsphere to the test since it's Websphere like.
Now, Arash, you are replying to a different issue. I noticed that
Tomahawk has added support for PortletFilters and I guess I jumped the
gun on wanting to use it. By removing dependencies on the wapper
objects in the filters, we can remove any dependency we have on the
implementation of the particular portal for now. Perhaps we may even
have to depend on our own bridge portlet which (like tomahawk) is
derived off of the MyFaces Bridge. The things that concerns me is that
never will the two run together in a portal environment if we do this.
I have a requirement to allow this stuff to run in a WSRP container
which is more like type 2 of your scenario. Therefore, I am flat
against using an implied implementation (like taking advantage of the
fact that WebSphere wraps httpServletRequest/Response objects. I
*don't* mind providing an interface with various adapters (for each
portal maybe) that could implement these wrapper objects as hopefully
well have something similar in the spec in a year or so.
That being said, while LifeRay is not of the first type you recomended,
someone familiar with the system should be able to provide a wrapper
object for LifeRay's PortletRequest implementation object.
Scott
Arash Rajaeeyan wrote:
there two kind of portals
some use Servlet classes as a base for Portlet and other Portlet
Classes,
and subclasses classes like PortletRequest from HttpServletRequest.
some develop Portlet classes from scratch.
lots of problems arise in second type of portlet API implementation
which
the Portlet classes can not be casted to Servlet classes.
IBM websphere is from first kind.
Liferay is second type.
pluto is some thing between:
package org.apache.pluto.internal.impl;
public abstract class PortletRequestImpl extends
HttpServletRequestWrapper
implements PortletRequest, InternalPortletRequest {
as you see they have subclasses HttpServletRequestWrapper
so they have all methods of HttpServlet
so I think its better that we don't test portlet patch
implementation on
pluto.
On 10/10/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Scott,
testing against Pluto (Portlet RI)?
-M
On 10/10/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
I added seven issues to the Trinidad Portlet component in Jira and
one
to the MyFaces Portlet_Support component. That should get us
started.
We'll have to have MYFACES-1448, MYFACES-1383, and ADFFACES-234
done
before we can start, however.
I do have a fix for MYFACES-1383, but it needs some testing
Public API's not part of JSF
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: [Jira] adding new category/component for Portlet ?
Arash, I'll get some JIRA tasks loaded up for this and you can have at it. We're going to need to make some enhancements to the bridge as well and we might need to have a Trinidad bridge which derives off the Generic Bridge in MyFaces to handle some of the special cases that we can't handle until the JSR-286 is release. There are, however, tons of housekeeping things we need to do as well in order to get things ready. Any help you can give would be much appreciated. I would be interested in understanding how you solved PPR and Filter issue in Tomahawk as well. Scott Adam Winer wrote: That'd be excellent. I know there's also some internal work at Oracle on ADF Faces that should apply to Trinidad - I'll ping the developer about that. -- Adam On 10/6/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: I was volunteer to work on tomahawk portal which looks shinsuke has solved it (at least for my test on liferay) now if you open some thing for trinidad I am volunteer to start working on it. On 10/6/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi Can we open up a component for Portal in the JIRA for Trinidad? (I have no access to that, Martin? Craig?) Thx, Matthias -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Arash Rajaeeyan
Re: Trinidad on JDK 1.4
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.
