On Mon, 3 Apr 2000, Ed Knutson wrote:
> > -1 for storing XML in the DB right now. Not unless we can map the XML
> > schema out into a DB schema.
>
> IMPORTANT ISSUES:
> 1. I think we can store the portlet markup as relational fields. Would it be
> better to write a new PortletFactory.getInstance() that receives a
> TurbineUserPeer as a parameter, or write a Cocoon (something-or-other) that
> retrieves this info from the db and formats it with a stylesheet to PSML, whose
> url may be supplied to the existing PortletFactory via RunData?
>
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?
> 2. Turbine comes with stored sql procedures for setting up the database. I
> think we should have a separate Jetspeed database. In fact, I think we should
> be able to specify a different database for each table, with the option to
> share. This will make clustering easier in high-performance environments.
>
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
Maybe I am getting a little grandiose ;).
> 3. Should the administrator be forced to set up each table, or should Jetspeed
> have some amount of control over this (such as creating a certain table if it
> doesn't already exist)?
>
I think for a first cut we go with a set up like Turbine where we have
canned scripts to run against the database that creates and initializes
the tables.
> >> I'm all for using as many different Apache projects as we can, but the
> >> barrier to entry on participating on this project is getting rather high.
> > OK. I don't want this. What can you suggest to improve what we
> > currently have?
> <snip/>
> > Docs are good. Maybe before the next release. Things are still up in
> > the air as well on certain things and once they settle down it will be
> > docs time again :)
>
> Tell you what. Right now, I'm at the point where I know enough to work on
> existing code but not enough to really write much of my own. While I still
> have the newbie perspective, I'm going to make some documentation of all the
> stuff I wish someone had told me 6 weeks ago (& stuff that didn't exist 6 weeks
> ago). Then, when things settle down, we can add more "advanced" literature.
> Just a primer on the API and how it is built on the /lib packages. Like the
> developer doc, but a bit more elaborate....
>
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.
I fought with whether or not to join Jetspeed with my calendar stuff
because I didnt really know anything about the XM* technologies which are
used heavily in Jetspeed. For me in the end, the added benefits of the
portal functionality was key. On one hand, I could have a calendar that
did x,y, and z or I could have a portal site w/ calendar.
Certainly, anyone contributing to Jetspeed will have personal motivations
and must be willing to learn. However, IMHO, anything we can do to reduce
the learning curve for new developers will be beneficial to Jetspeed.
It would be cool if we could have a 'Learn to be a Jetspeed developer 7
easy lessons :). I had found some links to some xml tutorials they could
be a start.
> -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]
>
Jeff Prickett
[EMAIL PROTECTED]
--
--------------------------------------------------------------
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]
