> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 08, 2000 6:47 AM
>
> > I'm not sure about this, though. Anybody else, comments?
>
> I am not sure how this should look either. Off the top of my
> head having a
> directory with all the users with multiple custimizations means that
> directory is going to be chock full o stuff. Maybe IMHO too
> much stuff.
I agree. Ideally, I would like to put all this in a database or some XML
store like Ozone.
> +1 with caveat
>
> I like this but I would also go one step further and make the
> directory
> configurable by assigning each user a home directory on the
> server.
Ok with me, but I'm not that sure anymore if we need some many files in
the first place... Should first check out the possibilities with
PanedPortletController...
> I am not sure how to do this because Jetspeed currently doesnt require
a
> database, which is where I would store the home directory.
what do you mean by "doesnt require a database"? For using user logging
in feature, you have to have a database. For just seeing the "public"
part, no database needed, true.
> > Would be cleaner solution, but it wouldn't be backwards
> compatible...
> >
>
> 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 think in the future when our user
> base is much larger and more established we will need to think about a
> more formal deprecation scheme
ok.
> I think that personalization is very important to Jetspeed
> and I will try
> to help you along on this as much as possible. I may even get
> to helping
> write code.
>
> In the meantime keep digging in the code and submitting more patches.
sure. My whole project depends on Jetpseed, so I have no other choice
;-)
> I didnt write the original code on this so I wont commit the
> patch, but maybe Kevin could weigh in on this.
>
> I would like to hear from Kevin on these changes and would
> like the active
> developers to weigh in on personalization in general.
Yep, also would love to hear their ideas on this.
> 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...
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.
This is the ideal goal for me at least. In reality CSS is not that well
supported and we'll probably have to add style information to the
"bones" also (for older browsers). However, the user customization would
still be achieved through the use of custom styles (and the user won't
get these features with older browser, but this is not that big issue).
> If we have more than one personalized page (which I would
> like to +1 that)
> how do we navigate between pages?
this was what I meant with the "toolbar"... Now I though more of it and
considered the possible future use of Ozone for this data... and came to
the conclusion, that we already have all the stuff there, I just want to
understand how to use PanedPortletController. Maybe we should allow to
do mountable portlets configuration files, adding <url> tag to
<portlets>, something like this:
<portlets user="default">
<controller
name="org.apache.jetspeed.portal.controllers.CardPortletController">
<parameter name="parameter" value="pane"/>
</controller>
<skin>
<property name="selected-color" value="#990000"/>
<property name="background-color" value="FFFFFF"/>
<property name="title-color" value="#FFCC00"/>
</skin>
<portlets>
<controller
name="org.apache.jetspeed.portal.controllers.RowColumnPortletController"
>
<parameter name="sizes" value="66%,34%"/>
<parameter name="mode" value="row"/>
</controller>
<layout position="0"/>
<metainfo>
<title>Home Page</title>
</metainfo>
<skin>
<property name="background-color"
value="#FFFFFF"/>
</skin>
<url>
customPage.psml
</url>
</portlets>
</portlets>
This way we would need to deal with two files on each request, but it
might be better than dealing with one BIG file?
And later, when we use some XML store, we could just put everything in
one place, without any <url> tags.
Or we can use XInclude to include files, but it beats the reason for
having separate files in the first place because then all the files
would be included, not just one.
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.
> Should users be able to share some of their personalized pages with
> friends/world/anyone?
> How would the permissions look on this?
Would be a nice feature, I have also been thinking about this... but I
haven't figured out any neat solution to this yet.
I have had some ideas though. I'll include an adaptation of one of our
company internal memos that I sent out in March (you can ignore the
parts about URL localization, these plans have been postponed...
probably could bring this up in the Cocoon2 sitemap development):
----- cut here -----
The site would be divided into three main parts:
* Private pages
* Shared pages
* Public pages
The private pages would be the customized pages that each user can
customize according to his/her needs. They would be accessible through
some fixed folder name (different in different languages) on in the URL,
for example http://one.lv/myPages /myNews or
http://one.lv/minuLehed/minuUudised. The myPages (or minuLehed) is the
folder that signals that this request goes for some user's personal
page. The name of a page, myNews or minuUudised, must be unique for the
logged in user.
The users can use shared pages to publish their private information to
other users. These are very similar to the private pages, except that
the names of the shared pages must be unique across all the users.
Alternative to separate private and public pages could be the use of
combined structure (like in MS Exchange). This means that all the pages
would be "private" and the user would grant access to these pages, for
example, to see Neeme's calendar, you should go to
http://one.lv/private/neeme/kalender. However, as this is tied to a
certain user, this could create some inconveniences in the case of group
calendars. Actually we could somehow combine these two approaches (one
more folder level under /shared, like /shared/neeme/kalender?).
The public pages are accessible to everybody without logging in. An XML
document is used to store the information about the structural
relationships (parent/child) of the public pages and folders. By
querying the document, the system is able to map a specific page request
to the information about the page stored in the database. The use of XML
document allows us to have hierarchical page structure (folders) with
translatable URLs.
----- cut here -----
Any comments on this kind of "sharing"?
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]
