> > 1. I think we can store the portlet markup as relational fields.
> I think before we do this we have to ask ourselves where do we want the
> Portlet Markup to permanently reside. In a file or in a db?
It has to go in the database for persistence: I think we all agreed the
filesystem would be a messy solution. With PortletMarkeup, we can specify a
default set and a total set of portlets by writing a simple xml file. But when
it gets stored, it is placed in a relational structure that conforms to the
schema. It makes good sense to me then to reconstruct this xml from the
database whenever it is requested, but then to cache this generated xml and use
it if the user hasn't modified anything since the last request. That way, we
don't have to totally rewrite the PortletFactory again: we can use the same
system for both defaultPortlets.xml and individual custom user pages.
> You mean something like a virtual db. I am tentatively +1 but am not sure
> it is a priority, at least for me. IMHO, This could take a fair amount of
> work to do right. I think it would be slick if we set up our own JDBC
> drivers for a virtual db. We could have linkings of virtual table -> db
> and tablename. It would be fairly straightforward for simple queries like
> 'select * from tablename;', but could get ugly with such things as joins
> because the joins could conceivably span 2 or more databases. Then there
> is the whole issue of parsing the sql
Each user will have a set of rows in the db that list their portlets and any
options associated with them. We use the Turbine db for user authentication.
We shouldn't need to join with that table....
I mean, we should group the tables logically, but keep in mind that if there is
no reason to keep two tables together, give the option in the config files to
set up a different database. Or, to say that it should be the same as another
specified database if we have a small setup and don't anticipate the need for
multiple database servers/clusters.
> I agree with you that there is a need for this type of documentation. I
> also agree that the Jetspeed learning curve can be a deterrent to first
> time contributors. Of course XML/XSLT are still very much moving targets,
> maybe not so much the XML, but the transformations are definitely.
A lot of Jetspeed has nothing to do with XML. By the time it gets to the API
level, it's all pretty abstract. But, for somebody who doesn't know Turbine,
Village, Castor, or ECS, what exactly is going on?
First, a glossary of basic terms. Then a description of what processing
actually takes place when Turbine starts up. Something like a roadmap of how
the different branches of the API work together. It will be a nice complement
to the descriptions of the components that the existing Turbine and Jetspeed
documentation provide.
-ed
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
