[jira] [Commented] (PORTLETBRIDGE-192) Proposal for 3.0 API: javax.portlet.faces.context.BridgeContext and associated BridgeContextFactory

2011-05-09 Thread Michael Freedman (JIRA)

[ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13030805#comment-13030805
 ] 

Michael Freedman commented on PORTLETBRIDGE-192:


Alexandr -- it looks like you are commenting on Neil's APIs as the above 
doesn't fully describe the set of APIs I have proposed/started to put into use. 
 Could you repost comments pertaining to the APIs that are in the refactored 
code?

As to your points:
1) PortletContext, Request/Response are included in the API because there is a 
short period of time between when the controller is invoked (with a 
BridgeContext) and when it acquires a FacesContext (and if a nonFaces resource 
it never acquires one).  These APIs allow the controller access to these 
portlet objects before they are exposed in Faces.

2) Do we really need another threadlocal (and what do we gain by having one)?  
95%+ of the time we will need to acquire the BridgeContext we will either have 
or also need to acquire the FacesContext.  I had been planning on adding the 
BridgeContext to the FacesContext scope and let extensions/etc. access it there 
as needed.  The only real thing running outside the FacesContext is the 
controller which is passed the BridgeContext explicitly.

3) default viewId's and PortletConfig are in the BridgeConfig

4) Whether or not we have setter methods to allow for object initialization 
(somewhat) depends on the APIs you come up with for the factories.  If the 
factories cleanly allow for this type of object initialization and allows us to 
easily extend add new initialization 'attributes in the future then you are 
right there is no need to have the set methods.  I included them so as we have 
to support new features in Faces that require additional config/context -- it 
is easy to add a get/set method and have the code using the factory updated to 
do the additional initialization call.

 Proposal for 3.0 API: javax.portlet.faces.context.BridgeContext and 
 associated BridgeContextFactory
 ---

 Key: PORTLETBRIDGE-192
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-192
 Project: MyFaces Portlet Bridge
  Issue Type: New Feature
  Components: General
Affects Versions: 3.0.0
Reporter: Neil Griffin
Assignee: Michael Freedman

 This class contains contextual information related to the bridge. It is 
 inherently request scoped, and is useful for sharing data between 
 implementations of Bridge.java and ExternalContext.java
 Please refer to the following classes for this proposal: 
 http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/context/BridgeContext.java
 http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/context/BridgeContextFactory.java

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (PORTLETBRIDGE-192) Proposal for 3.0 API: javax.portlet.faces.context.BridgeContext and associated BridgeContextFactory

2011-05-06 Thread Neil Griffin (JIRA)

[ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13029877#comment-13029877
 ] 

Neil Griffin commented on PORTLETBRIDGE-192:


Regarding #1, #2, and #4: Sounds fine, I could go either way.

Regarding #3: I've implemented BridgeContext and BridgeConfig and found that 
the getPortletConfig() and getDefaultViewIdMap() belong on BridgeContext. This 
is because BridgeContext contains information about the current portlet-name 
from portlet.xml, since more than one portlet can be defined in portlet.xml. 
When I had those methods on BridgeConfig, I found that 
BridgeConfig.getPortletConfig() didn't know which portlet-name to work with, 
since it is didn't know what the current portlet was. For example, getting 
context-param values.


 Proposal for 3.0 API: javax.portlet.faces.context.BridgeContext and 
 associated BridgeContextFactory
 ---

 Key: PORTLETBRIDGE-192
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-192
 Project: MyFaces Portlet Bridge
  Issue Type: New Feature
  Components: General
Affects Versions: 3.0.0
Reporter: Neil Griffin
Assignee: Michael Freedman

 This class contains contextual information related to the bridge. It is 
 inherently request scoped, and is useful for sharing data between 
 implementations of Bridge.java and ExternalContext.java
 Please refer to the following classes for this proposal: 
 http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/context/BridgeContext.java
 http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/context/BridgeContextFactory.java

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (PORTLETBRIDGE-192) Proposal for 3.0 API: javax.portlet.faces.context.BridgeContext and associated BridgeContextFactory

2011-05-06 Thread Alexandr Smirnov (JIRA)

[ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13030089#comment-13030089
 ] 

Alexandr Smirnov commented on PORTLETBRIDGE-192:


Way, ther's a good point about BridgeConfig scope. I supposed that BridgeConfig 
should contain per-portlet configuration, including portlet name, standard and 
extended options and so on. Moving all of them into context seems as overkill.
So, we have three scopes of information: request scope, including portlet 
state, viewId, redirect parameters and request type, portlet scoped : view 
portlet name, config, per-portlet options and application-wide parameters.
I suggest to have different objects for every scope: BridgeContext for current 
request state, BridgeConfig that's really contains current portlet 
configuration, and some for application-wide options - BridgeApplicationConfig 
?.
Ther are not a lot of options at application scope, so they could be put into 
BridgeConfig too.
P.S. In the Jboss bridge, BridgeImpl actually implements BridgeConfig interface 
tha's available via custom BridgeContext.

 Proposal for 3.0 API: javax.portlet.faces.context.BridgeContext and 
 associated BridgeContextFactory
 ---

 Key: PORTLETBRIDGE-192
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-192
 Project: MyFaces Portlet Bridge
  Issue Type: New Feature
  Components: General
Affects Versions: 3.0.0
Reporter: Neil Griffin
Assignee: Michael Freedman

 This class contains contextual information related to the bridge. It is 
 inherently request scoped, and is useful for sharing data between 
 implementations of Bridge.java and ExternalContext.java
 Please refer to the following classes for this proposal: 
 http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/context/BridgeContext.java
 http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/context/BridgeContextFactory.java

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (PORTLETBRIDGE-192) Proposal for 3.0 API: javax.portlet.faces.context.BridgeContext and associated BridgeContextFactory

2011-05-05 Thread Alexandr Smirnov (JIRA)

[ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13029606#comment-13029606
 ] 

Alexandr Smirnov commented on PORTLETBRIDGE-192:


There are my opinion:
1) To keep BridgeContext smaller, do not put information that available by 
other API there: Context, Request and Response objects etc.
2) Make BridgeContext as an abstract class with ThreadLocal instance variable, 
similar to the FacesContext. BridgeContext should be created before 
FacesContext and released after that.
3) put default view id's belong to the BridgeConfig

 Proposal for 3.0 API: javax.portlet.faces.context.BridgeContext and 
 associated BridgeContextFactory
 ---

 Key: PORTLETBRIDGE-192
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-192
 Project: MyFaces Portlet Bridge
  Issue Type: New Feature
  Components: General
Affects Versions: 3.0.0
Reporter: Neil Griffin
Assignee: Michael Freedman

 This class contains contextual information related to the bridge. It is 
 inherently request scoped, and is useful for sharing data between 
 implementations of Bridge.java and ExternalContext.java
 Please refer to the following classes for this proposal: 
 http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/context/BridgeContext.java
 http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/context/BridgeContextFactory.java

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira