"Kevin A. Burton" wrote:
>
> Rapha�l Luta wrote:
> >
> > "Kevin A. Burton" wrote:
> > >
> > > Rapha�l Luta wrote:
> > > <snip>
> > > > -1
> > > >
> > > > For most parameters I can think of, the controllers just want the current
>value for
> > > > a given parameter, they don't want to know if it's a locally overridden
>property
> > > > or if it's inherited from the current set. Why would they need to care ?
> > > > Do you have an explicit need for querying local only parameters ?
> > >
> > > Why would we ever need to override a local property. I think the
> > > distinction is important. Can you give an example where this
> > > functionality is needed?
> > >
> >
> > Well, in the PanedPortletControlelr I need 2 informations to layout
> > the portlets: column number and position for each of the portlets. If I want to
> > specify a default behavior for all portlets, I set in the portletSet (or one of
> > the panes, default values for these parameters, and only explicit values in the
> > portlets entries when I need non standard behavior.
> >
> > This could also apply for XSL stylesheets used in CocoonPortlets, where a default
> > value can be set for a portletSet and then overridden by some specific ones.
> >
> > You can argue that this behavior can be achieved by specifying the portletSet value
> > as default. True but the structure is already 3 levels deep
>(PortletSet,Pane,Portlet)
> > and may grow arbitrarily deep in future revisions. PortletSets are just a way to
> > group portlets and affect them a coherent behavior (and layout). These groups may
> > themselves be nested and I don't want to force the programmer to explore the
> > object hierarchy to find where a property has been defined.
>
> Sorry about the dated reply :(
>
Sorry about the dated reply too, just came back from extended Easter week-end
with no Internet connection...
> I see your point. But this overriding behavior can be potentially bad.
> IMO we should have a static set of values that are allowed to be
> overrided. This way if someone defines something like "put" we don't
> have namespace issues.
>
> I don't have a problem with giving you this behavior but we should limit
> it to a certain set of parameters.
>
> We should also build a better "blend" mechanism. I don't like how we
> are doing the blend in multiple places. This can lead to problems.
>
Yeah, I thought a little more about the issue and I came to a couple of
conclusions (while coding over the week-end) :
- the main need for overriding values are in the layout setup and not in the
parameters for the portlet so if we separate InitParameters and Layout calls,
we can specify 2 different behaviors. This is currently done in my
version of PortletConfig, with no cascading InitParameters but cascading layout.
- I think there's a need in the Portlet interface for an applet-like
getParameterInfo() which factories, controllers and editors can use to list
the expected parameters for a given portlet. This function should give us
the tools to check parameters validity.
- I'm still not easy on the storing of the RunData (or any request dependent
info) in the PortletConfig, I feel these should be passed as parameters in
for getContent() (nothing major though, I don't propose a change unless
we find a situation where it would be really useful))
- I think we should avoid propagating portletmarkup elements outside of the
Factory scope to better separate the interface of the implementation
(I see the portlet generation as a kind of peer-based system, where the
PSML markup and objects are the peers of the Portlet, PortletSet and
PortletConfig elements)
The only element used outside of this scope is Metainfo in PortletConfig,
IMO this should be fixed.
I've done some major PSML rework, among the proposed changes:
- create 2 different markups, one for the registry and one for the site markup
proper, this allows better description control of the different elements
- rework of the layout elements to simplify handling by castor, the new layout
section is something like this:
<layout size="NORMAL" position="1">
<property name="column" value="1"/>
<property name="stylesheet" value="file://test.xsl"/>
</layout>
- I implemented the PortletSet as Portlet. Each PortletSet have one attached
PortletController and one PortletConfig. I deprecated all direct parameter
access methods on the PortletSet since they are now in the PortletConfig.
When getContent() is called on the PortletSet, it delegates the layout and
rendering to the attached controller.
- Following the previous change, in the PSML markup I removed the entry
element (everything has to be declared in the registry), removed the
pane element (not necessary anymore) and allowed portlets imbrication.
The pane feature is compeltely handled by the controller choice.
Example of new markup:
<portlets user="turbine">
<controller>org.apache.jetspeed.portal.PanedPortletController</controller>
<parameter name="defaultpane" value="Home"/>
<portlets name="Home">
<controller>org.apache.jetspeed.portal.FlowPortletController
</controller>
<layout position="0"/>
<entryRef ref="RSS">
<layout position="0">
<property name="column=" value="1"/>
</layout>
</entryRef>
<entryRef/>
</portlets>
<portlets name="Channels">
<layout position="1"/>
<portlets>
<entryRef/>
</protlets>
<entryRef/>
<portlets/>
</portlets>
- I have a couple of additionnal controllers and a revised XMLPortletController
along with a ECS patch for XHTML output...
I don't know yet how I'm going to commit these changes back especially since I need
to merge all Kevin changes... If someone is -1 on one of the changes let me know
quickly.
Couple of things I'd want to implement but I'd like feedback from the list before:
- place of PortletControl in the new PortletSet/Portlet/PortletController system :
I've currently kept the PortletControl as is but I think it would be more
satistying if the PortletControl was as property of Portlet
I was thinking of allowing multiple controls per portlet which could complement
each other. This is very handy and correct for the decoration part of the
PortletControl interface but not really appropriate for the metadata information
part.
- to allow multi-access to the portal, I think we need to add methods
to the Portlet interface to specify the content-type that can be returned
by the portlet. Something like:
String[] getSupportedType() {
return { "text/html","text/xhtml","text/wml","text/xml" }
}
getContent(String type) {}
This, based on clien capability would allow the protlets to be called only if
can output the correct desired type (may also be used by XMLController to ask
xml-compliant output from a portlet, etc...)
This could also be ehance to a full client capability map to allow the portlet
output to change if the browser doesn't support table, 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://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
