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.
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]
