You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-user@portals.apache.org by "Luta, Raphael (VUN)" <Ra...@groupvu.Com> on 2003/08/07 18:54:41 UTC
J2 PSML persistence (was RE : Jetspeed performance [was RE: mast
er detail records displaye d in a portlet])
[ moved to dev and renamed given the current content of the thread ]
For mt PSML stuff in JS2, I've currently broken down the persistence
options like this:
- PageManagerService:
Function:
Handles page persistence (ie loading and saving pages and fragments to
storage as well as creating new pages and fragments)
Implementation:
I have 2 implementations in the works:
- XML/Castor, with XML files on disk (complete, I just need to
stop answering mails and write the related unit test files :)
- OJB based (through the persistence plug-in) (in progress, 80%
complete)
For the XML files, the default service implementation just write
files in a flat directory, with files identified by an id (this
is different from JS1 behavior).
Typical directory layout would be:
/WEB-INF/pages/
pageID1.psml
pageID2.psml
pageID3.psml
...
pageIDX.psml
- PageRegistryService
Function:
Register available portal pages and map these pages to user and role
profiles. The API of this service will be an extension of the default
Registry service
Implementation:
Again 2 implementations possible:
- XML/Castor based on the current JS1 registry code (70% complete)
- OJB/Persistence plug-in like the new PortletRegsitry written by
Scott (0% complete)
With XML implementation, information is stored in one or several
xreg files in /WEB-INF/conf by default.
Example of page registry entries:
// default anonymous page for html markup
<page-entry default="true">
<media-type ref="html"/>
<page ref="pageID1"/>
</page-entry>
// default page for any logged-in user
<page-entry name="home" user="*" default="true">
<meta-info>
<title>My Portal Home</title>
<descritpion>User Home page</description>
</meta-info>
<page ref="pageID2.psml"/>
</page-entry>
// secondary page for any logged-in user
<page-entry name="news" user="*">
<meta-info>
<title>My News Page</title>
<descritpion>User specific news page</description>
</meta-info>
<page ref="pageID3.psml"/>
</page-entry>
// custom news page for user raphael
<page-entry name="news" user="raphael">
<meta-info>
<title>My News Page</title>
<descritpion>User specific news page</description>
</meta-info>
<page ref="pageID4.psml"/>
</page-entry>
// default news page for role admin, note that
// it can be the same ID that as above
<page-entry name="news" role="admin">
<meta-info>
<title>My News Page</title>
<descritpion>Role specific news page</description>
</meta-info>
<page ref="pageID4.psml"/>
</page-entry>
This setup should IMO be both more efficient in the XML and
SQL persistent mode because of the flatter structure and be
more flexible because the PageRegistry allows a central page
repository and some user->page mappings that were not possible
in JS1, including the ability to "off-line" a page without
removing it physically.
--
Raphaël Luta - raphael@apache.org
Jakarta Jetspeed - Enterprise Portal in Java
http://jakarta.apache.org/jetspeed/
> -----Message d'origine-----
> De : Weaver, Scott [mailto:Sweaver@rippe.com]
> Envoyé : jeudi 7 août 2003 18:25
> À : 'Jetspeed Users List'
> Objet : RE: Jetspeed performance [was RE: master detail
> records displaye d in a portlet]
>
>
> Hi Meghan,
>
> File based as in how?
>
> The goal is to have JMX/MBean UIs be as simple and straight
> forward as possible. There will still a jetspeed.properties
> file for configuring all the basic service stuff and what not.
>
> One of the major goals is to make deploying and using
> Jetspeed 2 as painless as possible
>
> Regards,
> *===================================*
> * Scott T Weaver *
> * Jakarta Jetspeed Portal Project *
> * weaver@apache.org *
> *===================================*
>
>
>
> > -----Original Message-----
> > From: Meghan_E_Pietila@eFunds.Com
> [mailto:Meghan_E_Pietila@eFunds.Com]
> > Sent: Thursday, August 07, 2003 12:06 PM
> > To: Jetspeed Users List
> > Subject: Re: Jetspeed performance [was RE: master detail records
> > displayed in a portlet]
> >
> >
> > Will there continue to be an option to have these values
> file-based?
> > We are hoping to give customers of our other software the option to
> > deploy the portal onsite, and the less we have to ask the smaller
> > companies to set up and configure, the better...
> >
> > Meghan
> >
> >
> >
> >
> > "Weaver, Scott"
> > <Sweaver@rippe.co To:
> 'Jetspeed Users
> > List' <je...@jakarta.apache.org>
> > m> cc:
> > Subject: Jetspeed
> > performance [was RE: master detail records displayed in a
> > 08/07/2003 10:57 portlet]
> > AM
> > Please respond to
> > "Jetspeed Users
> > List"
> >
> >
> >
> >
> >
> >
> > With Jetspeed 2, we are trying to keep as much of the
> information in
> > the DB as possible as to make clustering
> servers/upgrade/deployment as
> > easy as possible. The registry implementation is entirely
> RDBMS based
> > and I think Raphael is planning on making the page
> information (PSML
> > stuff) RDBMS based
> > also.
> >
> > We are also going to try to expose as much of the configuration
> > information as possible through JMX and MBeans.
> >
> > Regards,
> > *===================================*
> > * Scott T Weaver *
> > * Jakarta Jetspeed Portal Project *
> > * weaver@apache.org *
> > *===================================*
> >
> >
> >
> > > -----Original Message-----
> > > From: Serge Huber [mailto:shuber2@jahia.com]
> > > Sent: Thursday, August 07, 2003 11:43 AM
> > > To: Jetspeed Users List
> > > Subject: RE: master detail records displayed in a portlet
> > >
> > > At 11:27 AM 8/7/2003 -0400, you wrote:
> > > >I would not be surprised if there is a speed penalty but
> then again
> > > >my
> > > first
> > > >programming language was assembler and I have no doubt that
> > > >writting software in assembler will result in fast
> execution. I am
> > > >not about to
> > go
> > > >back to that. You almost always pay for productivity
> with speed but
> > that
> > >
> > > I know you said you weren't going to back it up, but
> believe me : it
> > > is possible to write slow code in assembly language. One
> of the ways
> > > is accessible very low performance memory such as old-time VGA
> > > cards. The overall speed of the software is not only the speed of
> > > execution of the application's main code, but also all the
> > > sub-systems that it
> > communicates
> > > with.
> > >
> > > As for Jetspeed's performance. If it's the only problem you have
> > > with
> > the
> > > software, you should not shy away, because you can always :
> > >
> > > - buy faster hardware (as you said it's the cheapest solution)
> > > - contribute more efficient designs
> > >
> > > One thing I don't know about Jetspeed because I was away from the
> > project
> > > for a few years is if it's easily to set up in a cluster. This is
> > > one of my main points of interest right now.
> > >
> > > Regards,
> > > Serge Huber.
> > >
> > >
> > > >-----Original Message-----
> > > >From: Weaver, Scott [mailto:Sweaver@rippe.com]
> > > >Sent: Thursday, August 07, 2003 11:01 AM
> > > >To: 'Jetspeed Users List'
> > > >Subject: RE: master detail records displayed in a portlet
> > > >
> > > >
> > > > > I tried to do a few things with JetSlow, and then I
> went Struts.
> > > >
> > > >Okay, that comment was uncalled for. Please try and
> refrain from
> > > >mud slinging as it does no one any good and is fodder
> for a flame
> > > >war,
> > which
> > > is
> > > >not conducive to the goals of this list.
> > > >
> > > >Regards,
> > > >*===================================*
> > > >* Scott T Weaver *
> > > >* Jakarta Jetspeed Portal Project *
> > > >* weaver@apache.org *
> > > >*===================================*
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Vic Cekvenich [mailto:maillist@baseBeans.com]
> > > > > Sent: Thursday, August 07, 2003 9:29 AM
> > > > > To: jetspeed-user@jakarta.apache.org
> > > > > Subject: Re: master detail records displayed in a portlet
> > > > >
> > > > > I tried to do a few things with JetSlow, and then I
> went Struts.
> > This
> > > is
> > > > > using JSTL, not Velocity, but same concept, Struts supports
> > Velocity.
> > > > > Master detail processing is done all the time, and several
> > > > > working
> > > samples
> > > > > are in there:
> > > > > http://cvs.sourceforge.net/cgi-
> > > bin/viewcvs.cgi/basicportal/bPproj/bP/WEB-
> > > > > INF/portlets/newsBlg/NewsBlgCmntsLst.jsp
> > > > > Note that it using the core master tag and then iterating a
> > > > > list.
> > This
> > > is
> > > > > usnig nested beans. I think that is the key conecpt I
> recommend,
> > nest
> > > > > beans
> > > > > and then use dot notation to get to each of the 3 iterating
> > > > > collections/beans. So you can have one bean, that
> nests your 3
> > > > > beans. You can download and look at sample (or CVS source).
> > > > >
> > > > > Here is an example of how to click in, and get detail:
> > > > > http://cvs.sourceforge.net/cgi-
> > > bin/viewcvs.cgi/basicportal/bPproj/bP/WEB-
> > > > > INF/portlets/cms/ContentAdminLst.jsp
> > > > >
> > > > > KISS,
> > > > >
> > > > > .V
> > > > >
> > > > > ps:
> > > > > And here is a navigation, but I do not think you
> asked for that:
> > > > > http://cvs.sourceforge.net/cgi-
> > > bin/viewcvs.cgi/basicportal/bPproj/bP/WEB-
> > > > > INF/config/navigation.xml
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > "D.S. Johnson" <ds...@insightbb.com> wrote in message
> > > > > news:3F32424E.5060701@insightbb.com...
> > > > > > Ron Wheeler wrote:
> > > > > >
> > > > > > >We are fairly new to Jetspeed and have made pretty good
> > > > > > >progress
> > > > > dispite
> > > > > the
> > > > > > >documentation.
> > > > > > >
> > > > > > >We are wondering how to create the following fairly common
> > > > > > >web
> > page
> > > > > > >structure.
> > > > > > >We have three identical problems. List of case
> studies, list
> > > > > > >of
> > > white
> > > > > > >papers, list of training courses.
> > > > > > >In each case, we want to present the user with the
> list and
> > > > > > >when
> > > they
> > > > > click
> > > > > > >on one of them, show them the details of that item.
> > > > > > >
> > > > > > >The information is in one or more XML files. (list
> of items
> > > > > > >in
> > one
> > > XML
> > > > > that
> > > > > > >links to the many individual XML files containing
> the details
> > > > > > >of
> > te
> > > > > item.)
> > > > > > >
> > > > > > >The first problem is that we do not see how we can use
> > > > > > >separate
> > > > > portlets
> > > > > > >since we only want either the list or one of the
> items on the
> > > screen at
> > > > > once
> > > > > > >and we do not the menu to change while the user navigates
> > > > > > >within
> > > the
> > > > > topic.
> > > > > > >
> > > > > > >If we use a single portlet, then we need to be able to
> > > > > > >respond to
> > > > > selection
> > > > > > >of one item (a Case Study for example) by clearing
> the list
> > > > > > >and
> > > > > displaying
> > > > > > >the selected document (the Case Study).
> > > > > > >We have the xsl stylesheets to display the initial
> list and
> > > > > > >the
> > > details
> > > > > of
> > > > > > >the idividual item.
> > > > > > >
> > > > > > >1) Are we on the right track and understanding the
> problem in
> > > > > > >a
> > > > > reasonable
> > > > > > >way?
> > > > > > >2) Which portlet type would be the best way to handle this?
> > > > > > >3) Does anyone have a model that we could see/use for this
> > > > > > >type
> > of
> > > > > > >application?
> > > > > > >4) Should we be looking at Velocity/DVSL rather
> than XSLT if
> > > > > > >we
> > are
> > > > > going
> > > > > to
> > > > > > >work with Jetspeed?
> > > > > > >
> > > > > > >Thanks for the help.
> > > > > > >
> > > > > > >Ron
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > -------------------------------------------------------------------
> > > --
> > > > > > >To unsubscribe, e-mail: jetspeed-user-
> > > unsubscribe@jakarta.apache.org
> > > > > > >For additional commands, e-mail: jetspeed-user-
> > > help@jakarta.apache.org
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > I don't use Velocity very much so I don't know if this will
> > > > > > work
> > for
> > > > > > you. But, I have used java server pages and
> servlets to switch
> > > between
> > > > > > pages in the same portlet. Usually, I create a menu
> and then
> > > > > > based
> > > on
> > > > > > the users choice I switch to that page in the
> portlet. Using
> > links
> > > I
> > > > > > can then switch between different pages in the same
> portlet, I
> > > believe
> > > > > > this is what you want to do.
> > > > > >
> > > > > > What I do is create the initial jsp page which will
> have the
> > > > > > logic
> > > for
> > > > > > jumping to other pages. So the switch file would look
> > > > > > something
> > like
> > > > > this;
> > > > > > I don't know if this is the best way but, it is a
> way to solve
> > your
> > > > > > problem, it has worked me.
> > > > > >
> > > > > >
> > > > > > ## switch.jsp##
> > > > > >
> > > > > > <%@page language="java" import="java.sql.*"%>
> > > > > > <%@ taglib uri='/WEB-INF/templates/jsp/tld/template.tld'
> > > > > > prefix='jetspeed' %>
> > > > > >
> > > > > > <%
> > > > > > // Create and get the switch val, this will be a val to
> > > > > > decide on
> > > what
> > > > > > page to load.
> > > > > >
> > > > > > String var_switchval =request.getParameter("switchval");
> > > > > >
> > > > > > // If switchval is null ( on first pass ) then
> load the main
> > > > > > menu
> > > page
> > > > > >
> > > > > > if ( var_switchval == null ||
> > > var_switchval.compareTo("val_main_menu")
> > > > > > == 0 ) {
> > > > > >
> > > > > > %>
> > > > > >
> > > > > > <%
> > > > > >
> > > > > > // Include the file with the menu code, this file will have
> > > > > > HTML
> > > code
> > > > > > and a parameter called switchval.
> > > > > > // So in this included file you will need to create a
> > > > > > parameter (switchval), setting this val will cause
> the other
> > > > > > pages to be
> > > included
> > > > > > // into switch.jsp
> > > > > >
> > > > > > // Example: <a href="?switchval=val_casestudies">
> > > > > > // When this link is executed then the case studies
> page would
> > > > > > be included and loaded. // You would want to add
> code for each
> > > > > > page you want to switch to
> > > > > >
> > > > > > @ include file="/WEB-
> > > INF/templates/jsp/portlets/html/artifact_menu.jsp"
> > > > > >
> > > > > > %>
> > > > > >
> > > > > > <%
> > > > > > }
> > > > > > %>
> > > > > >
> > > > > > <%
> > > > > > if ( var_switchval != null )
> > > > > > if ( var_switchval.compareTo("val_casestudies") == 0 ) {
> > > > > >
> > > > > > %>
> > > > > > <%@ include file="/WEB-
> > > INF/templates/jsp/portlets/html/casestudies.jsp"
> > > > > %>
> > > > > >
> > > > > > <%
> > > > > > }
> > > > > > %>
> > > > > >
> > > > > > <%
> > > > > > if ( var_switchval != null )
> > > > > > if ( var_switchval.compareTo("val_whitepapers") == 0 ) {
> > > > > >
> > > > > > %>
> > > > > > <%@ include file="/WEB-
> > > INF/templates/jsp/portlets/html/whitepapers.jsp"
> > > > > %>
> > > > > >
> > > > > > <%
> > > > > > }
> > > > > > %>
> > > > > >
> > > > > >
> > > > > > <%
> > > > > > if ( var_switchval != null )
> > > > > > if (
> var_switchval.compareTo("val_trainingcourses") == 0 )
> > > > > > {
> > > > > >
> > > > > > %>
> > > > > > <%@ include file
> > ="/WEB-INF/templates/jsp/portlets/html/training.jsp"
> > > %>
> > > > > >
> > > > > > <%
> > > > > > }
> > > > > > %>
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> ----------------------------------------------------------------
> > > > > ----
> > -
> > > > > To unsubscribe, e-mail:
> > > > > jetspeed-user-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail:
> > jetspeed-user-help@jakarta.apache.org
> > > >
> > > >
> > > >
> > >
> >-------------------------------------------------------------------
> > > >--
> > > >To unsubscribe, e-mail:
> jetspeed-user-unsubscribe@jakarta.apache.org
> > > >For additional commands, e-mail:
> jetspeed-user-help@jakarta.apache.org
> > >
> > > - -- --- -----=[ shuber2 at jahia dot com ]=---- --- -- -
> > > www.jahia.org : A collaborative source CMS and Portal Server
> > >
> > >
> > >
> > >
> --------------------------------------------------------------------
> > > -
> > > To unsubscribe, e-mail:
> jetspeed-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> jetspeed-user-help@jakarta.apache.org
> >
> >
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> jetspeed-user-help@jakarta.apache.org
>
**********************************************
Vivendi Universal - HTTP://www.vivendiUniversal.com:
The information transmitted is intended only for the person or entity
to which it is addressed and may contain confidential and/or privileged
material of Vivendi Universal which is for the exclusive use of the
individual designated above as the recipient. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon,
this information by persons or entities other than the intended recipient
is prohibited. If you received this in error, please contact immediately
the sender by returning e-mail and delete the material from any computer.
If you are not the specified recipient, you are hereby notified that all
disclosure, reproduction, distribution or action taken on the basis of this
message is prohibited.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: J2 PSML persistence (was RE : Jetspeed performance [was RE: mast er detail records displaye d in a portlet])
Posted by David Sean Taylor <da...@bluesunrise.com>.
Hey, that was supposed to go to the dev list!
Guess I need to look at the reply-to field
Here it is again...
On Thursday, August 7, 2003, at 11:10 AM, David Sean Taylor wrote:
>
> On Thursday, August 7, 2003, at 09:54 AM, Luta, Raphael (VUN) wrote:
>
>>
>> [ moved to dev and renamed given the current content of the thread ]
>> For mt PSML stuff in JS2, I've currently broken down the persistence
>> options like this:
>> - PageManagerService:
>>
>> Function:
>> Handles page persistence (ie loading and saving pages and fragments
>> to
>> storage as well as creating new pages and fragments)
>>
>> Implementation:
>> I have 2 implementations in the works:
>> - XML/Castor, with XML files on disk (complete, I just need to
>> stop answering mails and write the related unit test files :)
>> - OJB based (through the persistence plug-in) (in progress, 80%
>> complete)
>>
> Do you mind if we look at this from the database table view?
> I know its a implementation detail, but Im interested in the database
> end of things, so if you don't mind
>
> Have you had a look at the DDL in the CVS?
> see create-db-phase2.sql
> The DDL does not have blobs.
> I was hoping that the database impl would not make use of blobs...
>
> I see the service as storing something like the PSML_ENTRY table (see
> the phase2 sql file)
>
>> For the XML files, the default service implementation just write
>> files in a flat directory, with files identified by an id (this
>> is different from JS1 behavior).
>>
>> Typical directory layout would be:
>> /WEB-INF/pages/
>> pageID1.psml
>> pageID2.psml
>> pageID3.psml
>> ...
>> pageIDX.psml
>>
>> - PageRegistryService
>>
>> Function:
>> Register available portal pages and map these pages to user and role
>> profiles. The API of this service will be an extension of the
>> default
>> Registry service
>>
>
> I see this service as storing the equivalent of the PSML table in the
> above sql fle
>
>> Implementation:
>> Again 2 implementations possible:
>> - XML/Castor based on the current JS1 registry code (70% complete)
>> - OJB/Persistence plug-in like the new PortletRegsitry written by
>> Scott (0% complete)
>>
>> With XML implementation, information is stored in one or several
>> xreg files in /WEB-INF/conf by default.
>>
>> Example of page registry entries:
>>
>> // default anonymous page for html markup
>> <page-entry default="true">
>> <media-type ref="html"/>
>> <page ref="pageID1"/>
>> </page-entry>
>>
>> // default page for any logged-in user
>> <page-entry name="home" user="*" default="true">
>> <meta-info>
>> <title>My Portal Home</title>
>> <descritpion>User Home page</description>
>> </meta-info>
>> <page ref="pageID2.psml"/>
>> </page-entry>
>>
>> // secondary page for any logged-in user
>> <page-entry name="news" user="*">
>> <meta-info>
>> <title>My News Page</title>
>> <descritpion>User specific news page</description>
>> </meta-info>
>> <page ref="pageID3.psml"/>
>> </page-entry>
>>
>> // custom news page for user raphael
>> <page-entry name="news" user="raphael">
>> <meta-info>
>> <title>My News Page</title>
>> <descritpion>User specific news page</description>
>> </meta-info>
>> <page ref="pageID4.psml"/>
>> </page-entry>
>>
>> // default news page for role admin, note that
>> // it can be the same ID that as above
>> <page-entry name="news" role="admin">
>> <meta-info>
>> <title>My News Page</title>
>> <descritpion>Role specific news page</description>
>> </meta-info>
>> <page ref="pageID4.psml"/>
>> </page-entry>
>>
>> This setup should IMO be both more efficient in the XML and
>> SQL persistent mode because of the flatter structure and be
>> more flexible because the PageRegistry allows a central page
>> repository and some user->page mappings that were not possible
>> in JS1, including the ability to "off-line" a page without
>> removing it physically.
>>
> For the file-based system, I see the big difference in that the PSML
> is not stored in a directory tree.
> All PSML is stored in one flat directory area, and a new XML file
> makes the mapping.
> I guess Im not too concerned, since I prefer to store in the DB.
> But it just makes me wonder about two things:
> 1. migration. people are used to the directory layout
> 2. Is this going to overly complicate the simple deployments
>
> I see the file-based solution best for users who need a simple portal
> that is easy to configure.
> The directory layout was very easy to understand.
>
> --
> David Sean Taylor
> Bluesunrise Software
> david@bluesunrise.com
> +01 707 773-4646
> +01 707 529 9194
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>
>
>
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
+01 707 773-4646
+01 707 529 9194
Re: J2 PSML persistence (was RE : Jetspeed performance [was RE: mast er detail records displaye d in a portlet])
Posted by David Sean Taylor <da...@bluesunrise.com>.
Hey, that was supposed to go to the dev list!
Guess I need to look at the reply-to field
Here it is again...
On Thursday, August 7, 2003, at 11:10 AM, David Sean Taylor wrote:
>
> On Thursday, August 7, 2003, at 09:54 AM, Luta, Raphael (VUN) wrote:
>
>>
>> [ moved to dev and renamed given the current content of the thread ]
>> For mt PSML stuff in JS2, I've currently broken down the persistence
>> options like this:
>> - PageManagerService:
>>
>> Function:
>> Handles page persistence (ie loading and saving pages and fragments
>> to
>> storage as well as creating new pages and fragments)
>>
>> Implementation:
>> I have 2 implementations in the works:
>> - XML/Castor, with XML files on disk (complete, I just need to
>> stop answering mails and write the related unit test files :)
>> - OJB based (through the persistence plug-in) (in progress, 80%
>> complete)
>>
> Do you mind if we look at this from the database table view?
> I know its a implementation detail, but Im interested in the database
> end of things, so if you don't mind
>
> Have you had a look at the DDL in the CVS?
> see create-db-phase2.sql
> The DDL does not have blobs.
> I was hoping that the database impl would not make use of blobs...
>
> I see the service as storing something like the PSML_ENTRY table (see
> the phase2 sql file)
>
>> For the XML files, the default service implementation just write
>> files in a flat directory, with files identified by an id (this
>> is different from JS1 behavior).
>>
>> Typical directory layout would be:
>> /WEB-INF/pages/
>> pageID1.psml
>> pageID2.psml
>> pageID3.psml
>> ...
>> pageIDX.psml
>>
>> - PageRegistryService
>>
>> Function:
>> Register available portal pages and map these pages to user and role
>> profiles. The API of this service will be an extension of the
>> default
>> Registry service
>>
>
> I see this service as storing the equivalent of the PSML table in the
> above sql fle
>
>> Implementation:
>> Again 2 implementations possible:
>> - XML/Castor based on the current JS1 registry code (70% complete)
>> - OJB/Persistence plug-in like the new PortletRegsitry written by
>> Scott (0% complete)
>>
>> With XML implementation, information is stored in one or several
>> xreg files in /WEB-INF/conf by default.
>>
>> Example of page registry entries:
>>
>> // default anonymous page for html markup
>> <page-entry default="true">
>> <media-type ref="html"/>
>> <page ref="pageID1"/>
>> </page-entry>
>>
>> // default page for any logged-in user
>> <page-entry name="home" user="*" default="true">
>> <meta-info>
>> <title>My Portal Home</title>
>> <descritpion>User Home page</description>
>> </meta-info>
>> <page ref="pageID2.psml"/>
>> </page-entry>
>>
>> // secondary page for any logged-in user
>> <page-entry name="news" user="*">
>> <meta-info>
>> <title>My News Page</title>
>> <descritpion>User specific news page</description>
>> </meta-info>
>> <page ref="pageID3.psml"/>
>> </page-entry>
>>
>> // custom news page for user raphael
>> <page-entry name="news" user="raphael">
>> <meta-info>
>> <title>My News Page</title>
>> <descritpion>User specific news page</description>
>> </meta-info>
>> <page ref="pageID4.psml"/>
>> </page-entry>
>>
>> // default news page for role admin, note that
>> // it can be the same ID that as above
>> <page-entry name="news" role="admin">
>> <meta-info>
>> <title>My News Page</title>
>> <descritpion>Role specific news page</description>
>> </meta-info>
>> <page ref="pageID4.psml"/>
>> </page-entry>
>>
>> This setup should IMO be both more efficient in the XML and
>> SQL persistent mode because of the flatter structure and be
>> more flexible because the PageRegistry allows a central page
>> repository and some user->page mappings that were not possible
>> in JS1, including the ability to "off-line" a page without
>> removing it physically.
>>
> For the file-based system, I see the big difference in that the PSML
> is not stored in a directory tree.
> All PSML is stored in one flat directory area, and a new XML file
> makes the mapping.
> I guess Im not too concerned, since I prefer to store in the DB.
> But it just makes me wonder about two things:
> 1. migration. people are used to the directory layout
> 2. Is this going to overly complicate the simple deployments
>
> I see the file-based solution best for users who need a simple portal
> that is easy to configure.
> The directory layout was very easy to understand.
>
> --
> David Sean Taylor
> Bluesunrise Software
> david@bluesunrise.com
> +01 707 773-4646
> +01 707 529 9194
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>
>
>
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
+01 707 773-4646
+01 707 529 9194
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: J2 PSML persistence (was RE : Jetspeed performance [was RE: mast er detail records displaye d in a portlet])
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Thursday, August 7, 2003, at 09:54 AM, Luta, Raphael (VUN) wrote:
>
> [ moved to dev and renamed given the current content of the thread ]
> For mt PSML stuff in JS2, I've currently broken down the persistence
> options like this:
> - PageManagerService:
>
> Function:
> Handles page persistence (ie loading and saving pages and fragments
> to
> storage as well as creating new pages and fragments)
>
> Implementation:
> I have 2 implementations in the works:
> - XML/Castor, with XML files on disk (complete, I just need to
> stop answering mails and write the related unit test files :)
> - OJB based (through the persistence plug-in) (in progress, 80%
> complete)
>
Do you mind if we look at this from the database table view?
I know its a implementation detail, but Im interested in the database
end of things, so if you don't mind
Have you had a look at the DDL in the CVS?
see create-db-phase2.sql
The DDL does not have blobs.
I was hoping that the database impl would not make use of blobs...
I see the service as storing something like the PSML_ENTRY table (see
the phase2 sql file)
> For the XML files, the default service implementation just write
> files in a flat directory, with files identified by an id (this
> is different from JS1 behavior).
>
> Typical directory layout would be:
> /WEB-INF/pages/
> pageID1.psml
> pageID2.psml
> pageID3.psml
> ...
> pageIDX.psml
>
> - PageRegistryService
>
> Function:
> Register available portal pages and map these pages to user and role
> profiles. The API of this service will be an extension of the default
> Registry service
>
I see this service as storing the equivalent of the PSML table in the
above sql fle
> Implementation:
> Again 2 implementations possible:
> - XML/Castor based on the current JS1 registry code (70% complete)
> - OJB/Persistence plug-in like the new PortletRegsitry written by
> Scott (0% complete)
>
> With XML implementation, information is stored in one or several
> xreg files in /WEB-INF/conf by default.
>
> Example of page registry entries:
>
> // default anonymous page for html markup
> <page-entry default="true">
> <media-type ref="html"/>
> <page ref="pageID1"/>
> </page-entry>
>
> // default page for any logged-in user
> <page-entry name="home" user="*" default="true">
> <meta-info>
> <title>My Portal Home</title>
> <descritpion>User Home page</description>
> </meta-info>
> <page ref="pageID2.psml"/>
> </page-entry>
>
> // secondary page for any logged-in user
> <page-entry name="news" user="*">
> <meta-info>
> <title>My News Page</title>
> <descritpion>User specific news page</description>
> </meta-info>
> <page ref="pageID3.psml"/>
> </page-entry>
>
> // custom news page for user raphael
> <page-entry name="news" user="raphael">
> <meta-info>
> <title>My News Page</title>
> <descritpion>User specific news page</description>
> </meta-info>
> <page ref="pageID4.psml"/>
> </page-entry>
>
> // default news page for role admin, note that
> // it can be the same ID that as above
> <page-entry name="news" role="admin">
> <meta-info>
> <title>My News Page</title>
> <descritpion>Role specific news page</description>
> </meta-info>
> <page ref="pageID4.psml"/>
> </page-entry>
>
> This setup should IMO be both more efficient in the XML and
> SQL persistent mode because of the flatter structure and be
> more flexible because the PageRegistry allows a central page
> repository and some user->page mappings that were not possible
> in JS1, including the ability to "off-line" a page without
> removing it physically.
>
For the file-based system, I see the big difference in that the PSML is
not stored in a directory tree.
All PSML is stored in one flat directory area, and a new XML file makes
the mapping.
I guess Im not too concerned, since I prefer to store in the DB.
But it just makes me wonder about two things:
1. migration. people are used to the directory layout
2. Is this going to overly complicate the simple deployments
I see the file-based solution best for users who need a simple portal
that is easy to configure.
The directory layout was very easy to understand.
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
+01 707 773-4646
+01 707 529 9194
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: J2 PSML persistence (was RE : Jetspeed performance [was RE: mast er detail records displaye d in a portlet])
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Thursday, August 7, 2003, at 09:54 AM, Luta, Raphael (VUN) wrote:
>
> [ moved to dev and renamed given the current content of the thread ]
> For mt PSML stuff in JS2, I've currently broken down the persistence
> options like this:
> - PageManagerService:
>
> Function:
> Handles page persistence (ie loading and saving pages and fragments
> to
> storage as well as creating new pages and fragments)
>
> Implementation:
> I have 2 implementations in the works:
> - XML/Castor, with XML files on disk (complete, I just need to
> stop answering mails and write the related unit test files :)
> - OJB based (through the persistence plug-in) (in progress, 80%
> complete)
>
Do you mind if we look at this from the database table view?
I know its a implementation detail, but Im interested in the database
end of things, so if you don't mind
Have you had a look at the DDL in the CVS?
see create-db-phase2.sql
The DDL does not have blobs.
I was hoping that the database impl would not make use of blobs...
I see the service as storing something like the PSML_ENTRY table (see
the phase2 sql file)
> For the XML files, the default service implementation just write
> files in a flat directory, with files identified by an id (this
> is different from JS1 behavior).
>
> Typical directory layout would be:
> /WEB-INF/pages/
> pageID1.psml
> pageID2.psml
> pageID3.psml
> ...
> pageIDX.psml
>
> - PageRegistryService
>
> Function:
> Register available portal pages and map these pages to user and role
> profiles. The API of this service will be an extension of the default
> Registry service
>
I see this service as storing the equivalent of the PSML table in the
above sql fle
> Implementation:
> Again 2 implementations possible:
> - XML/Castor based on the current JS1 registry code (70% complete)
> - OJB/Persistence plug-in like the new PortletRegsitry written by
> Scott (0% complete)
>
> With XML implementation, information is stored in one or several
> xreg files in /WEB-INF/conf by default.
>
> Example of page registry entries:
>
> // default anonymous page for html markup
> <page-entry default="true">
> <media-type ref="html"/>
> <page ref="pageID1"/>
> </page-entry>
>
> // default page for any logged-in user
> <page-entry name="home" user="*" default="true">
> <meta-info>
> <title>My Portal Home</title>
> <descritpion>User Home page</description>
> </meta-info>
> <page ref="pageID2.psml"/>
> </page-entry>
>
> // secondary page for any logged-in user
> <page-entry name="news" user="*">
> <meta-info>
> <title>My News Page</title>
> <descritpion>User specific news page</description>
> </meta-info>
> <page ref="pageID3.psml"/>
> </page-entry>
>
> // custom news page for user raphael
> <page-entry name="news" user="raphael">
> <meta-info>
> <title>My News Page</title>
> <descritpion>User specific news page</description>
> </meta-info>
> <page ref="pageID4.psml"/>
> </page-entry>
>
> // default news page for role admin, note that
> // it can be the same ID that as above
> <page-entry name="news" role="admin">
> <meta-info>
> <title>My News Page</title>
> <descritpion>Role specific news page</description>
> </meta-info>
> <page ref="pageID4.psml"/>
> </page-entry>
>
> This setup should IMO be both more efficient in the XML and
> SQL persistent mode because of the flatter structure and be
> more flexible because the PageRegistry allows a central page
> repository and some user->page mappings that were not possible
> in JS1, including the ability to "off-line" a page without
> removing it physically.
>
For the file-based system, I see the big difference in that the PSML is
not stored in a directory tree.
All PSML is stored in one flat directory area, and a new XML file makes
the mapping.
I guess Im not too concerned, since I prefer to store in the DB.
But it just makes me wonder about two things:
1. migration. people are used to the directory layout
2. Is this going to overly complicate the simple deployments
I see the file-based solution best for users who need a simple portal
that is easy to configure.
The directory layout was very easy to understand.
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
+01 707 773-4646
+01 707 529 9194