cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From burtonator <bur...@relativity.yi.org>
Subject Re: Cocoon and Jetspeed
Date Mon, 05 Jun 2000 23:33:42 GMT
Neeme Praks wrote:
<snip> 
> 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.
> 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.
> 

Yeah.  I agree.  But it would be nice if we could just think of the
whole thing (filesystem or DB) as XML and then deal with it that way.  I
don't see why XML is involved.

> > No.  The engine is smart enough to handle static files that
> > 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.

Yes.  This will work.  The XSP app just creates a new XML document
in-memory with castor and then writes it to disk.  Jetspeed is smart
enough to realized that the file has changed.
 
> >  We really just need to write a PSML
> > content provider
> > and abstract its data representation so that you can use a
> > 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...

fine.  At some point you need to hit the DB and this needs to be
abstracted.  Maybe Prowler is the solution... haven't looked at it yet
:(
 
<snip>
> > > I mean, if I want to return SAX events instead of ECS
> > element, how can I
> > > achieve that?
> >
> > ClearElement.  You can put whatever you want in there.  This
> > is how the
> > FileServerPortlet works, it just reads in any file and shoves
> > 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.

Well hopefully the ClearElement will be a valid document fragment (not
the DOM DocumentFragment) and it can snap into an XML schema (with
validation).  This is why it is important to pick the correct mime-type.
 
<snip>
> > 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
> > 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.

yes.  It will be much better :)

> 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.

Yeah.  I would agree.  If we do this it will probably be a while.  It
would have to go up for vote.  It could be possible to have a snap-in
cocoon implementation where you can select from Cocoon 1.7x or 2.0 but
this might be kludgy.  Certainly at some point it will be a requirement
to halt Jetspeed development and assure that the Cocoon 2.0 development
goes well.  I can't say when this will be though.
 
> 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.

Hopefully sooner than later :)
 
> > > But I'm still uneasy about putting in "dumb" CDATA
> > sections... I would
> > > rather leave this job totally to serializers. But I
> > understand that this
> > > wouldn't be possible if we want to support writing portlets with
> > > webmacro for example.
> >
> > We could do schema validation on the resulting XML document.
> > IE PSML ->
> > WAP Portlets -> combined WAP document -> schema validation.
> 
> well, but for this you would have to re-parse the CDATA sections...

yes.  True.  But in some situations they might not be parsed in the
first place.  Ex if you were to use Webmacro to write XML this wouldn't
be validated while it was produced so you wouldn't see a performance
hit.
 
<snip>
> > 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
> > 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.

If we do a URI provider mechanism.  Then maybe remote portlets could be
done.  I am still -1 because you can do this with with the JVM.
 
<snip>
-- 
Kevin A Burton (burton@apache.org)
http://relativity.yi.org
Message to SUN:  "Please Open Source Java!"
"For evil to win is for good men to do nothing."

Mime
View raw message