You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Chuck Johnson <cd...@viviport.com> on 2001/06/18 15:31:26 UTC
PSML related object model
Raphael,
As I study the Jetspeed architecture and source code, one of the things that
troubles me is the object model surrounding the PSML and Portlets. As I can
tell, the basic flow is as follows:
PSML XML File --> Profiler Service --> Profile --> PSMLDocument -->
Portlets --> PortletSet
I'm not sure that I have this totally understood yet, but it seems to be an
area that has suffered from some evolutionary demise.
I think I have seen comments from David along these same lines, as well as
some comments in the code calling out areas for improvement. I was
wondering if there is any effort underway to streamline this part of the
object model.
Is this related to the effort described in the TODO as "Substitute the
layout engine with a new stream-based one"?
Thanks,
Chuck
--
Charles D. Johnson
Vice President of Engineering
ViviPort, Inc., North Andover, Massachusetts USA
978.686.0096 | cdjohns@viviport.com | www.viviport.com
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: PSML related object model
Posted by David Sean Taylor <da...@bluesunrise.com>.
Just wanted to point out that there is already a psml repository abstraction
in the cvs head:
See org.apache.jetspeed.services.PSMLManagerService.
Here is the interface:
public interface PsmlManagerService extends Service
{
/** The name of the service */
public String SERVICE_NAME = "PsmlManager";
/**
* Returns a PSML document of the given name.
* For this implementation, the name must be the document
* URL or absolute filepath
*
* @param name the name of the document to retrieve
*/
public PSMLDocument getDocument( String name );
/** Save the PSML document on disk, using its name as filepath
*
* @param doc the document to save
* @return true if the operation succeeded
*/
public boolean saveDocument(PSMLDocument doc);
/** Save the PSML document on disk to the specififed fileOrUrl
*
* @param fileOrUrl a String representing either an absolute URL
* or an absolute filepath
* @param doc the document to save
* @return true if the operation succeeded
*/
public boolean saveDocument(String fileOrUrl, PSMLDocument doc);
}
We also provide one implementation:
org.apache.jetspeed.services.psmlmanager.CastorPsmlManagerService.
This interface enables you to store your psml content in any persistent
store that you choose to implement, a database, ldap, etc... Jetspeed will
minimally provide the Castor-based XML persistence store. Castor also
supports a JDO-like persistence to databases, which we are also considering.
Considering a request for a psml resource, an inverted flow would be:
Request
-->Request -->
Request Parameters (mediatype,device caps,language,profile
params)
-->Profiler -->
Profile ( an abstract description of the requested resource )
--> Locator Service (this is currently coupled with the profiler)-->
(using the psml-manager interfaces to retrieve the document)
Document-Name (its currently a file-based path, this needs
improvement...)
--> PSML Manager.getDocument -->
PSML Document
IMO, we still need to refine the locator service/profiler issue, since the
profiler is now used to locate templates also.
----- Original Message -----
From: "Chuck Johnson" <cd...@viviport.com>
To: <je...@jakarta.apache.org>
Sent: Monday, June 18, 2001 6:31 AM
Subject: PSML related object model
> Raphael,
>
> As I study the Jetspeed architecture and source code, one of the things
that
> troubles me is the object model surrounding the PSML and Portlets. As I
can
> tell, the basic flow is as follows:
>
> PSML XML File --> Profiler Service --> Profile --> PSMLDocument -->
> Portlets --> PortletSet
>
> I'm not sure that I have this totally understood yet, but it seems to be
an
> area that has suffered from some evolutionary demise.
>
> I think I have seen comments from David along these same lines, as well as
> some comments in the code calling out areas for improvement. I was
> wondering if there is any effort underway to streamline this part of the
> object model.
>
> Is this related to the effort described in the TODO as "Substitute the
> layout engine with a new stream-based one"?
>
> Thanks,
> Chuck
>
> --
> Charles D. Johnson
>
> Vice President of Engineering
> ViviPort, Inc., North Andover, Massachusetts USA
> 978.686.0096 | cdjohns@viviport.com | www.viviport.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
RE: To create tables and Generate Reports using Hypersoonic SQL>>>>>>>>>>>>
Posted by David Sean Taylor <da...@bluesunrise.com>.
Websphere Portal Server - The next step after LoginThe Jetspeed distribution
includes a Hypersonic SQL database populated with some minimal rows for
users and related information.
You can run the Hypersonic SQL Administrator from /WEB-INF/db/manageDB.bat
I will check in a UNIX version as soon as I test it on Linux)
>From there, its pretty easy. Just type your SQL and execute it.
As for report writers, sorry but I don't know of any open source report
writers.
There are several commercial report writers available that work with any
JDBC-compliant driver, including Hypersonic SQL's driver.
As for general Hypersonic SQL questions, try here:
http://sourceforge.net/projects/hsqldb/
-------------------------------------
David Sean Taylor
taylor@apache.org
-------------------------------------
http://jakarta.apache.org/jetspeed
-------------------------------------
-----Original Message-----
From: Narayanan Natarajan
[mailto:natarajan_narayanan@nonhp-sg.exch.hp.com]
Sent: Monday, June 25, 2001 11:17 PM
To: jetspeed-dev@jakarta.apache.org;
jetspeed-user-help@jakarta.apache.org; jetspeed-dev-help@jakarta.apache.org
Subject: To create tables and Generate Reports using Hypersoonic
SQL>>>>>>>>>>>>
Hi,
Can you please help me out how to create tables using Hypersonic SQL and
generate reports from that?
Write me in detail about the information to create the new database using
Hypersonic SQL also.
Thanks,
Kind Regards,
Natarajan
To create tables and Generate Reports using Hypersoonic SQL>>>>>>>>>>>>
Posted by Narayanan Natarajan <na...@nonhp-sg.exch.hp.com>.
Websphere Portal Server - The next step after LoginHi,
Can you please help me out how to create tables using Hypersonic SQL and generate reports from that?
Write me in detail about the information to create the new database using Hypersonic SQL also.
Thanks,
Kind Regards,
Natarajan
Websphere Portal Server - The next step after Login
Posted by Nadine Boucher <nj...@entechnologies.com>.
Hi,
I am currently working with the WebSphere Portal Server 1.1.1. (WAS 3.5 with
IBM HTTP Server )
So far I never had to modified the default login --> portal processing.
Currently
I would like to display differents frames depending on a user login.
How can I retrieved after the login page, the Rundata object so I can then
retrieved the company name from a LDAP directory based on my userid. I do
not have
access to the loggin source code. The only thing I can do it is to
specified which servlet must be called if the user log in successfully.
How can I, from my servlet (which is call when a user log in successfully),
retrieved the rundata object (to eventually get the user object, then the
username)?
Thanks for your help!
Nadine
Re: PSML related object model
Posted by Frans Thamura <ft...@yahoo.com>.
Where I can get this information?? Like a draft concept of PSML, and why you
create PSML and what should I do learn it? both as a user and as a
developer.
I think, it is important for me?
Frans
----- Original Message -----
From: "Raphaël Luta" <ra...@networks.groupvu.com>
To: <je...@jakarta.apache.org>
Sent: Tuesday, June 19, 2001 12:02 AM
Subject: Re: PSML related object model
> Chuck Johnson wrote:
>
> > Raphael,
> >
> > As I study the Jetspeed architecture and source code, one of the things
that
> > troubles me is the object model surrounding the PSML and Portlets. As I
can
> > tell, the basic flow is as follows:
> >
> > PSML XML File --> Profiler Service --> Profile --> PSMLDocument -->
> > Portlets --> PortletSet
> >
> > I'm not sure that I have this totally understood yet, but it seems to be
an
> > area that has suffered from some evolutionary demise.
> >
>
>
> 3 quick notes on this:
> - first, there's definitely some "evolutionary" weight in the process and
it can
> definitely be streamlined
> - second, one of the major step for streamlining this is to remove the
Castor
> generated API and use a hand-craft OM API that is persisted using
Castor
> mapping files (ie do to PSML exactly what has been done for the
Registry)
> - third, the process you describe is not exactly linear as stated, the
relevant
> relations are rather:
>
> Profiler
> request parameters ---------------+---------------> Profile (config
locator)
>
> PsmlManager
>
> Profile ----------------+-------------------------> PSMLDocument
(config)
>
>
> PSMLDocument include a Portlets object (the config document itself)
> and provide manipulation methods on the document. These 2 objects will
> be merged together when the PSML API will be moved to an interface
based
> object model API.
>
> Once you have a PSMLDocument, you can completely manipulate the pane
> description for a given portal page, you only need to get a PortletSet
> if you want to render a page and actually have portlets processing the
> request.
>
>
> > I think I have seen comments from David along these same lines, as well
as
> > some comments in the code calling out areas for improvement. I was
> > wondering if there is any effort underway to streamline this part of the
> > object model.
> >
>
>
> The steps are defined, but right now, as far as I know, nobody is tackling
> them... feel free to step in.
>
>
> > Is this related to the effort described in the TODO as "Substitute the
> > layout engine with a new stream-based one"?
> >
>
>
> Somewhat related but not completely, the layout process needs to be
reimplmented
>
> to work better with the new Portlet API which is completely stream-driven.
> Right now, the buffered model of Turbine is expensive to use in Jetspeed
because
> we have to handle a lot more of small buffers generated by the different
control,
> controller and portlet. Switching to a pure stream model will probably
increase
> the global performance of the engine.
>
>
> --
> Raphael Luta - raphael.luta@networks.groupvu.com
> Vivendi Universal Networks - Paris
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: PSML related object model
Posted by Raphaël Luta <ra...@networks.groupvu.com>.
Chuck Johnson wrote:
> Raphael,
>
> As I study the Jetspeed architecture and source code, one of the things that
> troubles me is the object model surrounding the PSML and Portlets. As I can
> tell, the basic flow is as follows:
>
> PSML XML File --> Profiler Service --> Profile --> PSMLDocument -->
> Portlets --> PortletSet
>
> I'm not sure that I have this totally understood yet, but it seems to be an
> area that has suffered from some evolutionary demise.
>
3 quick notes on this:
- first, there's definitely some "evolutionary" weight in the process and it can
definitely be streamlined
- second, one of the major step for streamlining this is to remove the Castor
generated API and use a hand-craft OM API that is persisted using Castor
mapping files (ie do to PSML exactly what has been done for the Registry)
- third, the process you describe is not exactly linear as stated, the relevant
relations are rather:
Profiler
request parameters ---------------+---------------> Profile (config locator)
PsmlManager
Profile ----------------+-------------------------> PSMLDocument (config)
PSMLDocument include a Portlets object (the config document itself)
and provide manipulation methods on the document. These 2 objects will
be merged together when the PSML API will be moved to an interface based
object model API.
Once you have a PSMLDocument, you can completely manipulate the pane
description for a given portal page, you only need to get a PortletSet
if you want to render a page and actually have portlets processing the
request.
> I think I have seen comments from David along these same lines, as well as
> some comments in the code calling out areas for improvement. I was
> wondering if there is any effort underway to streamline this part of the
> object model.
>
The steps are defined, but right now, as far as I know, nobody is tackling
them... feel free to step in.
> Is this related to the effort described in the TODO as "Substitute the
> layout engine with a new stream-based one"?
>
Somewhat related but not completely, the layout process needs to be reimplmented
to work better with the new Portlet API which is completely stream-driven.
Right now, the buffered model of Turbine is expensive to use in Jetspeed because
we have to handle a lot more of small buffers generated by the different control,
controller and portlet. Switching to a pure stream model will probably increase
the global performance of the engine.
--
Raphael Luta - raphael.luta@networks.groupvu.com
Vivendi Universal Networks - Paris
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org