Santiago Gala wrote:
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Santiago Gala
> Sent: Tuesday, November 21, 2000 5:45 AM
> To: JetSpeed
> Subject: Re: CVS Clean-Up, Part 2: services, architecture
>
>
>
>
> Raphael Luta wrote:
>
> > Santiago Gala wrote:
> > >
> > > Raphael Luta wrote:
> > >
> > > >
> > > > * URLManager
> > > > This started as a port of the BadURLManager code but
> morphed into a new service. The
> > > > idea behind the idea is : why have a service that only deal
> with bad urls when you can
> > > > have a service that deal with any URL and affects them a status ?
> > > > So the URLManager is just that: a central clearing house
> for registering URLs and their
> > > > status (which can be extended to also store their next
> update date, caching status,
> > > > etc...).
> > > > Since this require a lot of change in JetspeedDiskCache and
> associated classes which
> > > > Santiago is working on, I currently only use it to emulate
> the BadURLManager behavior
> > > > (ie store only the bad URLs).
> > > > It's fairly untested because I did not have a real internet
> connection for testing
> > > > during the week-end so it may take a few days to make it
> work well but it doesn't
> > > > break the basic operation of Jetspeed. If you find bugs in
> it, please send patches.
> > > >
> > >
> > > The idea is good. The whole idea of having a ResourceManager
> goes along the same lines.
> > > feeddaemon, badurlmanager and diskcache are our simple
> implementations of this manager.
> > >
> >
> > I'll leave you the implementation details then. I simply don't
> understand how
> > JetspeedDiskCache works... :(
> >
> > > >
> > > > Architecture
> > > > ============
> > > >
> > > > I've changed a little the src package architecture and
> remove some unused classes.
> > > > Mainly I renamed the 'turbine' package to 'modules' in
> order to match the standard
> > > > Turbine naming conventions.
> > > > This means that the 'localization' subpackage should
> certainly move because it's not
> > > > a 'module' in the Turbine sense but I'm not sure yet where
> these classes should
> > > > belong.
> > >
> > > See below: turbine.localization, if it is related to turbine
> modules, or
> > > jetspeed.localization if it is abstract.
> > >
> > > >
> > > >
> > > > Speaking about package organisation, I think the target
> architecture should be
> > > > something like:
> > > >
> > > > jetspeed
> > > > modules/
> > > > screens/
> > > > navigations/
> > > > layouts/
> > > > localization/ ???
> > > > om/
> > > > portal/ (portal object model: Portlet, PortletSet, etc...)
> > > > peer/ (Persitense dependant implementations)
> > > > syndication/ (syndcation object model: URLInfo, etc...)
> > > > peer/ (Persitense dependant implementations)
> > > > services/
> > > > profiler/ (layout)
> > > > capability/ (layout)
> > > > portletcache/ (layout)
> > > > cocoon/ (layout/templating)
> > > > xsl/ (layout/templating)
> > > > urlmanager/ (syndication/CMS)
> > > > diskcache/ (syndication/CMS)
> > > > feeddaemon/ (syndication)
> > > > contentdaemon/ (CMS)
> > > > castor/ (persistence, Object Relational model)
> > > >
> > >
> > > I thought that the portlet API (interfaces) would go into
> org.apache.portlet, and then the
> > > implementation under org.apache.jetspeed.portal (or something
> similar). In this way, we
> > > distinguish between the (I hope abstract) Portlet API and our
> buggy and dirty
> > > implementation of it :-)
> > >
> >
> > I'd prefer the Portlet API (the new generic one) to live in
> org.apache.portal since it should
> > not be tied to Jetspeed IMO. What I place in om.portal is what
> is currently defined
> > in org.apache.jetspeed.portal. Actually the architecture
> described here is
> >
>
> Ok. I had not read correctly here.
>
> >
> > > Also, I prefer that turbine modules would go into a
> turbine.modules package, to stress that
> > > there we store the glue between Jetspeed and Turbine. If we
> had alternate implementations
> > > of the Portlet API (for instance, for pure XML portlets, or
> for Stream oriented portlets)
> > > they would go into different packages. Also, we could use
> turbine.rundata for our
> > > extensions of RunData, ParameterParser, etc.
> > >
> >
> > There's no "glue" between Jetspeed and Turbine.
> > In this implementation, nearly everything we use in Jetspeed
> builds on top of
> > Turbine: services, resources, modules, etc...
> > Why only mark the modules as part of Turbine and not the services ?
>
> Well, I was looking to it from the page rendering point of view.
> There are two different things
> we use from Turbine:
>
> - The services and the global architecture
> - The layout system, with a few pages, actions or navigations
>
> The first one is obvious: we are a Turbine Application using
> Turbine services properly (at least
> when we finished migration/cleaning of a lot of code based on old
> versions or badly implemented).
>
> The layout system, on the other hand, should be handled in a very
> specific way by Jetspeed.
> I have less clear that Jetspeed would not have to stop using
> different screens, navigations, etc.
> for operation, and plug itself into Turbine as a single
> layout/screen. Different PSML resources
> could play the role that we have now with the
> portlet.PortletInfoScreen, Admin screen,
> JetspeedNavigations, etc.
>
> A PSML can already specify the navigation/screen part in a
> single, uniform way, through portlets.
>
> The actions are cool, but we need a way to separate actions
> coming from different portlets and
> manage isolation of internal path/vars in the global URL space,
> so we will have probably to
> specialize these classes again to deal with portlet events and
> queryString/pathInfo/portletCookie
> management.
>
So what you are suggesting is that Jetspeed has only one entry point from
the Turbine servlet.
Now it is the Turbine Screen org.apache.jetspeed.turbine.screens.Home.
With the subclassing of the Turbine servlet, it gave me some ideas about
using 'interceptors' to provide services declaratively. For example, the
profile service could intercept requests so that it doesnt have to be
specifically called from every Jetspeed module. If we only have one
module-entry point Turbine screen (or action), the same can be accomplished.
Have you tried to formalise the URL specification to resources?
For example, you always have the root:
/content/servlet/jetspeed/
and then the resource path can be specified as:
{page}/{portlet}/{action}/
for example:
/default/MyPortlet/nextPage
> This is the reason why I preferred to isolate this area. I have
> much less clear that it is stable
> from the architecture point of view.
>
> a org.apache.jetspeed.turbine package would offer a place where
> we could extend RunData,
> ParameterParser, and maybe other classes that we could need to
> extend/supply. I thought that the
> current Turbine modules fit naturally in this package.
>
> But I have no strong oppinions on that issue. Read it as a -0
>
> >
> > The choice for this implementation of Jetspeed is to use the
> Turbine framework, I
> > don't see a real reason for "ghettoing" Turbine based code in a
> sub-package.
> > We're advertised as a Turbine webapp so I think we should stick
> to existing
> > Turbine conventions when they exist and I think we must have a
> very good reason
> > to break these.
> >
> > BTW, I noticed I forgot a 'components' directory in the tree
> for storing default
> > portlets, controls, controllers, etc...
> >
>
> Also, the org.apache.portal package is not in the tree, but you
> mentioned it up.
>
> >
> > --
> > Rapha�l Luta - [EMAIL PROTECTED]
> >
> > --
> > --------------------------------------------------------------
> > Please read the FAQ! <http://java.apache.org/faq/>
> > To subscribe: [EMAIL PROTECTED]
> > To unsubscribe: [EMAIL PROTECTED]
> > Archives and Other: <http://marc.theaimsgroup.com/?l=jetspeed>
> > Problems?: [EMAIL PROTECTED]
>
>
>
> --
> --------------------------------------------------------------
> Please read the FAQ! <http://java.apache.org/faq/>
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Archives and Other: <http://marc.theaimsgroup.com/?l=jetspeed>
> Problems?: [EMAIL PROTECTED]
>
>
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://marc.theaimsgroup.com/?l=jetspeed>
Problems?: [EMAIL PROTECTED]
