[EMAIL PROTECTED] wrote:
> Santiago Gala wrote:
>
>>[EMAIL PROTECTED] wrote:
>>
>>
>>I would like a lot that AbstractPortlet be really abstract. It is very
>>misleading that a class named Abstract has a concrete implementation.
>>Further, if it implements things that are not abstract at all, as a
>>caching behaviour coupled with a way to retrieve cached content. We have
>>had quite a few errors related with the fact that AbstractPortlet
>>implements too many things.
>>
>>
>
> I agree with the idea but do you see a mean to reduce the amount of functionality
> implemented by the AbstractPortlet (or Abstract*) without breaking compatibility ?
>
> I would think that AbstractPortlet should *not* implement Cacheable and should not
> provide an implementation for getContent() at the very least. If people are OK with
> dropping the Cacheable interface from AbstractPortlet, I'm definitely +1 but I fear
> this may have border effects on existing code.
>
This was also my concern. AbstractPortlet implies Cacheable, and a way
to retrieve content from cache.
I think we can wait until we go to the new Portlet API, which will break
most of the code, for such changes.
>
>>>OK, I'll see if I can integrate that into 1.3a2 without breaking existing code...
>>>
>>>While I'm testing waters here :
>>>
>>>Are there users out there who depend on PortletSet, PortletControl and PortletConfig
>>>being real classes rather that interfaces (for things like new PortletConfig() or
>>>new PortletSet() ) ?
>>>
>>>If not, I'd like to make these interfaces and provide the existing implementations
>>>as BasePortletConfig(), BasePortletSet() and AbstractPortletControl(). That will
>>>give us a lot of additionnal flexibility.
>>>
>>>
>>Again, I would pray that any "Abstract..." be really abstract. If it is
>>not abstract --> "Base..."
>>
>>
>
> The distinction I see between Base* and Abstract* is that a Base* class is likely
> to be the only implementation of this interface whereas Abstract* is a helper class
> for implementing an interface which is expected to have many implementations
>(Portlet,
> PortletControl, PortletController).
>
> Does that make sense to you ?
Yes. What I don't like is using Abstract for an implementation that
implements all methods. So if you subclass it with an empty behaviour,
you get something that compiles, but it will not run probably.
We have already had a bug related with this, as the caching behaviour
was not expected when a guy subclassed AbstractPortlet. So, for me the
problem is that the name of the class created a fake "implicit contract"
with the developer. If the class would have been called
"AbstractCacheablePortlet" this would not have been happened.
But I agree that it is not the time of moving this code too much. We
have already plenty to do. :)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
