I'll ask the dumb question What is Strike-thru formatting?
As noted, strike-thru formatting is just a text decoration that draws the text with a line through it. Regarding the wiki, the idea was to preserve the removed text for a while so that people wouldn't be confused by the change.
Then again, that wiki entry is so old that its confusing anyway!
Joe
~Martin~ ----- Original Message ----- From: "Joe Germuska" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Sunday, March 07, 2004 6:12 PM Subject: Re: Struts starter
At 9:14 PM +0000 3/7/04, Frank Burns wrote: >Hi, >I'm in the middle of working with my first application using Struts >and desperately need some help. >I've read nearly all of Ted Husted's "Struts In Action" book and >browsed the mailing list archives but have not found a solution for >what I want to do. >I mention this to let you know that I have already tried hard, >unsuccessfully, to find an answer to what seems to me to be a basic >requirement. >However, I may be struggling with my own misunderstanding!
Frank:
Don't blame yourself: you've stumbled onto one of my personal top priorities to improve in Struts: prefilling forms with non-request data.
While I was writing this, John McGrath described a general strategy which works *if* you don't already need to use the single "ActionForm" that is passed to Action.execute for processing *input* data. However, in most cases, you have a chain of events where you have different "input" and "output" forms. We've developed a few strategies for ealing with this where I work, but they're all the sort of thing which may not be ready for "prime time" -- that is, officially adding to the Struts core.
Right now, Struts doesn't provide a particularly convenient way to get an instance of what we call the "output" form -- the form which will be in the view to which control is directed. Since 1.2.0, I've committed a few changes which make it a little easier for you to get Form Bean instances, but what is still missing right now is a proposal for a standard place to configure Struts to know which form bean you want.
Practically speaking, you can get an Object of the right class from a static method of RequestUtils with no more than a FormBeanConfig and the ActionServlet. You can get a FormBeanConfig from a ModuleConfig instance, which you can get using ModuleUtils. So inside any Action, you can bootstrap yourself to having a Form bean object, which you can populate however you need.
http://jakarta.apache.org/struts/api/org/apache/struts/util/RequestUtils.htm l#createActionForm(org.apache.struts.config.FormBeanConfig,%20org.apache.str uts.action.ActionServlet)
http://jakarta.apache.org/struts/api/org/apache/struts/config/ModuleConfig.h tml#findFormBeanConfig(java.lang.String)
http://jakarta.apache.org/struts/api/org/apache/struts/util/ModuleUtils.html #getModuleConfig(javax.servlet.http.HttpServletRequest)> it. But Struts is still a good bit away from officially switching to
One possible flaw with this (as it is now) is that it doesn't honor the "scope" parameter and search the request or session for possibly existing bean instances. Of course, that code is available inside non-public methods of RequestUtils; it's just a matter of choosing the right way of exposing them publicly.
The sticky parts, in terms of packing this up so that it's easy for everyone to use in Struts is configuring the form bean name and scope in the right place -- where in the struts-config.xml (or in some other file) would you tell Struts the name (and scope) of the bean you want?
At work, we're using the struts-chain "ComposableRequestProcessor" with a request chain command "PagePrep", which looks up config information and choreographs finding a form bean and making it available to a piece of Java code which might know how to populatethe ComposableRequestProcessor, and our config information is part of a general "UIToolkit" which is not currently a part of Struts in any way.
The general strategy we use would fit decently well into a Tiles "Controller," except that a Tiles Controller doesn't have access to the running Servlet, and if you use ValidatorForms, your FormBean must have access to the Servlet object. There's been some talk about trying to apply the general "controller" pattern to all Struts forwards, and in some ways, that's what we do with our "PagePrep" strategy, but it's been a while since anyone suggested a specific approach, and I don't think I've ever seen any actual code to do it.
I'd be open to community discussions about how to integrate some behavior like this into Struts before we get there, but I must admit that since I have a solution where I need it, I'll need some external motivation to work on a solution that fits into the current RequestProcessing model.
This was discussed at great length last Spring (that long ago?!)
http://marc.theaimsgroup.com/?l=struts-dev&m=105415755227385&w=2
but nothing ever congealed the point where code was cut for the core Struts distribution.
Joe
-- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining." -- Jef Raskin
--------------------------------------------------------------------- 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]
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining."
-- Jef Raskin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
