Neeme Praks wrote:
> >
> > IMHO Jetspeed is at a stage of development where this type of
> > backwards
> > compatibility is not such an issue. As a matter of fact I believe that
> > too much thought on backward compatibility too early can be very
> > detrimental because it can tie you into something you have totally
> > outgrown...
>
> yep. I agree, current state of Jetspeed is still a little bit "alpha".
> At least on the user customization end.
>
I would say "alpha" is generous...
> > Some questions,
> >
> > What should be configurable?
> >
> > colors?
> > which portlets to display on a page?
> > Page title?
> > Page meta-data?
>
> more or less, yes. ;-)
> We actually have this part in the user configuration markup already.
> Maybe just needs some extending...
>
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.
> 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.
>
> <snip mountable PSML files>
>
> Also, I was thinking, when the user customizes his page, should we just
> copy the default and make necessary changes or use kind of inheritance:
> user configuration information simply overrides some of the default
> settings, no copy being made. This would simplify the administration
> when I would need to add a portlet to some "public" page. When a copy is
> being made, I would need to edit the configuration files of all the
> users. If inheritance is used, I would simply add this to the "public"
> page and it would be automatically shown for all the users.
>
> So, something like:
> default.psml: default page - "public" page, can be accessed anonymously
> username.psml: default page - reference to the "public" default page
> stored in default.psml; together with the reference, there are also the
> overriding settings for this user.
>
> username.psml can also contain "totally custom" pages, in the sense that
> users can build these from scratch. In this case, no reference to any
> "public" page is made.
>
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...
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.
I let to your imagination what may be the point of specifying user "burton" in
my example...
Any thoughts or comments are welcome.
--
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]
