From neeme@one.lv Thu Jun 1 13:05:26 2000 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 34221 invoked from network); 1 Jun 2000 13:05:26 -0000 Received: from the.one.lv (159.148.169.70) by locus.apache.org with SMTP; 1 Jun 2000 13:05:26 -0000 content-class: urn:content-classes:message From: "Neeme Praks" To: Subject: RE: Cocoon and Jetspeed Date: Thu, 1 Jun 2000 15:06:46 +0200 Message-ID: <2ECFE9456D0F6A4FA77B38C25AAE230918F0@the.one.lv> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.4208.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Cocoon and Jetspeed Thread-Index: Ab/Kg44SZ/meq06gRnSl6o7HX7025wBPKl0w X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N Sorry for such a delay in answering but my daily job kept me too occupied to write any "in-depth" responses ;-) > -----Original Message----- > From: burtonator [mailto:burton@relativity.yi.org] > Sent: Wednesday, May 31, 2000 12:07 AM > To: cocoon-dev@xml.apache.org; jetspeed@list.working-dogs.com > Subject: Re: Cocoon and Jetspeed >=20 > Basically an XSP app that takes in an existing PSML document=20 > and renders > a UI for it. You would configure your PSML and then save it back to > disk. That is a lot less complicated than it really is. It=20 > is a large > job but it needs to be done. well, I think this makes things much less flexible. My suggestion would still be to use cocoon when reading the personal PSML file: if you store profiles in static files (as we have right now) you can use XSP (or whatever other cocoon method ) to return them as they are; however, I have the option to use XSP to generate the file from some other data source instead. How it could actually look like: you have the default.psml file that is actually an XSP page.=20 If anonymous user requests this page, XSP returns the default.psml file from the filesystem. If authenticated user requests this page, XSP returns the user personal page from the filesystem (stored as username.psml, for example). At the same time, this doesn't limit the developer to the default storage (filesystem). Instead, I could replace the logic in the XSP to get the data from database (or any other datastore) instead. Simple and powerful, isn't it? > No. The engine is smart enough to handle static files that=20 > change. If > you modify default.psml while Jetspeed is running it will rebuild your > PSML page for you. But I mean personalization-on-the-fly, not that I sometimes change the file and the _all_ users see these changes. What I mean is that the content is customized for _each_ individual user by the means of XSP page. > We really just need to write a PSML=20 > content provider > and abstract its data representation so that you can use a=20 > file or a DB. well, then we would be limited to file and DB, until somebody adds some other "content provider". As Stefano also pointed out, we could _reuse_ Cocoon's generating capabilities for this, instead of reinventing the wheel... > Do you mean the deployer? I think that by default a Portlet=20 > should have > the capability to support certain media types but it is up to its > deployment to determine if it can actually render these at runtime. ok > > (also goes together with the concept > > of "remote portlets"). >=20 > I didn't follow. I mean the case of storing stylesheet ref's in the registry vs. storing only capabilities in the registry and storing actual stylesheet ref's with the portlet. The second case is more preferable for the remote portlets idea: the portlet resides on remote server and the owner of that portlet can easily change the stylesheet ref's that are used for actual transformation of the XML portlet into target media (and all the Jetspeed servers that use that portlet would automatically update the rendering logic). In the first case the owner would have to notify all the Jetspeed servers that use his portlet about the change of stylesheet. > > So, the registry would store metadata about the portlet:=20 > where to find > > and how to access the portlet and what media types does it=20 > support. Then > > I would be up to the portlet developer to actually=20 > implement the support > > for these media types. >=20 > I see it the other way around, but yes. =20 Other way around? > > I mean, if I want to return SAX events instead of ECS=20 > element, how can I > > achieve that? >=20 > ClearElement. You can put whatever you want in there. This=20 > is how the > FileServerPortlet works, it just reads in any file and shoves=20 > it into a ClearElement. well, but here we arrive to the same problem of "dumb" string data: in order to do any sensible post-processing, Cocoon would have to parse the string (in ClearElement) and convert it to SAX events. Of course, this is a problem only if we would want to do some post-processing on the contents of ClearElement. > > Then again, if we could drop the support for everything else than > > cocoon, I think that would reduce the complexity... but we=20 > wouldn't lose > > anything in functionality, only gain... (OK-OK, I'm just speculating > > here ;-) >=20 > The other issue is the current Cocoon impl. Honestly, the Cocoon > integration isn't something that I am proud off. It forces us to have > RunData everywhere (which is a serious technical problem within the > core, IE if you wish to kick of a Thread you need to bring the RunData > with you :(). When Cocoon 2.0 ships (still 6 months away) we=20 > will be in a better place but until then we are still in a kludgy env :( I also think that Cocoon 2 will be the version of Cocoon that I would like to integrate Jetspeed with. The time delay is of course a problem, but I think we can influence the design of Cocoon 2 by taking the issue of integrating Jetspeed early in the process. Meanwhile I'll probably have to use the current state of Jetspeed to deliver a beta version of the product I'm working on. And then port it to Cocoon2/Jetspeed when it is finally there. > > But I'm still uneasy about putting in "dumb" CDATA=20 > sections... I would > > rather leave this job totally to serializers. But I=20 > understand that this > > wouldn't be possible if we want to support writing portlets with > > webmacro for example. >=20 > We could do schema validation on the resulting XML document. =20 > IE PSML -> > WAP Portlets -> combined WAP document -> schema validation. well, but for this you would have to re-parse the CDATA sections... > I thought this is what you were hinting at :)=20 >=20 > There is a document for doing this with JServ. It really=20 > should be done > at the Servlet engine level. ok, maybe. I'm not very familiar with servlet programming _yet_. > There is a security hole here in that if I put some Javascript into my > portlet and then cnn.com served a portlet from hacker.org, the > hacker.org person could get passwords from cookies on the=20 > cnn.com domain > :( Yes, that could be an issue... Then you would have to give the user a _serious_ warning that this can be major security hole and that he should only use portlets from trusted sources. > Still an interesting idea though... But maybe it should just be > something like RSS or XMLRPC. I mean essentially a Remote=20 > Portlet would > only be data communication and nothing else. =20 But this takes away much of the simplicity and flexibility, doesn't it? With remote portlets, a user could put together his own simple portlet on his homepage by following a few quite simple rules... without a need to learn the complex syntax of RSS or XMLRPC. Neeme