Rapha�l Luta wrote:
<snip>
> > -1. That is Java2 only :( There is no reason we can implement all the
> > methods but just to implement the interface.
> >
>
> Yeah, I remember now why I don't see these interfaces used so often... :(
Ug. Yet another reason that the VM needs to be OSS. This was a totally
moronic (sorry... no better word) decision by SUN. They should have put
the new collections stuff in java.collections or something and added now
JDK 1.2 requirements. :(
> > > - what if we want to use this object to allow the controller to retrieve a
> > > Config object:
> > > PortletSet.getControllerConfig() or PortletSet.getPanes() doesn't ring so well
> > > to me...
> >
> > That would probably be in the controller. The PortletSet would just be
> > the content not its representation. So:
> >
> > PortletController.getPortletControllerConfig().getPanes()
> >
>
> That's a possibility, such a construct would require that a markup for the
> PortletControllerConfig to be stored with each user config and would also
> make panes controller specific... yes, that can work.
I also want to provide "suggestions". Hopefully these would be cross
controller. IE a suggestion like:
<layout useTitle="false"/>
It would be up to the Control/Controller do determine if it should use a
title within its HTML.
<snip>
> Do you mean you want to insert a CacheContentPortlet between the
> PortleControland the real Portlet such as
>
> PortletControl -> CacheContentPortlet -> RealPortlet
>
> The CacheContentPortlet implements the Portlet API and delegates all
> the calls to RealPortlet except getContent() and getContent(PC) that would
> be checked against a memory/disk cache ?
>
> That would require many instances of CacheContentPortlet running, since each
> would be linked to a specific RealPortlet... stateful portlets... not good.
>
> Am I missing something here ?
Not really. Just that the Factory would branch. IE
PortletFactory.getPortlet( classname, url )
- is it in memory cache:
- no
- is it in disk cache
- yes
- create a dummy portlet and return it.
- create a thread to initialize the correct Portlet
- at completion thread would replace the correct instance
in the cache with the dummy instance.
This is actually more complicated than it sounds. We need to make sure
multiple threaded portlet requests aren't kicked off and that the
PortletCache is thread safe. The MemoryStore is not so...
<snip>
> > I originally thought of a mechanism similar to the one you have above
> > but the problem is that we have to rely on our Portlets correctly
> > implementing the content restoration. They could get by this and just
> > provide NO OP code and then they would actually start doing work on
> > getContent().
> >
>
> I don't understand this. The CacheContentManager (CCM) would be part of the
> Engine and completely transparent to the Portlet developer.
Huh. This is what I meant :)
> In case of crash or reboot, the CCM would not even need to
> instanciate dummy portlets since they won't be called if the cache is valid,
> there's simply a need for a Recovery mode in the CCM which would always
> consider cache info valid and start a thread which would:
> - recreate instances of a portlet
> - regenerate cache entries
> - reset expiration date on each regenerated entry
>
> Plus this construct can either be implemented as a singleton or a pool of
> objects to increase availability while limiting general resource consumptions
Right. We are along the same lines I think.
> > This would be a Bad Thing and would screw over Jetspeed. That and it is
> > Engine specific code. The point being that Jetspeed is a Portal
> > Application server and when you develop under it you shouldn't have to
> > worry about the implementation details of crash persistence, etc.
> >
> > Thoughts?
> >
>
> Agreed on the masking of implementation details, but I think I missed one of
> your points because I don't see any advantage to the ContentCachePortlet.
I only see it as being a stand by until the actual Portlet is ready. I
just don't want to have content-swap in capability within the actual
Portlets.
<snip>
> >
> > No UML. But it is big. OSS is awesome but only if the communications
> > channels are high bandwidth. UML will help broaden that. I will jump
> > on that after 1.1 ships.
>
> +1000. IMO, the difficulty in OSS is getting the appriopriate level of mind
> reading necessary to understand where the project is going... :)
<snip>
Totally. This is one of the reasons I started Alexandria. To help
connect all our work together. The JXR project will be huge too. Have
you seen this:
http://relativity.yi.org/alexandria/content/html/jxr/org/apache/index.html
You got to admit that is cool :)
The really cool thing is when it starts to make AI suggestions like:
- your methods are too long.
- a similar algorithm is implemented in org.apache.tomcat.Main.main()
- you need to put in more comments/javadoc
- this package relies on JDK 1.3. Please remove the following methods
or rewrite them for 1.1
Oh baby! :)
BTW. For 1.2/1.3 I will incorporate this thread.
Kevin
--
Kevin A Burton ([EMAIL PROTECTED])
http://relativity.yi.org
Message to SUN: "Please Open Source Java!"
"For evil to win is for good men to do nothing."
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
