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:
Do you mind if we look at this from the database table view?
[ 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)
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
For the file-based system, I see the big difference in that the PSML is not stored in a directory tree.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.
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 [EMAIL PROTECTED] +01 707 773-4646 +01 707 529 9194
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] +01 707 773-4646 +01 707 529 9194
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
