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