You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-user@portals.apache.org by Endre Stølsvik <En...@Stolsvik.com> on 2002/05/04 20:59:43 UTC
Hi! What's the "concept" with Jetspeed's portlets?
I am writing a review of different EIP implementations, and trying to
analyze which "functionality" each framework provide.
The problem I'm facing with Jetspeed, is the documentation! I cannot seem to
grasp the overview of Jetspeed, so if someone could clear up on a couple of
problems I'm faced with, I would be very happy! If I obviously have missed
some essential documentation, could someone please lead me to the light? ;)
*) It seems like there are a couple of portlets present in the framework,
and it looks to me like in the documentation that these are supposed to be
enough for you, except if you have really weird needs. Is this so? Doesn't
one break MVC somewhat by using Velocity template language in addition to
the XML registiry stuff only to program new portlets?
*) Is Jetspeed primarily designed to handle _viewing_ of enterprise data,
that is to extract data from the underlying source, and then present it to
the user? It seems a bit like this because of the "we have made 5 portlets
for you that handle almost everything you'd want" approach. What about the
Enterprise Application Integration concept, where portlets should expose
some of an enterprise application's functionality? Or application-like
functionality, e.g. implement a group calendar system or a simple CRM system
like www.salesforce.com, directly in the portal system?
*) The "instance" and "ref" types. What is this? Is it similar to the
"instance" stuff talked about in this document:
http://www-3.ibm.com/software/webservers/portal/doc/V41PortletDevelopmentGui
de.pdf
*) The actions. Are these supposed to take care of all your business logic
needs?
*) The "addressing" of the portlets. The hello-velocity portlet has some
data that can be sent to it.
1) Where is the action defined? How is this configured?
2) How is it addressed? What if two portlets on the same screen had a
submit button?
*) "Porlet applications": are Jetspeed supposed to handle, at this stage, a
".par" file, where all the necessary stash is bundled into a file?
Any help would be valued! Jetspeed isn't _that_ easy, with all the stuff
coming from both turbine and jetspeed.. ;-)
Endre.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jetspeed's "new API" and IBM's WebSphere 4.1 API...
Posted by Endre Stølsvik <En...@Stolsvik.com>.
A quick follow up on my own mail..
| Raphael Lute: thank you very much for your tremendously helpful and
| informative answers!
Raphaël Luta, even! ;)
but..
| This inheritance scares me! This, to me, seems like a TOTAL trashing of
the
| concept of a "loadable module" or "portal application" that I've found it
| called here at Jetspeed. You're supposed to package the portal application
| in a .war file. How are you supposed to have multiple portal applications
| installed, then? Install multiple _web_ applications? But how is the
| communication between the different portal applications supposed to be
made?
| For example, a HttpSession should not be migrated between different web
| applications, according to the Servlet specs.
|
| Given that IBM somewhat ambiguously states "The Portlet API offered in
| WebSphere Portal Version 4.1 is the first step toward the Portlet API
| standardization." (pg 6), I wonder about this Servlet dependency.
|
| Jason van Zyl and David Sean Taylor: hi! Do you folks have any inside info
| you can share?! ;)
I now believe that what IBM have done, is to require a full J2EE environment
instead of a simple servlet container. Portlet Applications are packaged as
war's, and deployed like a normal web application. But since the instance of
the _enterprise_ application is a special portal type of application, there
must exist one special portal-web-application within, controlling all the
other portlet web applications. Probably, by clever use of J2EE features,
e.g. EJBs, JNDI (?), JMX (?), and some special "spanning RequestDispatchers"
or whatever, the different web applications will be sewn together into one
portal application.
Dynamic loading of portlet applications will now have to be implemented by
the J2EE server. Good thing that most servlet containers can handle this
already.
I can not decide whether I find this VERY bad or pretty OK! ;) I hate the
overhead with the J2EE system, but there are also some cool stuff in there.
Endre.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Jetspeed's "new API" and IBM's WebSphere 4.1 API...
Posted by Endre Stølsvik <En...@Stolsvik.com>.
Raphael Lute: thank you very much for your tremendously helpful and
informative answers!
So..
While reading the document for the IBM WebSphere Portal v.4.1, I run into
something that I do not understand, and thought that maybe you (or someone
else here) may be able to answer:
On page 7, a Porlet is shown like an extension of PortletAdapter, which is
an extension of Portlet. I guess the latter one is meant to shown
"implements". Nevertheless, these are both from package
org.apache.jetspeed.portlet. OK. But what I do not understand, is the logic
with the next step, where Porlet inherits from
_javax.servlet.http.HttpServlet_.
Has the Jetspeed API, old or new, _ever_ had any inheritance from the
servlet specification?
Is the Jetspeed API shown in this document actually available from the
Jetspeed CVS?
This inheritance scares me! This, to me, seems like a TOTAL trashing of the
concept of a "loadable module" or "portal application" that I've found it
called here at Jetspeed. You're supposed to package the portal application
in a .war file. How are you supposed to have multiple portal applications
installed, then? Install multiple _web_ applications? But how is the
communication between the different portal applications supposed to be made?
For example, a HttpSession should not be migrated between different web
applications, according to the Servlet specs.
Given that IBM somewhat ambiguously states "The Portlet API offered in
WebSphere Portal Version 4.1 is the first step toward the Portlet API
standardization." (pg 6), I wonder about this Servlet dependency.
Jason van Zyl and David Sean Taylor: hi! Do you folks have any inside info
you can share?! ;)
Thanks,
Endre.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Hi! What's the "concept" with Jetspeed's portlets?
Posted by ra...@networks.groupvu.com.
Endre Stølsvik wrote:
>Thanks a lot for the quick reply!
>
>I do have some follow-up questions, though..!
>
>
Huh... feared so :)
><snip>
>| >
>| >*) It seems like there are a couple of portlets present in the framework,
>| >and it looks to me like in the documentation that these are supposed to
>be
>| >enough for you, except if you have really weird needs. Is this so?
>Doesn't
>| >one break MVC somewhat by using Velocity template language in addition to
>| >the XML registiry stuff only to program new portlets?
>| >
>| >
>| For the first part of the question, I'm not sure these portlets are
>| really supposed to handle *all* your
>| current needs (for example we're missing a standard POP3/IMAP inbox
>| monitor portlet...) but they
>| are supposed to give you a good start.
>
>OK.. But they are so tiny. They seems to only be made for aggregation of
>internet data, and not to do any complex processing.
>
>
Well... Turbine gives you many tools for developing a complete business
application or at least
business components. Jetspeed mainly adds aggregation on top of Turbine
so Jetspeed itself does
not really help a developer to build his business components it
currently expects him to use Turbine
framework.
The Portlet component is effectively devised only for the rendering of
content in an aggregated environment
and does not imply or expect anything on the technology used to generate
the content. You get to chose
whatever tool/framework you best like.
><snip>
>|
>| >*) Is Jetspeed primarily designed to handle _viewing_ of enterprise data,
>| >that is to extract data from the underlying source, and then present it
>to
>| >the user? It seems a bit like this because of the "we have made 5
>portlets
>| >for you that handle almost everything you'd want" approach. What about
>the
>| >Enterprise Application Integration concept, where portlets should expose
>| >some of an enterprise application's functionality? Or application-like
>| >functionality, e.g. implement a group calendar system or a simple CRM
>system
>| >like www.salesforce.com, directly in the portal system?
>| >
>| >
>| You can develop enterprise application integration portlet, it's just
>| that we have not developped any.
>| In any case, these kinds of development would more probably be done by a
>| Jetspeed integrator
>| although we could certainly host within the project some very generic
>| ones like messaging, calendar, etc
>
>Thanks.. But I was more referring to the "programmability" of the framework.
>If I want to make some _new_ portlets, not simply aggregating easy-to-fetch
>internet concent, how do I do this? Am I supposed to be helped by the
>VelocityPortlet thingy, or do I have to make my own portlets? If I must make
>my own, how do I go about doing this? What if I'd like to make a hugly
>complex application with TONS of Java code and ten different portlets
>working in conjunction, each having ten different templates that they'd like
>to juggle between? Where do I start, kind of??
>
>
Well, "portlets" basically provide views to your complex application.
These views can be aggregated and personalized. So in a large app
development like this, you would first develop your business components
EJBs for example and then possibly use VelocityPortlet to develop your
different views with a couple/dozen
of Action classes controlling the overall app behavior. These Action
classes will load the different business
EJBs into the Velocity context (unless you have wrapped them into
Turbine ApplicationTools and use the
Turbine "pull" methodology).
>|
>| >*) The "instance" and "ref" types. What is this? Is it similar to the
>| >"instance" stuff talked about in this document:
>| >
>|
>
>
>>http://www-3.ibm.com/software/webservers/portal/doc/V41PortletDevelopmentGu
>>
>>
>i
>| >de.pdf
>
>Has anyone read that document?! ;) I try to sneak it into my every email, as
>it seems to be a blastin' good portlet API! But I wonder how they're going
>to handle "loadable modules", that is, point your configuration to a URL,
>and then you will have another cool application with images, portlets and
>everything "installed". Well, whatever..
>
>
Well, I've not read it completely yet but I do recognize many of the
points we have discussed with the
IBM team last year (with some differences though... :). It's a
definitely better API than the current
Jetspeed one. The current issue for us is not whether we're going to
change it, it's whether we're going
to implement the one found in "portlet_api" or wait for the JSR results.
Also in all the cases, we need to
think on how to provide migration path for the current API to the new
one and possibly support
backward compatibility...
>| >
>| >*) The actions. Are these supposed to take care of all your business
>logic
>| >needs?
>| >
>| >
>| No. Actions are typically "controllers". They may sometimes be used to
>| also implement the
>| business logic, but Turbine would typically expect you to encapsulate
>| all business logic within other classes
>| (like Turbine AppplicationTools) all use the Action to populate the
>| context provided to the template with
>| the appropriate business objects (or use implicit context loading in
>| case of Tools).
>
>My idea is that since VelocityPortlet is pretty stupid, then Actions would
>have to be where I make my business logic, showing stuff into the context
>from within the Action. But apparently not. So how do I configure that
>loading, basically; which class do I extend, and where do I configure it to
>run with my template?
>
>
Best practice would be to wrap all your "model" classes in specific
classes (for example Torque generated)
then use your Action as "controller" to specify which business
components to make available to the template
at any given time and react to user input. The velocity portlet would be
the "view" part proper.
The VelocityPortlet itself is the just the code required to make this
happen by tying an Action, a Portlet and
a template.
You can also use the "pull" methodology of Turbine and implicitely load
your business objects in all the portlet
contexts (configured in WEB-INF/conf/TurbineResources.properties)
>|
>| >*) The "addressing" of the portlets. The hello-velocity portlet has some
>| >data that can be sent to it.
>| > 1) Where is the action defined? How is this configured?
>| >
>| There's several way to invoke the action:
>| - the Turbine way of specifying an "action" parameter in the portlet
>| <form> tag.
>| - the Jetspeed VelocityPortlet way of using an implicit action
>| associated with a portlet through
>| the registry. In this case, the FORM action must reference the calling
>| portlet name or id. This
>| is always done automatically when you use the Jetspeed provided link
>| objects ($link, $jlink, etc...
>| in the Velocity templates)
>
>Where do I get more information about these link objects? And may I change
>that "implicit action" for my porlet?
>
>
See WEB-INF/conf/TurbineResources.properties for the association between
the context object name and
class and the org.apache.jetspeed.util.template package for the tools
themselves.
>|
>| > 2) How is it addressed? What if two portlets on the same screen had a
>| >submit button?
>| >
>| >
>| Since in each they specify the action to call and give a portlet
>| identifier, it's not an issue.
>
>a) Hello Velocity doesn't seem to be doing this..?
>
>
Yes it does. It uses the default Action tied to the portlet in its
registry definition.
>b) What about two hello velocities, then? Is this supported?
>
>
Only since very recently when the portlet unique id was introduced that
helps identity several instances of the
same portlet. It may still be somewhat buggy.
>| >Any help would be valued! Jetspeed isn't _that_ easy, with all the stuff
>| >coming from both turbine and jetspeed.. ;-)
>| >
>| >
>| >
>| If you ever write a valuable documentation on Jetspeed from your study,
>| you're welcome to
>| contribute it back... :)
>
>I am afraid that it will be a more "review" tone over that document. I'd
>just like to understand the concepts before writing it. But I will certainly
>post the document (or a link, of course) to the list..!
>
>
>
I'm looking forwward to it then.
--
Raphaël Luta - raphael.luta@networks.groupvu.com
Professional Services Manager
Vivendi Universal Networks - Paris
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Hi! What's the "concept" with Jetspeed's portlets?
Posted by Endre Stølsvik <En...@Stolsvik.com>.
Thanks a lot for the quick reply!
I do have some follow-up questions, though..!
| Endre Stølsvik wrote:
|
| >I am writing a review of different EIP implementations, and trying to
| >analyze which "functionality" each framework provide.
| >
| >The problem I'm facing with Jetspeed, is the documentation! I cannot seem
to
| >grasp the overview of Jetspeed, so if someone could clear up on a couple
of
| >problems I'm faced with, I would be very happy! If I obviously have
missed
| >some essential documentation, could someone please lead me to the light?
;)
| >
| >*) It seems like there are a couple of portlets present in the framework,
| >and it looks to me like in the documentation that these are supposed to
be
| >enough for you, except if you have really weird needs. Is this so?
Doesn't
| >one break MVC somewhat by using Velocity template language in addition to
| >the XML registiry stuff only to program new portlets?
| >
| >
| For the first part of the question, I'm not sure these portlets are
| really supposed to handle *all* your
| current needs (for example we're missing a standard POP3/IMAP inbox
| monitor portlet...) but they
| are supposed to give you a good start.
OK.. But they are so tiny. They seems to only be made for aggregation of
internet data, and not to do any complex processing.
| For the second part of the question, if you're talking about the
| VelocityPortlet read below about
| "hello-velocity".
Didn't quite get this one..
|
| >*) Is Jetspeed primarily designed to handle _viewing_ of enterprise data,
| >that is to extract data from the underlying source, and then present it
to
| >the user? It seems a bit like this because of the "we have made 5
portlets
| >for you that handle almost everything you'd want" approach. What about
the
| >Enterprise Application Integration concept, where portlets should expose
| >some of an enterprise application's functionality? Or application-like
| >functionality, e.g. implement a group calendar system or a simple CRM
system
| >like www.salesforce.com, directly in the portal system?
| >
| >
| You can develop enterprise application integration portlet, it's just
| that we have not developped any.
| In any case, these kinds of development would more probably be done by a
| Jetspeed integrator
| although we could certainly host within the project some very generic
| ones like messaging, calendar, etc
Thanks.. But I was more referring to the "programmability" of the framework.
If I want to make some _new_ portlets, not simply aggregating easy-to-fetch
internet concent, how do I do this? Am I supposed to be helped by the
VelocityPortlet thingy, or do I have to make my own portlets? If I must make
my own, how do I go about doing this? What if I'd like to make a hugly
complex application with TONS of Java code and ten different portlets
working in conjunction, each having ten different templates that they'd like
to juggle between? Where do I start, kind of??
|
| >*) The "instance" and "ref" types. What is this? Is it similar to the
| >"instance" stuff talked about in this document:
| >
|
>http://www-3.ibm.com/software/webservers/portal/doc/V41PortletDevelopmentGu
i
| >de.pdf
Has anyone read that document?! ;) I try to sneak it into my every email, as
it seems to be a blastin' good portlet API! But I wonder how they're going
to handle "loadable modules", that is, point your configuration to a URL,
and then you will have another cool application with images, portlets and
everything "installed". Well, whatever..
| >
| >*) The actions. Are these supposed to take care of all your business
logic
| >needs?
| >
| >
| No. Actions are typically "controllers". They may sometimes be used to
| also implement the
| business logic, but Turbine would typically expect you to encapsulate
| all business logic within other classes
| (like Turbine AppplicationTools) all use the Action to populate the
| context provided to the template with
| the appropriate business objects (or use implicit context loading in
| case of Tools).
My idea is that since VelocityPortlet is pretty stupid, then Actions would
have to be where I make my business logic, showing stuff into the context
from within the Action. But apparently not. So how do I configure that
loading, basically; which class do I extend, and where do I configure it to
run with my template?
|
| >*) The "addressing" of the portlets. The hello-velocity portlet has some
| >data that can be sent to it.
| > 1) Where is the action defined? How is this configured?
| >
| There's several way to invoke the action:
| - the Turbine way of specifying an "action" parameter in the portlet
| <form> tag.
| - the Jetspeed VelocityPortlet way of using an implicit action
| associated with a portlet through
| the registry. In this case, the FORM action must reference the calling
| portlet name or id. This
| is always done automatically when you use the Jetspeed provided link
| objects ($link, $jlink, etc...
| in the Velocity templates)
Where do I get more information about these link objects? And may I change
that "implicit action" for my porlet?
|
| > 2) How is it addressed? What if two portlets on the same screen had a
| >submit button?
| >
| >
| Since in each they specify the action to call and give a portlet
| identifier, it's not an issue.
a) Hello Velocity doesn't seem to be doing this..?
b) What about two hello velocities, then? Is this supported?
| >Any help would be valued! Jetspeed isn't _that_ easy, with all the stuff
| >coming from both turbine and jetspeed.. ;-)
| >
| >
| >
| If you ever write a valuable documentation on Jetspeed from your study,
| you're welcome to
| contribute it back... :)
I am afraid that it will be a more "review" tone over that document. I'd
just like to understand the concepts before writing it. But I will certainly
post the document (or a link, of course) to the list..!
Endre.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Hi! What's the "concept" with Jetspeed's portlets?
Posted by ra...@networks.groupvu.com.
Endre Stølsvik wrote:
>I am writing a review of different EIP implementations, and trying to
>analyze which "functionality" each framework provide.
>
>The problem I'm facing with Jetspeed, is the documentation! I cannot seem to
>grasp the overview of Jetspeed, so if someone could clear up on a couple of
>problems I'm faced with, I would be very happy! If I obviously have missed
>some essential documentation, could someone please lead me to the light? ;)
>
>*) It seems like there are a couple of portlets present in the framework,
>and it looks to me like in the documentation that these are supposed to be
>enough for you, except if you have really weird needs. Is this so? Doesn't
>one break MVC somewhat by using Velocity template language in addition to
>the XML registiry stuff only to program new portlets?
>
>
For the first part of the question, I'm not sure these portlets are
really supposed to handle *all* your
current needs (for example we're missing a standard POP3/IMAP inbox
monitor portlet...) but they
are supposed to give you a good start.
For the second part of the question, if you're talking about the
VelocityPortlet read below about
"hello-velocity".
>*) Is Jetspeed primarily designed to handle _viewing_ of enterprise data,
>that is to extract data from the underlying source, and then present it to
>the user? It seems a bit like this because of the "we have made 5 portlets
>for you that handle almost everything you'd want" approach. What about the
>Enterprise Application Integration concept, where portlets should expose
>some of an enterprise application's functionality? Or application-like
>functionality, e.g. implement a group calendar system or a simple CRM system
>like www.salesforce.com, directly in the portal system?
>
>
You can develop enterprise application integration portlet, it's just
that we have not developped any.
In any case, these kinds of development would more probably be done by a
Jetspeed integrator
although we could certainly host within the project some very generic
ones like messaging, calendar, etc
>*) The "instance" and "ref" types. What is this? Is it similar to the
>"instance" stuff talked about in this document:
>
>http://www-3.ibm.com/software/webservers/portal/doc/V41PortletDevelopmentGui
>de.pdf
>
>*) The actions. Are these supposed to take care of all your business logic
>needs?
>
>
No. Actions are typically "controllers". They may sometimes be used to
also implement the
business logic, but Turbine would typically expect you to encapsulate
all business logic within other classes
(like Turbine AppplicationTools) all use the Action to populate the
context provided to the template with
the appropriate business objects (or use implicit context loading in
case of Tools).
>*) The "addressing" of the portlets. The hello-velocity portlet has some
>data that can be sent to it.
> 1) Where is the action defined? How is this configured?
>
There's several way to invoke the action:
- the Turbine way of specifying an "action" parameter in the portlet
<form> tag.
- the Jetspeed VelocityPortlet way of using an implicit action
associated with a portlet through
the registry. In this case, the FORM action must reference the calling
portlet name or id. This
is always done automatically when you use the Jetspeed provided link
objects ($link, $jlink, etc...
in the Velocity templates)
> 2) How is it addressed? What if two portlets on the same screen had a
>submit button?
>
>
Since in each they specify the action to call and give a portlet
identifier, it's not an issue.
>*) "Porlet applications": are Jetspeed supposed to handle, at this stage, a
>".par" file, where all the necessary stash is bundled into a file?
>
>
Not yet. That's only implemented in the "portlet_api" branch of the CVS
with the IBM contributed code
but it's not (yet) integrated into the CVS head.
>Any help would be valued! Jetspeed isn't _that_ easy, with all the stuff
>coming from both turbine and jetspeed.. ;-)
>
>
>
If you ever write a valuable documentation on Jetspeed from your study,
you're welcome to
contribute it back... :)
--
Raphaël Luta - raphael.luta@networks.groupvu.com
Professional Services Manager
Vivendi Universal Networks - Paris
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>