> +1. The only problem, and this is just a general technical problem not
> really Jetspeed related. Current DB absctraction/implementation APIs
> don't lend themselves to using XML that well. I would love to see a way
> to hide the DB persistence through an Avalon Block interface. We can
> them provide this back to the API
>
> Portlet API
> |
> Factory
> |
> Data Snap-in Framework ( Avalon )
> |
> | |
> XML Database (OPL, Castor JDO, Expresso DB impl, etc)
I was thinking of just storing the customized defaultPortlets as a VARCHAR.
I know this in some ways defeats the abstract advantages of using an
"XML-capable DBMS," but I think we can do this reasonably because the field is
generally accessed in its entirety. That is, we're usually going to read
this record when a user signs in (or write when saving settings) and then we
want the whole thing, which can then be parsed or have whatever Castor does
done to it.
We plug it into Jetspeed as a logical equivalent to defaultPortlets.xml. The
only time this would be disadvantageous would be storing a setting for an
individual portlet. We would have to write the entire record just to store one
setting. Is that performance trade off worth making our lives a lot more
complicated? I would say no, because I don't expect people to change
individual settings much. I assume people will be more interested in picking
what content they want; they may occasionally want to apply a different look,
but once they have the look they want, I doubt they'll change it much.
Of course, I haven't really looked at Avalon, but that brings up another issue:
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. On one hand,
I'm super happy the apidocs are posted on Jetspeed's web site. On the other
hand, I'm having a lot of trouble figuring out how to incorporate all these
other projects. I knew Cocoon before I started. Turbine is just beginning
to make sense. Jyve looks pretty straightforward but I still have to sit down
and look at all the source code....
Maybe what I really need is a sort of Getting Started with Jetspeed (like
Turbine has), except more focused on what all the different packages that come
with Jetspeed do. Maybe we could even do javadocs for all the packages in the
distro and put em up with the Jetspeed docs.
What do y'all think?
-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]
