You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-user@portals.apache.org by Jason Novotny <no...@aei.mpg.de> on 2003/12/11 14:10:32 UTC
concrete/application portlets
Hi,
Let's say I'm migrating some portlets developed with the IBM
WebSphere API which differerentiates between application portlet
definitions (of which there is one) and one or more concrete portlet
definitions which allow you to provide parameterized portlet instances.
My question is how can I refactor my portlets which use this model into
JSR compliant portlets which seem to only have the notion of an
application portlet? So for instance, before the PortletSettings object
provided per concrete portlet definition information, but now I guess I
don't have that. Any thoughts on the subject would be great-- having
looked at both API's, I'm still convinced the WebSphere API seems to
offer more functionality than the JSR does...
Thanks, Jason
Re: concrete/application portlets
Posted by Stefan Hepper <st...@hursley.ibm.com>.
Glenn,
sorry for another abbrevation, but yes it is the gang of four book.
Stefan
Glenn Golden wrote:
> Stefan -
>
> Thanks! Very clear. The GoF is "gang of four" is Gamma, Helm, Johnson
> and Vlissides, right? Just bought their book (rather their CD).
>
> Now to master the proper use of render params. and urls.
>
> - Glenn
>
> On Dec 12, 2003, at 11:43 AM, Stefan Hepper wrote:
>
>> Glenn,
>> the flyweight pattern utilizes an object instance with different data
>> per call instead of creating different object instances for these
>> different data. In the portlet model this is the case for portlets, as
>> for every user the request is submitted to the same portlet instance.
>> The configuration and personalization data that are user specific are
>> given to the portlet in the request via the portlet preferences. This
>> is exactly the flyweight pattern of the pattern book of the GoF.
>>
>> Stefan
>>
>> Glenn Golden wrote:
>>
>>> Stefan -
>>> I for one am not so clear on the rendering parameters, as you could
>>> tell from my recent inquires. I also don't know what you mean by
>>> "flyweight" for preferences.
>>> Any materials that would he me (us) understand these concepts better
>>> would be appreciated!
>>> Thanks.
>>> - Glenn
>>> On Dec 12, 2003, at 2:26 AM, Stefan Hepper wrote:
>>>
>>>> You need to create different JSR 168 portlet apps for all you
>>>> concrete WP apps and provide the settings via different deployment
>>>> descriptors. I agree that this is not as powerfull as the WP model,
>>>> however a standard needs to be simple at first and easy to
>>>> understand. I think the portlet specification is already complex
>>>> enough for people comming from the servlet world with the render
>>>> parameter concept, the portlet preferences flyweight pattern and
>>>> aggregation model. We've experienced that the portlet programmers
>>>> very often confused by the different layers abstract / concrete /
>>>> concrete instance that we have in the IBM WP API. Thus we wanted the
>>>> standard to be simpler and more easy to understand, which of cause
>>>> comes with the price of reduced functionality. Next versions of the
>>>> standard will provide additional functionality and therefore further
>>>> close the functional gap between the JSR 168 and IBM WP API.
>>>>
>>>> Stefan
>>>>
>>>> Jason Novotny wrote:
>>>>
>>>>> Hi,
>>>>> Let's say I'm migrating some portlets developed with the IBM
>>>>> WebSphere API which differerentiates between application portlet
>>>>> definitions (of which there is one) and one or more concrete
>>>>> portlet definitions which allow you to provide parameterized
>>>>> portlet instances. My question is how can I refactor my portlets
>>>>> which use this model into JSR compliant portlets which seem to only
>>>>> have the notion of an application portlet? So for instance, before
>>>>> the PortletSettings object provided per concrete portlet definition
>>>>> information, but now I guess I don't have that. Any thoughts on the
>>>>> subject would be great-- having looked at both API's, I'm still
>>>>> convinced the WebSphere API seems to offer more functionality than
>>>>> the JSR does...
>>>>> Thanks, Jason
>
>
>
Re: concrete/application portlets
Posted by Glenn Golden <gg...@umich.edu>.
Stefan -
Thanks! Very clear. The GoF is "gang of four" is Gamma, Helm, Johnson
and Vlissides, right? Just bought their book (rather their CD).
Now to master the proper use of render params. and urls.
- Glenn
On Dec 12, 2003, at 11:43 AM, Stefan Hepper wrote:
> Glenn,
> the flyweight pattern utilizes an object instance with different data
> per call instead of creating different object instances for these
> different data. In the portlet model this is the case for portlets, as
> for every user the request is submitted to the same portlet instance.
> The configuration and personalization data that are user specific are
> given to the portlet in the request via the portlet preferences. This
> is exactly the flyweight pattern of the pattern book of the GoF.
>
> Stefan
>
> Glenn Golden wrote:
>
>> Stefan -
>> I for one am not so clear on the rendering parameters, as you could
>> tell from my recent inquires. I also don't know what you mean by
>> "flyweight" for preferences.
>> Any materials that would he me (us) understand these concepts better
>> would be appreciated!
>> Thanks.
>> - Glenn
>> On Dec 12, 2003, at 2:26 AM, Stefan Hepper wrote:
>>> You need to create different JSR 168 portlet apps for all you
>>> concrete WP apps and provide the settings via different deployment
>>> descriptors. I agree that this is not as powerfull as the WP model,
>>> however a standard needs to be simple at first and easy to
>>> understand. I think the portlet specification is already complex
>>> enough for people comming from the servlet world with the render
>>> parameter concept, the portlet preferences flyweight pattern and
>>> aggregation model. We've experienced that the portlet programmers
>>> very often confused by the different layers abstract / concrete /
>>> concrete instance that we have in the IBM WP API. Thus we wanted the
>>> standard to be simpler and more easy to understand, which of cause
>>> comes with the price of reduced functionality. Next versions of the
>>> standard will provide additional functionality and therefore further
>>> close the functional gap between the JSR 168 and IBM WP API.
>>>
>>> Stefan
>>>
>>> Jason Novotny wrote:
>>>
>>>> Hi,
>>>> Let's say I'm migrating some portlets developed with the IBM
>>>> WebSphere API which differerentiates between application portlet
>>>> definitions (of which there is one) and one or more concrete
>>>> portlet definitions which allow you to provide parameterized
>>>> portlet instances. My question is how can I refactor my portlets
>>>> which use this model into JSR compliant portlets which seem to only
>>>> have the notion of an application portlet? So for instance, before
>>>> the PortletSettings object provided per concrete portlet definition
>>>> information, but now I guess I don't have that. Any thoughts on the
>>>> subject would be great-- having looked at both API's, I'm still
>>>> convinced the WebSphere API seems to offer more functionality than
>>>> the JSR does...
>>>> Thanks, Jason
Re: concrete/application portlets
Posted by Stefan Hepper <st...@hursley.ibm.com>.
Glenn,
the flyweight pattern utilizes an object instance with different data
per call instead of creating different object instances for these
different data. In the portlet model this is the case for portlets, as
for every user the request is submitted to the same portlet instance.
The configuration and personalization data that are user specific are
given to the portlet in the request via the portlet preferences. This is
exactly the flyweight pattern of the pattern book of the GoF.
Stefan
Glenn Golden wrote:
> Stefan -
>
> I for one am not so clear on the rendering parameters, as you could tell
> from my recent inquires. I also don't know what you mean by "flyweight"
> for preferences.
>
> Any materials that would he me (us) understand these concepts better
> would be appreciated!
>
> Thanks.
>
> - Glenn
>
> On Dec 12, 2003, at 2:26 AM, Stefan Hepper wrote:
>
>> You need to create different JSR 168 portlet apps for all you concrete
>> WP apps and provide the settings via different deployment descriptors.
>> I agree that this is not as powerfull as the WP model, however a
>> standard needs to be simple at first and easy to understand. I think
>> the portlet specification is already complex enough for people comming
>> from the servlet world with the render parameter concept, the portlet
>> preferences flyweight pattern and aggregation model. We've experienced
>> that the portlet programmers very often confused by the different
>> layers abstract / concrete / concrete instance that we have in the IBM
>> WP API. Thus we wanted the standard to be simpler and more easy to
>> understand, which of cause comes with the price of reduced
>> functionality. Next versions of the standard will provide additional
>> functionality and therefore further close the functional gap between
>> the JSR 168 and IBM WP API.
>>
>> Stefan
>>
>> Jason Novotny wrote:
>>
>>> Hi,
>>> Let's say I'm migrating some portlets developed with the IBM
>>> WebSphere API which differerentiates between application portlet
>>> definitions (of which there is one) and one or more concrete portlet
>>> definitions which allow you to provide parameterized portlet
>>> instances. My question is how can I refactor my portlets which use
>>> this model into JSR compliant portlets which seem to only have the
>>> notion of an application portlet? So for instance, before the
>>> PortletSettings object provided per concrete portlet definition
>>> information, but now I guess I don't have that. Any thoughts on the
>>> subject would be great-- having looked at both API's, I'm still
>>> convinced the WebSphere API seems to offer more functionality than
>>> the JSR does...
>>> Thanks, Jason
>
>
>
Re: concrete/application portlets
Posted by Glenn Golden <gg...@umich.edu>.
Stefan -
I for one am not so clear on the rendering parameters, as you could
tell from my recent inquires. I also don't know what you mean by
"flyweight" for preferences.
Any materials that would he me (us) understand these concepts better
would be appreciated!
Thanks.
- Glenn
On Dec 12, 2003, at 2:26 AM, Stefan Hepper wrote:
> You need to create different JSR 168 portlet apps for all you concrete
> WP apps and provide the settings via different deployment descriptors.
> I agree that this is not as powerfull as the WP model, however a
> standard needs to be simple at first and easy to understand. I think
> the portlet specification is already complex enough for people comming
> from the servlet world with the render parameter concept, the portlet
> preferences flyweight pattern and aggregation model. We've experienced
> that the portlet programmers very often confused by the different
> layers abstract / concrete / concrete instance that we have in the IBM
> WP API. Thus we wanted the standard to be simpler and more easy to
> understand, which of cause comes with the price of reduced
> functionality. Next versions of the standard will provide additional
> functionality and therefore further close the functional gap between
> the JSR 168 and IBM WP API.
>
> Stefan
>
> Jason Novotny wrote:
>
>> Hi,
>> Let's say I'm migrating some portlets developed with the IBM
>> WebSphere API which differerentiates between application portlet
>> definitions (of which there is one) and one or more concrete portlet
>> definitions which allow you to provide parameterized portlet
>> instances. My question is how can I refactor my portlets which use
>> this model into JSR compliant portlets which seem to only have the
>> notion of an application portlet? So for instance, before the
>> PortletSettings object provided per concrete portlet definition
>> information, but now I guess I don't have that. Any thoughts on the
>> subject would be great-- having looked at both API's, I'm still
>> convinced the WebSphere API seems to offer more functionality than
>> the JSR does...
>> Thanks, Jason
Re: concrete/application portlets
Posted by Stefan Hepper <st...@hursley.ibm.com>.
You need to create different JSR 168 portlet apps for all you concrete
WP apps and provide the settings via different deployment descriptors. I
agree that this is not as powerfull as the WP model, however a standard
needs to be simple at first and easy to understand. I think the portlet
specification is already complex enough for people comming from the
servlet world with the render parameter concept, the portlet preferences
flyweight pattern and aggregation model. We've experienced that the
portlet programmers very often confused by the different layers abstract
/ concrete / concrete instance that we have in the IBM WP API. Thus we
wanted the standard to be simpler and more easy to understand, which of
cause comes with the price of reduced functionality. Next versions of
the standard will provide additional functionality and therefore further
close the functional gap between the JSR 168 and IBM WP API.
Stefan
Jason Novotny wrote:
>
> Hi,
>
> Let's say I'm migrating some portlets developed with the IBM
> WebSphere API which differerentiates between application portlet
> definitions (of which there is one) and one or more concrete portlet
> definitions which allow you to provide parameterized portlet instances.
> My question is how can I refactor my portlets which use this model into
> JSR compliant portlets which seem to only have the notion of an
> application portlet? So for instance, before the PortletSettings object
> provided per concrete portlet definition information, but now I guess I
> don't have that. Any thoughts on the subject would be great-- having
> looked at both API's, I'm still convinced the WebSphere API seems to
> offer more functionality than the JSR does...
>
> Thanks, Jason
>
>
Re: concrete/application portlets
Posted by Glenn Golden <gg...@umich.edu>.
Has anyone tried Pluto and it's test driver portal engine in a
configuration that includes JBoss? Did it work? Any problems?
Thanks.
- Glenn