struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Mitchell" <jmitch...@apache.org>
Subject RE: Contributions
Date Thu, 27 Feb 2003 19:14:37 GMT
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


Mime
View raw message