Flying Cloud wrote:
> A design for portal-like applications is of high interest to me. I would
> love to hear as soon as you have this design (or draft) published. I could
> see many instances where personalization is almost a necessity.
Stand by ;-)
> I realize this is still a bit early but what is the interest for integrating
> Struts/Tiles and the Jetspeed Portlet API? It's of high interest on my end.
I'm very interested in doing that. I've reviewed the new API spec in
depth, including the latest from WebSphere, and believe that we can
support
a good deal of the specification from within Struts, perhaps all of it,
and
make the portlets available to any container.
The portlets themselves are very similar to Actions. I believe we could
use a Struts Action to dispatch the portlets, and then use Tiles to
render the view. It may also be possible to have that Action recognize
things like the portlet.xml, and merge that with the application's
runtime configuration. (Get's a little hazy here;-)
> It looks like this would offer performance with a solution based upon this
> and background XML compilation. Take all the xml feeds, pre-compile them
> into html / jsp fragments, and then all this would have to happen at request
> time, is that the engine would assemble all the fragments that were already
> precompiled. Is this what you were envisioning?
I'm working along the lines of transforming the XML feeds into
JavaBeans (Craig is doing this already with his RSS implmentation in the
Commons-Digester package), and then passing the beans to the view. The
Tiles then just write the view from the bean, same as you would for a
database query, or any other instance of dynamic content.
The tricky part is setting up so that each Tile (fragment) can easily
grab its own bean. This is where we may need to tap into what is
provided by the API.
> The things that are waiting technology-wise might be - is this a standstill
> until this is done?:
> 1 - Completed integration of struts and tiles. May be a few months?
> 2 - Jetspeed implementation of the Portlet-API: not been fully integrated
> into the main branch, and then some testing.
Tiles can already be easily integrated into Struts by subclassing the
ActionController. Cedric provides this in the JAR, so it's ready to go.
At some point, we can change this over so it uses Oleg's services
instead, but the Tiles/Struts integration is available today.
It's really quite cool. You can define a page layout in a XML
configuration file, and then refer to that defination in an
ActionForward. The controller then renders the "page" directly by
including the specified tiles. This eliminates the extra "wrapper" pages
you end up using with the original Templates library.
> What are your thoughts?
Now there's a dangerous question ;-)
Here's something that came up in a private thread, based on ideas
contributed by Hans Gerwitz.
What we should be doing is writing our applications so that they "play
well with others", by providing a RSS view of their essential frontend
and/or providing a query services via an open API.
We don't need to write our applications AS "portlets" but to expose
themselves TO portlets. Then you can use Jetspeed, or a Struts portal,
or whatever you like for a portal frontend. If the backend application
is doing its job, the portlet implementation can be trivial.
Consider these two examples
My.Netscape (my.netscape.com) - I can set up a Weather portlet that
gives me the local skinny, but I can click through to a whole weather
site. The portlet is a remote query system, maybe using RPC-XML, or more
likely something that just takes a query string and returns a dynamic
RSS.
Meerkat (www.oreillynet.com/meerkat) - This is so cool. It started with
a simple query-string API for access, but now also works with RPC-XML
(http://www.oreillynet.com/pub/a/rss/2000/11/14/meerkat_xmlrpc.html).
What I really think need is a package that add this type of remote query
functionality to our applications, the way Lucene adds searching. So
portlets become an application's "remote page".
If you think about it, this approach dovetails nicely with Model 2. The
page is not suppose to know where the content comes from anyway, and
here it just comes from another application altogether. So, just like
you might write an application to support HTML and WAP, now you write it
to support remote pages too.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/about/struts/
