> -----Original Message-----
> From: Rapha�l Luta [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 08, 2000 5:41 PM
>
> Customization is currently implemented for the following elements:
>
> portlet to display
> meta-data (including title, description, etc..) for each portlet
> screen organisation
> portlet decoration
> portlet parameters
>
> What is missing currently is *user* cutomization, ie a
> web-accessible GUI for each
> user to taylor its page at will.
yep... I understood that Kevin is working on this?
> > I will use XSP for writing portlets and XSLT stylesheets for page
> > "controlling". The user can "skin" the portal by choosing among
> > available stylesheets. XSLT would generate the "bones" for
> the "skin"
> > and CSS would be used to add the "flesh" to the "skin": add
> the colors
> > and other formatting information.
> > User can also customize the style of the "skin" by overriding the
> > default CSS style information.
>
> Yes, that's the goal. But don't forget that you using XSLT
> for controlling
> makes user cutomization difficult.
>
> Example: user wants to add a new portlet to his page, the
> page is controlled by a
> RowColumnController.
> When the user as selected and configured his portlet, the
> controller will
> propose its layout options, which in the case of RowColumn is
> very easy:
> which position do you want to give this portlet ?
> Same as before but the page is controlled by a XSLController
> using stylesheet A.
> Which layout option do you display to the user ? What happens
> when you switch to stylesheet B ?
>
> Using generic controllers/controls is very flexible from the
> designer/administrator point of view but makes presenting a GUI to
> the user more difficult than single purpose controllers with
> well-known
> capacities.
yep, very relevant points. I see it in the way that you implement the
RowColumnController with a stylesheet... This clarifies the user
confusion and allows the designers to have more control over the design.
But I'm not familiar with contollers and their capabilities that much so
I might change by mind after I have started to look in them more
closely. I just making a lot of assumptions here about the
implementation of these controllers.
> I was also ondering whether we should use a copy or reference
> model for user
> cutomization. While I agree that the reference model seems
> very nice, I also
> anticipate a lot of implementation issues...
yep, implementation could be tricky.
> Currently my idea was :
> let's define profiles in the registry which are valid PSML fragments
>
> <profile name="Corporate">
> <controller/>
> <entry>
> <portlets>
> <controller/>
> <control/>
> <entry/>
> </portlets>
> </profile>
>
> now let's allow portlets to be linked to profiles, a linked
> portlets element would
> be initialized with the profile content.
>
> <portlets profile="corporate">
> <controller/>
> <entry>
> <portlets>
> <controller/>
> <control/>
> <entry/>
> </portlets>
> </portlets>
>
> let's use the user attribute on portlets (currently defined
> by unused) to
> name the user that has the right to modify the portlets
> content (ie add/remove
> a portlet, change the control/controller). If no user
> attribute is specified on a
> portlets element, its parent user attribute is inherited.
>
> we may get a sample PSML file like this :
>
> luta.psml
> <portlets user="luta">
> <portlets user="default" profile="Corporate">
> <controller/>
> <entry>
> <portlets>
> <controller/>
> <control/>
> <entry/>
> </portlets>
> <portlets user="default" profile="MegaCorporate"/>
> <portlets profile="Custom"/>
> <portlets user="burton" profile="CustomShared"/>
> </portlets>
>
> This file would be used to display the portlet for user luta,
> since it's
> named luta.psml.
> We would have the following capability matrix
>
> no profile / no user: fixed content, not editable by anybody
> profile / no user: each time the profile is changed, the
> content of these
> section is updated as they're not editable
> no profile / user : user is free to edit this element and
> put whatever it
> likes inside.
> profile / user : content is intialized by profile and
> editable by
> user. It's not kept up to sync with
> the profile changes.
ok, looks good. One thing though: I would like to separate the "state"
(minimized, etc) of the portlet from the <portlets>, so we could have
more unmodifiable/centrally-administrable blocks... but this brings us
actually back to the reference issue...
> I let to your imagination what may be the point of specifying
> user "burton" in my example...
making a copy of burton's portlets... well, interesting idea... however,
I would still love to implement this also as a reference, so when burton
changes his portlets, yours would also be changed. Tricky to implement
in the case of filesystem storage, though... Also, the option of making
a copy should still be there.
Neeme
--
--------------------------------------------------------------
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]
