"Kevin A. Burton" wrote:
> >
> > - 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.
>
> Maybe we should just cascade the <layout> data with a getLayout() method
> that returns a Layout object that is the blend? This seems nice.
>
That's what I've done ;)
> > - 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.
>
> There currently is Portlet.getConfig().getInitParameters() and
> getMetaInfo(). Is this not enough? Parameter validity should be up to
> the Portlet.
>
Well getInitParameters() will return the parameters set for the portlet in the PSML.
How do you know how to set them in the first place ? In the registry markup.
How do you add en entry in the registry ? currently manually but we can envision a
register(Portlet) call in the PortletRegistry and this would require a way to
ask the portlet which parameters it needs to operate so we either need a
getParameterInfo or a EJB-like deployment descriptor file...
> > - 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))
>
> +1. I totally agree. I spent a saturday morning researching this. It
> just isn't possible right *now*. Hopefully soon. I am going to write
> up an e-mail about this. I will get back to this list with a better
> explaination.
>
*waiting mode*
> -1 on putting it in getContent(). Anything that calls getContent()
> should obtain the Portlet through PortletFactory which calls
> setRunData() again before returning the Portlet so we are cool here.
>
Yeah I know, it's just that I don't like the forced call to setRunData(), but
it's more on religious grounds than anything else... :)
> > - 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 am not happy with this either. The metainfo really isn't needed
> anymore. I reworked the PortletFactory to force titles/descriptions on
> the Portlet after it was instantiated so that the user can override the
> title and description if we want. There shouldn't be any need for this
> anymore. I will put it in the TODO.
>
OK, I'll take care of that.
> > 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
>
> Cool. I was going to bring this up.
>
:)
> > - 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>
>
> So why not:
>
> <layout size="NORMAL" position="1">
> <column value="1"/>
> <property value="file://test.xsl"/>
> <property name="test" value="hello world"/>
> </layout>
>
> This way column/row information is typed.
>
because some controllers (or should I say many) have no notions of "columns"
whereas position is used to give a display order for siblings entries in the
markup so is meaningful for any controller (this is important because it allows
to use non-ordering object stores (like Hashtable) in implementations but still
return an appropriate display order.
I wish to type in the markup only the elements that can be acted upon by *all*
controllers.
> > - 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.
>
> OK..
>
> > 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>
>
> Not sure if I like the duplicate "portlets" element. How about
> "section" or something?
>
I chose to resues portlets because they are exactly the same objects...
> > - I have a couple of additionnal controllers and a revised XMLPortletController
> > along with a ECS patch for XHTML output...
>
> Cool!
>
> > 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.
>
> No -1 here! Go ahead +1 !!! Still need to look at the PortletSet thing
> being a Portlet.... haven't had time.
>
OK, I'll try to polish up the code and land everything over the week-end.
> > 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.
>
> Huh? How could you have multiple PortletControls? What would each do?
> Certainly people should be able to pick their PortletControls so that
> they can change the look of the screen (or at least configure a master
> version) but I am not sure about multiple ones.
>
If you remove the "provide metadata" role of a PortletControl, it basically provides
a decoration to the portlet (ie, draw title bar, draw a frame around the portlet,
and so on...). We can then imagine than by writing of couple of basic "decorations":
TitleBarControl, BorderControl, etc... and attaching them to a portlet we can
achieve a much more flexible decoration system...
> > - 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" }
> > }
>
> I agree. +1024.
>
> > getContent(String type) {}
>
> I am wondering if we should have a basic MimeType object so that we can
> add additional functionality in the future. Also we could have:
>
> getContent( MimeType type );
> getContent( String someFutureMethod );
>
> so that in the future if we want a getContent(String) we can still do
> it.
>
yeah I agree that It's better to type it rather than using a generic String, it was
just to illustrate the point, not a proposal...
> > 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...)
>
> In the XML world getContent should just be a CDATA though.... thoughts?
I don't know, putting the content in CDATA would:
- prevent the controller from accessing any part of the content information
(title, headers, etc..)
- require a type-specific serializer to convert the CDATA to markup if the
output is not XML (eg HTML...)
I'd rather have the portlet itself determine what it should return based on
a type/capability request than enforcing XML compliance but removing any
useful data-processing capability.
> If we start to use XML then I think we should use an XMLSchema to return
> from getContent() so that validation and data integrity can be
> maintained.
>
I don't understand this point, how can you enforce validity of every
possible portlet output ? I'd rather have the following process:
- System build an ordered list a desired output format such as:
- text/html, no table, css1
- text/html
- text/plain
- Ask the portlet for supported types
- Determine best type supported by portlet
if non supported, don't ask for content
if there's a match, ask content for the best match
If you query for text/xml, you just want any xml compliant markup. If
you want a specific format query directly to that format (text/rss, text/xhtml,
text/rdf, 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...
>
> yup. Like on wireless devices, Palm or thin devices!
>
Yeah, I have a nice Nokia 9110 that doesn't handle tables...
> Just note that any code you commit has to be clean by May 15 or so for
> Jetspeed 1.2. :)
>
I'll be preparing my wedding, so everything will either be committed before that
date or long after...
--
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]
