On Friday, August 8, 2003, at 01:41 AM, Luta, Raphael (VUN) wrote:
De : David Sean Taylor [mailto:[EMAIL PROTECTED]On Thursday, August 7, 2003, at 09:54 AM, Luta, Raphael (VUN) wrote:
I don't think blobs would be necessary. I specifically kept a typed fragment class in the OM to be able to store fragments as rows in a single table.
Thus the schema (normalized) can look something like this:
TABLE PAGE ( PAGE_ID VARCHAR(32) PK, PAGE_TITLE VACHAR(128), PAGE_SKIN VARCHAR(128), PAGE_ACL VARCHAR(32), )
There isn't any (USER/GROUP/ROLE), MEDIA_TYPE, COUNTRY, PAGE Are we discontinuing this kind of support for pages (PSML)?
TABLE PAGE_DEFAULTS ( DEFAULTS_PAGEID VARCHAR(32) NOT NULL FK PAGE(PAGE_ID), DEFAULTS_FRAGMENT_TYPE CHAR(1) NOT NULL, DEFAULTS_DECORATOR VARCHAR(128) NOT NULL )
TABLE FRAGMENT ( FRAGMENT_ID VARCHAR(32) PK, FRAGMENT_PAGE_ID VARCHAR(32) NOT NULL FK PAGE(PAGE_ID), FRAGMENT_PARENT_ID VARCHAR(32) FK FRAGMENT(FRAGMENT_ID), FRAGMENT_TYPE CHAR(1) NOT NULL, FRAGMENT_NAME VARHCAR(128) NOT NULL, FRAGMENT_ACL VARCHAR(32), FRAGMENT_DECORATOR VARCHAR(128), FRAGMENT_SKIN VARCHAR(128), FRAGMENT_STATE CHAR(1), FRAGMENT_REF VARCHAR(32) FK FRAGMENT(FRAGMENT_ID) )
TABLE FRAGMENT_PROPERTY
(
PROPERTY_FRAGMENT_ID VARCHAR(32) NOT NULL FK FRAGMENT(FRAGMENT_ID),
PROPERTY_LAYOUT VARCHAR(128),
PROPERTY_NAME VARCHAR(128),
PROPERTY_VALUE LVARCHAR
)
My main concern right now is whether to keep this schema normalized with the costs associated for looking up an object tree or have a denormalization fields to speed up fragment requests. I'm not familiar enough with OJB to see right now if such a denormalization field could be easily used by OJB.
Yes, thats always a decision to be made.
I prefer to normalize it unless we really see a need to optimize (denormalize).
Speaking of OJB, here is an interesting feature that may be useful:
http://db.apache.org/ojb/howto-use-anonymous-keys.html
I see the service as storing something like the PSML_ENTRY table (see the phase2 sql file)
As you can see, it's pretty similar to phase2 except that I'm using varchar for keys instead of INT IDs, for 2 main reasons: - I wanted to use the impl objects for the time being for both XML and OBJ - I want to be able to store GUID/UUID as PK if we move this way.
no problem
Yes, similar but I'm still playing with exactly what attributes/objects I want to include in this registry (this will probably be the subject of another mail).
more flexibleImplementation: 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:
<snip markup examples>
This setup should IMO be both more efficient in the XML and SQL persistent mode because of the flatter structure and bebecause 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.
Concern 1: Luckily it's very easy to flatten a deep directory structure, actually mush easier than moving from one tree structure to another :) The PSML migration task will have to perform the following actions (assuming migration from PSML on disk) - create a new empty Page Registry (XML or OJB) - browse the PSML disk tree structure and for each PSML file found: - register the page in the page registry based on the directory path - extract the <entry> parameters and store them separately in the user preferences store (and create a new GUID for this entry) - transform the current PSML file to the new format through XSLT - store the tansformed page in the flat page store The most tricky action here is exporting the user prefs to another store because of the amount of ID messing involved.
Concern 2: Yes, it does add an additionnal step but OTOH, even when using disk based persistence I foresee a much greater reliance on tools/GUI for deployment issues that JS1. The PageRegistry will make implementation of an updated PsmlBrowser both much simpler and more powerful so there should be really fewer incentives to manipulate the psml files directly.
To add another point on the PSML XML vs SQL debate: in the proposed Page OM, the page description is completely user neutral and *never* stores any user-specific information even when it's shared by several logged-in users. Because of this, Page caching will be much more efficient and the portal should very rarely have to update the pages. That makes page loading performance from storage a much smaller issue than for JS1 and make the XML viable for larger deployments than in JS1.
Once users start customizing, the number of pages will increase.
I agree this will help the overall cache footprint to not create a new page until its needed
-- 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]
