Basically I try to say is that when you want to be able to personalize your component, you should go for portlets because they have a personalization framework that comes with the JSR 168/286 standard. You can easily add parameters and let users personalize them. We looked for such a feature in taskflows and it was limited to ADF Faces components that are personalizable like tables were users can choose what columns to show and so. Andrejus told in another topic ( https://groups.google.com/group/webcenter-emg/browse_thread/thread/be...) that it is possible to use the MDS to store other personalization, however this needs some custom coding…
Another issue between portlets and taskflows is security. Although this is also discussed in another topic, it seems that we can map ADF enterprise roles to J2EE roles and use them in the portlets.
One of the biggest issues I currently see for portlets is that they are rendered in an iframe. This gives lots of rendering issues when you have rich portlets with content that is not static. When you use popups in portlets, they are rendered in the iframe so if your popup is bigger than the portlet, scrollbars show up instead of a resizing of the portlets.
Based upon all this, or other differences, what made you decide to choose for portlets or taskflows?
In a project I have done I had to make the comparison between portlets and taskflows . At the end we decided to go for portlets because we wanted to provide the users a high level of personalization. Although we knew that we needed to be very careful for the layout and usage of popups, taskflows brought a bigger risk than this… We experimented a lot for creating a framework to build in personalization on taskflow but we didn’t succeed. Not even with some help from Oracle…
Another thing that convinced us to use portlets was that other portals were built on Oracle Portal 10g, soon to be upgraded to 11g. When we create taskflows, Oracle portal could not use them, when we create portlets, oracle portal could consume them using WSRP.
It would be nice to start a discussion about portlets vs taskflows. Seems like a nice one J Would love to hear some input from Oracle on this…
Yannick, One of the primary advantages of portlets over task flows is application extensibility - its very easy to add new portlet producers to an existing, deployed application without bouncing the servers. Its a little more difficult if you want to add new task flows...especially if you didn't plan for it when you created your application. This is because task flows need to be included in the application classpath whereas portlets do not. Portlets can also be more easily shared among multiple applications.
> Basically I try to say is that when you want to be able to personalize your component, you should go for portlets because they have a personalization framework that comes with the JSR 168/286 standard. You can easily add parameters and let users personalize them. > We looked for such a feature in taskflows and it was limited to ADF Faces components that are personalizable like tables were users can choose what columns to show and so. > Andrejus told in another topic (https://groups.google.com/group/webcenter-emg/browse_thread/thread/be...) that it is possible to use the MDS to store other personalization, however this needs some custom coding�
> Another issue between portlets and taskflows is security. Although this is also discussed in another topic, it seems that we can map ADF enterprise roles to J2EE roles and use them inthe portlets.
> One of the biggest issues I currently see for portlets is that they are rendered in an iframe. This gives lots of rendering issues when you have rich portlets with content that is not static. When you use popups in portlets, they are rendered in the iframe so if your popup is bigger than the portlet, scrollbars show up instead of a resizing of the portlets.
> Based upon all this, or other differences, what made you decide to choose for portlets or taskflows?
> In a project I have done I had to make the comparison between portlets and taskflows . At the end we decided to go for portlets because we wanted to provide the users a high level of personalization. Although we knew that we needed to be very careful for the layout and usage of popups, taskflows brought a bigger risk than this� We experimented a lot for creating a framework to build in personalization on taskflow but we didn�t succeed. Not even with some help from Oracle�
> Another thing that convinced us to use portlets was that other portals were built on Oracle Portal 10g, soon to be upgraded to 11g. When we create taskflows, Oracle portal could not use them, when we create portlets, oracle portal could consume them using WSRP.
> It would be nice to start a discussion about portlets vs taskflows. Seems like a nice one J > Would love to hear some input from Oracle on this�
> Regards > Yannick
> -- > You received this message because you are subscribed to the WebCenter Enterprise Methodology Group (http://groups.google.com/group/webcenter-emg). To unsubscribe send email to webcenter-emg+unsubscribe@googlegroups.com
> Yannick, > One of the primary advantages of portlets over task flows is > application extensibility - its very easy to add new portlet producers to an > existing, deployed application without bouncing the servers. Its a little > more difficult if you want to add new task flows...especially if you didn't > plan for it when you created your application. This is because task flows > need to be included in the application classpath whereas portlets do not. > Portlets can also be more easily shared among multiple applications.
> Chris
> On 1/27/2011 8:48 AM, Yannick Ongena wrote:
> I was not really thinking on creating such a topic but because something > Maiko said, I wanted to start this discussion…
> Since the beginning of WebCenter 11g I was intrigued by the difference > between portlets and taskflows and how to position them in a portal.
> Basically I try to say is that when you want to be able to personalize your > component, you should go for portlets because they have a personalization > framework that comes with the JSR 168/286 standard. You can easily add > parameters and let users personalize them. > We looked for such a feature in taskflows and it was limited to ADF Faces > components that are personalizable like tables were users can choose what > columns to show and so. > Andrejus told in another topic ( > https://groups.google.com/group/webcenter-emg/browse_thread/thread/be...) > that it is possible to use the MDS to store other personalization, > however this needs some custom coding…
> Another issue between portlets and taskflows is security. Although this is > also discussed in another topic, it seems that we can map ADF enterprise > roles to J2EE roles and use them in the portlets.
> One of the biggest issues I currently see for portlets is that they are > rendered in an iframe. This gives lots of rendering issues when you have > rich portlets with content that is not static. When you use popups in > portlets, they are rendered in the iframe so if your popup is bigger than > the portlet, scrollbars show up instead of a resizing of the portlets.
> Based upon all this, or other differences, what made you decide to choose > for portlets or taskflows?
> In a project I have done I had to make the comparison between portlets and > taskflows . At the end we decided to go for portlets because we wanted to > provide the users a high level of personalization. Although we knew that we > needed to be very careful for the layout and usage of popups, taskflows > brought a bigger risk than this… We experimented a lot for creating a > framework to build in personalization on taskflow but we didn’t succeed. Not > even with some help from Oracle…
> Another thing that convinced us to use portlets was that other portals were > built on Oracle Portal 10g, soon to be upgraded to 11g. When we create > taskflows, Oracle portal could not use them, when we create portlets, oracle > portal could consume them using WSRP.
> It would be nice to start a discussion about portlets vs taskflows. Seems > like a nice one J > Would love to hear some input from Oracle on this…
> Regards > Yannick > -- > You received this message because you are subscribed to the WebCenter > Enterprise Methodology Group (http://groups.google.com/group/webcenter-emg). > To unsubscribe send email to webcenter-emg+unsubscribe@googlegroups.com
> -- > Chris Broadbent| Consulting Member of Technical Staff | 540 687 6216 > Oracle Server Technologies > 1900 Oracle Way, Reston VA 20190
> -- > You received this message because you are subscribed to the WebCenter > Enterprise Methodology Group (http://groups.google.com/group/webcenter-emg). > To unsubscribe send email to webcenter-emg+unsubscribe@googlegroups.com<webcenter-emg%2Bunsubscribe@goog legroups.com>
Portlets are slower because there is a lot of overhead because of the WSRP standard. I really don't get why portlets deployed on the same server should be accessed by WSRP.
If you look at other J2EE portals, they all deploy portlets on the same server and they use it directly without using WSRP.
It's good that webcenter (and other portals) support WSRP but I find it weird that it is used for "local" portlets.
Yannick
From: Andrejus Baranovskis [mailto:andrejus.baranovs...@gmail.com] Sent: donderdag 27 januari 2011 19:08 To: webcenter-emg@googlegroups.com Cc: Yannick Ongena Subject: Re: [WebCenter EMG] Portlets vs Taskflows
Hi,
But from other side - portlets are slower and can't provide same interface richness as Task Flows :)
Andrejus
On 27 January 2011 15:24, Chris Broadbent <chris.broadb...@oracle.com> wrote:
Yannick, One of the primary advantages of portlets over task flows is application extensibility - its very easy to add new portlet producers to an existing, deployed application without bouncing the servers. Its a little more difficult if you want to add new task flows...especially if you didn't plan for it when you created your application. This is because task flows need to be included in the application classpath whereas portlets do not. Portlets can also be more easily shared among multiple applications.
Chris
On 1/27/2011 8:48 AM, Yannick Ongena wrote:
I was not really thinking on creating such a topic but because something Maiko said, I wanted to start this discussion.
Since the beginning of WebCenter 11g I was intrigued by the difference between portlets and taskflows and how to position them in a portal.
Basically I try to say is that when you want to be able to personalize your component, you should go for portlets because they have a personalization framework that comes with the JSR 168/286 standard. You can easily add parameters and let users personalize them. We looked for such a feature in taskflows and it was limited to ADF Faces components that are personalizable like tables were users can choose what columns to show and so. Andrejus told in another topic ( <https://groups.google.com/group/webcenter-emg/browse_thread/thread/be... a37201b3> https://groups.google.com/group/webcenter-emg/browse_thread/thread/be... 37201b3) that it is possible to use the MDS to store other personalization, however this needs some custom coding.
Another issue between portlets and taskflows is security. Although this is also discussed in another topic, it seems that we can map ADF enterprise roles to J2EE roles and use them in the portlets.
One of the biggest issues I currently see for portlets is that they are rendered in an iframe. This gives lots of rendering issues when you have rich portlets with content that is not static. When you use popups in portlets, they are rendered in the iframe so if your popup is bigger than the portlet, scrollbars show up instead of a resizing of the portlets.
Based upon all this, or other differences, what made you decide to choose for portlets or taskflows?
In a project I have done I had to make the comparison between portlets and taskflows . At the end we decided to go for portlets because we wanted to provide the users a high level of personalization. Although we knew that we needed to be very careful for the layout and usage of popups, taskflows brought a bigger risk than this. We experimented a lot for creating a framework to build in personalization on taskflow but we didn't succeed. Not even with some help from Oracle.
Another thing that convinced us to use portlets was that other portals were built on Oracle Portal 10g, soon to be upgraded to 11g. When we create taskflows, Oracle portal could not use them, when we create portlets, oracle portal could consume them using WSRP.
It would be nice to start a discussion about portlets vs taskflows. Seems like a nice one J Would love to hear some input from Oracle on this.
Regards Yannick
-- You received this message because you are subscribed to the WebCenter Enterprise Methodology Group (http://groups.google.com/group/webcenter-emg). To unsubscribe send email to webcenter-emg+unsubscribe@googlegroups.com
-- Chris Broadbent| Consulting Member of Technical Staff | 540 687 6216 Oracle Server Technologies 1900 Oracle Way, Reston VA 20190
-- You received this message because you are subscribed to the WebCenter Enterprise Methodology Group (http://groups.google.com/group/webcenter-emg). To unsubscribe send email to webcenter-emg+unsubscribe@googlegroups.com <mailto:webcenter-emg%2Bunsubscribe@googlegroups.com>
Well, I'd define TaskFlows as "local portlets" - ok, I know that there are differences (personalization, etc.), but at the end of the day, that's what we could say in a simplified way. What I understand from what Chris is saying is that he wants something like WSIF and then abstract the where and what is being called, and then the plumbing would take care of short-circuiting everything to a local call...
... OR ...
... what if we could provide some cool WSRP features straight from Task Flows?
Interesting how the line between TFs and Portlets starts to blur even more. :-)
I've go a couple of beefs with Portlets. And I'm not speaking as an Oracle employee, these are my personal opinions.
I don't like remoteable UIs because.
1. It's hard to keep a consistent look and feel with heterogeneous portlet producers 2. Rendering either on iframe or inline still streams back data and markup mixed up. This uses more bandwidth and brings down performance 3. If you render on an iframe it is faster because the browser parallelizes the requests to the portlets, but then you have the issues brought up by Yannick. Conversely, if you render them inline you're limited by how JSF (in our case) renders the components sequentially - that means that during render it needs to wait for each portlet call to render the markup inline. 4. Security is harder to deal with, again, already brought up by Yannick 5. None of the most used consumer-facing, "old fashioned portals" like Yahoo, iGoogle, use portlets. What they have is much closer to a TaskFlow than to a Portlet
I'd much rather use Web Services, public APIs, or whatever you call them and build custom, good-looking, UIs targeted to my "gadget-like" UI needs. As for Preferences/Personalization, although you have the full power of MDS, all that you need is a back-end Preferences table that persists information that would be stored in memory (request, session, view scope whatever is your need) as a HashMap. No matter what, you still need to provide the personalization by reacting to the data selected by the user. Of course you'd be losing a lot of wiring provided OOTB for Portlets, and if this is the most critical or most common use case for you then by all means rely on Portlets for that.
[]s! Maiko
On Thu, Jan 27, 2011 at 4:27 PM, Yannick Ongena <yannick.ong...@gmail.com>wrote:
> Portlets are slower because there is a lot of overhead because of the WSRP > standard. I really don’t get why portlets deployed on the same server should > be accessed by WSRP.
> If you look at other J2EE portals, they all deploy portlets on the same > server and they use it directly without using WSRP.
> It’s good that webcenter (and other portals) support WSRP but I find it > weird that it is used for “local” portlets.
> But from other side - portlets are slower and can't provide same interface > richness as Task Flows :)
> Andrejus
> On 27 January 2011 15:24, Chris Broadbent <chris.broadb...@oracle.com> > wrote:
> Yannick, > One of the primary advantages of portlets over task flows is > application extensibility - its very easy to add new portlet producers to an > existing, deployed application without bouncing the servers. Its a little > more difficult if you want to add new task flows...especially if you didn't > plan for it when you created your application. This is because task flows > need to be included in the application classpath whereas portlets do not. > Portlets can also be more easily shared among multiple applications.
> Chris
> On 1/27/2011 8:48 AM, Yannick Ongena wrote:
> I was not really thinking on creating such a topic but because something > Maiko said, I wanted to start this discussion…
> Since the beginning of WebCenter 11g I was intrigued by the difference > between portlets and taskflows and how to position them in a portal.
> Basically I try to say is that when you want to be able to personalize your > component, you should go for portlets because they have a personalization > framework that comes with the JSR 168/286 standard. You can easily add > parameters and let users personalize them. > We looked for such a feature in taskflows and it was limited to ADF Faces > components that are personalizable like tables were users can choose what > columns to show and so. > Andrejus told in another topic ( > https://groups.google.com/group/webcenter-emg/browse_thread/thread/be...) > that it is possible to use the MDS to store other personalization, however > this needs some custom coding…
> Another issue between portlets and taskflows is security. Although this is > also discussed in another topic, it seems that we can map ADF enterprise > roles to J2EE roles and use them in the portlets.
> One of the biggest issues I currently see for portlets is that they are > rendered in an iframe. This gives lots of rendering issues when you have > rich portlets with content that is not static. When you use popups in > portlets, they are rendered in the iframe so if your popup is bigger than > the portlet, scrollbars show up instead of a resizing of the portlets.
> Based upon all this, or other differences, what made you decide to choose > for portlets or taskflows?
> In a project I have done I had to make the comparison between portlets and > taskflows . At the end we decided to go for portlets because we wanted to > provide the users a high level of personalization. Although we knew that we > needed to be very careful for the layout and usage of popups, taskflows > brought a bigger risk than this… We experimented a lot for creating a > framework to build in personalization on taskflow but we didn’t succeed. Not > even with some help from Oracle…
> Another thing that convinced us to use portlets was that other portals were > built on Oracle Portal 10g, soon to be upgraded to 11g. When we create > taskflows, Oracle portal could not use them, when we create portlets, oracle > portal could consume them using WSRP.
> It would be nice to start a discussion about portlets vs taskflows. Seems > like a nice one J > Would love to hear some input from Oracle on this…
> Regards > Yannick
> -- > You received this message because you are subscribed to the WebCenter > Enterprise Methodology Group (http://groups.google.com/group/webcenter-emg). > To unsubscribe send email to webcenter-emg+unsubscribe@googlegroups.com
> -- > Chris Broadbent| Consulting Member of Technical Staff | 540 687 6216<tel:+15406876216> > Oracle Server Technologies > 1900 Oracle Way, Reston VA 20190
> -- > You received this message because you are subscribed to the WebCenter > Enterprise Methodology Group (http://groups.google.com/group/webcenter-emg). > To unsubscribe send email to webcenter-emg+unsubscribe@googlegroups.com<webcenter-emg%2Bunsubscribe@goog legroups.com>
> -- > You received this message because you are subscribed to the WebCenter > Enterprise Methodology Group (http://groups.google.com/group/webcenter-emg). > To unsubscribe send email to webcenter-emg+unsubscribe@googlegroups.com<webcenter-emg%2Bunsubscribe@goog legroups.com>
I couldn't agree more about your personal opinions. I share your pain :) We also had these issues at a customer but still we developed portlets.
I see from other customers that it often happens that customers want to migrate from oracle portal to webcenter so one of their requirements is that we need to develop something that works on both because oracle portal and webcenter will be used together. Maybe you are right, if they provide a cool WSRP feature for taskflows, than we can plug in taskflows into portal... But wait their is... Portletize your application, right click a taskflow and create a portlet entry. But i don't think that is whay you meant... :p
I do think that if Oracle would provide a WSRP feature for TF's, we loose again a lot of the advantages of taskflows. When you use WSRP, the producer runs in its own container, has its own context and so on while taskflows currently share the context and security with the application. When using WSRP, this coupling will also be lost and we would have the same issues as we would with portlets.
It would be nice to see a build in framework (in ADF or WebCenter) for adding custom personalization parameters to taskflows. This would really blurs the line between TF's and portlets.
With the JSR 286 standard it even gets easier to wire portlets together. In WebCenter 11g PS2 you had to wire the page parameters together, set partial triggers and so on. With JSR 286 you just need to put two portlets of the same provider on your page and that's it. Eat that taskflows...
On Thu, Jan 27, 2011 at 8:18 PM, Maiko Rocha <maiko.ro...@gmail.com> wrote: > Well, I'd define TaskFlows as "local portlets" - ok, I know that there are > differences (personalization, etc.), but at the end of the day, that's what > we could say in a simplified way. What I understand from what Chris is > saying is that he wants something like WSIF and then abstract the where and > what is being called, and then the plumbing would take care of > short-circuiting everything to a local call...
> ... OR ...
> ... what if we could provide some cool WSRP features straight from Task > Flows?
> Interesting how the line between TFs and Portlets starts to blur even more. > :-)
> I've go a couple of beefs with Portlets. And I'm not speaking as an Oracle > employee, these are my personal opinions.
> I don't like remoteable UIs because.
> 1. It's hard to keep a consistent look and feel with heterogeneous > portlet producers > 2. Rendering either on iframe or inline still streams back data and > markup mixed up. This uses more bandwidth and brings down performance > 3. If you render on an iframe it is faster because the browser > parallelizes the requests to the portlets, but then you have the issues > brought up by Yannick. Conversely, if you render them inline you're limited > by how JSF (in our case) renders the components sequentially - that means > that during render it needs to wait for each portlet call to render the > markup inline. > 4. Security is harder to deal with, again, already brought up by > Yannick > 5. None of the most used consumer-facing, "old fashioned portals" like > Yahoo, iGoogle, use portlets. What they have is much closer to a TaskFlow > than to a Portlet
> I'd much rather use Web Services, public APIs, or whatever you call them > and build custom, good-looking, UIs targeted to my "gadget-like" UI needs. > As for Preferences/Personalization, although you have the full power of MDS, > all that you need is a back-end Preferences table that persists information > that would be stored in memory (request, session, view scope whatever is > your need) as a HashMap. No matter what, you still need to provide the > personalization by reacting to the data selected by the user. Of course > you'd be losing a lot of wiring provided OOTB for Portlets, and if this is > the most critical or most common use case for you then by all means rely on > Portlets for that.
> []s! > Maiko
> On Thu, Jan 27, 2011 at 4:27 PM, Yannick Ongena <yannick.ong...@gmail.com>wrote:
>> Portlets are slower because there is a lot of overhead because of the >> WSRP standard. I really don’t get why portlets deployed on the same server >> should be accessed by WSRP.
>> If you look at other J2EE portals, they all deploy portlets on the same >> server and they use it directly without using WSRP.
>> It’s good that webcenter (and other portals) support WSRP but I find it >> weird that it is used for “local” portlets.
>> But from other side - portlets are slower and can't provide same interface >> richness as Task Flows :)
>> Andrejus
>> On 27 January 2011 15:24, Chris Broadbent <chris.broadb...@oracle.com> >> wrote:
>> Yannick, >> One of the primary advantages of portlets over task flows is >> application extensibility - its very easy to add new portlet producers to an >> existing, deployed application without bouncing the servers. Its a little >> more difficult if you want to add new task flows...especially if you didn't >> plan for it when you created your application. This is because task flows >> need to be included in the application classpath whereas portlets do not. >> Portlets can also be more easily shared among multiple applications.
>> Chris
>> On 1/27/2011 8:48 AM, Yannick Ongena wrote:
>> I was not really thinking on creating such a topic but because something >> Maiko said, I wanted to start this discussion…
>> Since the beginning of WebCenter 11g I was intrigued by the difference >> between portlets and taskflows and how to position them in a portal.
>> Basically I try to say is that when you want to be able to personalize >> your component, you should go for portlets because they have a >> personalization framework that comes with the JSR 168/286 standard. You can >> easily add parameters and let users personalize them. >> We looked for such a feature in taskflows and it was limited to ADF Faces >> components that are personalizable like tables were users can choose what >> columns to show and so. >> Andrejus told in another topic ( >> https://groups.google.com/group/webcenter-emg/browse_thread/thread/be...) >> that it is possible to use the MDS to store other personalization, however >> this needs some custom coding…
>> Another issue between portlets and taskflows is security. Although this is >> also discussed in another topic, it seems that we can map ADF enterprise >> roles to J2EE roles and use them in the portlets.
>> One of the biggest issues I currently see for portlets is that they are >> rendered in an iframe. This gives lots of rendering issues when you have >> rich portlets with content that is not static. When you use popups in >> portlets, they are rendered in the iframe so if your popup is bigger than >> the portlet, scrollbars show up instead of a resizing of the portlets.
>> Based upon all this, or other differences, what made you decide to choose >> for portlets or taskflows?
>> In a project I have done I had to make the comparison between portlets and >> taskflows . At the end we decided to go for portlets because we wanted to >> provide the users a high level of personalization. Although we knew that we >> needed to be very careful for the layout and usage of popups, taskflows >> brought a bigger risk than this… We experimented a lot for creating a >> framework to build in personalization on taskflow but we didn’t succeed. Not >> even with some help from Oracle…
>> Another thing that convinced us to use portlets was that other portals >> were built on Oracle Portal 10g, soon to be upgraded to 11g. When we create >> taskflows, Oracle portal could not use them, when we create portlets, oracle >> portal could consume them using WSRP.
>> It would be nice to start a discussion about portlets vs taskflows. Seems >> like a nice one J >> Would love to hear some input from Oracle on this…
>> Regards >> Yannick
>> -- >> You received this message because you are subscribed to the WebCenter >> Enterprise Methodology Group ( >> http://groups.google.com/group/webcenter-emg). To unsubscribe send email >> to webcenter-emg+unsubscribe@googlegroups.com
>> -- >> Chris Broadbent| Consulting Member of Technical Staff | 540 687 6216<tel:+15406876216> >> Oracle Server Technologies >> 1900 Oracle Way, Reston VA 20190
>> -- >> You received this message because you are subscribed to the WebCenter >> Enterprise Methodology Group ( >> http://groups.google.com/group/webcenter-emg). To unsubscribe send email >> to webcenter-emg+unsubscribe@googlegroups.com<webcenter-emg%2Bunsubscribe@goog legroups.com>
In terms of design, this is the biggest limitation of portlets that
I've encountered - sometimes you want to have a popup or some kind of
summary that doesn't open new windows or navigate the user away from
the main page.
So far, that need for modal windows has been the biggest driver behind
choosing to use taskflows over portlets for some functionality.
On Jan 27, 7:48 am, Yannick Ongena <yannick.ong...@gmail.com> wrote:
> One of the biggest issues I currently see for portlets is that they are
> rendered in an iframe. This gives lots of rendering issues when you have
> rich portlets with content that is not static. When you use popups in
> portlets, they are rendered in the iframe so if your popup is bigger than
> the portlet, scrollbars show up instead of a resizing of the portlets.
Agreed; this is a problem. Two points: 1) If you have a way to control the initial real estate of your portlet and you can make big enough for the biggest pop-up, you should be OK. 2) We have plans to provide inline portlet support for JSF Bridge porlets (ADF portlets) for WebCenter as the consumer. If we can hear more people's input/feedback on this issue, we may be able to prioritize this high(er).
On Wed, Feb 2, 2011 at 9:14 AM, Chad Thompson <chad_thomp...@mac.com> wrote: > In terms of design, this is the biggest limitation of portlets that > I've encountered - sometimes you want to have a popup or some kind of > summary that doesn't open new windows or navigate the user away from > the main page.
> So far, that need for modal windows has been the biggest driver behind > choosing to use taskflows over portlets for some functionality.
> On Jan 27, 7:48 am, Yannick Ongena <yannick.ong...@gmail.com> wrote:
> > One of the biggest issues I currently see for portlets is that they are > > rendered in an iframe. This gives lots of rendering issues when you have > > rich portlets with content that is not static. When you use popups in > > portlets, they are rendered in the iframe so if your popup is bigger than > > the portlet, scrollbars show up instead of a resizing of the portlets.
> -- > You received this message because you are subscribed to the WebCenter > Enterprise Methodology Group (http://groups.google.com/group/webcenter-emg). > To unsubscribe send email to webcenter-emg+unsubscribe@googlegroups.com<webcenter-emg%2Bunsubscribe@goog legroups.com>
Another point is dont exist documentation about how propagate the identity(user an roles) from an user logged in a webcenter application to a portlet producer. However with taskflows is in the ADF Security way.
Emmerson.
On Mon, Feb 7, 2011 at 6:58 AM, pmosk...@gmail.com <pmosk...@gmail.com>wrote:
> Agreed; this is a problem. > Two points: > 1) If you have a way to control the initial real estate of your portlet and > you can make big enough for the biggest pop-up, you should be OK. > 2) We have plans to provide inline portlet support for JSF Bridge porlets > (ADF portlets) for WebCenter as the consumer. If we can hear more people's > input/feedback on this issue, we may be able to prioritize this high(er).
> Peter
> On Wed, Feb 2, 2011 at 9:14 AM, Chad Thompson <chad_thomp...@mac.com>wrote:
>> In terms of design, this is the biggest limitation of portlets that >> I've encountered - sometimes you want to have a popup or some kind of >> summary that doesn't open new windows or navigate the user away from >> the main page.
>> So far, that need for modal windows has been the biggest driver behind >> choosing to use taskflows over portlets for some functionality.
>> On Jan 27, 7:48 am, Yannick Ongena <yannick.ong...@gmail.com> wrote:
>> > One of the biggest issues I currently see for portlets is that they are >> > rendered in an iframe. This gives lots of rendering issues when you have >> > rich portlets with content that is not static. When you use popups in >> > portlets, they are rendered in the iframe so if your popup is bigger >> than >> > the portlet, scrollbars show up instead of a resizing of the portlets.
>> -- >> You received this message because you are subscribed to the WebCenter >> Enterprise Methodology Group ( >> http://groups.google.com/group/webcenter-emg). To unsubscribe send email >> to webcenter-emg+unsubscribe@googlegroups.com
> -- > You received this message because you are subscribed to the WebCenter > Enterprise Methodology Group (http://groups.google.com/group/webcenter-emg). > To unsubscribe send email to webcenter-emg+unsubscribe@googlegroups.com
emmerson.mira...@gmail.com> wrote: > Another point is dont exist documentation about how propagate the > identity(user an roles) from an user logged in a webcenter application to a > portlet producer. However with taskflows is in the ADF Security way.
> Emmerson.
> On Mon, Feb 7, 2011 at 6:58 AM, pmosk...@gmail.com <pmosk...@gmail.com>wrote:
>> Agreed; this is a problem. >> Two points: >> 1) If you have a way to control the initial real estate of your portlet >> and you can make big enough for the biggest pop-up, you should be OK. >> 2) We have plans to provide inline portlet support for JSF Bridge porlets >> (ADF portlets) for WebCenter as the consumer. If we can hear more people's >> input/feedback on this issue, we may be able to prioritize this high(er).
>> Peter
>> On Wed, Feb 2, 2011 at 9:14 AM, Chad Thompson <chad_thomp...@mac.com>wrote:
>>> In terms of design, this is the biggest limitation of portlets that >>> I've encountered - sometimes you want to have a popup or some kind of >>> summary that doesn't open new windows or navigate the user away from >>> the main page.
>>> So far, that need for modal windows has been the biggest driver behind >>> choosing to use taskflows over portlets for some functionality.
>>> On Jan 27, 7:48 am, Yannick Ongena <yannick.ong...@gmail.com> wrote:
>>> > One of the biggest issues I currently see for portlets is that they are >>> > rendered in an iframe. This gives lots of rendering issues when you >>> have >>> > rich portlets with content that is not static. When you use popups in >>> > portlets, they are rendered in the iframe so if your popup is bigger >>> than >>> > the portlet, scrollbars show up instead of a resizing of the portlets.
>>> -- >>> You received this message because you are subscribed to the WebCenter >>> Enterprise Methodology Group ( >>> http://groups.google.com/group/webcenter-emg). To unsubscribe send email >>> to webcenter-emg+unsubscribe@googlegroups.com
>> -- >> You received this message because you are subscribed to the WebCenter >> Enterprise Methodology Group ( >> http://groups.google.com/group/webcenter-emg). To unsubscribe send email >> to webcenter-emg+unsubscribe@googlegroups.com
> -- > You received this message because you are subscribed to the WebCenter > Enterprise Methodology Group (http://groups.google.com/group/webcenter-emg). > To unsubscribe send email to webcenter-emg+unsubscribe@googlegroups.com
1) There is one other question I have about using Task Flows. It
relates to task flow returns and how they would work within WebCenter
spaces. A task flow return would essentially return the user to a
blank fragment within the portlet and this isn't the most pleasing of
user experiences. I would love to hear how others use task flows and
whether they use task flow returns at all. If we don't use task flow
returns, when/how does the page flow scope for that particular region
get released? Do the AMs and the DB connections that they hold get
released correctly?
2) There is a "bug" in Spaces that prevents propagation of the ADF BC
error messages from a task flow to the user. Instead the user gets an
"Irresolvable errors..." message. Rather than wait for Oracle to work
on the ER (10361072), I had to implement my own nasty workarounds to
get this to work.
--
Bijesh Krishnadas
On Feb 7, 8:54 pm, Yannick Ongena <yannick.ong...@gmail.com> wrote:
> On Mon, Feb 7, 2011 at 10:44 AM, Emmerson Miranda <
> emmerson.mira...@gmail.com> wrote:
> > Another point is dont exist documentation about how propagate the
> > identity(user an roles) from an user logged in a webcenter application to a
> > portlet producer. However with taskflows is in the ADF Security way.
> > Emmerson.
> > On Mon, Feb 7, 2011 at 6:58 AM, pmosk...@gmail.com <pmosk...@gmail.com>wrote:
> >> Agreed; this is a problem.
> >> Two points:
> >> 1) If you have a way to control the initial real estate of your portlet
> >> and you can make big enough for the biggest pop-up, you should be OK.
> >> 2) We have plans to provide inline portlet support for JSF Bridge porlets
> >> (ADF portlets) for WebCenter as the consumer. If we can hear more people's
> >> input/feedback on this issue, we may be able to prioritize this high(er).
> >> Peter
> >> On Wed, Feb 2, 2011 at 9:14 AM, Chad Thompson <chad_thomp...@mac.com>wrote:
> >>> In terms of design, this is the biggest limitation of portlets that
> >>> I've encountered - sometimes you want to have a popup or some kind of
> >>> summary that doesn't open new windows or navigate the user away from
> >>> the main page.
> >>> So far, that need for modal windows has been the biggest driver behind
> >>> choosing to use taskflows over portlets for some functionality.
> >>> On Jan 27, 7:48 am, Yannick Ongena <yannick.ong...@gmail.com> wrote:
> >>> > One of the biggest issues I currently see for portlets is that they are
> >>> > rendered in an iframe. This gives lots of rendering issues when you
> >>> have
> >>> > rich portlets with content that is not static. When you use popups in
> >>> > portlets, they are rendered in the iframe so if your popup is bigger
> >>> than
> >>> > the portlet, scrollbars show up instead of a resizing of the portlets.
> >>> --
> >>> You received this message because you are subscribed to the WebCenter
> >>> Enterprise Methodology Group (
> >>>http://groups.google.com/group/webcenter-emg). To unsubscribe send email
> >>> to webcenter-emg+unsubscribe@googlegroups.com
> >> --
> >> You received this message because you are subscribed to the WebCenter
> >> Enterprise Methodology Group (
> >>http://groups.google.com/group/webcenter-emg). To unsubscribe send email
> >> to webcenter-emg+unsubscribe@googlegroups.com
> > --
> > You received this message because you are subscribed to the WebCenter
> > Enterprise Methodology Group (http://groups.google.com/group/webcenter-emg).
> > To unsubscribe send email to webcenter-emg+unsubscribe@googlegroups.com
