Re: Who decides?
On 9/10/05, Leon Rosenberg <[EMAIL PROTECTED]> wrote: > > > > > -Ursprüngliche Nachricht- > > Von: Craig McClanahan [mailto:[EMAIL PROTECTED] > > Gesendet: Samstag, 10. September 2005 18:06 > > An: Struts Users Mailing List; [EMAIL PROTECTED] > > Betreff: Re: Who decides? > > > > Here's a couple of things that (had we known then what we > > know now) would very likely be different -- and areas where I > > think improvements would be > > helpful: > > > > * Actions as stateless singletons, instead of per-request instances > > I think they 'de facto' are stateless singletons? I mean the controller > only > creates one instance, and you shouldn't create another :-) Well, you can certainly make your custom RequestProcessor do this as well ... but nearly every successful developer using Struts has had it pounded into their heads that you shouldn't use instance variables in an Action to store per-request state. Creating an Action per request also still doesn't let you eliminate form beans and just use properties on the Action instance itself (the way WebWork, Tapestry, and JSF like you to do). > * Expression language syntax (based on BeanUtils) is way too limited > > For those who need it :-) The conciseness and power of using expression language based manipulations, especially when it can do dependency injection style bean creation the way JSF managed beans work "for free", and even when you're programming your actions in Java, is one of the hidden jewels that remains for many developers to discover :-). > > > * Totally dependent on Servlet API objects, making (a) unit > > tests hard, and (b) implementations on portlet difficult > > I think it's the nature of a http framework? Nope ... it's the nature of an http framework that was designed before portlets existed. JSF, for one, goes to great pains to hide the differences between the two environments. The same result should be possible with pretty much any architectural strategy that passes a context object around ... just make sure the context object has accessors to get to the abstract idea of a "request parameter" (and so on), without being coded directly to the servlet or portlet API. In the Commons Chain world, for example, that's why the WebContext abstraction exists. ... > > Regards > Leon Craig PS: No, it's not really 5 in the morning where I am ... just arrived in Bejing for the Java China conference going on this week , and it's 8pm here. But you're not very likely to see me participating in conversations in semi-real-time this week :-).
Re: Who decides?
Speaking for myself, yes. On 9/10/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > Ted, I read what you wrote here with interest. I consider myself a > champion of backwards compatibility... in fact, within the past month I > recall being involved in a discussion thread here where I seemed to be > the only one saying backwards compatibility should not be broken, within > the context of that discussion (which, to be honest, I do not recall :) > ). I completely agree that it is an important consideration always. > > What I infer from what you wrote, and please correct me if the inference > is not accurate, is that the milestone of breaking things out into > subprojects could in essence serve to open the floodgates a bit... > meaning, maybe the committers will be more willing to entertain some > ideas that they may have previously passed on once that reorganization > is complete and "in the wild" because it will theoretically be easier to > do them then. Is that a fair assessment? > > If so, I for one look forward to the 1.3 release even more than I did > before :) > > Frank > > Ted Husted wrote: > > On 9/10/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > > >>Over the past few months there have been a number of people who have > >>attempted to evolve Struts to "catch up" in some ways with what other > >>frameworks are doing. They have been turned away, sometimes for > >>obviously legitimate reasons, sometimes for more debatable ones. > > > > > > Usually, the problem has been retaining backward compatibility. When a > > suggestion breaks backward compatibility, we tend to pass, at least > > until we can setup a deprecate/ remove/ release cycle. Since this > > cycle can take a year or more, some people drift away before we can > > implement a suggestion. > > > > Some suggestions have been out of scope, mainly for the taglibs. Along > > the way we decided that the original taglibs should stick to the HTML > > 4.1 specification. Some taglib suggestions are non-starters because of > > the product's scope. > > > > The big fix for both of these problems, and several others, is to > > subdivide the one-size-must-fit-all Struts distribution into > > subprojects. If a suggestion is not backwardly compatible, then > > perhaps we can make it an optional component in the Extras subproject. > > If a taglib is not HTML 4.1 compliant, then maybe we can start another > > taglib subproject. > > > > But, until last month, we simply didn't have the infrastructure to > > even consider such things. > > > > Another problem is being sure that there be someone around to maintain > > the code. We like to see broad enough support for any suggestion to > > ensure that there will be at least three people around who will > > support the code. It doesn't matter if comes from a developer or a > > committer. A lot of suggestions from committers die on the vine > > because too few people seem interested. > > > > Many folks don't realize that extensions we now take for granted, like > > Validator and Tiles, were being used in production applications for > > *years* before we added them to the distribution. (I used both myself > > in April 2001, before Struts 1.0 final.) > > > > In the same light, I expect we will see an Ajax subproject for Apache > > Struts one day. But before that happens, we'd like to see broad > > support for Ajax among Struts users. Then, we can be sure there will > > be committers around to support the subproject later. > > > > As it stands, we are just now completing tasks we planned *18 months* > > ago. But, we are completing them, slow and steady. > > > > In fact, I remember Don Brown making the first "subproject > > reorganization" commits at ApacheCon 2004 last November. Martin and I > > were sitting at a table with him at the Hackathon, jovially giving Don > > verbal +1s. :) > > > > Ten months later, we're finally at the point where we can build and > > distribute the original Struts subprojects, along with the new kids on > > the block, Flow, Scripting, and Shale. > > > > > >>Everyone seems to want to go off and create something entirely new when > >>I haven't seen a single good, concrete reason why Struts as it exists > >>today can't be evolved. Why? > > > > > > It *is* being evolved. It's just that evolution takes time. > > Personally, I still fully intend to walk down the Struts Classic > > Roadmap that we posted over a year ago. We're just now hitting the > > first milestone: subprojects. We hit this one, and we'll hit the > > others too. > > > > * http://struts.apache.org/roadmap.html > > > > Meanwhile, exploring alternatives like Ti can be good for Struts > > Classic too. Like as not, there will be techniques used in Ti that we > > can retrofit to Struts Classic. And, perhaps, one day, they might even > > evolve into the same product. Or not. At this point, Ti is still > > hypotethical. > > > > > >>Many of the things that people claim to want in a modern framework I > >>have either myself do
Re: Who decides?
On 9/10/05, Murray Collingwood <[EMAIL PROTECTED]> wrote: > I am very happy to contribute towards the development of Struts (since Craig > invited > me) however I'm still kinda new so I might not be much use for a while. So, > here I am > sticking up my virtual hand and asking "what would you like me to do?" as a > volunteer > does. The first thing any prospective volunteer should do is review the "How to Help" FAQ, which includes several concrete suggestions. * http://struts.apache.org/faqs/helping.html It would also be helpful, but not required, for newcomers to review the How the ASF works pages. * http://apache.org/foundation/how-it-works.html and our project guidelines * http://struts.apache.org/bylaws.html A followup suggestion to the How to Help FAQ would be for someone to review, apply, and report on some or all of the 22 enhancements with patches. There's a link on the Roadmap page to the Bugzilla issues. * http://struts.apache.org/roadmap.html#Bugzilla A very helpful thing would be for someone to review the 252 outstanding Bugzilla enhancement sugggestions, and summarize them in some way. We don't want to jettison them all, we just want to find someway to handle the backlog gracefully. At this point, my only suggestion is to extend the "Idea Jar" page. * http://wiki.apache.org/struts/StrutsIdeaJar Then perhaps we can work them into the Roadmap for Struts 1.7 and beyhond. There are also several milestones on the roadmap that will need coding. The next in line are the "experimental interfaces". The elephant in the room is that our first crack at the new Request Processing chain is no where near as slick as we would like. Someone interested in that can start by reviewing the Commons CoR documentation and code, the MailReader example in the sandbox, and the Core 1.3 code. * http://jakarta.apache.org/commons/chain/ * http://svn.apache.org/viewcvs.cgi/struts/sandbox/trunk/mailreader-chain/?rev=280105 * http://svn.apache.org/viewcvs.cgi/struts/core/trunk/conf/java/chain-config.xml?view=markup There are also some OnJava articles on Chain * http://www.onjava.com/lpt/a/5671 * http://www.onjava.com/lpt/a/5693 Right now, our implementation is too much like a template and too little like a true chain. Struts Classic 1.3.x is built with Maven (maven.apache.org). I'm working on the documentation updates now. In the meantime, there's a Wiki page on the Maven build here: * http://wiki.apache.org/struts/StrutsMaintenanceMaven > > Some of the responses we have had indicate that 'committers' are making > direction > decisions rather than the PMC. The role of the PMC is to control the > project. It sounds > from some responses that our 'committers' (some not all) have their own > agendas and > this is being accepted by the PMC. As a volunteer (contributor) I should be > doing what > the PMC ask me to, otherwise they aren't "in control" and I'm not really a > volunteer. The "How it works document" does say that "The PMC as a whole is the entity that controls the project, nobody else.", but the PMC does *not* control through delegation. The PMC members *are* the committers. In the normal course, after a committer has been active for six months or so, we will invite the comitter to join the PMC (or explain why we are not). The goal of an ASF project is for all the committers to be PMC members. A guiding principle of the Apache Way is "them that do the work, make the decisions". This phrase is actually a double-entendre. We do make some decisions by voting (very few), but the real decisions are made when a volunteer does the work. Otherwise, because we are a volunteer organization, nothing actually happens. Even when we vote, there is an implication of volunteering. If a PMC member "vetos" a code change, the PMC member is obligated to produce a sound technical reason *or* an alternate implementation. If neither of these things happen, then the veto is not binding. Likewise, when we vote +1 on a release, we are also pledging to actively support the release by applying patches and answering questions. It's not about having an opinion, it's about being ready, willing, and able to do the work. > > SUMMARY > -- > Maybe my view is a little altruistic or idealistic. I would like to see the > PMC take control > of the project and assign those tasks identified below (by Craig) to the > volunteer > developers that work on this project. As mentioned, the PMC members *are* the volunteer developers that work on this project. When a new volunteer starts submitting patches, and conducting themselves well on the lists, after about six months, we invite them to join us as a Committer. After another six months, a Committer becomes a PMC member. Committers volunteer for tasks as our schedules permit. If one of us stops volunteering altogether for more than six months, then we change that individual's status from "active" to "emeritus". If the volunteer's schedule changes later, a
Re: Wrapping Struts tags in tag files
It appears the definition may be out of scope /out of context
This can be achieved thru tiles by 'Put an attribute' into enclosing
attribute container tag
(where container tag can be or )
http://struts.apache.org/api/org/apache/struts/taglib/tiles/PutTag.html
(Unless of course there is a problem with resolving your RTExpr)
Anyone else?
M-
- Original Message -
From: "Laurie Harper" <[EMAIL PROTECTED]>
To:
Sent: Saturday, September 10, 2005 10:03 PM
Subject: Wrapping Struts tags in tag files
This isn't really Struts specific, but I'm trying to wrap some of the
Struts HTML tags with tag files (in order to compose them into more
complex 'controls') and I'm running into a slight problem... Some
attributes are mutually exclusive (e.g. 'alt' vs. 'altKey'). I can't see a
way to pass attributes through from the tag file to the Struts tag that
works with this constraint. For example, if I write a tag file like this:
<[EMAIL PROTECTED] name="property" required="true" rtexprvalue="true"%>
<[EMAIL PROTECTED] name="alt" required="false" rtexprvalue="true"%>
<[EMAIL PROTECTED] name="altKey" required="false" rtexprvalue="true"%>
...
then, regardless of whether I set alt and/or altKey in the call to the tag
file, the html:text tag complains that I can't specify both attributes.
I've tried passing in the values using "${empty alt ? null : alt}" but get
the same result.
Does anyone know a way to work around this (i.e. a 'correct' way to
pass-through attributes from tag files to custom tags)?
Failing that, how big a deal would it be to change the Struts tags to
treat the empty string equivalently to 'null' when performing these
checks? [I'll happy put together a patch to do that]
L.
-
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: Who decides?
As my wife likes to say, cool beans :) Frank Ted Husted wrote: Speaking for myself, yes. On 9/10/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: Ted, I read what you wrote here with interest. I consider myself a champion of backwards compatibility... in fact, within the past month I recall being involved in a discussion thread here where I seemed to be the only one saying backwards compatibility should not be broken, within the context of that discussion (which, to be honest, I do not recall :) ). I completely agree that it is an important consideration always. What I infer from what you wrote, and please correct me if the inference is not accurate, is that the milestone of breaking things out into subprojects could in essence serve to open the floodgates a bit... meaning, maybe the committers will be more willing to entertain some ideas that they may have previously passed on once that reorganization is complete and "in the wild" because it will theoretically be easier to do them then. Is that a fair assessment? If so, I for one look forward to the 1.3 release even more than I did before :) Frank Ted Husted wrote: On 9/10/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: Over the past few months there have been a number of people who have attempted to evolve Struts to "catch up" in some ways with what other frameworks are doing. They have been turned away, sometimes for obviously legitimate reasons, sometimes for more debatable ones. Usually, the problem has been retaining backward compatibility. When a suggestion breaks backward compatibility, we tend to pass, at least until we can setup a deprecate/ remove/ release cycle. Since this cycle can take a year or more, some people drift away before we can implement a suggestion. Some suggestions have been out of scope, mainly for the taglibs. Along the way we decided that the original taglibs should stick to the HTML 4.1 specification. Some taglib suggestions are non-starters because of the product's scope. The big fix for both of these problems, and several others, is to subdivide the one-size-must-fit-all Struts distribution into subprojects. If a suggestion is not backwardly compatible, then perhaps we can make it an optional component in the Extras subproject. If a taglib is not HTML 4.1 compliant, then maybe we can start another taglib subproject. But, until last month, we simply didn't have the infrastructure to even consider such things. Another problem is being sure that there be someone around to maintain the code. We like to see broad enough support for any suggestion to ensure that there will be at least three people around who will support the code. It doesn't matter if comes from a developer or a committer. A lot of suggestions from committers die on the vine because too few people seem interested. Many folks don't realize that extensions we now take for granted, like Validator and Tiles, were being used in production applications for *years* before we added them to the distribution. (I used both myself in April 2001, before Struts 1.0 final.) In the same light, I expect we will see an Ajax subproject for Apache Struts one day. But before that happens, we'd like to see broad support for Ajax among Struts users. Then, we can be sure there will be committers around to support the subproject later. As it stands, we are just now completing tasks we planned *18 months* ago. But, we are completing them, slow and steady. In fact, I remember Don Brown making the first "subproject reorganization" commits at ApacheCon 2004 last November. Martin and I were sitting at a table with him at the Hackathon, jovially giving Don verbal +1s. :) Ten months later, we're finally at the point where we can build and distribute the original Struts subprojects, along with the new kids on the block, Flow, Scripting, and Shale. Everyone seems to want to go off and create something entirely new when I haven't seen a single good, concrete reason why Struts as it exists today can't be evolved. Why? It *is* being evolved. It's just that evolution takes time. Personally, I still fully intend to walk down the Struts Classic Roadmap that we posted over a year ago. We're just now hitting the first milestone: subprojects. We hit this one, and we'll hit the others too. * http://struts.apache.org/roadmap.html Meanwhile, exploring alternatives like Ti can be good for Struts Classic too. Like as not, there will be techniques used in Ti that we can retrofit to Struts Classic. And, perhaps, one day, they might even evolve into the same product. Or not. At this point, Ti is still hypotethical. Many of the things that people claim to want in a modern framework I have either myself done or seen done with the current Struts codebase. Things like components that remember and render their own state ala JSF, a simple managed bean facility (IoC), built-in AJAX support, something akin to a prerender facility, the work of Michael Jouravlev, all of these
Re: Who decides?
My aim with the list of patterns / features was to give you something to scan over quickly to point out where the Spring MVC framework provides something better than struts. They're not really just struts features, they're more patterns found in any web-app. I find several of them require cumbersome solutions in struts. Are you saying then really that the main plus-point for Spring over Struts is the stability of the project? Dakota Jack on 10/09/05 21:24, wrote: The main issue, Adam, was stability. I believe that my statements were useful for the person asking the question. I am not interested in being "non-contensious" or otherwise satisfying your personal needs. I was trying to answer the question in a helpful way, even if you might do otherwise. If you would like to do otherwise, do so. I don't care. I think that a honest answer to the questioner requires stating what is relevant. That seems okay to me. LIke I said, do what you like. If you don't like what I say, I recommend you take evasive action. I am not trying to impress you but assist someone else. Regarding the list you tossed out, much of that is portable and almost all could be easily made portable. Some of the "features", e.g. the way Struts code does multiple commands on a form submit, I personally consider to be more a bug that a feature. What you like is not my concern. I was talking to someone else. I don't find your list to be fair, however. A large part of your list is stuff that is quite portable and not Struts specific and others are simply not covered by Strust. Anyway, I have always liked Struts classic and still do. What I was saying is that the community is unstable and that a person starting an application would be taking a risk at this point starting with Struts. On 9/10/05, Adam Hardy <[EMAIL PROTECTED]> wrote: Dakota Jack on 10/09/05 07:09, wrote: I sympathize entirely with what you are saying, Murray, and believe that there is no good reason for the present difficulties you face. The situation is NOT inevitable or even desirable. I would strongly suggest you consider the Spring alternative which is highly unlikely to change in fundamentals for a very long time. There is no vision here that is not willy nilly and merely fulfilling some philosophical opinions about community which come down to servicing the older committers' daytime jobs and reputatoins, in my opinion. They say that too, but I will guess that they don't want anyone else saying it. Struts is a very unstable community producing inferior code at this point with political infighting on a "nice" level to steal the name for the latest and greatest old idea trying to claim to be very, very, very new. Dakota, can't you control your trollish instincts? There are far less contentious ways of saying what you said. Since you are recommending Spring, can you answer a couple of questions about it? For instance, is there any outstanding improvement over struts in the patterns that it offers for say: * tiles * breadcrumb menu * taglibs * nested beans * l12n and i18n (prob: dropdowns) * reference data cache * dropdown data collections (Id & Label) * DTOs to view mapping * validator * multiple commands on form submit * cancel button * post-redirect-get * exception handling * displaying messages * security - Spring is based on Acegi right? * transaction token - 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]
Character encoding...
Hi, I had problem with character encoding in my web application. I was trying to display Polish characters using UTF-8 but data from forms was not getting in proper format to the business layer. I managed to solve this by setting filter which does request.setCharacterEncoding(encoding); But the question is: WHY it didn't work when I was using request.setCharacterEncoding() in Action's execute() method?? Wojtek
Re: Character encoding...
I had problem with character encoding in my web application. I was trying to display Polish characters using UTF-8 but data from forms was not getting in proper format to the business layer. I managed to solve this by setting filter which does request.setCharacterEncoding(encoding); But the question is: WHY it didn't work when I was using request.setCharacterEncoding() in Action's execute() method?? The request's character encoding can only be set before the input values are read. By the time the Action executes, the ActionForm has already been populated, which means that the request has already deserialized the request parameters from bytes on the wire into Java Strings. Thus, a ServletFilter is the best way to make sure that this value is set at the earliest possible time. Hope this helps, Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to get the value of parent form field in child - logic:equal
Help please! BACKGROUND == A parent window/form - formA opens up formB. In formB, I am using logic:equal. In the value attribute of logic:equal, I want to dynamically get the current value of a field in formA - opener. PART OF SOURCE CODE === PROBLEM === None of the lines below (value attribute of logic:equal) work: value=opener.forms[0].to_country.value value="opener.forms[0].to_country.value" value='opener.forms[0].to_country.value' value=javascript:opener.forms[0].to_country.value value="javascript:opener.forms[0].to_country.value" value='javascript:opener.forms[0].to_country.value' The only time it works is when the value is hardcoded i.e. value="UK" I do not want to hard code the country name, because it is not always UK. Please tell me how to proceed... Thank you. O. Oke ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
getting ActionMessages and form bean from simple servlet
How to get ActionMessages and form bean objects when simple sevlet is used as a view ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with Validation of Struts DynaValidatorForm
You probably need your form to be declared as type
org.apache.struts.action.DynaActionForm (rather than DynaValidatorForm).
The difference between their behaviour is a little subtle so it's easy
to get them mixed up. Try changing it and see if it works.
L.
Weng Kong Lee wrote:
Hi all,
I've just started exploring the use of Struts DynaValidatorForms. I've
tried to set-up a very simple login form with a username and password
fields, where both are required. Here's the relevant details:
1. struts-config.xml
The application message resource bundle has been configured with the
required validation messages for the validation framework, and the
validator plugin is also declared.
I declared a form bean as follows:
form-bean
name="loginForm" type="org.apache.struts.validator.DynaValidatorForm">
Then I declared a action tied to the form bean as follows:
2. login.jsp
This is the JSP with the form. It uses both client and server-side
validation.The code is as follows:
Login:
Password:
3. validation.xml
I declared both the "userName" and the "password" fields to be
"required", as follows:
4. Action class, LoginAction.java
Here's the execute mehod implementation. Basically, it rejects the
login when the userName and password are not both "test".
public ActionForward execute(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse
response) {
DynaValidatorForm loginForm = (DynaValidatorForm) form;
String userName = loginForm.getString("userName");
String password = loginForm.getString("password");
if ((userName == null) || (!userName.equals("test"))) {
return mapping.findForward("failure");
} else if ((password == null) || (!password.equals("test"))) {
return mapping.findForward("failure");
} else {
return mapping.findForward("success");
}
}
I then tried to test the above by deploying the application, hitting
login.jsp and attempting to login with invalid userName and password.
The Javascript validation works fine, and the messages display
correctly => The message resource is configured correctly.
However when I turned off Javascript on my bowser to test the
server-side validation. The validation did not take place at all! If I
supplied a blank userName and/or password, it simply performs the
logic in LoginAction and sends me back to login.jsp, without any error
messages!
Anyone has any ideas what I might have missed out here?
Thanks in advance for any suggestions!
Weng Kong Lee
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wrapping Struts tags in tag files
That's only relevant to Tiles, though; it doesn't help for general JSP tags.
L.
Martin Gainty wrote:
It appears the definition may be out of scope /out of context
This can be achieved thru tiles by 'Put an attribute' into enclosing
attribute container tag
(where container tag can be or )
http://struts.apache.org/api/org/apache/struts/taglib/tiles/PutTag.html
(Unless of course there is a problem with resolving your RTExpr)
Anyone else?
M-
- Original Message - From: "Laurie Harper" <[EMAIL PROTECTED]>
To:
Sent: Saturday, September 10, 2005 10:03 PM
Subject: Wrapping Struts tags in tag files
This isn't really Struts specific, but I'm trying to wrap some of the
Struts HTML tags with tag files (in order to compose them into more
complex 'controls') and I'm running into a slight problem... Some
attributes are mutually exclusive (e.g. 'alt' vs. 'altKey'). I can't
see a way to pass attributes through from the tag file to the Struts
tag that works with this constraint. For example, if I write a tag
file like this:
<[EMAIL PROTECTED] name="property" required="true" rtexprvalue="true"%>
<[EMAIL PROTECTED] name="alt" required="false" rtexprvalue="true"%>
<[EMAIL PROTECTED] name="altKey" required="false" rtexprvalue="true"%>
...
then, regardless of whether I set alt and/or altKey in the call to the
tag file, the html:text tag complains that I can't specify both
attributes. I've tried passing in the values using "${empty alt ? null
: alt}" but get the same result.
Does anyone know a way to work around this (i.e. a 'correct' way to
pass-through attributes from tag files to custom tags)?
Failing that, how big a deal would it be to change the Struts tags to
treat the empty string equivalently to 'null' when performing these
checks? [I'll happy put together a patch to do that]
L.
-
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]
File upload in a form which has some other fields too - I have probelm to do it
Hi Thank you for reading my post. here is my problem : 1-is it possible to upload a file from a jsp file which has some more other fields too ? I mean for example a registration form which must have a file item to be uploaded ? 2-which method should be used to send the jsp fields to action ? Post or GET ? 3-is it manedatory to use Struts html tags to have file upload ? I used a plain jsp to gather myregistration dara and a to upload the file. 4-how i should retrive the file data in action ? 5-how i can save the file into a specefic folder in my web application -as you know host provider restrict the access to getRealPath() method-
Re: How to get the value of parent form field in child - logic:equal
You're trying to mix JSP syntax, which is processed on the server before the page is sent to the browser, with Javascript, which is processed by the browser after the page is sent. You can't do that. What you'll need to do is, when formA opens formB (presumably by submitting an HTTP request), include the information you need from formA as request parameters formB can then access during rendering. L. O. Oke wrote: Help please! BACKGROUND == A parent window/form - formA opens up formB. In formB, I am using logic:equal. In the value attribute of logic:equal, I want to dynamically get the current value of a field in formA - opener. PART OF SOURCE CODE === PROBLEM === None of the lines below (value attribute of logic:equal) work: value=opener.forms[0].to_country.value value="opener.forms[0].to_country.value" value='opener.forms[0].to_country.value' value=javascript:opener.forms[0].to_country.value value="javascript:opener.forms[0].to_country.value" value='javascript:opener.forms[0].to_country.value' The only time it works is when the value is hardcoded i.e. value="UK" I do not want to hard code the country name, because it is not always UK. Please tell me how to proceed... Thank you. O. Oke ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to get the value of parent form field in child - logic:equal
Laurie is of course correct. However, the other way you can do this is to have the script that you show here in the value attribute execute as a result of the onLoad event. That way you would not need to pass the information through with the request. The flow of what happens in that case is basically: (1) Some event on the page with formA occurs, either some Javascript that opens a new window, or a form submission targeted to a new window (2) The request is processed on the server and the page with formB is rendered, but with no values set. (3) The page with formB on it is returned to the client and shown in a new window. (4) Event onLoad fires executing the script which copies the values from the parent to the child. This is actually a fairly typical way of doing this, it's up to you whether you prefer the more client-side approach of this or the more server-side approach as Laurie suggests. I wouldn't say either is drastically better than the other. Frank Laurie Harper wrote: You're trying to mix JSP syntax, which is processed on the server before the page is sent to the browser, with Javascript, which is processed by the browser after the page is sent. You can't do that. What you'll need to do is, when formA opens formB (presumably by submitting an HTTP request), include the information you need from formA as request parameters formB can then access during rendering. L. O. Oke wrote: Help please! BACKGROUND == A parent window/form - formA opens up formB. In formB, I am using logic:equal. In the value attribute of logic:equal, I want to dynamically get the current value of a field in formA - opener. PART OF SOURCE CODE === PROBLEM === None of the lines below (value attribute of logic:equal) work: value=opener.forms[0].to_country.value value="opener.forms[0].to_country.value" value='opener.forms[0].to_country.value' value=javascript:opener.forms[0].to_country.value value="javascript:opener.forms[0].to_country.value" value='javascript:opener.forms[0].to_country.value' The only time it works is when the value is hardcoded i.e. value="UK" I do not want to hard code the country name, because it is not always UK. Please tell me how to proceed... Thank you. O. Oke ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to get the value of parent form field in child - logic:equal
Thanks for your response, I have taken note of your points. Please note, formB is actually opened as a popup - I should have mentioned this. --- Laurie Harper <[EMAIL PROTECTED]> wrote: > You're trying to mix JSP syntax, which is processed > on the server before > the page is sent to the browser, with Javascript, > which is processed by > the browser after the page is sent. You can't do > that. > > What you'll need to do is, when formA opens formB > (presumably by > submitting an HTTP request), include the information > you need from formA > as request parameters formB can then access during > rendering. > > L. > > O. Oke wrote: > > Help please! > > > > BACKGROUND > > == > > A parent window/form - formA opens up formB. In > > formB, I am using logic:equal. In the value > attribute > > of logic:equal, I want to dynamically get the > current > > value of a field in formA - opener. > > > > PART OF SOURCE CODE > > === > > property="country_id" > > value=opener.forms[0].to_country.value> > > > > > > PROBLEM > > === > > None of the lines below (value attribute of > > logic:equal) work: > > value=opener.forms[0].to_country.value > > value="opener.forms[0].to_country.value" > > value='opener.forms[0].to_country.value' > > value=javascript:opener.forms[0].to_country.value > > > value="javascript:opener.forms[0].to_country.value" > > > value='javascript:opener.forms[0].to_country.value' > > > > The only time it works is when the value is > hardcoded > > i.e. > > value="UK" > > > > I do not want to hard code the country name, > because > > it is not always UK. > > > > > > Please tell me how to proceed... > > > > Thank you. > > > > O. Oke > > > > > > > > > > > > > ___ > > > Yahoo! Messenger - NEW crystal clear PC to PC > calling worldwide with voicemail > http://uk.messenger.yahoo.com > > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > ___ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: File upload in a form which has some other fields too - I have probelm to do it
> 1-is it possible to upload a file from a jsp file which has some more other
> fields too ?
> I mean for example a registration form which must have a file item to be
> uploaded ?
Absolutely - it's just a standard HTTP request form after all.
> 2-which method should be used to send the jsp fields to action ?
> Post or GET ?
Definitely POST. Get has a maximum length according to the specification, I
think it's
256 or 2048 bytes or something. Your file is likely to be longer than this.
> 3-is it manedatory to use Struts html tags to have file upload ?
> I used a plain jsp to gather myregistration dara and a
>
> to upload the file.
Hmmm, not sure. I just used the Struts stuff so that everything is consistent.
Remember you want the Struts servlet to manage the fields so it is probably
better to let
Struts know about it from the beginning of your form creation through to the
end.
Remember you need the enctype= parameter in your HTML:FORM tag.
> 4-how i should retrive the file data in action ?
Here's a snippet from my code, 'df' is the form returned and I was uploading an
image
file:
// Get information about the uploaded file
FormFile uploaded = df.getImage();
df.setSize(uploaded.getFileSize());
df.setFilename(uploaded.getFileName());
File remote = new File(df.getFilename());
// Insert a record into the database, the IID field is
AUTO_INCREMENTing
pstmt = conn.prepareStatement(sql1.toString());
pstmt.setString(1, df.getTitle());
pstmt.setString(2, df.getFilename());
pstmt.setInt(3, df.getSize());
rc = (pstmt.executeUpdate() == 1);
// Retrieve the IID (unique number) so we can name and store the file
locally
if (rc) {
// Close and open a new statement
pstmt.close();
pstmt = conn.prepareStatement("SELECT LAST_INSERT_ID()");
rs = pstmt.executeQuery();
if (rs.next()) {
// Give this image a local name and write the data to this
file
// Here I'm creating "/fixedPathToImages/27_originalName.jpg"
// "27" is the unique number from the database so users can
// repeatedly load the same filename and it won't overwrite
InputStream is = uploaded.getInputStream();
df.setImageid(rs.getInt(1));
df.setLocal(df.getImageid() + IMAGESEP + remote.getName());
File local = new File(Manager.getImageDirectory() + "/" +
df.getLocal());
FileOutputStream fos = new FileOutputStream(local);
byte[] buffer = new byte[32768];
int n = 0;
while ((n = is.read(buffer)) != -1)
fos.write(buffer, 0, n);
is.close();
fos.close();
// Now store the LOCAL name in the record
pstmt.close();
pstmt = conn.prepareStatement("UPDATE Doc SET " + LOCAL + " =
?
WHERE " + IMAGEID + " = ? ");
pstmt.setString(1, df.getLocal());
pstmt.setInt(2, df.getImageid());
rc = (pstmt.executeUpdate() == 1);
}
}
> 5-how i can save the file into a specefic folder in my web application -as
> you know host provider restrict the access to getRealPath() method-
This is an interesting question. You probably don't want to store your images
in your
web directory, is the answer I came up with. Have you ever used the "undeploy"
option
in the Tomcat Manager/Administrator? When you use "undeploy" it removes the
entire
directory where your WAR file was extracted. If you stored any data there then
it's all
history.
I tried storing the files as Blobs in my database but you don't want to go here
either, it's
a performance nightmare (8 seconds to download a 140k file).
You need a fixed directory somewhere on your server to write these files. My
preference is to keep them near the database files so that they get backed up
together.
However, I think there is some performance issue with MySQL (or SQL in general)
if it
can't handle these files being stored as Blobs. What's the point in defining a
Blob type
that handles 32mb if it doesn't perform in practice.
Kind regards
mc
FOCUS Computing
Mob: 0415 24 26 24
[EMAIL PROTECTED]
http://www.focus-computing.com.au
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.10.20/95 - Release Date: 9/09/2005
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to get the value of parent form field in child - logic:equal
Frank, Thanks for your advise. I wish to look into the onLoad option that you suggested, but please tell me, how to set the value attribute of logic:equal to the value of the opening form's field. For example, if opener.forms[0].to_country.value has a value of UK, how can I get this value (UK) to the value attribute of logic:equal in formB? Please note that fromB opens up as a pop up. Thank you. --- "Frank W. Zammetti" <[EMAIL PROTECTED]> wrote: > Laurie is of course correct. However, the other way > you can do this is > to have the script that you show here in the value > attribute execute as > a result of the onLoad event. That way you would > not need to pass the > information through with the request. > > The flow of what happens in that case is basically: > > (1) Some event on the page with formA occurs, either > some Javascript > that opens a new window, or a form submission > targeted to a new window > > (2) The request is processed on the server and the > page with formB is > rendered, but with no values set. > > (3) The page with formB on it is returned to the > client and shown in a > new window. > > (4) Event onLoad fires executing the script which > copies the values from > the parent to the child. > > This is actually a fairly typical way of doing this, > it's up to you > whether you prefer the more client-side approach of > this or the more > server-side approach as Laurie suggests. I wouldn't > say either is > drastically better than the other. > > Frank > > Laurie Harper wrote: > > You're trying to mix JSP syntax, which is > processed on the server before > > the page is sent to the browser, with Javascript, > which is processed by > > the browser after the page is sent. You can't do > that. > > > > What you'll need to do is, when formA opens formB > (presumably by > > submitting an HTTP request), include the > information you need from formA > > as request parameters formB can then access during > rendering. > > > > L. > > > > O. Oke wrote: > > > >> Help please! > >> > >> BACKGROUND > >> == > >> A parent window/form - formA opens up formB. In > >> formB, I am using logic:equal. In the value > attribute > >> of logic:equal, I want to dynamically get the > current > >> value of a field in formA - opener. > >> > >> PART OF SOURCE CODE > >> === > >> property="country_id" > >> value=opener.forms[0].to_country.value> > >> > >> > >> PROBLEM > >> === > >> None of the lines below (value attribute of > >> logic:equal) work: > >> value=opener.forms[0].to_country.value > >> value="opener.forms[0].to_country.value" > >> value='opener.forms[0].to_country.value' > >> value=javascript:opener.forms[0].to_country.value > >> > value="javascript:opener.forms[0].to_country.value" > >> > value='javascript:opener.forms[0].to_country.value' > >> > >> The only time it works is when the value is > hardcoded > >> i.e. value="UK" > >> > >> I do not want to hard code the country name, > because > >> it is not always UK. > >> > >> > >> Please tell me how to proceed... > >> > >> Thank you. > >> > >> O. Oke > >> > >> > >> > >> > >> > >> > ___ > Yahoo! > >> Messenger - NEW crystal clear PC to PC calling > worldwide with > >> voicemail http://uk.messenger.yahoo.com > > > > > > > > > - > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > > > > > > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Who decides?
On 9/11/05, Ted Husted <[EMAIL PROTECTED]> wrote:> > Right now, our implementation is too much like a template and too > little like a true chain. That is because the template method was used first and the chain was enlisted to fix this mistake. Had a strategy pattern been used in the first place, this spaghetti would not be necessary. -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Who decides?
I am saying that for me Struts is not a viable product to use in any new commercial areas because of this. Spring is hugely superior as things stand and Struts is threatening to devolve. Indeed, it would be easier to build a new Struts on top of Spring than to fix get anyone to evolve Struts rather than change it into something that no fan of the Struts type architecture could possibly understand and love. On 9/11/05, Adam Hardy <[EMAIL PROTECTED]> wrote: > My aim with the list of patterns / features was to give you something to > scan over quickly to point out where the Spring MVC framework provides > something better than struts. > > They're not really just struts features, they're more patterns found in > any web-app. I find several of them require cumbersome solutions in struts. > > Are you saying then really that the main plus-point for Spring over > Struts is the stability of the project? > > > Dakota Jack on 10/09/05 21:24, wrote: > > The main issue, Adam, was stability. I believe that my statements > > were useful for the person asking the question. I am not interested > > in being "non-contensious" or otherwise satisfying your personal > > needs. I was trying to answer the question in a helpful way, even if > > you might do otherwise. If you would like to do otherwise, do so. I > > don't care. I think that a honest answer to the questioner requires > > stating what is relevant. That seems okay to me. LIke I said, do > > what you like. If you don't like what I say, I recommend you take > > evasive action. I am not trying to impress you but assist someone > > else. > > > > Regarding the list you tossed out, much of that is portable and almost > > all could be easily made portable. Some of the "features", e.g. the > > way Struts code does multiple commands on a form submit, I personally > > consider to be more a bug that a feature. > > > > What you like is not my concern. I was talking to someone else. I > > don't find your list to be fair, however. A large part of your list > > is stuff that is quite portable and not Struts specific and others are > > simply not covered by Strust. Anyway, I have always liked Struts > > classic and still do. What I was saying is that the community is > > unstable and that a person starting an application would be taking a > > risk at this point starting with Struts. > > > > > > > > On 9/10/05, Adam Hardy <[EMAIL PROTECTED]> wrote: > > > >>Dakota Jack on 10/09/05 07:09, wrote: > >> > >>>I sympathize entirely with what you are saying, Murray, and believe > >>>that there is no good reason for the present difficulties you face. > >>>The situation is NOT inevitable or even desirable. > >>> > >>>I would strongly suggest you consider the Spring alternative which is > >>>highly unlikely to change in fundamentals for a very long time. > >>> > >>>There is no vision here that is not willy nilly and merely fulfilling > >>>some philosophical opinions about community which come down to > >>>servicing the older committers' daytime jobs and reputatoins, in my > >>>opinion. They say that too, but I will guess that they don't want > >>>anyone else saying it. > >>> > >>>Struts is a very unstable community producing inferior code at this > >>>point with political infighting on a "nice" level to steal the name > >>>for the latest and greatest old idea trying to claim to be very, very, > >>>very new. > >> > >>Dakota, can't you control your trollish instincts? There are far less > >>contentious ways of saying what you said. > >> > >>Since you are recommending Spring, can you answer a couple of questions > >>about it? For instance, is there any outstanding improvement over struts > >>in the patterns that it offers for say: > >> > >> * tiles > >> * breadcrumb menu > >> * taglibs > >> * nested beans > >> * l12n and i18n (prob: dropdowns) > >> * reference data cache > >> * dropdown data collections (Id & Label) > >> * DTOs to view mapping > >> * validator > >> * multiple commands on form submit > >> * cancel button > >> * post-redirect-get > >> * exception handling > >> * displaying messages > >> * security - Spring is based on Acegi right? > >> * transaction token > >> > >> > >>- > >>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] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wrapping Struts tags in tag files
you're welcome
- Original Message -
From: "Laurie Harper" <[EMAIL PROTECTED]>
To:
Sent: Sunday, September 11, 2005 3:45 PM
Subject: Re: Wrapping Struts tags in tag files
That's only relevant to Tiles, though; it doesn't help for general JSP
tags.
L.
Martin Gainty wrote:
It appears the definition may be out of scope /out of context
This can be achieved thru tiles by 'Put an attribute' into enclosing
attribute container tag
(where container tag can be or )
http://struts.apache.org/api/org/apache/struts/taglib/tiles/PutTag.html
(Unless of course there is a problem with resolving your RTExpr)
Anyone else?
M-
- Original Message - From: "Laurie Harper" <[EMAIL PROTECTED]>
To:
Sent: Saturday, September 10, 2005 10:03 PM
Subject: Wrapping Struts tags in tag files
This isn't really Struts specific, but I'm trying to wrap some of the
Struts HTML tags with tag files (in order to compose them into more
complex 'controls') and I'm running into a slight problem... Some
attributes are mutually exclusive (e.g. 'alt' vs. 'altKey'). I can't see
a way to pass attributes through from the tag file to the Struts tag
that works with this constraint. For example, if I write a tag file like
this:
<[EMAIL PROTECTED] name="property" required="true" rtexprvalue="true"%>
<[EMAIL PROTECTED] name="alt" required="false" rtexprvalue="true"%>
<[EMAIL PROTECTED] name="altKey" required="false" rtexprvalue="true"%>
...
then, regardless of whether I set alt and/or altKey in the call to the
tag file, the html:text tag complains that I can't specify both
attributes. I've tried passing in the values using "${empty alt ? null :
alt}" but get the same result.
Does anyone know a way to work around this (i.e. a 'correct' way to
pass-through attributes from tag files to custom tags)?
Failing that, how big a deal would it be to change the Struts tags to
treat the empty string equivalently to 'null' when performing these
checks? [I'll happy put together a patch to do that]
L.
-
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: Problem with Validation of Struts DynaValidatorForm
Hi Laurie,
Thanks for the suggestion!
After digging into the Tomcat console logs, I've finally found out
what the problem is. Seems like my copy of validation-rules.xml was
corrupted. The arguments for the validateRequired method were wrong.
Corrected that and now it works fine :-)
Thanks for the reminder though on the tpye-casting for the form. That
could save me a lot of brain-cells some time down the line...
Weng Kong Lee
On 9/12/05, Laurie Harper <[EMAIL PROTECTED]> wrote:
> You probably need your form to be declared as type
> org.apache.struts.action.DynaActionForm (rather than DynaValidatorForm).
> The difference between their behaviour is a little subtle so it's easy
> to get them mixed up. Try changing it and see if it works.
>
> L.
>
> Weng Kong Lee wrote:
> > Hi all,
> > I've just started exploring the use of Struts DynaValidatorForms. I've
> > tried to set-up a very simple login form with a username and password
> > fields, where both are required. Here's the relevant details:
> >
> > 1. struts-config.xml
> > The application message resource bundle has been configured with the
> > required validation messages for the validation framework, and the
> > validator plugin is also declared.
> > I declared a form bean as follows:
> > > type="org.apache.struts.validator.DynaValidatorForm">form-bean
> > name="loginForm" type="org.apache.struts.validator.DynaValidatorForm">
> >
> >
> >
> >
> > Then I declared a action tied to the form bean as follows:
> > > attribute="loginForm"
> > input="/login.jsp"
> > name="loginForm"
> > path="/login"
> > scope="request"
> > type="project.struts.actions.LoginAction"
> > validate="true">
> >
> >
> >
> >
> > 2. login.jsp
> > This is the JSP with the form. It uses both client and server-side
> > validation.The code is as follows:
> >
> >
> > > onsubmit="return validateLoginForm(this);">
> >
> >
> > Login:
> >
> >
> >
> > Password:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 3. validation.xml
> > I declared both the "userName" and the "password" fields to be
> > "required", as follows:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 4. Action class, LoginAction.java
> > Here's the execute mehod implementation. Basically, it rejects the
> > login when the userName and password are not both "test".
> > public ActionForward execute(ActionMapping mapping, ActionForm form,
> > HttpServletRequest request, HttpServletResponse
> > response) {
> > DynaValidatorForm loginForm = (DynaValidatorForm) form;
> > String userName = loginForm.getString("userName");
> > String password = loginForm.getString("password");
> > if ((userName == null) || (!userName.equals("test"))) {
> > return mapping.findForward("failure");
> > } else if ((password == null) || (!password.equals("test"))) {
> > return mapping.findForward("failure");
> > } else {
> > return mapping.findForward("success");
> > }
> > }
> >
> > I then tried to test the above by deploying the application, hitting
> > login.jsp and attempting to login with invalid userName and password.
> > The Javascript validation works fine, and the messages display
> > correctly => The message resource is configured correctly.
> >
> > However when I turned off Javascript on my bowser to test the
> > server-side validation. The validation did not take place at all! If I
> > supplied a blank userName and/or password, it simply performs the
> > logic in LoginAction and sends me back to login.jsp, without any error
> > messages!
> >
> > Anyone has any ideas what I might have missed out here?
> >
> > Thanks in advance for any suggestions!
> >
> > Weng Kong Lee
>
>
> -
> 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]
Persistence on a form bean?
Hi folks Getting back to some operational questions... I want to edit some fields on a record in my database. I have a form bean which contains all of these fields plus a bunch of other fields that I won't be needing on the edit form. One of the fields I don't update is the ID property, it is my PRIMARY KEY and shouldn't be edited. So I create my DataEditForm action, my DataEdit.jsp and my DataEditSave action. DataEditForm action retrieves the record (by ID, say "27") from the database and populates my form bean, saving it as a request attribute. DataEdit.jsp displays just one text field from this bean (the current value of the field is displayed in this textbox) and I can edit it quite normally. DataEditSave action receives the form after editing but fails to update the record as the ID value now reflects "0" instead of "27". It seems to me that my DataEdit.jsp is dealing with 2 form beans, a pre-edit version that contains all of the data and a post-edit version that only contains the information from the html form. I know I could create "html:hidden" tags for all of the other fields, however this does seem a little arcane. I'm wondering if there is another option such as the form bean being saved pre-edit and restored post-edit and the fields from the html form then being updated again my form bean before being passed to my DataEditSave action? This would allow all of the unused fields to retain their true values. I guess pushing the form bean into the session would do this, but session variables for a request level function is probably not recommended. Looking forward to learning... Kind regards mc FOCUS Computing Mob: 0415 24 26 24 [EMAIL PROTECTED] http://www.focus-computing.com.au -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.10.21/96 - Release Date: 10/09/2005 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Persistence on a form bean?
From: "Murray Collingwood" <[EMAIL PROTECTED]> I guess pushing the form bean into the session would do this, but session variables for a request level function is probably not recommended. It is by me. :) Put the form in session scope, and most of your problems will disappear. You pick up a couple of new ones, but the tradeoffs are generally worth it. One of my webapps deals exclusively with editing records, and it takes several requests to finally complete an edit (or an add). All that time, I have a DTO (Value Object... what are we calling them this week?) and a form bean in session scope, updating the DTO as necessary until the user hits 'Finish'. The database key is read-only, in fact it's never in the form bean, it gets displayed with directly from the DTO. -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Persistence on a form bean?
On 9/11/05, Wendy Smoak <[EMAIL PROTECTED]> wrote: > From: "Murray Collingwood" <[EMAIL PROTECTED]> > > > I guess pushing the form bean into the session would do this, but session > > variables for a > > request level function is probably not recommended. > > It is by me. :) Put the form in session scope, and most of your problems > will disappear. You pick up a couple of new ones, but the tradeoffs are > generally worth it. > > One of my webapps deals exclusively with editing records, and it takes > several requests to finally complete an edit (or an add). All that time, I > have a DTO (Value Object... what are we calling them this week?) and a form > bean in session scope, updating the DTO as necessary until the user hits > 'Finish'. > > The database key is read-only, in fact it's never in the form bean, it gets > displayed with directly from the DTO. Same here, but instead of DTO I use real business object (BO), nested in the ActionForm with setters, that accept stringified data. I have my validation in the BO as well, which I call manually from action class. Oh, and I do not use pre-action and post-action, I use just one action in code-behind/event-dispatch style ;-) Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
