You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Shawn Hainsworth <sh...@acedsl.com> on 2003/02/27 18:56:43 UTC
Contributions
I have made a number of extensions to Struts, some trivial and some
non-trivial, which I am interested in contributing. The extensions are:
/* ---- TRIVIAL EXTENSIONS ---- */
1) HashedDynaActionForm
* This class modifies the basic DynaActionForm by creating a
<code>HashMap</code> of
* dynaValues. DynaActionForms are made active by calling the setCurrent
method.
* Deep cloning is available for the hashed DynaActionForm values
2) PersistentDynaActionForm (HashedDynaActionForm extends
PersistentDynaActionForm)
* This class modifies the basic DynaActionForm by adding a boolean property
which
* indicates whether or not the reset method will be called. Normally, for
every
* action request, Struts will either instantiate or recycle the form bean,
calling
* the reset method to reset the fields to their default values. In some
cases,
* it is important to have the values persist between action requests.
3) DynaPropertyJSPMap
This class generates a mapping between properties in a DynaActionForm and
JSP views. DynaPropertyJSPMap uses a new class PageState and a new
TagSupport extension: ValidatePageStateTag. Useful for wizards or complex
forms where the user must move through views in a specific order.
Determining a specific mapping between properties and views at run-time
allows us to refine our business rules in a more re-usable manner
/* --------- NON-TRIVIAL EXTENSIONS ------- */
4) Validator extension to use Complex Rules, such as Field Dependency Rules
and Filter Rules. Any new kind of complex rule can be added to extend the
validator. For example, if the valid values of one property depend on the
current values of another property, this would be a field dependency rule.
If someProperty = 10, then someOtherProperty can be between 1 and 10. You
can also specify, if someProperty = someReferenceProperty, then
someOtherProperty can be between 10 and 100. Value checks can be combined
using standard boolean operators, and all relational operators have been
included, including regular expressions. Filter Rules apply to collections.
For example, let's say I have someCollectionProperty = {1,2,3,4,5}. If
someProperty > 42 then filter the values with some pre-defined filter (such
as values > 3 ) and someCollectionProperty will be returned as {4,5}. I can
provide a much more detailed description of this along with XML config
files.
5) A DynaBeanSQLMap framework
* DynaBeanSQLMaps are defined in an XML configuration file.
*
* You can define any number of SQL - DynaBean property maps
* in a single conf file. For example, if you have a DynaBean
* with data that comes from three different files requiring 5
* different SQL statements, you can define all 5 in this file.
* There is currently one <dynabean-sql-map-set> tag per
* configuration file, although more could be added easily.
* Each <dynabean-sql-map-set> tag as five child nodes:
* <dynabean-populate>, <dynabean-update>, <dynabean-insert>
* <dynabean-delete> and <field-mapping>. The only one that
* is mandatory is <field-mapping>, but obviously, if there
* are no other SQL_ACTION_TYPES defined, the functionality
* is limited. However, you can just define a <dynabean-populate>
* tag if there will never be any inserts, updates or deletes.
*
* The populate tag is used to define SQL statements to select
* data and populate dynabean properties. The update tag is used
* to define SQL statements to update values in the database
* from bean properties, and an insert statement is used to
* define SQL statements to insert a new record into
* the database using values from bean properties.
* The delete statement will delete records based on a key.
*
* Each of these four tags contains any number of <sql-statement>
* tags. Each <sql-statement> represents a relationship between
* one SQL statement and certain DynaForm properties. These use
* datasources specified in struts-config.xml
*
* In addition, each of the four tags described above: populate,
* update, insert and delete are given two attributes,
* a name and values-type. The name is to uniquely identify the
* statement within the tag, and the values-type can be either
* single or collection. Single values are where each field has
* only one value, and Collection values map a Collection property
* in a DynaBean to a Foreign Key dependent relationship in the
* database.
*
* The final tag is a <field-mapping> tag, which defines the
* mapping between the database field name and the dynabean
* property name.
*
* In a Collection value-type, you can only define one field in
* the SELECT statement of the populate SQL. This is the
* value which will be added to the collection for each
* row returned
In process:
1) An extenstion to the BeanUtils package of a TrueDynaBean/TrueDynaClass,
which can be generated on the fly without having to specify properties and
types in advance. This allows more dynamic DynaActionForms which do not
have to be pre-defined in struts-config.xml
2) A Javascript Menu framework, which will allow XML configuration for
dynamic menu creation, based on the role of the requestor.
These extensions will require a varying amount of work to be contributed to
the framework. I realize that there is a significant amount of work
involved for established contributors to review contibutions. If you are
interested, I can send one of the trivial extension initially, so that you
can review the style/quality of the code overall -- or if you are
particularly interested in one of the non-trivial extensions, I can prepare
that one for submission.
Thanks,
-----------------------------------------
Shawn Hainsworth
854 West 181st Street, #4B
New York, NY 10033
(212) 740-1935
shawn@hainsworth.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: Contributions
Posted by James Mitchell <jm...@apache.org>.
So what do you think Shawn? Care to join us on sf.net?
--
James Mitchell
Web Developer/Struts Evangelist
http://www.microsoft.com/struts/
> -----Original Message-----
> From: Ted Husted [mailto:husted@apache.org]
> Sent: Thursday, February 27, 2003 7:06 PM
> To: Struts Developers List
> Subject: Re: Contributions
>
>
> Yes, if Shawn wanted to develop these packages through the
> SourceForge
> site, that would be a good way to get the code out where the
> Community
> could use. All we would need is his SF ID.
>
> I've actually been wondering whether we should use the
> SourceForge site
> like our "sandbox". A real benefit of keeping a
> sandbox/dev.contrib area
> in a non-Apache CVS is that people can participate without
> going through
> the Apache Committer guantlet.
>
> There are a number of very good packages out there right now, like
> struts-layout and struts-menu, that are not getting the
> attention they
> deserve. I'd like to start upgrading the SourceForge site so
> that we can
> attract more of these packages, and make them
> community-developed resources.
>
> As it stands, I'm giving any developer with a working product
> all rights
> except admin. Admin status on the SF site is open to any interested
> Struts Committer.
>
> -Ted.
>
>
> James Mitchell wrote:
> > Sounds like some candidates for sf.net/struts, what do you
> think Ted?
> >
> >
> >
> > --
> > James Mitchell
> > Web Developer/Struts Evangelist
> > http://www.apache.org/struts/
> >
> >
> >
> >
> >>-----Original Message-----
> >>From: Shawn Hainsworth [mailto:shains@acedsl.com]
> >>Sent: Thursday, February 27, 2003 12:57 PM
> >>To: Struts-Dev@Jakarta. Apache. Org
> >>Subject: Contributions
> >>
> >>
> >>I have made a number of extensions to Struts, some trivial and some
> >>non-trivial, which I am interested in contributing. The
> >>extensions are:
> >>
> >>/* ---- TRIVIAL EXTENSIONS ---- */
> >>
> >>1) HashedDynaActionForm
> >>* This class modifies the basic DynaActionForm by creating a
> >><code>HashMap</code> of
> >>* dynaValues. DynaActionForms are made active by calling the
> >>setCurrent
> >>method.
> >>* Deep cloning is available for the hashed DynaActionForm values
> >>
> >>2) PersistentDynaActionForm (HashedDynaActionForm extends
> >>PersistentDynaActionForm)
> >>* This class modifies the basic DynaActionForm by adding a
> >>boolean property
> >>which
> >>* indicates whether or not the reset method will be called.
> >>Normally, for
> >>every
> >>* action request, Struts will either instantiate or recycle
> >>the form bean,
> >>calling
> >>* the reset method to reset the fields to their default
> >>values. In some
> >>cases,
> >>* it is important to have the values persist between
> action requests.
> >>
> >>3) DynaPropertyJSPMap
> >>This class generates a mapping between properties in a
> >>DynaActionForm and
> >>JSP views. DynaPropertyJSPMap uses a new class PageState and a new
> >>TagSupport extension: ValidatePageStateTag. Useful for
> >>wizards or complex
> >>forms where the user must move through views in a specific order.
> >>Determining a specific mapping between properties and views
> >>at run-time
> >>allows us to refine our business rules in a more re-usable manner
> >>
> >>/* --------- NON-TRIVIAL EXTENSIONS ------- */
> >>
> >>4) Validator extension to use Complex Rules, such as Field
> >>Dependency Rules
> >>and Filter Rules. Any new kind of complex rule can be added
> >>to extend the
> >>validator. For example, if the valid values of one property
> >>depend on the
> >>current values of another property, this would be a field
> >>dependency rule.
> >>If someProperty = 10, then someOtherProperty can be between 1
> >>and 10. You
> >>can also specify, if someProperty = someReferenceProperty, then
> >>someOtherProperty can be between 10 and 100. Value checks
> >>can be combined
> >>using standard boolean operators, and all relational
> >>operators have been
> >>included, including regular expressions. Filter Rules apply
> >>to collections.
> >>For example, let's say I have someCollectionProperty =
> >>{1,2,3,4,5}. If
> >>someProperty > 42 then filter the values with some
> >>pre-defined filter (such
> >>as values > 3 ) and someCollectionProperty will be returned
> >>as {4,5}. I can
> >>provide a much more detailed description of this along with
> XML config
> >>files.
> >>
> >>5) A DynaBeanSQLMap framework
> >> * DynaBeanSQLMaps are defined in an XML configuration file.
> >> *
> >> * You can define any number of SQL - DynaBean property maps
> >> * in a single conf file. For example, if you have a DynaBean
> >> * with data that comes from three different files requiring 5
> >> * different SQL statements, you can define all 5 in this file.
> >> * There is currently one <dynabean-sql-map-set> tag per
> >> * configuration file, although more could be added easily.
> >> * Each <dynabean-sql-map-set> tag as five child nodes:
> >> * <dynabean-populate>, <dynabean-update>, <dynabean-insert>
> >> * <dynabean-delete> and <field-mapping>. The only one that
> >> * is mandatory is <field-mapping>, but obviously, if there
> >> * are no other SQL_ACTION_TYPES defined, the functionality
> >> * is limited. However, you can just define a <dynabean-populate>
> >> * tag if there will never be any inserts, updates or deletes.
> >> *
> >> * The populate tag is used to define SQL statements to select
> >> * data and populate dynabean properties. The update tag is used
> >> * to define SQL statements to update values in the database
> >> * from bean properties, and an insert statement is used to
> >> * define SQL statements to insert a new record into
> >> * the database using values from bean properties.
> >> * The delete statement will delete records based on a key.
> >> *
> >> * Each of these four tags contains any number of <sql-statement>
> >> * tags. Each <sql-statement> represents a relationship between
> >> * one SQL statement and certain DynaForm properties. These use
> >> * datasources specified in struts-config.xml
> >> *
> >> * In addition, each of the four tags described above: populate,
> >> * update, insert and delete are given two attributes,
> >> * a name and values-type. The name is to uniquely identify the
> >> * statement within the tag, and the values-type can be either
> >> * single or collection. Single values are where each field has
> >> * only one value, and Collection values map a Collection property
> >> * in a DynaBean to a Foreign Key dependent relationship in the
> >> * database.
> >> *
> >> * The final tag is a <field-mapping> tag, which defines the
> >> * mapping between the database field name and the dynabean
> >> * property name.
> >> *
> >> * In a Collection value-type, you can only define one field in
> >> * the SELECT statement of the populate SQL. This is the
> >> * value which will be added to the collection for each
> >> * row returned
> >>
> >>In process:
> >>1) An extenstion to the BeanUtils package of a
> >>TrueDynaBean/TrueDynaClass,
> >>which can be generated on the fly without having to specify
> >>properties and
> >>types in advance. This allows more dynamic DynaActionForms
> >>which do not
> >>have to be pre-defined in struts-config.xml
> >>
> >>2) A Javascript Menu framework, which will allow XML
> configuration for
> >>dynamic menu creation, based on the role of the requestor.
> >>
> >>These extensions will require a varying amount of work to be
> >>contributed to
> >>the framework. I realize that there is a significant amount of work
> >>involved for established contributors to review contibutions.
> >> If you are
> >>interested, I can send one of the trivial extension
> >>initially, so that you
> >>can review the style/quality of the code overall -- or if you are
> >>particularly interested in one of the non-trivial extensions,
> >>I can prepare
> >>that one for submission.
> >>
> >>Thanks,
> >>
> >>-----------------------------------------
> >>Shawn Hainsworth
> >>854 West 181st Street, #4B
> >>New York, NY 10033
> >>(212) 740-1935
> >>shawn@hainsworth.org
> >>
> >>
> >>------------------------------------------------------------
> ---------
> >>To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >>
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
> >
>
>
> --
> Ted Husted,
> Struts in Action <http://husted.com/struts/book.html>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Contributions
Posted by Ted Husted <hu...@apache.org>.
Yes, if Shawn wanted to develop these packages through the SourceForge
site, that would be a good way to get the code out where the Community
could use. All we would need is his SF ID.
I've actually been wondering whether we should use the SourceForge site
like our "sandbox". A real benefit of keeping a sandbox/dev.contrib area
in a non-Apache CVS is that people can participate without going through
the Apache Committer guantlet.
There are a number of very good packages out there right now, like
struts-layout and struts-menu, that are not getting the attention they
deserve. I'd like to start upgrading the SourceForge site so that we can
attract more of these packages, and make them community-developed resources.
As it stands, I'm giving any developer with a working product all rights
except admin. Admin status on the SF site is open to any interested
Struts Committer.
-Ted.
James Mitchell wrote:
> Sounds like some candidates for sf.net/struts, what do you think Ted?
>
>
>
> --
> James Mitchell
> Web Developer/Struts Evangelist
> http://www.apache.org/struts/
>
>
>
>
>>-----Original Message-----
>>From: Shawn Hainsworth [mailto:shains@acedsl.com]
>>Sent: Thursday, February 27, 2003 12:57 PM
>>To: Struts-Dev@Jakarta. Apache. Org
>>Subject: Contributions
>>
>>
>>I have made a number of extensions to Struts, some trivial and some
>>non-trivial, which I am interested in contributing. The
>>extensions are:
>>
>>/* ---- TRIVIAL EXTENSIONS ---- */
>>
>>1) HashedDynaActionForm
>>* This class modifies the basic DynaActionForm by creating a
>><code>HashMap</code> of
>>* dynaValues. DynaActionForms are made active by calling the
>>setCurrent
>>method.
>>* Deep cloning is available for the hashed DynaActionForm values
>>
>>2) PersistentDynaActionForm (HashedDynaActionForm extends
>>PersistentDynaActionForm)
>>* This class modifies the basic DynaActionForm by adding a
>>boolean property
>>which
>>* indicates whether or not the reset method will be called.
>>Normally, for
>>every
>>* action request, Struts will either instantiate or recycle
>>the form bean,
>>calling
>>* the reset method to reset the fields to their default
>>values. In some
>>cases,
>>* it is important to have the values persist between action requests.
>>
>>3) DynaPropertyJSPMap
>>This class generates a mapping between properties in a
>>DynaActionForm and
>>JSP views. DynaPropertyJSPMap uses a new class PageState and a new
>>TagSupport extension: ValidatePageStateTag. Useful for
>>wizards or complex
>>forms where the user must move through views in a specific order.
>>Determining a specific mapping between properties and views
>>at run-time
>>allows us to refine our business rules in a more re-usable manner
>>
>>/* --------- NON-TRIVIAL EXTENSIONS ------- */
>>
>>4) Validator extension to use Complex Rules, such as Field
>>Dependency Rules
>>and Filter Rules. Any new kind of complex rule can be added
>>to extend the
>>validator. For example, if the valid values of one property
>>depend on the
>>current values of another property, this would be a field
>>dependency rule.
>>If someProperty = 10, then someOtherProperty can be between 1
>>and 10. You
>>can also specify, if someProperty = someReferenceProperty, then
>>someOtherProperty can be between 10 and 100. Value checks
>>can be combined
>>using standard boolean operators, and all relational
>>operators have been
>>included, including regular expressions. Filter Rules apply
>>to collections.
>>For example, let's say I have someCollectionProperty =
>>{1,2,3,4,5}. If
>>someProperty > 42 then filter the values with some
>>pre-defined filter (such
>>as values > 3 ) and someCollectionProperty will be returned
>>as {4,5}. I can
>>provide a much more detailed description of this along with XML config
>>files.
>>
>>5) A DynaBeanSQLMap framework
>> * DynaBeanSQLMaps are defined in an XML configuration file.
>> *
>> * You can define any number of SQL - DynaBean property maps
>> * in a single conf file. For example, if you have a DynaBean
>> * with data that comes from three different files requiring 5
>> * different SQL statements, you can define all 5 in this file.
>> * There is currently one <dynabean-sql-map-set> tag per
>> * configuration file, although more could be added easily.
>> * Each <dynabean-sql-map-set> tag as five child nodes:
>> * <dynabean-populate>, <dynabean-update>, <dynabean-insert>
>> * <dynabean-delete> and <field-mapping>. The only one that
>> * is mandatory is <field-mapping>, but obviously, if there
>> * are no other SQL_ACTION_TYPES defined, the functionality
>> * is limited. However, you can just define a <dynabean-populate>
>> * tag if there will never be any inserts, updates or deletes.
>> *
>> * The populate tag is used to define SQL statements to select
>> * data and populate dynabean properties. The update tag is used
>> * to define SQL statements to update values in the database
>> * from bean properties, and an insert statement is used to
>> * define SQL statements to insert a new record into
>> * the database using values from bean properties.
>> * The delete statement will delete records based on a key.
>> *
>> * Each of these four tags contains any number of <sql-statement>
>> * tags. Each <sql-statement> represents a relationship between
>> * one SQL statement and certain DynaForm properties. These use
>> * datasources specified in struts-config.xml
>> *
>> * In addition, each of the four tags described above: populate,
>> * update, insert and delete are given two attributes,
>> * a name and values-type. The name is to uniquely identify the
>> * statement within the tag, and the values-type can be either
>> * single or collection. Single values are where each field has
>> * only one value, and Collection values map a Collection property
>> * in a DynaBean to a Foreign Key dependent relationship in the
>> * database.
>> *
>> * The final tag is a <field-mapping> tag, which defines the
>> * mapping between the database field name and the dynabean
>> * property name.
>> *
>> * In a Collection value-type, you can only define one field in
>> * the SELECT statement of the populate SQL. This is the
>> * value which will be added to the collection for each
>> * row returned
>>
>>In process:
>>1) An extenstion to the BeanUtils package of a
>>TrueDynaBean/TrueDynaClass,
>>which can be generated on the fly without having to specify
>>properties and
>>types in advance. This allows more dynamic DynaActionForms
>>which do not
>>have to be pre-defined in struts-config.xml
>>
>>2) A Javascript Menu framework, which will allow XML configuration for
>>dynamic menu creation, based on the role of the requestor.
>>
>>These extensions will require a varying amount of work to be
>>contributed to
>>the framework. I realize that there is a significant amount of work
>>involved for established contributors to review contibutions.
>> If you are
>>interested, I can send one of the trivial extension
>>initially, so that you
>>can review the style/quality of the code overall -- or if you are
>>particularly interested in one of the non-trivial extensions,
>>I can prepare
>>that one for submission.
>>
>>Thanks,
>>
>>-----------------------------------------
>>Shawn Hainsworth
>>854 West 181st Street, #4B
>>New York, NY 10033
>>(212) 740-1935
>>shawn@hainsworth.org
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
--
Ted Husted,
Struts in Action <http://husted.com/struts/book.html>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: Contributions
Posted by James Mitchell <jm...@apache.org>.
Sounds like some candidates for sf.net/struts, what do you think Ted?
--
James Mitchell
Web Developer/Struts Evangelist
http://www.apache.org/struts/
> -----Original Message-----
> From: Shawn Hainsworth [mailto:shains@acedsl.com]
> Sent: Thursday, February 27, 2003 12:57 PM
> To: Struts-Dev@Jakarta. Apache. Org
> Subject: Contributions
>
>
> I have made a number of extensions to Struts, some trivial and some
> non-trivial, which I am interested in contributing. The
> extensions are:
>
> /* ---- TRIVIAL EXTENSIONS ---- */
>
> 1) HashedDynaActionForm
> * This class modifies the basic DynaActionForm by creating a
> <code>HashMap</code> of
> * dynaValues. DynaActionForms are made active by calling the
> setCurrent
> method.
> * Deep cloning is available for the hashed DynaActionForm values
>
> 2) PersistentDynaActionForm (HashedDynaActionForm extends
> PersistentDynaActionForm)
> * This class modifies the basic DynaActionForm by adding a
> boolean property
> which
> * indicates whether or not the reset method will be called.
> Normally, for
> every
> * action request, Struts will either instantiate or recycle
> the form bean,
> calling
> * the reset method to reset the fields to their default
> values. In some
> cases,
> * it is important to have the values persist between action requests.
>
> 3) DynaPropertyJSPMap
> This class generates a mapping between properties in a
> DynaActionForm and
> JSP views. DynaPropertyJSPMap uses a new class PageState and a new
> TagSupport extension: ValidatePageStateTag. Useful for
> wizards or complex
> forms where the user must move through views in a specific order.
> Determining a specific mapping between properties and views
> at run-time
> allows us to refine our business rules in a more re-usable manner
>
> /* --------- NON-TRIVIAL EXTENSIONS ------- */
>
> 4) Validator extension to use Complex Rules, such as Field
> Dependency Rules
> and Filter Rules. Any new kind of complex rule can be added
> to extend the
> validator. For example, if the valid values of one property
> depend on the
> current values of another property, this would be a field
> dependency rule.
> If someProperty = 10, then someOtherProperty can be between 1
> and 10. You
> can also specify, if someProperty = someReferenceProperty, then
> someOtherProperty can be between 10 and 100. Value checks
> can be combined
> using standard boolean operators, and all relational
> operators have been
> included, including regular expressions. Filter Rules apply
> to collections.
> For example, let's say I have someCollectionProperty =
> {1,2,3,4,5}. If
> someProperty > 42 then filter the values with some
> pre-defined filter (such
> as values > 3 ) and someCollectionProperty will be returned
> as {4,5}. I can
> provide a much more detailed description of this along with XML config
> files.
>
> 5) A DynaBeanSQLMap framework
> * DynaBeanSQLMaps are defined in an XML configuration file.
> *
> * You can define any number of SQL - DynaBean property maps
> * in a single conf file. For example, if you have a DynaBean
> * with data that comes from three different files requiring 5
> * different SQL statements, you can define all 5 in this file.
> * There is currently one <dynabean-sql-map-set> tag per
> * configuration file, although more could be added easily.
> * Each <dynabean-sql-map-set> tag as five child nodes:
> * <dynabean-populate>, <dynabean-update>, <dynabean-insert>
> * <dynabean-delete> and <field-mapping>. The only one that
> * is mandatory is <field-mapping>, but obviously, if there
> * are no other SQL_ACTION_TYPES defined, the functionality
> * is limited. However, you can just define a <dynabean-populate>
> * tag if there will never be any inserts, updates or deletes.
> *
> * The populate tag is used to define SQL statements to select
> * data and populate dynabean properties. The update tag is used
> * to define SQL statements to update values in the database
> * from bean properties, and an insert statement is used to
> * define SQL statements to insert a new record into
> * the database using values from bean properties.
> * The delete statement will delete records based on a key.
> *
> * Each of these four tags contains any number of <sql-statement>
> * tags. Each <sql-statement> represents a relationship between
> * one SQL statement and certain DynaForm properties. These use
> * datasources specified in struts-config.xml
> *
> * In addition, each of the four tags described above: populate,
> * update, insert and delete are given two attributes,
> * a name and values-type. The name is to uniquely identify the
> * statement within the tag, and the values-type can be either
> * single or collection. Single values are where each field has
> * only one value, and Collection values map a Collection property
> * in a DynaBean to a Foreign Key dependent relationship in the
> * database.
> *
> * The final tag is a <field-mapping> tag, which defines the
> * mapping between the database field name and the dynabean
> * property name.
> *
> * In a Collection value-type, you can only define one field in
> * the SELECT statement of the populate SQL. This is the
> * value which will be added to the collection for each
> * row returned
>
> In process:
> 1) An extenstion to the BeanUtils package of a
> TrueDynaBean/TrueDynaClass,
> which can be generated on the fly without having to specify
> properties and
> types in advance. This allows more dynamic DynaActionForms
> which do not
> have to be pre-defined in struts-config.xml
>
> 2) A Javascript Menu framework, which will allow XML configuration for
> dynamic menu creation, based on the role of the requestor.
>
> These extensions will require a varying amount of work to be
> contributed to
> the framework. I realize that there is a significant amount of work
> involved for established contributors to review contibutions.
> If you are
> interested, I can send one of the trivial extension
> initially, so that you
> can review the style/quality of the code overall -- or if you are
> particularly interested in one of the non-trivial extensions,
> I can prepare
> that one for submission.
>
> Thanks,
>
> -----------------------------------------
> Shawn Hainsworth
> 854 West 181st Street, #4B
> New York, NY 10033
> (212) 740-1935
> shawn@hainsworth.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org