struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Miller" <k...@vardus.com>
Subject Re: Struts TODO List and Future Planning
Date Sat, 26 Aug 2000 22:21:47 GMT
Wow Craig, thank you so much for putting this list together. I was actually
astounded at how long this list is. I guess it goes to show just how much
demand there is for this type of framework.

> What I would like all of us to do is review the list, make sure I

I've gone through and added some comments about some of the items on the
list. If I haven't commented, I either don't know/don't mind, or am all for
it!

> others will require discussion.  Along the way, we might be faced with
> choices about breaking backwards compatibility in some places.  The goal
> of this exercize is to define the features we want to have in an
> "official" Struts 1.0 release -- after which, we will want to think much
> more carefully about breaking backwards compatibility.

Backwards compatibility - an important topic. I don't have a problem with
breaking it as required considering Struts is pre 1.0. I have quite a lot of
code that depends on Struts, but I'm willing to change my dependent code if
it means Struts becomes a better solution for us long-term. There will be
people who want backwards-compat *now*. I would suggest this is perhaps
asking a bit much in some cases - and besides, do you really want a Struts
v1.00 that already has a few kludges to work around compatibility issues?
The source code is there so you can always patch it to your needs anyway, or
you could just live with the current version. There shouldn't be too many
cases that require significant changes anyway?
I'd rather we made compatibility compromises now than get stuck with
anything nasty post 1.0. The cleaner we can get things now, the longer
Struts' life will be.

> JDBC Data Sources [org.apache.struts.jdbc]:

I'm not especially keen on adding much/anything in the way of database
support to Struts - the way I see it, that's not what Struts is all about.
Besides, JDBC/databases cover a *lot* of ground, and once the floodgates are
opened...  Perhaps a separate project?

> - Fix Checkboxes!!!  See many notes, including:  STRUTS-DEV (08/08/2000)
>   Jeff R.  Also see STRUTS-DEV (08/22/2000) Chris Miller.

I submitted a patch that partially solves this problem, however Colin
Sampaleanu suggested (08/25/2000 - "Handling checkboxes with struts") an
approach that I quite like the sound of too. Whatever approach is decided
on, it will need to be enhanced to cater for indexed properties.

> - Support "disabled" modifier (from HTML 4.0) on relevant tags.
>   STRUTS-USER (08/23/2000) "Re: A new attribute for struts' button tags".

This could probably be turned into a more generic statement: "Add full
support for HTML 4.0 attributes on relevant tags.". Or perhaps an attribute
could be provided that allows users to pass text directly though to the HTML
tag being rendered?
For example,

<struts:text property="next" passthrough="readonly disabled"/>

> - Support MessageResources capability to reload bundles that have been
>   updated.  Maybe have a switch for auto-reload that is useful during
>   development?  Motivation:  STRUTS-DEV (07/24/2000) Chris Miller.

Again this could probably be generalised a bit. Perhaps adding a
development="true" parameter to Struts that auto-reloads action.xml and
messages.properties if the timestamps change (and also does anything else
that aids development?).


Also, I just saw Paul Speed's email about the threaded action handling - I
like the sound of this (although I don't have a use for it myself
currently).


Chris Miller



Mime
View raw message