Re: branching 1.2 and 1.3 and CVS reorg for TLP status
- Original Message - From: Ted Husted [EMAIL PROTECTED] Date: Sat, 20 Mar 2004 18:09:53 -0500 To: Struts Developers List [EMAIL PROTECTED] Subject: Re: branching 1.2 and 1.3 and CVS reorg for TLP status snip / Meanwhile, I would have no problem with calling for a VOTE on Commons Dev tonight to promote Commons Chain from the sandbox and roll the 1.0 release. I used it to good effect in an application based on Maverick, and it's certainly proved its worth in the Struts-Chain development. As mentioned elsewhere, I'm now taking a crack at a Commons-Chain-based MailReader. I totally agree Commons Chain is ready for a release. I've been using the chain for an application for the US Naval Undersea Warfare Center to help decompose complex data transformation processes and its been working great. Of course the release stamp would also sit better with our client :) Don -Ted. -- ___ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT][VOTE] Struts as an Apache Top Level Project
Sorry, I just moved from Hawaii to California so I haven't been following struts-dev like I should. About the TLP vote: +0 - no strong feelings one way or another Don - Original Message - From: Martin Cooper [EMAIL PROTECTED] Date: Thu, 11 Mar 2004 21:47:05 -0800 (PST) To: Struts Developers List [EMAIL PROTECTED] Subject: [RESULT][VOTE] Struts as an Apache Top Level Project The response to this vote has been unanimous, with all proposed PMC members responding except for two: Arron Bates and Don Brown. I have attempted to ping those two directly, but have not yet heard back. The next board meeting is March 17th, which is next Wednesday. I propose to submit our resolution this weekend, for consideration at that meeting. In the absence of responses from Arron and Don before then, I will remove their names from both lists. They will, of course, be welcome to join the PMC at a later time. If anyone has any objections to the above plan, please speak up now. -- Martin Cooper On Sat, 6 Mar 2004, Martin Cooper wrote: Following up on a brief thread on this list in December [1], Craig, Ted and I have put together a draft resolution to the board of directors [2], along with a cover letter [3], that would promote Struts to an Apache top-level project (TLP). The main reasons for moving to a TLP are described on the wiki [4]. In Craig's words, The short answer, though, is we will be in charge of our own releases (currently, the Jakarta PMC is the only body legally recognized to vote on releases of *any* software under Jakarta). In practice, we can really just continue doing what we've always done. As most of you are no doubt aware, several Jakarta sub-projects have already made the transition to TLPs, including Ant, Avalon, Gump, James, Log4J, Maven, OJB, and Torque. Most Jakarta PMC members seem to be in favour of the migrations, largely because a single PMC cannot possibly oversee a code base the size of all of Jakarta. If you're OK with Struts being a top-level Apache project, please respond to this thread with either a +1 or +0. Otherwise, please reply with your concerns. When we previously discussed this, it did not seem like anyone was opposed to the idea, but if anyone is, now is the time to speak up. The resolution as drafted lists the Struts Committers who could reasonably be considered active at this time. Of course, we should not put anyone on the PMC without their buy-in, so the final resolution would only list the Committers who responded to the Vote with a +1 or +0. The draft resolution also leaves the name of the Vice President blank. Craig seems like the logical candidate, and is willing to act in this capacity, but we wanted the VP selection to be a community decision. So, please also respond with your nomination for Vice President, Apache Struts. Here's my +1 on the resolution as drafted, and my +1 for Craig as Vice President. -- Martin Cooper [1] http://nagoya.apache.org/eyebrowse/SearchList?listId=[EMAIL PROTECTED]searchText=%22Why+you+*want*+to+be+on+the+PMC%22defaultField=subjectSearch=Search [2] http://www.apache.org/~martinc/struts/tlp/resolution.html [3] http://www.apache.org/~martinc/struts/tlp/cover.html [4] http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaPMCPropsedChanges - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- ___ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Proposal] ActionFactory refactoring
What if we extracted the creation of Actions and ActionForms (including
DynaActionForms) into an ActionFactory, overridable by the user?
Here's the problem as I see it: there is no simple way for a user to plug
in their own code to manage the creation of actions and action
forms. The actual creation is handled by static methods in
RequestUtils, obviously not overridable, leaving the only option to
extend RequestProcessor and duplicate a lot of logic.
Why would you want to plug in your own ActionFactory? My primary purpose
is to better integrate Inversion of Control (IoC), specifically Spring's
IoC, into Struts. By letting Spring create Struts objects, Spring can
handle any dependencies and configuration they need. Another use, as
stated in bug #23583
(http://issues.apache.org/bugzilla/show_bug.cgi?id=23583), could be a
factory that creates ActionForms using JavaAssist at runtime. Finally,
this factory would be an easy way for the user to create their own
DynaActionForms, particularly useful for unit testing.
Impact: This would have no impact on current Struts applications as it is
an internal refactoring and default behavior would remain the same.
Extensions that include custom RequestProcessors or interfere with object
creation might be affected.
Configuration: I'd recommend another attribute in the controller /
element in struts-config, possibily named actionFactoryClass, pointing
to the new ActionFactory implementation to use. If none specified, a
default factory which mimics current behavior would be used.
This is my proposed interface:
public interface ActionFactory {
public Action createAction(ActionServlet servlet);
public DynaActionForm createDynaActionForm(ActionServlet servlet,
FormBeanConfig config,
ActionConfig mapping);
public ActionForm createDefaultActionForm(ActionServlet,
FormBeanConfig config);
public ActionForm createActionForm(ActionServlet servlet,
FormBeanConfig config,
ActionConfig mapping);
}
Note createActionForm() creates either a DynaActionForm or ActionForm
depending on the config.
Comments? Obviously, I'd perform the refactorings if this feature was
agreed upon. Future targets for factories could include config objects:
http://issues.apache.org/bugzilla/show_bug.cgi?id=13638
Don
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] ActionFactory refactoring
On Fri, 2 Jan 2004, Vic Cekvenich wrote:
So here are comments:
- I like IoC idea! I prefer Nano, Hivemind or something else Jakarta
based. I have been using HiveMind on projects and it is very nice.
Exactly my point. Abstracting object creating into a factory would allow
you to create a factory that uses HiveMind. The IoC implementation
I mentioned wouldn't be a part of Struts, but rather for a Spring
plugin project I'm working on (http://struts.sf.net/struts-spring).
- I do not like any kind of factory. It's harder to teach and maintain
then just new(). Factory and pool had it's place in JDK 1.3, but a new()
is not bad in 1.4. Besides we know the type of object is comming, so no
reason for factory, it would just add complexity.
Perhaps we are speaking about different factories... All a factory
pattern does is hide the object creation details, not necessarily object
pooling which I'm not suggesting at all. This allows objects to be
created and therefore managed by custom code which could be an IoC impl or
a user's custom object factory. Furthermore, it makes it easy to change
class implementation either through a different interface impl or
subclass.
Finally, very few Struts apps would use their own factory, as this is more
of an internal refactoring. If anything, I think it would reduce
complexity as it cuts a section of code out of the huge RequestUtils.
- I like what Struts chain does, it's simple and clever and it shows
people how to create their own custom action that extend base action
with the user base. That should be the starting point and improvments
should be based on it, IMO. For example, calls from there to IoC. An IoC
Yes, with Struts chain, you would simply replace the command that creates
an action or action form, but still that duplicates logic. A simple
factory only handles creation, not checking to see if one already exists
like in the case of form beans.
More importantly, Struts chain isn't used now. RequestProcessor is. This
refactoring is fairly simple, backwards-compatible, and imposes zero or
little changes the user would notice. It would take probably a few hours
to code so little effort is wasted when the struts-chain move takes
place.
DAO that populates a XMLFormBean Document. Digester could be called via
IoC from CoR. I kind of think IoC is something users should do as calls
from Strut's CoR. I do have a question if struts chain already reads
digester or there is code someplace that does it or if I want to play
with it I have to read mapping by myslef?
commons-chain contains ConfigParser, which uses the digester to build
chains from XML, however this is completely optional. It is very easy to
build chains manually or from some other config source like a database.
The Struts-chain uses the ConfigParser to load its configuration.
Don
.V
ps: 2.0 wish: Call a use case implemnetation a bundle, same as other
light weight service implementation.
Don Brown wrote:
What if we extracted the creation of Actions and ActionForms (including
DynaActionForms) into an ActionFactory, overridable by the user?
Here's the problem as I see it: there is no simple way for a user to plug
in their own code to manage the creation of actions and action
forms. The actual creation is handled by static methods in
RequestUtils, obviously not overridable, leaving the only option to
extend RequestProcessor and duplicate a lot of logic.
Why would you want to plug in your own ActionFactory? My primary purpose
is to better integrate Inversion of Control (IoC), specifically Spring's
IoC, into Struts. By letting Spring create Struts objects, Spring can
handle any dependencies and configuration they need. Another use, as
stated in bug #23583
(http://issues.apache.org/bugzilla/show_bug.cgi?id=23583), could be a
factory that creates ActionForms using JavaAssist at runtime. Finally,
this factory would be an easy way for the user to create their own
DynaActionForms, particularly useful for unit testing.
Impact: This would have no impact on current Struts applications as it is
an internal refactoring and default behavior would remain the same.
Extensions that include custom RequestProcessors or interfere with object
creation might be affected.
Configuration: I'd recommend another attribute in the controller /
element in struts-config, possibily named actionFactoryClass, pointing
to the new ActionFactory implementation to use. If none specified, a
default factory which mimics current behavior would be used.
This is my proposed interface:
public interface ActionFactory {
public Action createAction(ActionServlet servlet);
public DynaActionForm createDynaActionForm(ActionServlet servlet,
FormBeanConfig config,
ActionConfig mapping);
public ActionForm createDefaultActionForm(ActionServlet
Re: [Proposal] ActionFactory refactoring
Yeah, I wasn't sure what to call them either. I think it would be nice to
have one that will create the form from the config, no matter what type it
is, but still have others that create the specific type. This is mostly
useful for testing as it makes it easy to create dynaforms, a feature I've
been hearing a lot. Of course, it could just be two methods, and if you
just wanted a dynaform, create a FormBeanConfig and set dynamic to true.
As for when, it doesn't matter. I could easily put it in over the
weekend, code and tests, but if we are trying to get 1.2 out the door, it
can wait.
Don
On Fri, 2 Jan 2004, Martin Cooper wrote:
Off the top of my head (meaning I haven't thought through all of the
possible ramifications yet ;), I like this idea. I know that when I added
factories to Commons FileUpload, it took the ability to customise things
to a level that just isn't possible with straight 'new' coding. I can see
how the same would be true for Actions as well.
I'm not sure about the specific API you suggest. I assume by default you
mean the non-dyna flavour? Something about the API doesn't feel right,
but I'll try to give it some thought later and see if I can come up with
anything better.
BTW, I assume you're proposing this as a post-1.2.0 change?
--
Martin Cooper
On Fri, 2 Jan 2004, Don Brown wrote:
What if we extracted the creation of Actions and ActionForms (including
DynaActionForms) into an ActionFactory, overridable by the user?
Here's the problem as I see it: there is no simple way for a user to plug
in their own code to manage the creation of actions and action
forms. The actual creation is handled by static methods in
RequestUtils, obviously not overridable, leaving the only option to
extend RequestProcessor and duplicate a lot of logic.
Why would you want to plug in your own ActionFactory? My primary purpose
is to better integrate Inversion of Control (IoC), specifically Spring's
IoC, into Struts. By letting Spring create Struts objects, Spring can
handle any dependencies and configuration they need. Another use, as
stated in bug #23583
(http://issues.apache.org/bugzilla/show_bug.cgi?id=23583), could be a
factory that creates ActionForms using JavaAssist at runtime. Finally,
this factory would be an easy way for the user to create their own
DynaActionForms, particularly useful for unit testing.
Impact: This would have no impact on current Struts applications as it is
an internal refactoring and default behavior would remain the same.
Extensions that include custom RequestProcessors or interfere with object
creation might be affected.
Configuration: I'd recommend another attribute in the controller /
element in struts-config, possibily named actionFactoryClass, pointing
to the new ActionFactory implementation to use. If none specified, a
default factory which mimics current behavior would be used.
This is my proposed interface:
public interface ActionFactory {
public Action createAction(ActionServlet servlet);
public DynaActionForm createDynaActionForm(ActionServlet servlet,
FormBeanConfig config,
ActionConfig mapping);
public ActionForm createDefaultActionForm(ActionServlet,
FormBeanConfig config);
public ActionForm createActionForm(ActionServlet servlet,
FormBeanConfig config,
ActionConfig mapping);
}
Note createActionForm() creates either a DynaActionForm or ActionForm
depending on the config.
Comments? Obviously, I'd perform the refactorings if this feature was
agreed upon. Future targets for factories could include config objects:
http://issues.apache.org/bugzilla/show_bug.cgi?id=13638
Don
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] ActionFactory refactoring
On Fri, 2 Jan 2004, Ted Husted wrote: snip / My one concern is the ActionServlet reference in the signature. I don't feel good about adding any more http dependencies to interfaces we may have to live with for some time. But it may be unavoidable, and when we do start encapsulating http, this whole she-bang might be encapsulated as well. I agree, however, when we do write Servlets out of Struts, I think everything will need to be rewritten, including this factory and the objects it creates. Since this is more of an internal refactoring than a new feature, I think we don't have to be as concerned about backward-compatibility, especially since writing Servlets out of Struts will break everything anyways. (of course by writing Servlets out of Struts I mean removing Servlet dependencies in Struts) If you can do it over the weekend, and post a patch that people could review first, and you felt confident in the code, I would say that it could still make the 1.2.0 cut. I feel strongly that we need to address the remaining problem reports regarding pagePattern et cetera. I'm actively working on the module examples application now, but the application and the fixes aren't going to happen before Monday. Of course, an equally reasonable opinion would be to hold the patch for after the 1.2.0 roll, so that it can live in the nightly build for awhile. But it seems like a fairly straight-forward matter to me, and should either work or not. Ok, sounds good. I'll create a bugzilla entry and post the patches there. Don -Ted. On Fri, 02 Jan 2004 12:17:16 -1000 (HST), Don Brown wrote: Yeah, I wasn't sure what to call them either. I think it would be nice to have one that will create the form from the config, no matter what type it is, but still have others that create the specific type. This is mostly useful for testing as it makes it easy to create dynaforms, a feature I've been hearing a lot. Of course, it could just be two methods, and if you just wanted a dynaform, create a FormBeanConfig and set dynamic to true. As for when, it doesn't matter. I could easily put it in over the weekend, code and tests, but if we are trying to get 1.2 out the door, it can wait. Don On Fri, 2 Jan 2004, Martin Cooper wrote: Off the top of my head (meaning I haven't thought through all of the possible ramifications yet ;), I like this idea. I know that when I added factories to Commons FileUpload, it took the ability to customise things to a level that just isn't possible with straight 'new' coding. I can see how the same would be true for Actions as well. I'm not sure about the specific API you suggest. I assume by default you mean the non-dyna flavour? Something about the API doesn't feel right, but I'll try to give it some thought later and see if I can come up with anything better. BTW, I assume you're proposing this as a post-1.2.0 change? -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Nighty Builds of Struts-Faces Integration Library
On Wed, 24 Dec 2003, Craig R. McClanahan wrote: snip / works. Tops on my list is ensuring that it works with Tiles as well ... most likely by having two different request processor subclasses and making you configure the one you need based on whether Tiles is in use or not. Not quite as transparent as the old release, but it should be able to work. In several Struts extension projects, I've been using a simliar technique. Take out all possible code out of your extended RequestProcessor and put it in a helper. Then create two RequestProcessors, one normal one and another that extends TilesRequestProcess; each rp delegates operation to the helper. Finally, create a plugin that detects which RequestProcess, the normal Struts one or Tiles one, is loaded and replace it with the appropriate custom request processor. This technique supports Tiles without requiring any additional config on the part of the user. Lars Hoss, another developer on SAIF, even went so far as to use byte-code processing to dynamically make the custom RequestProcessor extend the one that was already loaded. Of course the best option is to get the composable request processor operational :) Don PS. Mele Kalikimaka me ka Hauoli Makahiki Hou! (Merry Christmas and Happy New Year in Hawaiian) Craig PS: While nowhere near as cool as the gift of eternal life that we'll be celebrating tomorrow, please consider this a Christmas gift to all the Struts developers and users out there :-). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Yes, it is possible to do a lot of things with Struts currently, but for the most part, they are all hacks. With Struts 2.0, we have a chance to look at Struts best practices, other web frameworks, and current technologies to design Struts to be the best and easiest framework for web applications, and perhaps beyond. My point is we should look at whether to encourage through Struts design and documentation the combination of forms and actions, or keep the current design. In this process, I think it is important to look at other frameworks and the results of the design choices they made, particularly our close cousin WebWork2/XWork. Don On Sat, 20 Dec 2003, Ted Husted wrote: Don Brown wrote: Hmm...I'm not familiar with that discussion, but I don't see why general form functionality couldn't be defined in an interface, but the ActionForm left how it is. Of course we also have a chance to do what Craig said he'd change about Struts (at JavaOne 2003 JSF BOF) and combine forms and actions. WebWork2/XWork seems to have done well with that approach. It's been mentioned on the list that you can combine Actions and ActionForms already. All that's needed is an ActionForm subclass with an execute property, and a standard Action that simply returns that result instead: ExecuteForm ef = (ExecuteForm) form; return ef.execute(request,response,mapping,form); -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
I totally agree - let me clarify. I think Struts 2.0 could use an IoC framework like Spring to help improve its internal structure. Any configuration files should be stored in the Struts jar, but be able to be overridden by specifying an alternate IoC configuration path. This lets advanced users easily modify the structure of Struts itself, but not add complexity for the casual user. Of course, Spring and probably other frameworks allow you to easily customize the configuration process. Don On Thu, 18 Dec 2003, Martin Cooper wrote: On Wed, 17 Dec 2003, Don Brown wrote: Ok, I wasn't sure as I didn't want to distract from the onging 1.2.x release work. :) I'll throw out some ideas here, then develop them later in the wiki: - Make Inversion of Control central. By using an IoC framework to wire Struts together, it makes it really easy to extend or improve Struts not only for future development but for users as well. I'd recommend Spring's IoC impl as it is small (100k), really easy to use, and easily extendable. If we wanted to remain more agnostic, there are meta IoC frameworks that let you plug in Pico/Spring/Avalon, etc. I'm a little hesitant to start depending on other frameworks. It's not that I think they don't have anything to offer us, it's just what it does to the newcomer to Struts. If someone has to learn Struts *and* Spring (for example) to get going, then we've set the bar much higher. If we do end up deciding to depend on something like this, I believe we'll need to put in the work to make it look like Struts. Taking Spring as an example again, the substantial difference in the character of the XML config files would easily confuse a newcomer trying to get his/her head around the syntax. If we could make those files look like Struts config files (or vice versa, for that matter), that would help, though. -- Martin Cooper - Use XML Schema over DTD's. Give struts config its own default namespace to make it easier for users to mix in elements of other namespaces. An example would be adding custom documentation attributes and elements. Of course the usual arguments for XML Schema over DTD's apply as well. - Replace paths with URL's, allowing for a default protocol. An action path would look like action://foo or a tiles forward would be tiles://tilesdef This would make it easy to plug in handlers to support different presentation engines. If no protocol is specified, the path is handled as usual. - As Ted said, contine with the wildcard theme. Struts should do everything possible to cut down configuration. - Also, again totally agreeing with Ted, make everything interface based, have default implementations, and free apps of HTTP. Ideally, I'd like to see extra effort going into making it easy if not effortless to take a Struts 2.0 app and use the code in a portlet or web service environment. At least in my area, clients are wanting human and machine interfaces, with the human interface generally being behind a portal. Anyways, those are my brainstorming thoughts. If any look interesting, I'll write something up in the wiki. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Using JXPath is exactly what XMLForms (http://www.xmlforms.org) does to allow the form model to be anything from a DOM to a JavaBean or even a DynaBean. XMLForms came out of Cocoon, but I believe they still use something simliar. In stxx (http://stxx.sf.net), a Struts extension, I have been experimenting using XML as the data model for a form. It is particuarly useful as it allows forms to be simultaneously exposed via Struts and SOAP. Don On Thu, 18 Dec 2003, Craig R. McClanahan wrote: Quoting Mete Kural [EMAIL PROTECTED]: I am thinking of fliping sides on FormBean as interface, I am now leaning against formbeans being an interface. FormBean is a concept (properties that map to form elements), plus this idea of XML as a FormBean. It could be a List or String or anything. XML as a FormBean! That got my attention... Say we want to populate customer information where a user can edit it like in an Excel spreadsheet. If the Action accesses a web service and receives a SOAP response and some XML objects in the SOAP response, sometimes it is too much processing to convert XML to Java objects if it is a lot of XML (for example: If the web service returns a list of 50 customers with detailed info). In such cases it may make more sense to do an XSLT transformation over the XML objects and render the form. Any suggestions on how this could be done in Struts 2.0? The key to this, IMHO, is the expression language used to bind a reference to a field (say, in a JSP page) to some underlying data object representing the field's value. One very simple approach would be to teach BeanUtils and PropertyUtils how to treat the . operator differently when the base object is an Element (from the DOM API) ... it would find a child element with an element name equal to the property name. This would deal directly with any XML document totally based on elements (as opposed to attributes), in a very simple (and mostly backwards compatible) way, so it could therefore even be implemented in Struts 1.2.x. A more comprehensive (but tied to XML) approach would be to support the use of XPath for referencing elements and attributes in a DOM ... but ideally have a way to access trees of JavaBeans using the same search expressions. Tools like commons-jxpath make that pretty easy to do as well. If you can have pluggability in your binding expressions, you can adapt to pretty much any internal data representation. (That's one of the key reasons, for example, that JavaServer Faces supports pluggable VariableResolver and PropertyResolver implementations). Thanks, Mete Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
On Thu, 18 Dec 2003, PILGRIM, Peter, FM wrote: snip / What kind of Spring Framework classes would you want to use in Struts 2.0? The BeanWrapper and the BeanFactory are interesting ideas. An example of configuring commons DBCP is given http://www.springframework.org/docs/lightweight_container.html I am not convince however of the requirement for BeanFactory. I can understand if you need to have massive XML configuration and need to dynamic generate Beans (objects) at run-time. It is great but other than that I can really view to the advantage inverse of control there that Struts or Commons BeanUtils combine Digester could not do itself. Struts is great because it concentrates on doing one thing well MVC. I wouldn't want it to branch out go into a generic framework space e.g Avalon, Expresso, Keel, Spring, Pico etc. The major design difficulties are abstract away the request and response objects from the controller actions, and also configuration of any other front-end objects you need along the way. To a certain extent Commons Chain and its context leads the way regarding the former. I see Spring as helping Struts be better structure its internal components, specifically using a BeanFactory implementation. It would not replace struts-config in any way or even be exposed directly the a Struts application. The struts-chain request processor implementation makes it easy for Struts apps to plug in IoC frameworks themselves. I totally agree Struts shouldn't become some generic IoC framework, hence my suggestion of using Spring. The reason I think IoC is important for Struts 2.0 is for easier unit testing, more componentized development, easier to plug in alternate implementions of components like file upload, better dependency management, less object references, and easier for the advanced user to extend Struts in interesting ways. Notice these advantages are targeted for Struts developers and advanced Struts users. Don -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 *** The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. Authorised and regulated by the Financial Services Authority This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by The Royal Bank of Scotland plc in this regard and the recipient should carry out such virus and other checks as it considers appropriate. Visit our websites at: http://www.rbs.co.uk/CBFM http://www.rbsmarkets.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Yes, Spring is nice becuse not only does it provide a consistent factory-based implementation, but the code isn't dependent on Spring and could be replaced with some other IoC mechanism down the road if desired. Don On Fri, 19 Dec 2003, Ted Husted wrote: Don Brown wrote: I see Spring as helping Struts be better structure its internal components, specifically using a BeanFactory implementation. It would not replace struts-config in any way or even be exposed directly the a Struts application. The struts-chain request processor implementation makes it easy for Struts apps to plug in IoC frameworks themselves. I totally agree Struts shouldn't become some generic IoC framework, hence my suggestion of using Spring. Something Craig mentioned way back when was: * Ensure that all framework objects in 2.0 have consistent factory-based mechanisms to instantiate instances. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15604 is this an area where we could use Spring in our implemention? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Spring (was RE: Struts 2.0 Ideas)
On Fri, 19 Dec 2003, David Graham wrote: snip / The IoC topic deserves its own thread. Spring is bloated. It contains a DAO layer, JDBC helper library, Web MVC framework, IoC support, etc. I don't think we should be lugging around Spring inside of Struts. There are also non-technical aspects of Spring that have lowered my opinion of it. Actually, if anything, Spring is a good model of how to make code modular and accessible. Spring can be split up into different jars, each containing a major Spring functionality that can be used without the others. In this case, the IoC features are in a single jar, under 100k, and that jar doesn't contain any of the other code - Dao, JDBC, Web framework, or even AOP. I'm not up on the politics; I've just been using it for the last few months in several projects and been loving it. It really is some well-written, focused, code, IMO. If we want IoC inside of Struts we should look at something lighter weight like HiveMind. I'd also like some focused concrete examples of how IoC would benefit Struts internals before we decide to go that route. Yeah, I think we would need to stand a prototype up before we get too far down the requirements road. Especially things like IoC - it's hard to see their value until you see it in action or work with it personally. As for Hivemind, it could fit the bill as well, I just haven't worked with it at all. Kinda doubt it will be under 100k tho :) Don David Don -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Stxx and Multiple Presentation Engines in General (Re: Struts 2.0 Ideas)
Hmmm...that's a good question. I think there are pieces of stxx it would be good to provide with Struts for the casual user who wants to take an existing Struts action, and render content via XSLT/XSL-FO with little effort. To truely do XML processing right, however, I think a stronger solution of Struts and Cocoon integregated together is the answer. This, of course, would fall outside the scope of Struts core. Could stxx's XML processing features be put into Struts 1.x? Yes, but before that happens, I think some sort of url feature for forwarded paths should be put in first. This would allow a request to easily be forwarded to a different presentation system without modifying or overriding the request processor. For example, a forward to a jsp page could look like: jsp://Foo.jsp, for tiles: tiles://Foo.jsp, and for stxx: stxx://Foo.xsl. This feature would make it easy to have multiple presentation engines, a feature we say Struts supports, but it doesn't really. Don On Fri, 19 Dec 2003, Ted Husted wrote: Do we still want to integrate stxx into Struts 1.x? Don Brown wrote: Using JXPath is exactly what XMLForms (http://www.xmlforms.org) does to allow the form model to be anything from a DOM to a JavaBean or even a DynaBean. XMLForms came out of Cocoon, but I believe they still use something simliar. In stxx (http://stxx.sf.net), a Struts extension, I have been experimenting using XML as the data model for a form. It is particuarly useful as it allows forms to be simultaneously exposed via Struts and SOAP. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Stxx and Multiple Presentation Engines in General (Re: Struts 2.0 Ideas)
Yes, that is another way to handle it. I never liked that approach since it meant those urls could be accessed directly and I feel everything should be behind Struts and its security. Besides, that approach ties your app to the Servlet API. Don On Fri, 19 Dec 2003, Joe Germuska wrote: Could stxx's XML processing features be put into Struts 1.x? Yes, but before that happens, I think some sort of url feature for forwarded paths should be put in first. This would allow a request to easily be forwarded to a different presentation system without modifying or overriding the request processor. For example, a forward to a jsp page could look like: jsp://Foo.jsp, for tiles: tiles://Foo.jsp, and for stxx: stxx://Foo.xsl. This feature would make it easy to have multiple presentation engines, a feature we say Struts supports, but it doesn't really. I'm still uncomfortable with minting new URL schemes. Couldn't this be solved by deploying an additional servlet mapped to handle other extensions? This is how JSPs work as it is; if your deployment descriptor gave *.xsl to the STXX servlet, then requestDispatcher.forward() would give control to STXX just to do the view rendering. I thought this was how the Velocity/Struts integration stuff worked already. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com We want beef in dessert if we can get it there. -- Betty Hogan, Director of New Product Development, National Cattlemen's Beef Association - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Stxx and Multiple Presentation Engines in General (Re: Struts 2.0 Ideas)
Relying on the request dispatcher ties you to the Servlet API. Furthermore, extensions are inadequate as more than one handler, to use Joe's terminology, might be interested in a particular extension. If the URL idea is collectively shot down, I vote for Joe's idea of adding an attribute the the forward element. In either case, 100% backwards compatibility should be maintained. Don On Fri, 19 Dec 2003, Ted Husted wrote: Don Brown wrote: Yes, that is another way to handle it. I never liked that approach since it meant those urls could be accessed directly and I feel everything should be behind Struts and its security. Besides, that approach ties your app to the Servlet API. What's the Servlet API got to do with it? Instead of a .xls or .jsp reference, you could just as easily reference a .html or .php or .pdf resource. Of course, the others wouldn't have access to the Java contexts (at least not this side of JSR 223). But, mapping presentation engines to extensions is the de jure approach. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Stxx and Multiple Presentation Engines in General (Re: Struts 2.0 Ideas)
Lets start at the possible Use Cases. I see a web application wanting to have some actions be displayed as PDF's, others with a simple JSP page, still others with Tiles. I don't see the same action needing multiple forwards for each of the presentation types. If you are going to simultaneously expose an action via two different environments, say HTTP and SOAP, you will probably, in the SOAP case, have specific deployment configuration specific to SOAP and probably won't even be using struts-config.xml. If you are, I'd image you'd have one for HTTP and the other for SOAP, each with their respective view technologies. Currently, with stxx and I believe with tiles, you, as you said, put in a symbolic name that gets processed by the request processor. In stxx's case, it might look like: forward name=success path=success.dox / where the dox extension lets the stxx request processor know to send it to stxx, where it will probably be converted to success.xsl at some point. Yes, one solution could be to simply allow presentation engines to register extensions they want to handle and let them convert the string into a useful path of some sort. The advantage of the symbolic name is you can possibly encode more information to pass to the presentation tech, like simple/success.dox, which in the case of stxx, might be telling stxx to use the simple pipeline to process success.xsl. The disadvantage is it is kinda a hack and not particularly elegant. By explicitly specifying the presentation tech in either a separate attribute or the scheme of a URI, it is more clear. Taking into account the ability to pass parameters to the presentation engine either by encoding the info in a symbolic name or as part of a URI, perhaps another attribute wouldn't be adequate. In my stxx app, I make liberal use of encoding info in the symbolic name, using wildcards to extract that info within stxx pipelines. I originally suggested URI's to more standardize how info was encoded, but perhaps the symbolic name way would be more acceptable to some. Don On Fri, 19 Dec 2003, Joe Germuska wrote: At 12:14 PM -1000 12/19/03, Don Brown wrote: Relying on the request dispatcher ties you to the Servlet API. Furthermore, extensions are inadequate as more than one handler, to use Joe's terminology, might be interested in a particular extension. If the URL idea is collectively shot down, I vote for Joe's idea of adding an attribute the the forward element. In either case, 100% backwards compatibility should be maintained. Although now that we talk about it, I'm hesitant to put this in the forward config -- I'm afraid it would lead to people writing actions that were too conscious of the view handling. I imagine something like this, which I would not want to see: action type=MyAction forward name=httpSuccess path=success.jsp / forward name=httpFailure path=failure.jsp / forward name=soapSuccess path=success.xsl handler=stxx / forward name=soapFailure path=failure.xsl handler=stxx / /action Of course people can always do things the wrong ways... Is this better? action type=MyAction forward name=success path=success.jsp / forward name=failure path=failure.jsp / forward name=success handler=stxx path=success.xsl / forward name=failure handler=stxx path=failure.xsl / /action That is, multiple forwards with the same name, distinguished by their handlers? I don't like that much either, since it puts a lot of responsibility on mapping.findForward() So then it seems that a Tiles-ish solution might be better, where the path is another symbolic name, each kind of handler could potentially be configured with a way to dereference that symbolic name. What's the use case? Using one action to respond to HTTP, Portlet and SOAP, assuming that the control is the same but the view is different?Or is it using different view handlers in the same request domain -- that is some times you want to use JSP to respond to an HTTP request, and sometimes STXX or Velocity? If it's the first, you could expect the part of the request processor before the action is invoked to be able to leave a mark as to its ID, so that the corresponding view handler could take over after the action finishes. If it's the second, I'm having a hard time thinking of a clean way to organize that. I should be careful here, because I haven't had need for either of those cases myself. But in all my thinking about this, I wish it didn't have to be implemented using the current monolithic RequestProcessor -- do you guys still think we're on a 1.4 time frame for switching to a chain-based version? (as noted in the roadmap). Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com We want beef in dessert if we can get it there. -- Betty Hogan, Director of New Product Development, National Cattlemen's Beef Association
Struts 2.0 Discussion Forum
Is there one? I have several ideas I'd like to toss into the discussion.
Don
On 17 Dec 2003 [EMAIL PROTECTED] wrote:
husted 2003/12/17 12:49:28
Added: contrib/struts-jericho README.txt project.properties
project.xml
Log:
Create whiteboard directory for Struts-Jericho, a working proposal for Struts 2.x.
Revision ChangesPath
1.1 jakarta-struts/contrib/struts-jericho/README.txt
Index: README.txt
===
Jericho is a whiteboard proposal describing one possible implementation of Struts
2.x.
Since Struts 2.x is slated as a revolution, the Apache practice is to assign a
codename to a proposal until the Community comes to a consensus.
This proposal is called Jericho since it tries to tear-down the walls within the
Struts architecture. Jericho proposes to open-up Struts by
* Declaring interfaces for all core components.
* Providing working base implementations for all core components.
* Encapsulating alll path references within Location objects (fka
ActionForwards)and referring only to Locations from all other objects.
* Providing additional extension points from core components so that the
Inversion of Control pattern is fully realized.
* Providing POJO signatures that encapsulate HTTP classes so that applications
can be freed of HTTP semantics, if so desired.
* Retain optional access to HTTP objects so that applications can be free to do
whatever they need to do.
-Backward Compatibility-
Jericho is a revolution and backward compatability with prior versions of Struts
is not the prime consideration. However, care is being taken to create a clear
migration path, where practible, so that Jericho is available to the widest
community possible.
_DTD._ The Jericho Configuration file (DTD) builds on the best aspects of the
Struts 1.2 DTD. The elements are different but still similar. Our goal is to allow a
tool, such as a XLST processor, to migrate a Struts 1.2 DTD to Struts Jericho.
A second alternative to explore is to provide an alternate configuration loader
that would map the Struts 1.2 elements to Struts Jericho objects at initialization.
_Base Classes._ New base classes for Struts 1.2.x ActionForms and Actions are to
provided. These classes will provide the Struts 1.2.x behavior but also implement
the Struts Jericho interfaces, so that the framework can use them interchangeably.
These same techniques may be applied to provide adaptors for other frameworks, so
as to make Struts Jericho available to the widest community possible.
###
1.1 jakarta-struts/contrib/struts-jericho/project.properties
Index: project.properties
===
# ---
# P R O J E C T P R O P E R T I E S
# ---
compile.debug = on
compile.optimize = off
compile.deprecation = off
maven.linkcheck.enable=true
# documentation properties
maven.xdoc.date=left
maven.xdoc.version=${pom.currentVersion}
maven.xdoc.developmentProcessUrl=http://jakarta.apache.org/struts/status.html
1.1 jakarta-struts/contrib/struts-jericho/project.xml
Index: project.xml
===
?xml version=1.0 encoding=UTF-8?
project
extend../project.xml/extend
nameJericho/name
idstruts-jericho/id
currentVersion0.1-dev/currentVersion
inceptionYear2003/inceptionYear
shortDescriptionStruts Jericho 2.x Whiteboard/shortDescription
description
Jericho is a whiteboard proposal describing one possible implementation of
Struts 2.x.
Since Struts 2.x is slated as a revolution, the Apache practice is to
assign a codename to a proposal
until the Community comes to a consensus.
This proposal is called Jericho since it tries to tear-down the walls
within the Struts architecture.
/description
developers
developer
nameTed Husted/name
idhusted/id
email[EMAIL PROTECTED]/email
organization/organization
/developer
/developers
build
unitTest
includes
include**/*Test.java/include
/includes
/unitTest
/build
/project
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
On Wed, 17 Dec 2003, Joe Germuska wrote: - Make Inversion of Control central. By using an IoC framework to wire Struts together, it makes it really easy to extend or improve Struts not only for future development but for users as well. I'd recommend Spring's IoC impl as it is small (100k), really easy to use, and easily extendable. If we wanted to remain more agnostic, there are meta IoC frameworks that let you plug in Pico/Spring/Avalon, etc. Personally I suspect that a meta framework is more trouble than it's worth, although I haven't really looked at any too closely. (Have any pointers) So then, with specific frameworks, I don't understand how Pico's orientation towards constructors works in an environment where beans need to be dynamically instantiated, but perhaps I just haven't thought about it hard enough. Avalon seems too heavy, which leaves us (or me at least) with Spring and HiveMind. I haven't developed with either but so far the docs for Spring give me a warm fuzzy feeling while the HiveMind docs kind of scare me. HiveMind, from what I've read, is more service-oriented. I've been using Spring for a few months now and totally loving it. It completely stays out of your way, leaving your code with little or no Spring dependencies. Furthermore, it supports both javabean and constructor-style dependency resolution. - Use XML Schema over DTD's. Give struts config its own default namespace to make it easier for users to mix in elements of other namespaces. An example would be adding custom documentation attributes and elements. Of course the usual arguments for XML Schema over DTD's apply as well. XML Schema?! Naw, RelaxNG!!! After all, it is now an international standard (http://blogs.codehaus.org/people/bob/archives/000505_standards_are_great_everyone_should_have_one.html) Doesn't matter to me as long as I get namespace support :) - Replace paths with URL's, allowing for a default protocol. An action path would look like action://foo or a tiles forward would be tiles://tilesdef This would make it easy to plug in handlers to support different presentation engines. If no protocol is specified, the path is handled as usual. I'm a little sketched out about assigning schemes of our own. I see the motivation, and think the goal is good. Wonder if we could find another mechanism. Well, I've seen it used particularly in Forrest to good effect. The key is keeping the number of protocols to a small number, but allowing the user to develop more if they feel the need. Don - As Ted said, contine with the wildcard theme. Struts should do everything possible to cut down configuration. hear, hear! (, hear, hear, hear!!) - Also, again totally agreeing with Ted, make everything interface based, a few more hears here ;^) -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com We want beef in dessert if we can get it there. -- Betty Hogan, Director of New Product Development, National Cattlemen's Beef Association - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Nope, Spring is Apache-style, I just checked. You had me worried there for a minute :) Don On Wed, 17 Dec 2003, Sgarlata Matt wrote: - Original Message - From: Joe Germuska [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Wednesday, December 17, 2003 5:04 PM Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum) So then, with specific frameworks, I don't understand how Pico's orientation towards constructors works in an environment where beans need to be dynamically instantiated, but perhaps I just haven't thought about it hard enough. Avalon seems too heavy, which leaves us (or me at least) with Spring and HiveMind. I haven't developed with either but so far the docs for Spring give me a warm fuzzy feeling while the HiveMind docs kind of scare me. I agree with your assessment of frameworks 100%. However, Spring is under an LGPL license, so Struts can't use Spring unless either Struts switches to LGPL or Spring switches to ASF, right? It would be kind of silly for Struts to stay under ASF in this case, since the Spring license would force the undesirable LGPL clauses on any projects that were based on Struts. Am I right? Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Hmm...I'm not familiar with that discussion, but I don't see why general form functionality couldn't be defined in an interface, but the ActionForm left how it is. Of course we also have a chance to do what Craig said he'd change about Struts (at JavaOne 2003 JSF BOF) and combine forms and actions. WebWork2/XWork seems to have done well with that approach. Again, just throwing ideas out there :) Don On Wed, 17 Dec 2003, Edgar P Dollin wrote: And you're really going to have to break both of my arms and/or kick me out of Struts development if you want ActionForm *ever* changed to an interface again -- in *any* future Struts release. I think it's an absolutely horrible idea, for reasons that have been documented way too many times to count. Craig McClanahan - Also, again totally agreeing with Ted, make everything interface based, a few more hears here ;^) Joe Germuska The interface discussion has come up previously and there was some emotion tied to it. Edgar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Joe Germuska as a Struts Committer
+1 I thought he already was one :) Don On Sun, 7 Dec 2003, Martin Cooper wrote: Joe has been involved in the Struts community for some time now, and has been a great contributor on the -dev and -user lists, as well as in the bug database. I believe Joe would be a great asset to the team, and that it's time we invited him to join us as a Struts committer. Here's my +1. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven test run
Hmmm...I just updated, uncommented those two lines, and ran ant test.junit - all tests passed. Anyone else? Don On Thu, 27 Nov 2003, Ted Husted wrote: When I run the maven jar target, the upload tests fail (MultipartTestSuite). But, when I run the ant test.junit test, only the TestActionConfigMatcher test fails. Is it me, or do others share this experience? If so, any ideas as to why this would be? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-chain] Where to now?
Agreed, however couldn't we still offer struts-chain prebuilt, not in Struts core, but on the side to hopefully make it eaier for people to test it? While the code is pretty simple and I believe functional, I agree much work still has to be done before it is production ready - tiles support, unit tests, commons-chain release, and of course documentation. I'm thinking of Struts users that don't want to go through the hassle of setting up their environment for building struts-chain, but want to test its new features. Hopefully, we can find middle ground between build it yourself and official Struts code. It's really hard to get beta testers when, let's face it, our build is time consuming to setup. Don BTW, do we have nightly builds of Struts? If we could get nightly builds of struts-chains, that would certainly help. On Fri, 14 Nov 2003, Ted Husted wrote: David Graham wrote: I really think we should ship Struts 1.2 with either resources or chain but not both. We'll end up with another 1.1 once we start including more than 1 major change per release. I don't have the time right now to get resources or chain included for Struts 1.2 so I won't veto however you want to proceed. I'd suggest that we ship what we have now as 1.2 before adding Chain or Resources. We already moved to Commons Validator 1.1.1-dev, which I believe still needs to make a GA release. We (mostly David) did a lot of work pulling out deprecations that will affect a lot of existing applications. We should get those out there so people can start the de-deprecation process before putting anything else on the plate. The main holdup had been some of the tests were broken, but if those are fixed now, we should proceed with 1.2.0. But, under no circumstances should we allow our main trunk to become dependent on more than one prerelease JAR at a time. Right now, we have a dependence on Commons Validator 1.1.1-dev. Once CV 1.1.1 goes final, we should immediately release what we have as (another) 1.2.x, since that release would then have the potential of going GA. Once we hit that milestone (a Stuts 1.2.x release with CV 1.1.1 GA), we can look at adding a dependence on some other dev jar (Chain or Resources). But, as David said, we owe it to the community to avoid the 1.1 syndrome of juggling dependencies on other unreleased products. We have one prerelease dependency in the pipeline already. The Validator dependency must be resolved and made available in some kind of release (alpha, beta, GA) before adding another prerelease dependency. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multi Action servlet !
What about using Inversion of Control (IoC) to replace the current global context map? The action servlet loads up the IoC factory, initializing all objects, then puts the factory in the request attributes for each request, allowing other components, like taglibs, to be able to access that servlet's objects? Not only would this make managing dependencies much cleaner, but make it easier to extend Struts once class references were changed into interfaces. Of course since any objects that aren't pre-initialized can pull objects from the bean factory in the request, we can ensure that the servlets won't overlap. The impact to existing Struts can be minimal - we could even put IoC configuration in the jar to prevent any user confusion. For an IoC implementation, I've found Spring (http://www.springframework.org) to be very easy to use and straightforward, not to mention light weight, however it would be pretty easy to provide a few Struts classes to wrap the IoC framework to prevent being tied to one implementation. I'm no Spring expert, but I volunteer to do any work necessary, assuming the idea is approved. Don On Fri, 14 Nov 2003, Ted Husted wrote: The underlying problem is that Struts stores things directly in the application and session contexts under static names. So, the resources (in the generic sense) for one application can overwrite the other. One reason for modules is to put multiple sets of resources in the shared contexts under different names. An alternate design for the Struts 2.x timeframe might be to gather everything the framework uses into single context objects, perhaps named after the servlet. So the action servlet would have an action context in the application and session scope, and the differentAction servlet would have it's own differentAction context object. Inside of each context (a Map) would be things like the message resources and Locale the servlet and client are using. Then, when a request is being serviced, a default gateway context can be placed in the request that would link to the appropriate session and application contexts for a given controller instance. This is essentially what the module code does now, but with all the complications that backward compatibility brings. Of course, complications still arise. Such as if the action servlet changes the Locale for a client, is the differentAction servlet suppose to see that change? So, there might still be a global framework context at the top of the chain, which a controller instance could update and the other controllers could see. Another advantage here is that it would be easier for Struts applications to pass along its context to a business layer without binding that layer to HTTP. An Action could pass up the Context chain without passing the HTTP request itself, or pulling things out piecemeal. -Ted. [EMAIL PROTECTED] wrote: I'm with Edgar on this one - should it not be possible? Of course, I tried the following: servlet-mapping servlet-nameaction/servlet-name url-pattern*.do/url-pattern /servlet-mapping servlet-mapping servlet-namedifferentAction/servlet-name url-pattern*.dont/url-pattern /servlet-mapping with each mapping to different action servlets with different config files and everything got bunged up. It seems like it should have worked but alas. Perhaps it is a bit of a green question, but why would it not work? Best, Alvin Quoting Edgar P Dollin [EMAIL PROTECTED]: Why wouldn't changing the servlet mapping from *.do -- action servlet to *.[actiontype] -- [associated action servlet] work? As long as you are consistent would struts care? Edgar -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Friday, November 14, 2003 7:10 AM To: Struts Developers List Subject: Re: Multi Action servlet ! People have done it, but it's a delicate thing to try. The recommended approach is to use Struts 1.1 modules. To customize the front controller logic for each module, you can plug in alternate Request Processors if needed. This gives you all the benefits of having multiple servlets, without the extra overhead. (There is *no* performance benefit in having multiple servlets that do the same thing.) A better place to ask questions like this would be the Struts USER list. This is where you'd ask if we were going to support multiple servlets in the future. (Answer to that one: not any time soon.) -Ted. Karikalan Kumaresan wrote: Hi, Does anyone know, is it possible to have 2 action servlet configured in struts for different project in a same JVM/in same webserver. Cheers, Kari... -Original Message- From: Steve Raeburn [mailto:[EMAIL PROTECTED] Sent: 14 November 2003 07:15 To: Struts Developers List Subject: RE: Parsing Error in struts Most likely you haven't closed a JSP tag correctly. Try commenting
Re: Multi Action servlet !
On Fri, 14 Nov 2003, Ted Husted wrote: snip / Of course, we have the tyranny of the installed base to contend with. Right now, a lot of Struts-specific presentation code expects things to be stored in the shared contexts under the original keys. The module code was designed to swap things in and out for that reason. So, if backward compatibility is desirable, then the framework API object would have to do the same thing: push it's members into the original shared contexts before an Action or some tag tool were invoked. If that were accomplished, we could then deprecate accessing these resources from the shared locations, and eventually make everything available only through the framework API object. A framework API object should simplify the module implementation as well as the eventual portlet implementation, and would certainly be more testable. While I certainly am a huge fan of backwards compatibility, would that even be feasable? Take these chain of events: 1. Servlet 1 puts objects in context for action 1 2. Servlet 2 puts objects in context for action 2 3. Action 1 pulls out objects for Servlet 2 To rewrite all the code in the Struts CVS to use the framework API wouldn't be too difficult, however, its the third-party extensions, user actions, etc. which worry me. Perhaps a framework/services/IoC API should wait for a 2.0 release :/ If that's the case, I really want to start kicking 1.x releases out the door. What can I do to help? Don -Ted. Don Brown wrote: What about using Inversion of Control (IoC) to replace the current global context map? The action servlet loads up the IoC factory, initializing all objects, then puts the factory in the request attributes for each request, allowing other components, like taglibs, to be able to access that servlet's objects? Not only would this make managing dependencies much cleaner, but make it easier to extend Struts once class references were changed into interfaces. Of course since any objects that aren't pre-initialized can pull objects from the bean factory in the request, we can ensure that the servlets won't overlap. The impact to existing Struts can be minimal - we could even put IoC configuration in the jar to prevent any user confusion. For an IoC implementation, I've found Spring (http://www.springframework.org) to be very easy to use and straightforward, not to mention light weight, however it would be pretty easy to provide a few Struts classes to wrap the IoC framework to prevent being tied to one implementation. I'm no Spring expert, but I volunteer to do any work necessary, assuming the idea is approved. Don On Fri, 14 Nov 2003, Ted Husted wrote: The underlying problem is that Struts stores things directly in the application and session contexts under static names. So, the resources (in the generic sense) for one application can overwrite the other. One reason for modules is to put multiple sets of resources in the shared contexts under different names. An alternate design for the Struts 2.x timeframe might be to gather everything the framework uses into single context objects, perhaps named after the servlet. So the action servlet would have an action context in the application and session scope, and the differentAction servlet would have it's own differentAction context object. Inside of each context (a Map) would be things like the message resources and Locale the servlet and client are using. Then, when a request is being serviced, a default gateway context can be placed in the request that would link to the appropriate session and application contexts for a given controller instance. This is essentially what the module code does now, but with all the complications that backward compatibility brings. Of course, complications still arise. Such as if the action servlet changes the Locale for a client, is the differentAction servlet suppose to see that change? So, there might still be a global framework context at the top of the chain, which a controller instance could update and the other controllers could see. Another advantage here is that it would be easier for Struts applications to pass along its context to a business layer without binding that layer to HTTP. An Action could pass up the Context chain without passing the HTTP request itself, or pulling things out piecemeal. -Ted. [EMAIL PROTECTED] wrote: I'm with Edgar on this one - should it not be possible? Of course, I tried the following: servlet-mapping servlet-nameaction/servlet-name url-pattern*.do/url-pattern /servlet-mapping servlet-mapping servlet-namedifferentAction/servlet-name url-pattern*.dont/url-pattern /servlet-mapping with each mapping to different action servlets with different config files and everything got bunged up. It seems like it should have worked but alas. Perhaps it is a bit
*Config objects with references to ModuleConfig - Necessary?
I was looking at bug 22207 which is caused by FormBeanConfig having a reference to ModuleConfig, however in greping through the code, I couldn't find any instance where getModuleConfig was used. Furthermore, I don't see why a child object needs a reference to a parent one. It adds complexity and can cause problems, like the one noted here. Is there something I'm missing? Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.2.x [was Multi Action servlet !]
Ok, so we are moving to a Tomcat-style release numbering. How exactly do we make it clear that 1.2.0 will be beta quality while another in the 1.2.x line will be GA quality. One advantage of alpha, beta, and rc qualifiers is it is immediately obvious to users which one is which. I think tomcat is simplier, but it is also potentially more confusing. Don On Fri, 14 Nov 2003, Ted Husted wrote: Don Brown wrote: If that's the case, I really want to start kicking 1.x releases out the door. What can I do to help? The big stumbling block was that some of the tests weren't running. If they've been fixed, then anyone could cut a release when they felt the code base was ready. Like, say, now. :) The release guidelines are here: http://jakarta.apache.org/struts/releases.html and there's an old draft of a release plan here: http://jakarta.apache.org/struts/proposals/release-plan_1_2_0.html If someone else wants to jump and be the release manager, be my guest :) I still haven't actually gotten through the legacy LATER or REMIND tickets that we batch marked as part of the get 1.1 out the door initiative. But I have been through the truly old and decrepit ones, and enough may have been done on that score for now. I don't actually believe that the site documentation is ready for 1.2.x GA release yet. But, it doesn't have to be. We can cut a 1.2.0 to shake out what needs to be documented, make some updates, and then roll 1.2.1. The overall Jakarta mode seems to be 4-6 releases to a single GA release, so I wouldn't expect a GA until about 1.2.5 anyway. Of course, we will have to resolve the pending veto discussions before cutting a Struts release of any kind, but I imagine that can happen over the weekend, or even as part of a revised Release Plan. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[struts-chain] Where to now?
I added what I gathered was the last missing piece to struts-chain, file upload support. I'm really interested in doing whatever it takes to get this up and running as a viable alternative to the RequestProcessor. From here, I see the following needs to be done: - Unit tests (big one) - Tiles support - Portlet implementation - Documentation What is the status of commons-chain? Are there any outstanding issues that need to be sewn up? I think I will tackle the unit tests next. Tiles support should be pretty straightforward, some copy/paste. Craig had some ideas of how to support the Portlet API, which I'll leave to him until I can learn more about it. The documentation is the least important, at this stage, but it does help bring to light rough spots. Finally, what is that status on Struts 1.2? Could an early test version be put in for early adopters? Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re:Struts-chain
If you use the compile task (the default for the project), struts-chain
will build without any dependencies on the tomcat ant lib.
BTW, I'd recommend against cross posting...
Don
On Wed, 5 Nov 2003, BaTien Duong wrote:
Howdy:
I am trying to get Struts-chain up and running. I follow the instruction
of struts-chain in the cvs to build from the source:
export ANT_HOME=.../ant-1.6beta2
export JAVA_HOME=.../j2sdk1.4.2_02
export TOMCAT_HOME=.../tomcat-5.0.14
The build.properties is copied from the build.properties.sample
servlet.home=.../common/lib
struts.home=.../jakarta-struts-bin
chain.home=.../cvs/jakarta-commons-sandbox/chain
export
PATH=${PATH}:${JAVA_HOME}/bin:${ANT_HOME}/bin:${TOMCAT_HOME}/common/lib/servlet-api.jar:${TOMCAT_HOME}/server/lib/catalina-ant.jar
execute the following command at the struts-chain directory
[-]$ ant clean dist
I got the error:
/build.xml:54: taskdef class org.apache.catalina.ant.DeployTask could
not be found
Please feed me the latest instruction to create struts-chain.war
Thanks
BaTien
DBGROUPS
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: JSR-168 and Struts
Pretty much the only dependency of struts-chain is a recent build of jakarta-commons-sandbox/chain. To fully build commons-chain, in addition to other commons jars, you need the porlet api jar, the servlet jar, and the latest jsf jar from the sun web services pack 1.3 I believe. However, you should be able to build commons-chain with one of these jars missing if you don't need their related chain classes. Currently, struts-chain implements most of Struts functionality in the form of small commands, strung together by chain-config.xml. For any commands that would have a use outside servlets, there exist abstract classes in org.apache.struts.chain in the form of Abstract*.java which perform all possible tasks without accessing servlet apis. The abstract commands are implemented in o.a.s.c.servlet by servlet specific commands which handle all direct servlet contact. To make struts-chain work with the portlet api, a new package will be created, o.a.s.c.portlet, which will contain implementations of the abstract classes in o.a.s.chain. These commands will take the context, cast it into a PortletContext (I believe that's the name), and access portlet apis directly just as the servlet commands did. These commands, particularly the api dependent ones, are very short and should be very easy to port. Of course Struts in a portlet context will use a different chain-config.xml with commands pointing to the porlet implementations rather than the servlet ones, but it should pretty much be the same structure and behavior. I'm new to struts-chain, so hopefully this is an accurate description of the current state of struts-chain and how the portlet api will be supported. Don On Wed, 29 Oct 2003, Mete Kural wrote: Hello Struts and Pluto developers, There was a thread about developing JSR-168 support into Struts 2.0 in the pluto-dev list and we thought it might be best to continue this thread on both lists, pluto-dev and struts-dev synchronously. Below is the last email in the thread send by Scott Weaver to the pluto-dev list. Please reply all so that your emails will go to both groups. Thanks, Mete Scott's message: -- Original Message -- From: Weaver, Scott [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Wed, 29 Oct 2003 15:33:03 -0500 Hi Martin, -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 29, 2003 3:16 PM To: '[EMAIL PROTECTED]' Subject: RE: Pluto and Struts On Wed, 29 Oct 2003, Weaver, Scott wrote: Maybe it's just me, but I tried to build the contrib stuff in the CVS for struts a while back as I wanted to start taking a look at. However, I could never get it built. There were deps I had never heard of, nor did I know were to get them. If you could let me know what you're having problems with, I'll try to help you through getting it all built. The chances are that anything you haven't heard of comes from Jakarta Commons or the Commons Sandbox. (For example, 'chain' is currently in the sandbox.) I know most of the stuff in commons proper, I don't think that's were my issue lies. I am pretty sure it was chain that I couldn't find and, at the time, I am not sure it was available, even within commons-sandbox. I don't remember the specific issues as this was around 2 months ago when I last tried. I was actually having the same problem but from the other side of the coin, as it were. I need to build 'chain' against the Portlet API, but I couldn't get Pluto to build, and couldn't figure out the deps for that. (BTW, since Pluto's build.xml depends on ant-contrib, '-projecthelp' doesn't work until that's configured, which is quite mysterious until you look at the build file itself. ;) Try build driver, there are custom ant tasks that get included when you call the build script. I really don't do much at all with Pluto portal implementation in that my focus, concerning Jetspeed, is the core Pluto container itself. That is were I spend most of my time in regards to Pluto. That being said, there should be no fork in development to support either Pluto Portal or Jetspeed 2. In fact, if we do this correctly, the whole thing should be transparent to the Struts portlet app and that app should be easily portable to any other JSR-168 portal. p.s. I have no issues whatsoever with joining the Struts-dev mailing list, however, I think it might be in the best interest of all involved that we cross-post to both struts-dev and pluto-dev. I look forward to working with you. Regards, ** | Scott T Weaver | | [EMAIL PROTECTED]| | Apache Jetspeed Portal Project | | Apache Pluto Portlet Container | ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For
Re: Struts Chain... seams similar to HiveMind ?EOM
While both concern wiring code together using xml, I think the similarity ends there. Hivemind, from my cursory overview, seems more like another Inversion of Control (IoC) framework like Avalon, PicoContainer, and Spring. It is takes services and manages their dependencies and lifecycle, allowing the developer to organize code as a series of services. Struts chain links commands together into to create a process flow. Commands are very simple objects, like Struts Actions, implementing the execute() method to perform its tasks. There is no concept of service contracts and implementations and all non-primitive dependencies, AFAIK, are satisifed by putting them in the Context object by a previous command rather than having the container manage service dependencies. Since they are solving two different problems, both actually work pretty good together. I've been using Spring lately and have found it a great compliment to a Struts application (http://struts.sf.net/struts-spring). I'm sure HiveMind would also serve a similar purpose well. Don On Wed, 29 Oct 2003, Vic Cekvenich wrote: Struts Chain... seams similar to HiveMind ? Am I wrong? .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Chain... seams similar to HiveMind ?EOM
On Wed, 29 Oct 2003, Vic Cekvenich wrote: But... the chain has a set of steps that are pre-progrmed, and there was some discusion as to what those steps should be idealy. Yes, it can do return codes but If HiveMind (or an aproach like it) is used to do the chain, then I can easily add interceptors, and alterantice idea for consideration The chain supports the interceptors as well. A command can have any number of commands with each having commands and so on. I found this very educational: http://jakarta.apache.org/~hlship/HiveMind.ppt ... and based on that I made a leap, that, hey, we can intercept the flow. A bit of AOP. (There are some other ideas in there, like code to the interface contract) Since you can already intercept the flow with the chain, I don't see what an IoC, if even applicable, could offer. Struts needs a composible process flow that is easily manipulatable and pluggable. I agree all those other fancy service-oriented features are nice, but IMO, they belong in the action/form layer. Don .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/contrib/struts-chain/src/java/org/apache/struts/chain/servlet AuthorizeAction.java RequestNoCache.java SelectForward.java SetContentType.java
On Fri, 24 Oct 2003, Craig R. McClanahan wrote: snip / Welcome to the Chain Gang Don! :-) With a snappy name like that, we should t-shirts printed up :) I noticed that your implementation of AuthorizeAction does the same thing that the current Struts RequestProcessor does if authorization fails -- sends a Bad Request (status 400) message back. One thing we might consider instead is throwing a Struts-defined authentication exception, which would allow the exception handling mechanism to decide what to do instead. One nice feature of using the chain approach is that the exception handler (o.a.s.c.ExceptionCatcher) can handle exceptions thrown by *anything* that executes after it is installed in the chain, not just exceptions thrown by Actions. This allows us to use exceptions to enable application-defined handling of lots of exceptional events from the framework as well, rather than simply throwing a 400 response. In addition, sending a 400 isn't going to be possible in a portlet world anyway, so we might as well start thinking about what to do instead, and make it consistent in servlets as well. What do you think? Good point. I could have it throw an UnauthorizedException which is handled by UnauthorizedExceptionHandler in the servlet-exception chain before ExceptionHandler. This of course would entail creating o.a.s.c.AbstractUnauthorizedExceptionHandler, o.a.s.c.UnauthorizedException, and o.a.s.c.s.UnauthorizedExceptionHandler which kinda seems like a lot of code for one line in the case of a servlet environment. From how I understand it, as it stands, in a portlet environment, a whole new chain config would have to be used anyways due to most implementing classes depending on servlet apis. Therefore, to handle an unauthorized case for a portlet, the only addition code would be a different AuthorizeAction implementation, which would need to be provided anyways. That said, I think throwing an exception is the more logical choice, but it does add several more classes with little functional improvement. Of course, this is really a trivial part to the whole chain so whatever you think is best, I'll code it up :) Don Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-chain] More actions, but hit a snag
On Fri, 24 Oct 2003, Craig R. McClanahan wrote: snip / I hit a snag using the example app when logging in. It seems the logonForm is getting instantiated somewhere other than CreateActionForm and doesn't have its servlet property set, throwing an exception in validation. Perhaps it's right under my nose, so I'll look into it. Other than that, it's running smoothly and I am really looking forward to using the chain. :) Don I will try to look at this over the weekend. Did it work for you before your recent changes? It did for me. Strangely enough, everything worked fine for me today...could have been some stale form left in my session scope. Don Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/contrib/struts-chain/src/java/org/apache/struts/chain/servlet AuthorizeAction.java RequestNoCache.java SelectForward.java SetContentType.java
On Fri, 24 Oct 2003, Craig R. McClanahan wrote: snip / I agree that we would need the exception class, but why do we need anything other than the standard handler (o.a.s.c.ExceptionCatcher)? It fires off an exception handling chain, and the default handler there already looks at your exception settings in struts-config.xml to figure out what to do for any arbitrary exception class. It's up to the app to handle UnauthorizedException however it wants, just like it's up to the app to handle an SQLException (or any other type, for that matter) returned from an Action. While we're at it, there are a few other places where Struts 1.1 returns an HTTP error; they should be evaluated for being treated the same way in a chain-based request processor. That works for me - I was under the assumption 100% backwards compatibility was the goal (i.e. drop-in replacement). I'll write it up. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[struts-chain] More actions, but hit a snag
I've tried to fill in some of the missing pieces in the struts-chain as described in chain-config.xml. The new actions have pretty much a one-to-one relationship with RequestProcessor methods. Some seemed pretty trivial, RequestNoCache and SetContentType in particular, so maybe they could be combined into one controller config action, but for now, I figured I'll make them their own actions as it is always easier to combine than explode. I hit a snag using the example app when logging in. It seems the logonForm is getting instantiated somewhere other than CreateActionForm and doesn't have its servlet property set, throwing an exception in validation. Perhaps it's right under my nose, so I'll look into it. Other than that, it's running smoothly and I am really looking forward to using the chain. :) Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding to the user guide
What I meant was I modified the original struts-example to demonstrate wildcards when I distributed the code as a Struts extension. I bring it up to point out it requires the renaming of particularly the JSP page which may or may not be acceptable. If so, I can go ahead and modify the example as I used a modified struts-example to test the patch in the first place. Don On Thu, 9 Oct 2003, James Mitchell wrote: Sorry, I meant modifying the original struts-example. Or did you already do that? I can't seem to find anything in cvs. -- James Mitchell Software Engineer / Struts Evangelist http://www.struts-atlanta.org 678.910.8017 770.822.3359 AIM:jmitchtx - Original Message - From: Don Brown [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, October 09, 2003 10:38 PM Subject: Re: Adding to the user guide I did that when it was released as an extension here: http://www.twdata.org/struts-wildcard I modified the editSubscription mapping to edit*. Since Subscription is being mapped and replaced in the form name and jsp name, I had to change instances of subscription to Subscription. Thats it though. Don On Thu, 9 Oct 2003, James Mitchell wrote: +1 Looks good to me. I'll probably take a look at adding it into the struts-example at some point in the near future (time permitting). -- James Mitchell Software Engineer / Struts Evangelist http://www.struts-atlanta.org 678.910.8017 770.822.3359 AIM:jmitchtx - Original Message - From: Don Brown [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 09, 2003 10:03 PM Subject: Adding to the user guide I added a section in the user guide about wildcards in action mappings, however before I commit it, I'd like to make sure it follows documentation conventions as this is my first time writing Struts docs. I've put the section up here for review: http://www.twdata.org/dakine/site/userGuide/building_controller.html#action_mapping_wildcards If I don't hear anything in a day or so, I'll take it as a thumbs up and commit it. Thanks. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
struts-example/tour.htm
I updated the struts-example to use wildcards in struts-config-registration.xml and was about to update tour.htm when I noticed it was woefully out of date. It is worth updating? For 1.2, are we planning on shipping it with the new example app I've heard mentioned? Should I bother updating tour.htm? Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Adding to the user guide
I added a section in the user guide about wildcards in action mappings, however before I commit it, I'd like to make sure it follows documentation conventions as this is my first time writing Struts docs. I've put the section up here for review: http://www.twdata.org/dakine/site/userGuide/building_controller.html#action_mapping_wildcards If I don't hear anything in a day or so, I'll take it as a thumbs up and commit it. Thanks. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding to the user guide
I did that when it was released as an extension here: http://www.twdata.org/struts-wildcard I modified the editSubscription mapping to edit*. Since Subscription is being mapped and replaced in the form name and jsp name, I had to change instances of subscription to Subscription. Thats it though. Don On Thu, 9 Oct 2003, James Mitchell wrote: +1 Looks good to me. I'll probably take a look at adding it into the struts-example at some point in the near future (time permitting). -- James Mitchell Software Engineer / Struts Evangelist http://www.struts-atlanta.org 678.910.8017 770.822.3359 AIM:jmitchtx - Original Message - From: Don Brown [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 09, 2003 10:03 PM Subject: Adding to the user guide I added a section in the user guide about wildcards in action mappings, however before I commit it, I'd like to make sure it follows documentation conventions as this is my first time writing Struts docs. I've put the section up here for review: http://www.twdata.org/dakine/site/userGuide/building_controller.html#action_mapping_wildcards If I don't hear anything in a day or so, I'll take it as a thumbs up and commit it. Thanks. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Choosing a build/doc gen tool(s) [was: Re: The Forrest Option]
It might be broken, but then again, we aren't using Maven today anyways. I asked him about it, and he said last he heard it was working, some people reported it buggy, but since no one was using it, it was staying in jira until someone could put time into it. If we moved to Forrest, I would certainly put time in fixing it and getting it added to Maven's repository. Don On Thu, 2 Oct 2003, Robert Leland wrote: James Mitchell wrote: I thought that one of the Forrest Committters said that the Forrest plug-in for Maven is most likely broken ? Most of us have given (or at least hinted at) our opinions, so let's give a show of hands: Mavenization: [X] +1 - I am in favor of using Maven for build/dist/test/etc. [ ] +0 - I agree, but cannot help at this time. [ ] -0 - I don't agree, but not enough to give a -1. [ ] -1 - I am not in favor of using Maven for build/dist/test/etc. Forrestization: [X] +1 - I am in favor of using Forrest for site generation. [ ] +0 - I agree, but cannot help at this time. [ ] -0 - I don't agree, but not enough to give a -1. [ ] -1 - I am not in favor of using Forrest for site generation. Other: [X] - I would like to pursue the Maven-with-Forrest-as-a-plugin idea. (If I left out any, please add them) One question I have about all this, (and please forgive me if I missed it in any of the messages in this thread) how does using either approach affect the generation of the .tld from our source? -- James Mitchell Software Engineer / Struts Evangelist http://www.struts-atlanta.org 678.910.8017 770.822.3359 AIM:jmitchtx - Original Message - From: Don Brown [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Wednesday, October 01, 2003 7:18 PM Subject: Re: The Forrest Option On Wed, 1 Oct 2003, Craig R. McClanahan wrote: snip / ducks We can even add Forrest-based generation to our current Ant-based build scripts :-). It's just an external tool, after all. /ducks Actually it is very easy to do, using a forrest entity which imports forrest targets. The only setup needed is to install forrest and set FORREST_HOME. All the same ant targets used now to build the site can be used to build forrest. If the Forrest route was accepted, I planned to do this from the start. Don There's only so much time we each have to spend on Struts. I'd rather not spend much time learning the build process. David Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Forrest Option
On Tue, 30 Sep 2003, Robert Leland wrote: snip / I prefer Maven because it provides builds, testing, QA tools, and site generation in one tool. The repository of binaries makes building a distribution or maven enabled site as easy as typeing, 'maven' for new users. Changing the look/skin is straight forward, though as I say below I wouldn't invest alot of time tweaking it. When you say one tool, you mean Maven plus any plugins that you need to do what you want, like generate PDF. Since there is a Forrest plugin for Maven, you still get all the ease of use of Maven. My main question to the items below is 'which of these features would we use for the struts site' In short, Forrest offers these benefits over Maven's website generation: - Multiple output formats including PDF and HTML Maven has been doing this for a while now.. If you mean the PDF plugin, it seems from its page that all it does is create one PDF of the whole site. Can you create PDF's of each page, sections containing multiple pages? Its hard to evaluate the PDF plugin as its documention is really lacking. - SVG to PNG rendering - Built for handling and aggregating multiple XML sources like RRS (soon wiki and Docbook) Maven currently handles RRS, Docbook, and a few other formats, including the ability to take a preexisting framed html like JavaDoc and take it apart and assemble it again with a .maven wrapper. What's the wiki thing, and why do you think that would be usefull ?. The Wiki support currently in Forrest, albeit under construction, supports the parsing of Wiki text files for rendering. This allows the Wiki information to be ran through the XML pipeline, most likely to end up as a PDF. The ability to create PDF's out of wiki text would make wiki information more useful, IMO. Could you give an example how multiple XML sources would be aggregated and used as a single source. How is this capability an advantage for the struts web site. For example, currently, we have quite a few Struts extensions, example applications, and related frameworks that I feel Struts could do a better job of encouraging. Instead of requiring an extension developer to submit a patch to bugzilla to change a description or add their project to the page, why not have a page that aggregates extension project's RSS announcing new releases into a news-type page. Giving extension projects more exposure will generate more interest in finding ways to make Struts better. Look what it did for Maven :) - Power and features of Cocoon including charting, web services integration, scripting support, etc. Charting is nice. What types of charting do we get for free or almost free that would help with our site. I believe Maven can provide charts about bugs reports, While I mentioned these as nice features to have available, I wouldn't mind have a page of graphs and statistics showing downloads, new bugs, percentage of bugs as enhancements, number of bugs to go before the next release, etc. In my experience, people love the concept of a dashboard and what better way to get people more interested in fixing bugs? which I don't EVEN want to see ;-). How does web services/scripting fit into our needs? The ability to embed small BSF-compatible scripts in the documentation build process is a nice way to make something that would be more complex using Ant/Jelly easy. Especially useful in something like the statistics I mentioned earlier. Further, deciding between Forrest and Maven isn't an either/or situation. There exists a Forrest plugin for Maven and it would be easy to integrate Maven's reports into a Forrest site build. I am assuming this plugin uses the maven xml doc files and generates forrest docs ? No, just as the xdoc plugin generates html from xdocs, the Forrest plugin would generate a site from Forrest docs. As hinted to earlier, it can easily integrate into any generated documentation we'd like to keep from Maven. To me, the key feature of Forrest is the first one listed, multiple outputs. This is especially useful for documentation as PDF is much better than HTML for printing for the many users that like hard copies. Maven does this. Again, I didn't see a way to do more than just generate one PDF for the whole site, but of course, I could be wrong. Finally, Forrest content is built to be presented in not only multiple output formats, but multiple skins. To demonstrate this, I've quickly redone the Struts site into Forrest format (which is very similiar to the current format thanks to the xhtml work of late). I've only converted the menu and the main page, which should be sufficient. We only need one look, though I don't like the default Maven look, but not enough bothering changing it. We may customize it but we won't be changing it dynamically. I only included these links to show how output-independant Forrest was as it was asked in an earlier discussion if
Re: The Forrest Option
On Wed, 1 Oct 2003, David Graham wrote: snip / Rob mentioned something about Struts being setup for Maven already and I asked for clarification. If that's true then I see no point in complicating things with another build tool. Also, it seems that Maven in some ways is a superset of Forrest functionality. It handles the website plus the jar builds. Forrest is not a build tool. If we went with Maven, Forrest would just be another plugin, just like most people use the default site building plugin. The more tools involved means it's harder to understand the build process which limits the number of people willing to put up with it and work on Struts. My personal goal (and I hope the group's as well) is to have *one* easy to use tool that builds all of Struts. I don't care if this is Ant, Maven, or Forrest as long as it's only one of them. I agree, but if a Forrest plugin for Maven is used, you still use one tool to build all of Struts. Don David Though, a valid, technical objection would be that the website and the build (except for the current Cactus snafu) ain't broke, so we don't need to fix it. Steve's got everything running as valid XHTML. We're still using the original Apache look, but then so is the vast majority of other Apache projects. If we dusted off the struts-lib distribution (which appeared and disappeared during the last beta cycle), the quick-start concerns would be answered. Certainly, it would make sense to start new development on Forrest and/or Maven. If we spun off taglibs or rolled up our sleeves on 2.0, then we'd definitely want to make a decision there. (Based primarily on who was willing to do the work.) And, we do have Forrest running on the SourceForge site, so things like RSS feeds and WikiDocs could be tried there first to see how helpful they really are. (I must admit, I'm intrigued.) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build improvements (was Re: The Forrest Option)
On Wed, 1 Oct 2003, Ted Husted wrote: snip / Ah, well, you see we don't have JARs in our CVS. That's one of the reasons people have trouble building Struts at first. They have to go off and snag all the JARs themselves. Though, it seems like ruper might help in that regard. Doh! I blocked out the memory of having to get everything setup. I do that with traumatic events :) Don -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Choosing a build/doc gen tool(s) [was: Re: The Forrest Option]
I believe the question is not between maven and forrest, but rather between Anakia/xdoc and forrest. It is entirely possible to even use all the report output from Maven and include it in a forrest build of the website. Default Maven uses the xdoc plugin. All forrest would be doing is replacing it with the Forrst plugin. You would still be able to get all the Maven-generated content. Forrest is not a built tool. It only replaces xdoc whether we keep Ant or go to Maven. Could this vote not be redone? Mavenization with xdoc plugin: [ ] +1 - I am in favor of using Maven and the xdoc plugin [ ] +0 - I agree, but cannot help at this time. [ ] -0 - I don't agree, but not enough to give a -1. [ ] -1 - I am not in favor of using the xdoc plugin Mavenization with the Forrest plugin: [ ] +1 - I am in favor of using Forrest instead of xdoc. [ ] +0 - I agree, but cannot help at this time. [ ] -0 - I don't agree, but not enough to give a -1. [ ] -1 - I am not in favor of using Forrest instead of xdoc. I'm assuming a move to Maven is inevitable? Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
New feature process
What is the process when adding a new feature (in this case, wildcards for action mappings)? Do we wait until a release is ready to update the documentation or update it when the feature goes in? Also, I couldn't really find a changelog. Do we just use bugzilla to track new features? If so, should an enhancement request be made before a feature gets added? If this information is already on a webpage somewhere, I apologize in advance :) Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New feature process
I'm familiar with the process of bringing up new features to the group as it is documented on jakarta's site: http://jakarta.apache.org/site/decisions.html Rather, I was interesting in what the Struts process once the feature is committed. I would assume the following areas would be affected: - tests - changelog - documentation - bugzilla Don On Sun, 28 Sep 2003, Robert Leland wrote: Don Brown wrote: What is the process when adding a new feature (in this case, wildcards for action mappings)? Create a Subject: [Proposal] wild cards for action mappings. Use lazy Consensus. At least 3 +1 votes, no -1 votes. There is a doc somewhere that says when to use each type of vote. Also I thought we already discussed this and it's addition was approved ? Do we wait until a release is ready to update the documentation or update it when the feature goes in? I would say nightly Docs should always match the nightly source Also, I couldn't really find a changelog. If you have maven you can now build the top level struts documentation which includes a generated change log. Do we just use bugzilla to track new features? If so, should an enhancement request be made before a feature gets added? No. If this information is already on a webpage somewhere, I apologize in advance :) I would like to know that answer also. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/src/share/org/apache/struts/util ActionMappingMatcher.java WildcardHelper.java
Good point, I'll change it when I put in the unit tests I'm working on. Don On Sun, 28 Sep 2003, Robert Leland wrote: [EMAIL PROTECTED] wrote: mrdon 2003/09/28 18:24:21 Added: src/share/org/apache/struts/util ActionMappingMatcher.java WildcardHelper.java Wouldnt this be better placed in the action package ? Would any other package other than action ever use these ? If not then these classes could have package scope access. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
struts-chain, wildcards, web services
Unless there are any objections, I'd like to join the struts-chain effort, and hope to put in some time this weekend. I've been experimenting with ways to develop struts forms/actions that can simultaneously be exposed as SOAP web services in stxx (http://stxx.sf.net), but feel the struts-chain is key to building a robust implementation. Regarding wildcards (http://issues.apache.org/bugzilla/show_bug.cgi?id=21813), I decided to hold of on putting them as it seemed a 1.1.1(2?) was around the corner. However, as it looks like it is not, I'd like to put it in this weekend. Again, the patch will not affect any Struts apps that don't use wildcards in any way, performance or otherwise. It does open up some interesting possibilities not only for reduced configuration, but things like this: http://www.mail-archive.com/[EMAIL PROTECTED]/msg79295.html Finally, regarding web services, anyone know of any efforts to expose Struts forms/actions as web services? Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Editable Fields V/S Static Text
The Struts Sourceforge site, http://struts.sf.net, is a good place for such Struts extensions. Don On Thu, 25 Sep 2003, Chris Gastin wrote: As I can tell from the list I have opened topic that is pretty well beaten. Let me first apologize. I did not realize this was such a political topic in the Struts community. I am starting to think that there should be some sort of Struts Tag Lib Extensions, which would address some of these issues while being totally separate from the Struts project. I am starting to agree with David I don't want to polute Struts with non standard HTML, but it would be nice to have an add on module which is dependant on Struts that could give users the functionality which it seems that other are requesting. I am willing contribute to this effort. I did not realize there were so many bugs for the taglibs, which some of you pointed out. I will see if I can help out. I will check out bugzilla, and try to contribute in that area. Chris Gastin - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, September 25, 2003 3:39 PM Subject: RE: Editable Fields V/S Static Text --- Edgar P Dollin [EMAIL PROTECTED] wrote: I think it is more than a 'preference' based on the rapidity with which INVALID or WONTFIX is stamped on tag suggestions and patches. I can't speak for anyone else but here is my view on the tags: There are 3 things that earn my -1 on tag enhancements: 1. Functionality already provided by the JSTL. 2. Functionality that supports non-standard HTML generation. 3. Tags that don't tie into the Struts core functionality. These are better suited for the Jakarta Taglibs project. I'm personally open to other tag enhancements. If you check cvs, you'll see that I have volunteered some time at refactoring and enhancing the tags. Whenever tag extendability enhancements are discussed, we always hear complaints from a vocal minority but no tested working patches show up. I haven't heard any good suggestions that would make the tags easier to subclass. If the current factoring isn't good enough, provide patches for something better. The fact is that the current tags work great for my needs so I'm not motivated to spend a bunch of time pondering some ultimate extendability framework. There's not much we can do without use cases and patches. David Perhaps it would be best if the tags were cut loose from struts and a different group of committers were responsible for them. I wouldn't, nor would I expect anyone else interested in the tags to make any time commitment with the current 'RULES' placed on the tags, i.e. ONLY emit HTML 4.01 or XHMTL 1.0, only a 'thin' layer over standard html tags, etc. Edgar -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: Thursday, September 25, 2003 2:23 PM To: Struts Developers List Subject: Re: Editable Fields V/S Static Text It's only a political football in the sense that most of the current committers would prefer not to work on the HTML tags. If other folks came to the fore and committed themselves to supporting those tags, including writing unit tests and answering questions on the user list, I don't think you would see much opposition to development in that area -- along with an eventual nomination for committer status for the individuals involved so that they can do their work directly. Asking the existing committers to do all the work isn't the way to leverage how open source operates :-). Asking the existing committers to apply patches (and add unit test cases that already work), and pestering them until they get around to it (or nominate you to committer status so you can do it yourself) *is* the way to leverage how open source operates :-). Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: struts-chain, wildcards, web services
On Thu, 25 Sep 2003, Steve Raeburn wrote: snip / Shouldn't you be exposing your business objects as web services, not Struts actions or forms? Struts deals with controlling the user interface (currently Servlet specific) so any business tier / web services tier code would be outside of the Struts domain. I'm not suggesting this type of functionality be in Struts core, as I agree with you Struts is focused on controlling the user interface. However, I can imagine the following situation: using struts-chain, define an action that takes parameters, uses the context to determine authorization, checks for a web context to perform servlet-specific things, pulls data from the business facade and sticks it in the request. I would want to expose that both to Struts and as a web service without any extra code, save perhaps an Axis WSDD. While of course it isn't too hard to write an interface layer to expose business objects/facades via web services, since Actions are already only a few lines, I'd rather not write a whole other set of classes. And of course, I'd like to take the same actions and expose them to portlet code. struts-chain does a great job of remaining agnostic of implementation and let you mix and match just about anything. Don Steve Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where is Struts 2 going?
In the aforementioned stxx (http://stxx.sf.net) project, I've been working on combining Struts with xmlforms (http://www.xmlform.org) to create Struts ActionForms that use plain XML as the model. Using pure XML as the model has several advantages over javabeans I believe: - Quicker development - Use of XPath for powerful data access - Many different validation options (schematron, xsd, relax-ng, etc) - Ability to simultaneously expose forms as document-based SOAP web services While xml mapping toolkits have gotten better, I found keeping the model in XML saves development time, and with xpath and JDOM, the data can be accessed much quicker (in development time, not runtime of course). Don On Sat, 13 Sep 2003, robert burrell donkin wrote: On Friday, September 12, 2003, at 12:01 AM, Jing Zhou wrote: snip 4) We could add more... (like portlets) (this is probably a bit left field but you need to make time to dream...) i'm a big fan of cocoon and have some idea about when webservices are the answer but one idea i've been turning over in ideal moments is whether (or rather how) MVC (and in particular struts) could (or rather should) be applied to xml-centric environments. at the moment struts has action forms which are mapped from http requests. i've been wondering about plugging some kind of bean-centric pre-processor (could be betwixt, could be castor, could be a JAXB implementation, could be XMLBeans) to convert an incoming xml document into a bean representation and then feeding that into a struts action. probably need an xml-centric output wrapper to help write a response to xml from output beans. the advantage of this kind of approach is that it cuts the overhead which i've observed you get when you ask java coders to 'just go do that xml thing'. on the other hand, an experience struts coder should be able to handle java bean-in, java bean-out just fine. sightoo much to do, too little time/sigh - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Flexible form support (was Re: Simplifying DynaActionForms)
This reminds me, I think Struts should be more flexible supporting the configuration of other types of forms or extensions to existing forms (like the aforementioned modification to the dynaform). While you can specify any form class, you cannot pass properties to that instance making it difficult to develop generic, powerful forms, like dynaforms, outside the Struts framework. For example, I've been working with an extension of ActionForm that uses XML as its model, allowing the XML to be modified directly through Struts saving heaps of mapping code. In addition to naming my class, I'd like to specify the XML file it should use as a model. Currently, I do this although it is admittedly a hack: form-bean name=UserForm type=com.oroad.stxx.xform.DOMForm form-property name=xml type=/WEB-INF/models/user.xml /form-bean In addition, in order to have control over the form population, I have to extend RequestProcessor and override processPopulate(). Therefore, I think there should be a way to: 1. Pass parameters to a form in the configuration 2. Explicitly handle form population. Perhaps there are strong reasons why this wouldn't be a good idea, but I'd like to hear them. I apologize if this topic has already been dealt with. Don On Fri, 15 Aug 2003, Ted Husted wrote: In terms of simplifying the maintenance of DynaActionForms, I was wondering if we had tried anything like this yet? form-bean name=inputBean type=org.apache.struts.validator.DynaValidatorForm proxy=com.mycompany.project.businessBean / where the proxy class would be introspected, and String or boolean dynaproperties generated for each public property? (Rather than specify them ourselves as XML.) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts for Portlets (requesting your opinions)
I couldn't agree more, however I'm not sure if the answer is a completely independent core like xwork or totally wrapping servlet objects and method calls like Cocoon in generic Enviroment objects. If Struts application should be able to be exposed in multiple environments, perhaps the Cocoon approach has more value. It might be nice to eventually even be able to run Struts from the commandline :) Don On Wed, 13 Aug 2003, Mete Kural wrote: Agree. I just read Craig ideal view and I think this view may be a good start. I think so too. I will re-state Craig's ideal goal below for others to catch up: I believe that we should aim for the following ideal state -- a Struts application shoud be usable either as a webapp or as a portlet, with little (ideally no) changes. Therefore, I believe that we'd build whatever it takes to support this into the standard Struts distribution, which would then be used in both environments. I would like to ask everybody what their opinions are about this topic. Is it technically possible for Struts to enable the same application to be turned into a webapp or a portlet at the switch of a button? Could the fundamental differences between a webapp and a portlet not allow such a possibility? Mete -- Original Message -- From: BaTien Duong [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] Date: Wed, 13 Aug 2003 12:24:47 -0600 Agree. I just read Craig ideal view and I think this view may be a good start. BaTien DBGROUPS Mete Kural wrote: Struts-Tiles-Portal-Portlet framework and container. I think that there is a big difference between the framework used to build a portal server and a portlet framework. I see that Struts+Tiles is a very good framework to build a portal server, but it seems to me that the ways in which Struts would be used as a framework for building a portal server are very different than Struts being used as a portlet framework. IMHO, Struts developers should focus on making Struts an efficient portlet framework. Portal server developers could tweak Struts in their own ways in order to use it as a framework for building their portal server, but I don't see the need for standardization in this area. Standardization is rather necessary in the are of using Struts as a portlet framework. What are your opinions? -Mete -- Original Message -- From: BaTien Duong [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] Date: Wed, 13 Aug 2003 11:02:44 -0600 Greetings: I am very interested in this discussion, and will have more time to think of the overall structure after the release of JSR-168 Reference Implementation (Pluto). At a cursory level, i see Struts provides very simple and elegant flow controllers of what-to-do and how-to-do based on standard Servlet container. Tiles is an elegant dynamic templating engine, also based on standard Servlet container. I see JSP tiles as a plus rather than a short-coming since J2EE has JSP as its dynamic page assembling. JSR-168 portal/portlet containers are official extension of Servlet container. It seems not a very major issue to make Struts and tiles a 1-2 punch for JSR-168 portal/portlet containers. Tiles context may be refactored into Portlet context. Tiles already has a facility to dynamically generate tile attributes for changing the page assembling. This is probably what the JSR-168 authors mention that Portlet can act as controller, fill a bean with data, and include a JSP to render the output. See this pattern? The effort is valuable, since many Struts Plug-ins can be parts of our tools. I see Jetspeed is too heavy, not simple and elegant enough to realize the potential of JSR-168 and WSRP. We can learn many designs from Jetspeed to bring them into this new portal/portlet framework with simple and elegant design infrastructure. I hope many designers and developers interested in this relevant topic: Struts-Tiles-Portal-Portlet framework and container. BaTien DBGROUPS Mete Kural wrote: Hello Struts developers, I wanted to get your opinions on how Struts should be used as a portlet framework. I think that it would be great if a portlet framework was part of the standard Struts distribution in the near future. JSR-168 which defines standard portlets will be finalized pretty soon (a month?), although the specification draft is pretty much stable hereafter. I have two main questions: 1) My first question is technical. How do you think portlet support would be best added to Struts? Which classes should be extended? Are there necessary changes at the core classes of Struts in order to provide an efficient framework for building portlets? 2) Second question is about how a Struts-based or Struts-like portlet framework should be distributed. Should it be part
Re: Wildcard-matched actions (again)
Heh, thankfully no. :) In fact, that's one of the reasons I'd like to incorporate this into Struts itself to remove that alternate processor requirement. The patch adds a couple of lines to RequestProcessor.processMapping() to, in the case of no direct mapping found, try to match any wildcards. All of the logic of wildcard mapping is stored in a helper class to keep RequestProcessor as clean as possible. Don On Mon, 11 Aug 2003, David Graham wrote: --- Don Brown [EMAIL PROTECTED] wrote: I'd like to put the wildcard-matched action code from Bug #21813 (http://issues.apache.org/bugzilla/show_bug.cgi?id=21813) into Struts. When I mentioned it last, the only concern I heard raised was from Craig regarding performance penalties. As I noted in the bug description, the path isn't checked against compiled wildcards until an exact match cannot be found. Even then, it is only checked against action mappings that actually contain at least one wildcard. Let me know if anyone has any reason I shouldn't do this or concerns I can hopefully alleviate. Thanks. Looks pretty neat. On your site you have a custom WildcardRequestProcessor that performs this behavior. Are you planning on incorporating it directly into RequestProcessor now? I don't think we should exasperate the poor RequestProcessor situation any further by adding more of them. David Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wildcard-matched actions (again)
I apologize if I wasn't clear; there is absolutely no performance penalty for any existing or future Struts applications that do not use wildcards. Upon initialization of the RequestProcessor, it runs through each action mapping to see if any of them use wildcards. Only if a wildcard is found in the path attribute, the path value is compiled and added to a list of expressions to test. Therefore, if wildcards aren't used at all, this feature is completely ignored. When processMapping() is called, the path is tested against compiled wildcards only if the following requirements are NOT met: 1) There is no direct match for the path (usual Struts behavior) 2) There is at least one action mapping that uses wildcards Therefore, even if your entire application relies on the default action mapping, if you are not using wildcards, your application will suffer no penalty. As for putting it in post-1.2.0, that is fine. I've been using the code for over a month in my day job's application and it has been in stxx (http://stxx.sf.net) for as long. Furthermore, the core of it comes from Cocoon and forms the basis for how pipelines are matched in their sitemap. In my application, it cut the number of action mappings by 66% making Struts tons more manageable. But again, its completely optional and doesn't affect anyone who doesn't use wildcards. Don On Tue, 12 Aug 2003, David Graham wrote: --- Robert Leland [EMAIL PROTECTED] wrote: Matthias Bauer wrote: I would like to be able to turn off this pattern matching feature, as performance is a very critical issue for a CMS. +1 So far I haven't heard any definitive answer to the performance question. If there isn't any performance penalty then we don't need the ability to turn off pattern matching. I'm starting to think this enhancement should wait for 1.2.1 instead of trying to squeeze it in for 1.2.0. David --- Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Robert Leland [EMAIL PROTECTED] -- Java, J2EE, Struts, Web Application Development 804 N. Kenmore Street +01-703-525-3580 Arlington VA 22201 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/doc/resources extensions.xml
I wasn't sure since I submitted the request myself, but I will be sure to do so in the future. Don On Mon, 11 Aug 2003, David Graham wrote: I'm assuming this commit was prompted by a corresponding enhancement ticket. If so, it would be helpful if you included the ticket number in the commit message so we can reference it later for more info if needed. I think the typical notation is PR# . David --- [EMAIL PROTECTED] wrote: mrdon 2003/08/11 16:51:03 Modified:doc/resources extensions.xml Log: Added Struts BSF project link and description Revision ChangesPath 1.11 +1 -0 jakarta-struts/doc/resources/extensions.xml Index: extensions.xml === RCS file: /home/cvs/jakarta-struts/doc/resources/extensions.xml,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- extensions.xml15 Feb 2003 20:55:24 - 1.10 +++ extensions.xml11 Aug 2003 23:51:03 - 1.11 @@ -38,6 +38,7 @@ pa href=http://husted.com/struts/resources/mapper.htm;bMapper Framework/b/a by Capco - The Mapper framework can be used for automating the process of validating/converting/transferring data fields. font size=2(See README to get started. Updated 18-JUL-2001.)/font/p pa href=http://www.sura.ru/~gonza/bean-factory/;bBean factory/b/a by Oleg V Alexeev - Adds the ability to easily link data bean creation to any Struts Action. All information about databeans and actions mappings stored in the standard Struts configuraton file. /p pa href=http://home.earthlink.net/~dwinterfeldt/;bStruts Validator/b/a [Now bundled with Struts 1.1] by David Winterfeldt - Perform basic validations to check if a field is required, matches a regular expression, and some basic type checking. Different validation rules can be defined for different locales. The framework has basic support for user defined constants which can be used in some field attributes. The validation routines are modifiable in the validation.xml file so custom validation routines can be created and added to the framework./p +pa href=http://struts.sf.net;bScriptable Actions/b/a by Don Brown - Allows Struts Actions to be written in the scripting language of one's choice rather than as Java classes. It uses the a href=http://jakarta.apache.org/bsf;Beans Scripting Framework/a to allow scripts to be written in any language BSF supports like Python (using a href=http://www.jython.org/;Jython/a), Ruby (using a href=http://jruby.sourceforge.net/;JRuby/a), JavaScript (using a href=http://www.mozilla.org/rhino/;Rhino/a), or a href=http://www.beanshell.org;BeanShell/a./p /section /chapter/body/document - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Wildcard-matched actions (again)
I'd like to put the wildcard-matched action code from Bug #21813 (http://issues.apache.org/bugzilla/show_bug.cgi?id=21813) into Struts. When I mentioned it last, the only concern I heard raised was from Craig regarding performance penalties. As I noted in the bug description, the path isn't checked against compiled wildcards until an exact match cannot be found. Even then, it is only checked against action mappings that actually contain at least one wildcard. Let me know if anyone has any reason I shouldn't do this or concerns I can hopefully alleviate. Thanks. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: struts-config and xslt
There exists a project on the Struts Sourceforge site called StrutsDoc which seems to be what you are wanting - a JavaDoc tool for Struts (http://struts.sf.net/strutsdoc). While I agree visualization important, I'm not sure it belongs in Struts itself. The Struts Sourceforge project, on the other hand, is a great place to projects like this which many Struts users would find useful. Please feel free to get involved in StrutsDoc or any other project. As for the dtd mods, while web.xml does have name and description information, I agree it would be nice to have them in Struts in the case of multiple modules per servlet. Don On Tue, 5 Aug 2003, [iso-8859-1] Jonas Björnerstedt wrote: Hello, Having to evaluate an xml editor (I won't say which), I decided to use struts-config.xml as an example. After some hours wrestling with the program, this is the result I got: http://bjornerstedt.org/struts-config.html It is the config file from the struts-example application. It was created using: http://bjornerstedt.org/struts-config_1_1.xslt It's not that pretty (especially not in Mozilla). I am sure others can do it better, but given that it is rather easy to create an xslt, I think it would be a good idea to include one in Struts. Not only does it make the file more readable for large applications, it can also be used to make the xml - editor a decent Struts editor. While messing with the struts-config_1_1.dtd, I was surprised not to find a way to name and describe the whole application. Specifically, I would like to see display-name and description added to the struts-config element in the dtd: !ELEMENT struts-config (display-name?, description?, data-sources?, form-beans?, global-exceptions?, global-forwards?, action-mappings?, controller?, message-resources*, plug-in*) instead of: !ELEMENT struts-config (data-sources?, form-beans?, global-exceptions?, global-forwards?, action-mappings?, controller?, message-resources*, plug-in*) Descriptions should be available at all levels. Jonas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Don Brown as committer
On Wed, 23 Jul 2003, Rob Leland wrote: snip / Don, I wasn't familar with your name but after searching Google, I see that you developed stxx, Struts Cocoon adaptor, BFS scripting for struts, Action pattern matching, it also looks like you are familar with JetSpeed (Not sure) ... I have some interest in JetSpeed as it is the portal that is being evaluated by the US Navy to be their enterprise portal (most of our contracts here in Hawaii are with the US Navy). I tried to get struts working with it, but with Jetspeed 2.0, JSR 168, etc on the horizon, I put that project off. Besides, from my initial investigation, tight integration would require Struts to be more servlet-independent, sorta like xwork, which if it happens, is a long way off I'd guess. I settled with using stxx to expose pages as XML to be transformed later in a portlet. Not the best performer, but it is does let me reuse my app w/o having to rewrite or duplicate any Java code. However, with JSR 168 getting closer to finalization and Struts 1.1 out the door, perhaps I'll give it another wack. I'm a big fan of integrating existing technologies and tighter Struts integration with Jetspeed would be a good target I think. Don -- Rob Leland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Wildcard-matched actions
On Sunday 06 July 2003 02:12 am, Ted Husted wrote: snip / Don, Would your patch interact with http://issues.apache.org/bugzilla/show_bug.cgi?id=15921 I don't see why not. My patch inserts a few lines in processMapping which calls a helper class that runs through all the action configs, matches one, clones it and replaces wildcard values with the literal values, and returns the new clone. I'll put the code in patch form and post it on bugzilla. Don -Ted. Graham Leggett wrote: Don Brown wrote: Perhaps now that 1.1 is final, this would be a good time to bring this up. I've written a small extension to Struts that allows action mappings to use wildcards in matching URIs. I submitted a patch to bugzilla a while back that did prefix matching in matching URIs. A config called foo could be called, regardless of whether it was accessed as /bar/foo, or /fred/foo. Very useful for standard functionality that is reused in a site, such as a login form. We've been using it for a while, and it works great. Wildcard matching would also be really useful. Regards, Graham - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Wildcard-matched actions
Actually, the way I wrote the code, wildcards are only matched if an exact match cannot be found but before the unknown action mapping is executed. So, there is no performance penalty for existing applications that use specific matchings. The order: - Try to find an action mapping that matches the path exactly - Try to find an action mapping using wildcard matching - Try to locate the mapping for unknown paths Don On Saturday 05 July 2003 08:31 am, Craig R. McClanahan wrote: On Sat, 5 Jul 2003, Niall Pemberton wrote: Date: Sat, 5 Jul 2003 01:32:45 +0100 From: Niall Pemberton [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: [PROPOSAL] Wildcard-matched actions I like it. Perhaps you should create an enhancement request in bugzilla and attach a patch with your code. The idea makes some sense, and gets us more towards a general purpose site map approach to mapping arbitrary URLs to arbitrary actions. My one concern will be performance related, since this kind of matching will be slower than the existing approach. This could perhaps be alleviated by having a per-module-setting (or some smart initialization code) that only used the wildcard matching code if the module actually has some actions that need it, and uses the optimized version otherwise. Niall Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Wildcard-matched actions
And I forgot to mention, when using the wildcard matcher, only action mappings that actually contain wildcards will be tested. Don On Saturday 05 July 2003 01:18 pm, Don Brown wrote: Actually, the way I wrote the code, wildcards are only matched if an exact match cannot be found but before the unknown action mapping is executed. So, there is no performance penalty for existing applications that use specific matchings. The order: - Try to find an action mapping that matches the path exactly - Try to find an action mapping using wildcard matching - Try to locate the mapping for unknown paths Don On Saturday 05 July 2003 08:31 am, Craig R. McClanahan wrote: On Sat, 5 Jul 2003, Niall Pemberton wrote: Date: Sat, 5 Jul 2003 01:32:45 +0100 From: Niall Pemberton [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: [PROPOSAL] Wildcard-matched actions I like it. Perhaps you should create an enhancement request in bugzilla and attach a patch with your code. The idea makes some sense, and gets us more towards a general purpose site map approach to mapping arbitrary URLs to arbitrary actions. My one concern will be performance related, since this kind of matching will be slower than the existing approach. This could perhaps be alleviated by having a per-module-setting (or some smart initialization code) that only used the wildcard matching code if the module actually has some actions that need it, and uses the optimized version otherwise. Niall Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PROPOSAL] Wildcard-matched actions
Perhaps now that 1.1 is final, this would be a good time to bring this up.
I've written a small extension to Struts that allows action mappings to
use wildcards in matching URIs. The matched values can then be
substituted anywhere in the action mapping - similar to how Cocoon
operates (in fact the wildcard code was copied from Cocoon). The code
only affects the processActionMapping method of the RequestProcessor.
Why you ask?
- Much smaller config files
- Use of wildcards encourages more consistency of naming action forms,
actions, and jsp files.
- Allows for noun-based URLs in addition to current verb-based URLS,
particularly useful in REST-style web services
- No performance loss: wildcard matching only occurs when a direct
mapping for the URI cannot be found
For example:
!-- Matches all edit forms --
actionpath=/edit*
type=org.apache.struts.webapp.example.Edit{1}Action
attribute={1}Form
scope=request
validate=false
forward name=failure path=/mainMenu.jsp/
forward name=success path=/{1}.jsp/
/action
By including this feature directly in Struts, wildcards would be available
to all Struts applications as opposed to now where wildcard support
requires a RequestProcessor extension.
For more information:
http://www.twdata.org/struts-wildcard/
Don
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts can't get its act together - JavaPro
Rumor has it IDEA is working on a C# version :) Don On Fri, 13 Jun 2003, David Graham wrote: the .NET heads ( is there a term used to describe them? ) come back and say that it is easier and faster to build in C# then Java. They say that the tools to work with C# are better ( I don't agree ). Having worked with VS.NET and various Java IDEs I can say that .NET developers don't know what they're missing. They might have easy gui construction but VS is woefully lacking in ease of use and features (the most noticeable to me is the lack of automated refactorings). David In fairness, we should not assume that .NET developers are going to skip design or write GUIs with no functionality. We should look at the total cost of development. I must take issue with your point that It's this complexity that goes begging when UI construction is the sole (or even majority) measure of productivity. The fact is that as of right now you can build and maintain a GUI using .NET faster and easier (read productivity). You can build rich and complex functionality using C#. The building the business functionality is basically on par between Java and C#. Is it not fair to say that the productivity gained in the GUI construction is a clear win for .NET? If you take two groups one for Java/Struts/et. al. and one for .NET, where they are equally proficient in their respective technologies, and give them the same application to build, which will be done first? Bottom line who gets the job done first? The business world has decided that the .NET team will be done first. From what I have seen myself I have little reason to doubt this. I have made the argument about how much richer Java is as a language, and what I hear back is that the difference between Java and C# is like the difference between Coke and Pepsi. Again, perception is reality. Good tools do have a direct impact on development schedules. When are we going to have JSF and the tools to support it? Are the anti-Microsquish league (IBM, SUN, Oracle, et. al.) going to come up with tools to match .NET? Lastly, one of our teams here is writing a .NET front-end talking to Web Services supplied by a Java J2EE middle tier. The say they are having their cake and are able to eat it too. The interesting thing is they are succeeding and are getting their applications to the users faster and management has noticed. Glenn -Original Message- From: Chris Gerrard [mailto:[EMAIL PROTECTED] Sent: Friday, June 13, 2003 1:48 PM To: Struts Developers List Subject: RE: Struts can't get its act together - JavaPro Glenn, I'm continuously unimpressed by the implicit assumption that Developer Productivity == GUI construction. The blind acceptance of this hoary old chestnut has been a huge impediment to real progress in developing better systems. Given that the rapid construction of a UI is a good thing, what's my beef? Simply put, there's a whole world of complexity behind the UI that needs to be conceived of, designed, and implemented before the application is useful. It's this complexity that goes begging when UI construction is the sole (or even majority) measure of productivity. There are levels of productivity. GUI building is on the surface, easy to see. But it's thin, and not nourishing. Real productivity lies in the ability to provide rich, complex functionality that supports real people in getting real things done. GUI tools tend to concentrate on the thin layer on top, providing some hardwired mechanism(s) underneath to support the UI. This is an extreme limitation in real productivity in that it limits the access the developers have to the underlying bits. Struts provides the framework that lets us deal with the UI and get past it into the Java world where we're really limited only by our own skills and knowledge. Like Vic said in his post, I provide training in Struts (and other stuff) to corporate clients. I recently mentored a bunch of mainframe programmers starting up with Java/Struts in order to reimplement their existing FoxPro application. It's a simple customer info collection application - get some info into a form, save it, find it, update it, save the changes. The UI side of things is straightforward with Struts, as it would be with other technologies. BUT, real complexity lies unspoken in the find it functionality. The naive approach is to provide a single-field input form accepting a client ID# which is used to look up the info. Next up is the search form approach: Let's give them a form that looks like the input form, let them fill in some value(s) and then search for their info. OK, now we're talking. What fields are on the form? How do the values entered interact with one another - implicit ANDs or ORs, or do we try to give them a real query builder? And so it goes. Even better, as the user population gains experience with the application,
