hi berin, xfp is a kind of xml-based scripting framework.
1) Is XFP an application framework where users extend the basic one and add their components later?
xfp itself is not actually built with avalon (for now). being it a "scripting" tool, users will use avalon components (and javabeans) as "variables". the framework must take care of managing the life-cycle of components. what i'm trying to do is somewhat similar to the <jsp:useBean> tag in jsp, but instead of supporting only javabeans, i'd like to manage avalon components.
2) Exactly how does XFP allow users to specify their own components?
xfp has its own XML configuration file, where users put their "scripts".
the xml the user has to write to get an instance of an avalon component would be something like this:
<attribute name="mycomponent" entity="component" class="org.myfirm.MyAvalonComponent">
<property name="myproperty">myvalue</property>
<property name="myproperty">myvalue</property>
</attribute>
I see. Now for a bigger picture look at things, are these scripts run only once, or are they kept around waiting the be rerun on demand? It is trivial enough to provide a hook to configure your component, but just how easy we make it should be determined on the scripts themselves.
In a way, you could look at the Cocoon sitemap as a "declarative script". In it we have defined a set of components (complete with configurations), as well as a set of rules for how to use those components as it processes requests. It embodies one approach.
So how does XFP integrate with other systems (I am assuming that is what it is designed for)?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
