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 David Sean Taylor <da...@bluesunrise.com> on 2003/08/07 20:10:07 UTC
Re: J2 PSML persistence (was RE : Jetspeed performance [was RE: mast er detail records displaye d in a portlet])
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>.
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