Ed Knutson wrote:
>
> > The other drawback is that every project would need to include Castor.
>
> Why would it have to be cross project?
That is the point for the configuration stuff. That we minimize our
development resources. Something like a configuration repository is
Xproject.
> > I don't really see the advantage here. It would have to be smart enough
> > to know what these missing properties are. That and if they aren't used
> > they will get garbage collected.
>
> I'm basing this from the reactions I've seen from people trying to set up the
> system: the properties file is already a big headache for the average person
> trying to install the program. Once we have calendaring and messaging....
Hopefully if the average person ever sets up Jetspeed we will have an
Install Shield setup. Seriously if you can go through a properties file
you probably should be installing Jetspeed.
> The missing properties would be defined in the schema. The stylesheet which
> creates the admin screen would simply add a button for each undefined set of
> properties to create an empty (or default) structure for the given package and
> reload the screen with the new parameter fields.
Yes. And you don't put the missing elements in the instantiation if
won't validate against the schema :(
The admin screen is already done. It just enumerates over the
properties.
> > Don't bother with the parsing. Use Castor :) That is what it is there
> > for. I have already defined a Properties XML Schema that might be
> > useful. I experimented with marking up properties in feeds.xml.
>
> I was thinking Xerces. All I would have to do is set up SAXEventListeners
> which would set the appropriate properties during initialization.
Castor and xerces are different. Castor builds the API so you don't
have to think about xerces or SAX or DOM you just think about the API.
Much better ! :)
> I guess a lot of it depends on how much support Xerces has for schemas.
It is light.
> Basically, I think a well organized properties file would make the final
> product a lot more user-friendly---and the project in general easier to jump
> in and lend a hand with.
I don't see that. The current property system is actually *easier* than
it would be in XML. There is less code to look at and the format is
pretty much idiot proof. With XML you might screw up the format by not
completing the element. Using an element that isn't in the schema, etc.
> That could just mean organizing the file we have (eg,
> what is the difference between defaultportletcontrol.instance and
> portletcontrol.defaultinstance?). Either way, I did complete a sample file, so
> I'll add it to this mail, everyone can take a look, and we'll go from there....
<snip>
This is what I mean. There is no way that that is easier to manage than
a .properties file.
I am -1 for doing this. I went through this discussion in my head and
it just doesn't make sense. Even the Cocoon project which within Apache
has been more eager than any other project (less jetspeed) to except XML
(IE that is why it is xml.apache.org) is still using their
Properties/Configurations file.
There are also plenty of other places within Jetspeed that are broken.
:) The Properties configuration actually works so at the minimum lets
not break it :)
Kevin
--
Kevin A Burton ([EMAIL PROTECTED])
http://relativity.yi.org
Message to SUN: "Please Open Source Java!"
"For evil to win is for good men to do nothing."
--
--------------------------------------------------------------
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]
