Help Re: cancel and session-scope form
Any ideas are appreciated. Is there anyway to keep my session-scoped form from being populated by a click of an html:cancel button? Is there any hook in the underlying Action that I can intercept prior to the ActionForm auto-population? Thanks, Angie Angie Lin wrote: Hi there, How can I prevent a cancel button from populating the form bean? Normally this isn't a problem, except that my form bean is in session-scope (for an wizard-like implementation). I've considered reconfiguring it so that the form stays in request-scope for each page in the wizard. I would then instantiate the form in session-scope myself and manage the copying of form fields from each page manually depending on if the user submitted or cancelled. But I was hoping for a simpler solution. thanks, Angie -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Angie Lin [EMAIL PROTECTED] 408.519.9250 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Help Re: cancel and session-scope form
Just quickly thinking it over ... When your form submits, you're going to hit an action. Your action is going to look and see what the user told you they wanted to do and act appropriately. Now, that doesn't help you keep the form from being populated, but you can certainly keep from updating your persistent storage using this information - and know that, instead, you should request fresh data to repopulate the form with. I like to rename my buttons to something like action or userAction - and give all of them the same name - so I can judge off the value of that parameter what the user is telling me they'd like to have happen. That's my spontaneous, first-cut answer. I can't think of a way to circumvent the population ... Angie Lin wrote: Any ideas are appreciated. Is there anyway to keep my session-scoped form from being populated by a click of an html:cancel button? Is there any hook in the underlying Action that I can intercept prior to the ActionForm auto-population? Thanks, Angie -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Help Re: cancel and session-scope form
Actually ... I've never done this before, but ... Why couldn't you invoke a javascript method on your Cancel button that invoked the forms reset method? That might be the easiest solution ... Eddie Bush wrote: Just quickly thinking it over ... When your form submits, you're going to hit an action. Your action is going to look and see what the user told you they wanted to do and act appropriately. Now, that doesn't help you keep the form from being populated, but you can certainly keep from updating your persistent storage using this information - and know that, instead, you should request fresh data to repopulate the form with. I like to rename my buttons to something like action or userAction - and give all of them the same name - so I can judge off the value of that parameter what the user is telling me they'd like to have happen. That's my spontaneous, first-cut answer. I can't think of a way to circumvent the population ... -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Only single attribute collections in ActionForm?
Hi, I'm building a web application using Struts, all the aspects of the framework are new to me. I try to stick to the MVC design, the Model and Controller are quite clear to me. Thanks to the wonderful work of the Struts team and in particular Chuck Cavaness and his Jakarta Struts Book Review. I still don't know how to design my view components and FormActions, maybe because of the missing chapter 8 (Custom Tag Libraries) of the review? Question 1) Where can I find this missing chapter? (PS I pre-ordered the book) I want to stick to the struts tag-lib and their use with FormBeans but I didn't find any convincing example of ActionForms for composed input pages. I have a page with a table, in each cell is a picture with display attributes (number, comment, link, ...) and input fields (check box for selection, quantity, ... ), the last cells may be empty (conditional display). I designed a PageView which is composed of PictureViews (with all the attributes for one cell). Question 2) Where can I find an example for building this kind of JSP page with multi-level nested Struts tags (iterate, logic, ...) which will be used as input of an ActionForm? Question 3) Do I need to decompose my input attributes in my ActionForm to simple Arrays/ArrayLists (Is it a best practise?): selectedPictures[] pictureNumbers[] orderedQuanties[] Your help will be appreciated!! Frederic PS Mastering jakarta Struts is already part of Java collection. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Help Re: cancel and session-scope form
Thanks for the tip, but I'm trying to avoid javascript as much as possible. It looks like I'll have to go ahead and manage my session form manually, and use a request-scoped form so that the auto-population doesn't blow away the properties. Thanks again, Angie Eddie Bush wrote: Actually ... I've never done this before, but ... Why couldn't you invoke a javascript method on your Cancel button that invoked the forms reset method? That might be the easiest solution ... Eddie Bush wrote: Just quickly thinking it over ... When your form submits, you're going to hit an action. Your action is going to look and see what the user told you they wanted to do and act appropriately. Now, that doesn't help you keep the form from being populated, but you can certainly keep from updating your persistent storage using this information - and know that, instead, you should request fresh data to repopulate the form with. I like to rename my buttons to something like action or userAction - and give all of them the same name - so I can judge off the value of that parameter what the user is telling me they'd like to have happen. That's my spontaneous, first-cut answer. I can't think of a way to circumvent the population ... -- Angie Lin [EMAIL PROTECTED] 408.519.9250 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: all this traffic
No, I'm not a committer (from my understanding of the term). I can't commit anything to cvs, I've just submitted a few docs and maybe a patch for code. I understand that everything we submit won't get applied but if it's not going to be used they could at least post a response in bugzilla telling us why. Without that it's a bit discouraging. Dave From: Eddie Bush [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: Re: all this traffic Date: Fri, 27 Sep 2002 10:50:28 -0500 Well, David, you're a committer, right? What would you suggest a person do? I hear you on the patches - but, to be honest, patches are suggestions - there's no rule that states that they must be applied. The person committing the changes may, in fact, have a different perspective on the changes you made and not include your patch - but derive something from your patch that does get committed. My view on filing a fix is: Hey, here's my suggestion - oh, and I thought it through enough that I actually coded it and made it compile and TESTED it - it works for me. A good example of the debacle a commiter could find himself involved in is this latest thing with sub-apps that Steve Ditlinger and I have been hitting on. I'm sure you've followed it. The question is: Do we ahere strongly to this, or relax to include that too - that's a judgement call on the part of the committer, IMHO. My original patch was simply to make things work the way I understood Craig wanted them to. That didn't suit Steve, so he submitted another patch for what he wanted. Then, Martin piped up and suggested neither of us fully comprehended the situation (and we didn't! He had good points!) and last night I hacked out another patch - which I have yet to attack because I'm waiting for suggestions on whether I've covered all the bases or not. I think I have, but I can't claim to know Struts as well as those who are commiters for this piece of the machinery. In the end, one of the three patches will probably be used, and it's really irrelevant to me which one it is. I just want sub-app selection to be bulletproof :-) David Graham wrote: Agreed, but it's frustrating when you submit a patch or documentation and its not applied or responded to. It seems like they can get lost in the shuffle. Dave -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Proper exception handling of JDBC code? Need to call connection.rollback()?
It's good practice to always put the rollback in the catch block and the
close in the finally block. Never depend on the Connection to do this for
you. It's not really because of defensive programming, it's to ensure the
correctness of your data.
An easy way to not forget to do this is to create some kind of wrapper
method that calls your implementation method. The impl. method will throw
SQLException and not have any catch blocks for database problems. The
wrapper method that called the impl. method catches SQLException and calls
rollback. It also calls conn.commit() if successful and conn.close in the
finally block. This reduces your JDBC code considerably.
Dave
From: Bomb Diggy [EMAIL PROTECTED]
Reply-To: Struts Users Mailing List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Proper exception handling of JDBC code? Need to call
connection.rollback()?
Date: Sat, 28 Sep 2002 16:40:57 -0700 (PDT)
One of the many points I raised earlier was how to
properly close a database connection, and how that
might change depending on whether you were using
connection pooling and/or a DataSource. The example
JDBC code cited was that in the Struts 1.0.2 Javadoc:
http://jakarta.apache.org/struts/doc-1.0.2/api/org/apache/struts/util/package-summary.html#doc.JDBC
The part that looked a little funny to me and others
was the call to [myConnection].rollback() in the
catch{} block. I think I finally figured out why this
was put in - defensive programming.
It seems to me that if *any* part of a transaction is
successful, then [connection].rollback() needs to be
called, else the next piece of application code that
got its hands on that connection object and completed
a transaction successfully would also complete the
previously-uncommitted transaction.
For example, let's say your updateDB() method has two
separate method calls made within it that each update
a table. If only the first conn.executeUpdate()
method completes successfully, and the second
conn.executeUpdate() throws some kind of SQLException,
that transaction will *not* automatically be rolled
back. The driver won't do it. The database would do
it only when the connection is finally closed.
But what if that connection is part of a connection
pool, and before the application server (and thus the
pool) goes down for the night, that updateDB() method
is used again, this time with success. Now, the
leftover transaction from the first failed call to
updateDB() has been committed along w/ any changes
from follow-on calls to updateDB(). All of this
happens, if your DataSource/Connection Pooling
Mechanism/Wrapped Connection Object isn't smart enough
to call [connection].rollback() for you. The
GenericConnection object that ships with Struts is
smart enough - and that's why I probably hadn't been
burned in the past while using Struts, and not calling
conn.rollback() myself.
The GenericConnection object's first task in its
close() method is to call connection.rollback(). So,
as long as I call connection.close() before leaving my
updateDB() method, I'm good to go.
/* Code snippet from Struts source */
...
// Clean up any outstanding transaction as best we can
try {
conn.rollback();
} catch (SQLException e) {}
...
Hope all this is correct...don't want to mislead
people...
__
Do you Yahoo!?
New DSL Internet Access from SBC Yahoo!
http://sbc.yahoo.com
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
_
Send and receive Hotmail on your mobile device: http://mobile.msn.com
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Disabling jsessionid parameter in Struts forms
On Thu, 26 Sep 2002, Andrew Hill wrote: Date: Thu, 26 Sep 2002 17:11:41 +0800 From: Andrew Hill [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED], [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: RE: Disabling jsessionid parameter in Struts forms You are correct about encodeURL() - this is when the sessionId is appended. The sessionId is part of the servlet API session tracking mechanism , and as you have noticed is appended to the URL when not using cookies. (When using cookies it is instead stored in a cookie). If you do not include the sessionId , you will not be able to make much use of session scope in your website (as each request will get a new session). If you dont need to use session scope to keep track of anything, this probably won't be a problem (I think - unless struts itself needs it for certain things?). As for actually disabling the appending of sessionId I am afraid I have no idea how you might achieve it with regards to the struts tags. The jsessionid path parameter is indeed added by the call that Struts automatically makes to response.encodeURL() when setting up URLs for you. Without this automatic feature, you'd have to call encodeURL() yourself in order to ensure that your application works when your client does not have cookies enabled. So, why does this get generated when my client *does* have cookies? The reason is that, on the first response for a particular session, the server has no way to know if you have cookies enabled or not, so the session ID is sent *both* ways (via URL rewriting and as a cookie). If the session ID comes back in as a cookie, the server will understand that it no longer needs to rewrite from the second response on. There is no configuration parameter to turn this off, and there won't be. The important principle you should get used to is that the actual contents of the request URL is pretty meaningless in a web application based on Model 2 design patterns. You're far better training yourself (and your users) to ignore the URL completely rather than obsessing over the detailed contents. For stubborn users, I've occasionally resorted to running the app in a frameset with a single frame, just so the location bar URL doesn't change on every request ... Craig McClanahan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Property errors.prefix not used by HTML:errors ?
Hi all ! Complete newbe trying to get the html:errors to print pretty. I include the following into my ApplicationResources.properties errors.header=Feil oppstod!font color=red errors.prefix=* errors.sufffix=br errors.header=/font (ignore the lame tags they are just for testing) The errors.header and errors.header are displayed but the errors.prefix and errors.sufffix are not. (HTML example output:) Feil oppstod!font color=red Feltet inneholder for mye informasjon Feltet Navn er ikke utfyllt /font Any pointers ? Pel O. Kristiansen Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: logic:iterate with nested html:img
Eddie:
Thanks for you help. I promise this will be the last response on this
thread. I just want to be certain that it is valid to use EL with Struts
tags. Meaning, by using the bean:define tag I should be able to access
this object using EL. Or do I have to use c:set or jsp:useBean in order
to use EL?
By the way, I have tried everything from logic:iterate to
c:forEachAnyway, thanks again and I will just have to continue
troubleshooting.
Vinh
-Original Message-
From: Eddie Bush [mailto:[EMAIL PROTECTED]]
Sent: Sunday, September 29, 2002 12:33 AM
To: Struts Users Mailing List
Subject: Re: logic:iterate with nested html:img
Oh - cool! Glad you could upgrade!
All you should have to do is drop the JAR you built into your app's lib
directory, copy the TLDs over into wherever you keep those, add
references to the taglibs in your web.xml, declare the taglib in your
page, and use them just like you would the Struts tags - BUT - you have
EL support.
If you're running Tomcat 4, why not install the JSTL and use that for
iteration? :-)
I don't know what kind of errors you're getting in your page. I think
things look like they are setup right. One thing to remember is that
the EL is going to expect you to be following JavaBean patterns, so ...
is map.getSrcImage() valid? is map.getDesc() valid? If that's really a
map, you might want to try accessing it like map['srcImage'] and
map['desc'].
That's my best guess not knowing what problems you're having.
Vinh Tran wrote:
Eddie:
I'm finally up and running on Tomcat 4.0 but now I'm pulling my hair out
trying to get EL to work. Is it possible to use Struts-EL in conjunction
with Struts tags?
For example:
bean:define id=beanid name=MyBean type=com.custom.bean.MyBean
scope=session ignore=true/
...later in the page I attempt to iterate through a collection...
logic:iterate id=map name=beanid property=beanMap
html:img src=/images/${map.srcimage} alt=${map.desc} border=0/
/logic:iterate
Am I trying to defy the laws of physics, or at least Struts?
Vinh
--
Eddie Bush
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts and high performance sites revisited
On Thu, 26 Sep 2002, David Zimmerman wrote: Date: Thu, 26 Sep 2002 10:42:34 +0100 From: David Zimmerman [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED], [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Struts and high performance sites revisited Ok, so we got it nailed down these statements... - The Struts Controller doesn't add more overhead than a high performance site should be able to handle. In the regard flexibility contra performance, using the controller makes your application manageable with negligible overhead. That's a pretty good summary. For the vast majority of Struts based applications, the overhead of the Struts controller servlet is down in the noise level percentages -- and, of course, if you were to consider replacing it, you'd have to add back in the overhead of your replacement solution anyway. - There was also the everlasting discussion on EJB's be or not to be. I think that there are loads of variables that affects the choices of the design and that there still remains some issues with EJB's. However when only using stateless session beans with DAO's I think that the scalability-flexability-performance goes hand in hand and makes a preferrable design choice. Anyone disagrees? Would be nice to hear your opinions. There is no one correct answer to this question. Anyone trying to answer it with an absolute always use EJBs or never use EJBs should not be considered a trustworthy source of advice. What you *should* always start with is an understanding of your application's functional requirements -- both initially, and the directions it is likely to go. Just as a silly example, if you're building a simple intranet app for a ten-person department, with a database content measured in kilobytes instead of megabytes, you should just pick the technology you are the most familiar with and be done with it -- even if your solution isn't fastest possible, spending a couple of hundred dollars more on your server hardware is ***much*** cheaper than paying for the extra hours of development to learn a new technology. However, if your development team knows the stateless session bean + DAOs design pattern already, there's nothing wrong with using it. - But what was not discussed was the overhead of custom tags. This seems to be a question much avoided everywhere. When talking about flexability. Oh yes, use them. They makes your pages much easier to build and manage. They also makes for a great design of the application. BUT (capital letters), what about the performance overhead of the tags? When designing a web site where the absolute focus is to be able to handle as many transactions as possible to a low cost. Doesn't custom tags become very expensive to use in a case like this? There must have been extensive testing made on this. Does anyone have any facts or thoughts on this? Here are two basic lines of thoughts to consider. As with concern over the controller servlet's overhead, you can't just say custom tags are expensive so do not use them, without considering the cost of whatever you are going to replace them with. This matters a lot more than the controller servlet's potential overhead in many cases, but my experience is that the database tier tends to dominate the overall performance overhead of a web app, no matter what technology you use for the presentation tier. Second, the performance overhead of custom tags is very much dependent upon the quality of the JSP page compiler you are using, so it is (as with most things) impossible to create absolute guidelines that cover every possible situation. As an example, you should try running the same Struts based app on the current releases of Tomcat 4.0 (with the original JSP page compiler) and Tomcat 4.1 (with the completely rewritten Jasper 2 page compiler that has many optimizations to improve the generated code for custom tags). Performance improvements on the order of 600% to 800% have been observed on pages with lots of custom tags (which is typical of Struts apps), with *zero* changes to the application itself. You will see a very wide range of performance when you try out various other app servers as well. The moral of the story -- it's not custom tags that are fast or slow, it is the JSP page compiler's generated code for those tags that is fast or slow. Without defining what app server (and version) you are talking about, trying to ask about the performance of custom tags is a meaningless question. Craig McClanahan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts and high performance sites revisited
On Thu, 26 Sep 2002, Lister, Tom (ANTS) wrote: Date: Thu, 26 Sep 2002 13:21:45 +0100 From: Lister, Tom (ANTS) [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Subject: RE: Struts and high performance sites revisited Hi I've recently been struggling with performance issues related to tags, especially where there are large number in some of our pages. The biggest improvment we got was by switching application servers. Specifically by upgrading to the latest Tomcat 4.1.11. The difference in response is incredible. So it would seem that the major issue is with the type of code generated by the servlet engine. We spent some time looking at the generated code, the major issue being that every tag reference is created as a new object. There must be better way to do this. Until this point I was wrongly assuming that the tags were run as just method calls on one instance. The JSP Specification provides many standard opportunities that a JSP page compiler can use to improve the quality of the generated code for a custom tag invocation. One of the simplest is to reuse tag instances (as the Jasper 2 compiler in Tomcat 4.1 can do), but there are more aggressive things you can do as well. Consider something like this: c:forEach ... something that loops 100 times ... foo:bar name=x value=y/ /c:forEach Not only is it legal to reuse the custom tag instance for the bar tag (instead of creating 100 instances the way Tomcat 4.0 does), but the page compiler need not even call the setName() and setValue() methods 100 times inside the loop -- these can be moved outside the loop using standard techniques that optimizing compilers have used for decades. The JSP page compiler in Tomcat 4.1 and 5.0 (called Jasper 2) was rewritten from the ground up, primarily in order to make optimizations like this possible. You are seeing the fruits of this effort in 4.1, but we are by no means done with improving the optimizations that the page compiler can perform. will JSTL improve on this ? JSTL by itself doesn't change the code that is generated for a custom tag -- that's up to the page compiler. But the page compiler does have the opportunity to recognize JSTL tags (since they are a standard now) and generate specially optimized code (for example, turning a c:forEach into a real Java for statement instead of a custom tag invocation), as long as the semantic requirements are met. So, once the page compilers have been improved in this manner, using c:forEach will definitely run faster than a Struts logic:iterate tag that iterates the same number of times (unless someone were to optimize their page compiler for Struts tags, which seems less likely than optimizing for JSTL :-). :-) Tom Lister * 020 7612 3030 * [EMAIL PROTECTED] Craig McClanahan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: all this traffic
On Thu, 26 Sep 2002, Assenza, Chris wrote: Date: Thu, 26 Sep 2002 10:17:36 -0400 From: Assenza, Chris [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Subject: RE: all this traffic Usually mailing list operators solve this problem by separating mailing lists to a newbie list and a list for more experienced users. struts-user-beginner struts-user Which was one thing he originally suggested... =p While this idea is appealing in principle, it has dramatically failed to achieve the objectives in every case I've seen it used. Therefore, I'm going to -1 any proposal to do this for Struts. /me Doesn't care so much, I simply don't have enough time to read all this stuff, I usually scroll by to see what catches my eye, otherwise I select all and delete. :) Setting up your mail reader to automatically forward STRUTS-USER messages to a separate folder, and then sorting by thread, is a trivially easy approach to dealing with volume issues. Your inbox is no longer clogged, you can go read Struts mail when you have time, and can ignore entire irrelevant threads with a single command to advance to the next thread. -Chris Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: all this traffic
On Fri, 27 Sep 2002, adam kramer wrote: Date: Fri, 27 Sep 2002 10:17:19 -0400 (EDT) From: adam kramer [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: RE: all this traffic There's seems to be alot of resistance to any sort of suggestion that might create better documentation and useability of Struts. I can tell you for a fact that there's no resistance from Struts *developers* on this. What we resist, however, is the implication that *we* should do all the work. :-) Struts is an open source project. The documentation is part of the source code, in easily accessible formats (for Struts, it is XML files that are post-processed to produce the HTML), and maintained in the same CVS archives that the code is. Users are welcome to submit enhancement requests (for either the code or the documentation) via the bug tracking system: http://nagoya.apache.org/bugzilla/ and you can easily attach proposed patches to the enhancement requests. The general outline of how to create the patches starts at: http://jakarta.apache.org/site/getinvolved.html Rather than telling people they have bad management skills, the obvious thing to do would be to actually listen and try to find solutions. There are lots of messages like Jonas's and there seems to be a core of people who are unwilling to listen or to change; it's like a chorus of people complaining about a bad interface and a group of developers just saying get used to it buddy, always has been always will! just an oh so humble suggestion. My humble suggestion is to consider becoming part of the solution instead of part of the complaining horde. Patches welcome. -adam k. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
newbie to struts
hi there, I am using Orion 1.5.2 on windows 2000 platform, I tried to deploy the struts-documenation.war file on orion using console and I get an error com.evermind.server.ConfigFileNotFoundException: Unable to find/read assembly info for C:\orion\apachestruts\jakarta-struts-1.0.2\webapps\struts-documentation.war (META-INF/application.xml) If the answer to this has already been posted please let me know here I can find it. thanks, Liji -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Sunday, September 29, 2002 6:22 PM To: Struts Users Mailing List Subject: RE: all this traffic On Fri, 27 Sep 2002, adam kramer wrote: Date: Fri, 27 Sep 2002 10:17:19 -0400 (EDT) From: adam kramer [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: RE: all this traffic There's seems to be alot of resistance to any sort of suggestion that might create better documentation and useability of Struts. I can tell you for a fact that there's no resistance from Struts *developers* on this. What we resist, however, is the implication that *we* should do all the work. :-) Struts is an open source project. The documentation is part of the source code, in easily accessible formats (for Struts, it is XML files that are post-processed to produce the HTML), and maintained in the same CVS archives that the code is. Users are welcome to submit enhancement requests (for either the code or the documentation) via the bug tracking system: http://nagoya.apache.org/bugzilla/ and you can easily attach proposed patches to the enhancement requests. The general outline of how to create the patches starts at: http://jakarta.apache.org/site/getinvolved.html Rather than telling people they have bad management skills, the obvious thing to do would be to actually listen and try to find solutions. There are lots of messages like Jonas's and there seems to be a core of people who are unwilling to listen or to change; it's like a chorus of people complaining about a bad interface and a group of developers just saying get used to it buddy, always has been always will! just an oh so humble suggestion. My humble suggestion is to consider becoming part of the solution instead of part of the complaining horde. Patches welcome. -adam k. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Globals
On Thu, 26 Sep 2002, Anthony Martin wrote: Date: Thu, 26 Sep 2002 19:58:11 -0700 From: Anthony Martin [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts User List (E-mail) [EMAIL PROTECTED] Subject: Globals Is it now recommended to use members of Global like in Global.ERROR_KEY instead of Action.ERROR_KEY *even* in classes that extend Action? I know these members have not been marked as deprecated, but the note seems to indecate that they are preferred: Global manifest constants for the entire Struts Framework. Many of these constants were initially defined in Action, but were moved here so that they could be referenced without referencing the Action class itself. For backwards compatibility, constant references there point at this class, and the constant values themselves have not changed. So, it looks like either way is acceptable. But will the old way be deprecated sometime in the future? The old way is likely to be deprecated in the future, but not in 1.1. I made a mistake originally in defining these constants in Action.java instead of in their own class, but there's no going back now (by removing them from Action). And there is now a new flood of books that talks about using Action based constants, so it seems impolite of us to deprecate them in a 1.1 time frame ... Anthony Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: use Jakarta TagLibs in Struts
On Fri, 27 Sep 2002, Eddie Bush wrote: Date: Fri, 27 Sep 2002 00:12:52 -0500 From: Eddie Bush [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: Re: use Jakarta TagLibs in Struts I believe I saw a post in the commons-dev list that indicated the xsl taglib was stale and that a person should upgrade to the JSTL. JSTL is absolutely, positively the way to go if you need XSLT transformations in your JSP pages. The only potential negative is that it requires a Servlet 2.3 / JSP 1.2 container, but the benefits make a pretty compelling argument to upgrade if you're not already on this platform. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Is it really worth the effort to have a single instance of theAction?
On Fri, 27 Sep 2002, Andrew Hill wrote: Date: Fri, 27 Sep 2002 15:51:06 +0800 From: Andrew Hill [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED], [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: Is it really worth the effort to have a single instance of the Action? Given that for modern JVMs object creation and cleanup isnt the chore it used to be , I am wondering if it might not be more convienient to create a new Action instance for each request. The WebWorks framework (by Rickard Oberg) actually does things in the manner you suggest, and goes one step further -- he combines what we think of as the form bean and the Action into a single class, and calls all the property setters for your request fields directly on the Action instance before calling it's execute() method. Therefore, no separate form bean class is needed. If I had thought of this design pattern in the first place, I'd have been pretty tempted to use it. However, changing the semantics of a fundamental piece of Struts this radically doesn't seem like a good idea at this point, because it would reduce performance (albeit by a small amount) on existing Struts apps that are already programmed with thread safe Actions. The other concern I have is that this would encourage you to code your business logic in the Action directly, instead of delegating it to some logic bean. I view the most appropriate role of an Action to be as an adapter between the servlet-API-based web environment and the business logic of your application, which should *not* depend on any presentation layer APIs itself. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Retrieving list of Roles defined in web.xml [Revised]
On Fri, 27 Sep 2002, Vinh Tran wrote: Date: Fri, 27 Sep 2002 08:54:31 -0400 From: Vinh Tran [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED], [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Retrieving list of Roles defined in web.xml [Revised] I can also manage if there is a simple way to identify the roles a user particpates in (using container managed security). There is a call for isUserInRole() but nothing for getUserRoles()? There is no getUserRoles() method available in the servlet API, which means that any answer you get is going to be application server dependent. Indeed, it is incorrect to assume that the list of roles a user has is static -- it's quite conceivable for your server to define a role as is it between 8:00am and 5:00pm on a weekday and use that to limit the times a particular application function is available. You're going to need to research how your underlying app server stores and accesses authentication information. Any ideas? Thanks. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Action Error
Action Error must be impletmented in sorted order. Right now it appears to be Hashtable...When we try to display errors they dont show up in order we inserted... -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Sunday, September 29, 2002 6:35 PM To: Struts Users Mailing List Subject: Re: Globals On Thu, 26 Sep 2002, Anthony Martin wrote: Date: Thu, 26 Sep 2002 19:58:11 -0700 From: Anthony Martin [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts User List (E-mail) [EMAIL PROTECTED] Subject: Globals Is it now recommended to use members of Global like in Global.ERROR_KEY instead of Action.ERROR_KEY *even* in classes that extend Action? I know these members have not been marked as deprecated, but the note seems to indecate that they are preferred: Global manifest constants for the entire Struts Framework. Many of these constants were initially defined in Action, but were moved here so that they could be referenced without referencing the Action class itself. For backwards compatibility, constant references there point at this class, and the constant values themselves have not changed. So, it looks like either way is acceptable. But will the old way be deprecated sometime in the future? The old way is likely to be deprecated in the future, but not in 1.1. I made a mistake originally in defining these constants in Action.java instead of in their own class, but there's no going back now (by removing them from Action). And there is now a new flood of books that talks about using Action based constants, so it seems impolite of us to deprecate them in a 1.1 time frame ... Anthony Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [FRIDAY] [OT] Best misunderstanding of an acronym?
On Fri, 27 Sep 2002, Kevin A. Smith wrote: Date: Fri, 27 Sep 2002 11:07:53 -0400 From: Kevin A. Smith [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: [FRIDAY] [OT] Best misunderstanding of an acronym? The one that always baffles me is TANSTAAFL. A quick Google search reveals There Aint No Such Thing As A Free Lunch. It's also going to be well known to Robert Heinlein's The Moon Is A Harsh Mistress, one of my favorite SF novels. --Kevin Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Internationalization Broken on Struts 1.1b2?
On Fri, 27 Sep 2002, Ryan Cuprak wrote: Date: Fri, 27 Sep 2002 16:54:26 -0400 From: Ryan Cuprak [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: Re: Internationalization Broken on Struts 1.1b2? Okay, I figured it out, one has to add the following to their jsp page: html:html locale=true Why would I have to do this? If you were flowing all requests through the controller servlet, you wouldn't have to do this (assuming you have accepted the default Controller setting for the locale attribute). It sounds like you've got users who are accessing the JSP page's URL directly, which therefore bypasses the Struts controller. -Thanks, Ryan Cuprak Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: logic:iterate with nested html:img
Eddie:
I figured out that EL is working fine and it does indeed work with all types
of tags. Thanks again.
Vinh
-Original Message-
From: Vinh Tran [mailto:[EMAIL PROTECTED]]
Sent: Sunday, September 29, 2002 5:51 PM
To: Struts Users Mailing List
Subject: RE: logic:iterate with nested html:img
Eddie:
Thanks for you help. I promise this will be the last response on this
thread. I just want to be certain that it is valid to use EL with Struts
tags. Meaning, by using the bean:define tag I should be able to access
this object using EL. Or do I have to use c:set or jsp:useBean in order
to use EL?
By the way, I have tried everything from logic:iterate to
c:forEachAnyway, thanks again and I will just have to continue
troubleshooting.
Vinh
-Original Message-
From: Eddie Bush [mailto:[EMAIL PROTECTED]]
Sent: Sunday, September 29, 2002 12:33 AM
To: Struts Users Mailing List
Subject: Re: logic:iterate with nested html:img
Oh - cool! Glad you could upgrade!
All you should have to do is drop the JAR you built into your app's lib
directory, copy the TLDs over into wherever you keep those, add
references to the taglibs in your web.xml, declare the taglib in your
page, and use them just like you would the Struts tags - BUT - you have
EL support.
If you're running Tomcat 4, why not install the JSTL and use that for
iteration? :-)
I don't know what kind of errors you're getting in your page. I think
things look like they are setup right. One thing to remember is that
the EL is going to expect you to be following JavaBean patterns, so ...
is map.getSrcImage() valid? is map.getDesc() valid? If that's really a
map, you might want to try accessing it like map['srcImage'] and
map['desc'].
That's my best guess not knowing what problems you're having.
Vinh Tran wrote:
Eddie:
I'm finally up and running on Tomcat 4.0 but now I'm pulling my hair out
trying to get EL to work. Is it possible to use Struts-EL in conjunction
with Struts tags?
For example:
bean:define id=beanid name=MyBean type=com.custom.bean.MyBean
scope=session ignore=true/
...later in the page I attempt to iterate through a collection...
logic:iterate id=map name=beanid property=beanMap
html:img src=/images/${map.srcimage} alt=${map.desc} border=0/
/logic:iterate
Am I trying to defy the laws of physics, or at least Struts?
Vinh
--
Eddie Bush
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Strange Behavior With Map$Entry
All:
After alot of experimenting I was able to finally figure out how to retrieve
a value from a Map.Entry. However, it only works for certain tags. Below
is an example of this behavior.
logic:iterate id=mymap name=mybean property=map
html:img src=/images/${mymap.value.image} alt=${mymap.value.desc}
border=0/
c:out value=${mymap.value.desc}/
/logic:iterate
In the html:img tag the expressions do not work but in the c:out tag it
prints out the proper value. Any ideas?
html:options
I want to display a dropdown list. The list items are By First Name, By Last Name, By Date. I think I can do it by the following way: html:select size=1 property=choice html:option value=fName By First Name /html:option html:option value=fName By Last Name /html:option html:option value=fName By Date /html:option /html:select Is there any disadvantages to use above approach compared with using html:options...? If I use html:options ... instead of using above individual html:option...,as following: html:select property=choice size=1 html:options collection=%= myArrayList % property=value labelProperty=label/ /html:select where should I set myArrayList? in init method of my servlet class, or in my action form bean, or somewhere else? I am not quite understand it. Could some one please help me? Thank you Doug __ Post your free ad now! http://personals.yahoo.ca -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Retrieving list of Roles defined in web.xml [Revised]
One alternative thing I have done that I consider simple is use container managed autherhication, and then call a getPricnciplal. Based on the user name, I make a bean I put in session that contains all kinds of information about the user, session, security. Things like full name, organization, roles, etc. etc. These I them pass to beans for row based security. It is cross app server, since it your own bean on top of the getPrinicpal(). hth, V. Craig R. McClanahan wrote: On Fri, 27 Sep 2002, Vinh Tran wrote: Date: Fri, 27 Sep 2002 08:54:31 -0400 From: Vinh Tran [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED], [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Retrieving list of Roles defined in web.xml [Revised] I can also manage if there is a simple way to identify the roles a user particpates in (using container managed security). There is a call for isUserInRole() but nothing for getUserRoles()? There is no getUserRoles() method available in the servlet API, which means that any answer you get is going to be application server dependent. Indeed, it is incorrect to assume that the list of roles a user has is static -- it's quite conceivable for your server to define a role as is it between 8:00am and 5:00pm on a weekday and use that to limit the times a particular application function is available. You're going to need to research how your underlying app server stores and accesses authentication information. Any ideas? Thanks. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[Contributing] Re: all this traffic
Craig R. McClanahan wrote: On Fri, 27 Sep 2002, adam kramer wrote: Date: Fri, 27 Sep 2002 10:17:19 -0400 (EDT) From: adam kramer [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: RE: all this traffic There's seems to be alot of resistance to any sort of suggestion that might create better documentation and useability of Struts. I can tell you for a fact that there's no resistance from Struts *developers* on this. What we resist, however, is the implication that *we* should do all the work. :-) Struts is an open source project. The documentation is part of the source code, in easily accessible formats (for Struts, it is XML files that are post-processed to produce the HTML), and maintained in the same CVS archives that the code is. Users are welcome to submit enhancement requests (for either the code or the documentation) via the bug tracking system: http://nagoya.apache.org/bugzilla/ and you can easily attach proposed patches to the enhancement requests. The general outline of how to create the patches starts at: http://jakarta.apache.org/site/getinvolved.html What is the format of the patches that developers /contributer patches submit? Is it a context difference? diff -c acme.java acme.java.orig -- Peter Pilgrim +-\ +-+++++ Java Technologist | | | ||||| 'n' Shine | O | | || --+| ---+ /\| ._ / | | \ \ || / \ | | \ \ | |+-- || ---+ A new day /_ _\ Up| | | | | ||||| is coming ||+-+ +-+ +-+++++ home page=http://www.xenonsoft.demon.co.uk/; / -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Contributing] Re: all this traffic
On Mon, 30 Sep 2002, Peter A. J. Pilgrim wrote: http://jakarta.apache.org/site/getinvolved.html What is the format of the patches that developers /contributer patches submit? Is it a context difference? diff -c acme.java acme.java.orig The specific instructions on submitting patches are on the following page: http://jakarta.apache.org/site/bugs.html which is accessible from the page I quoted above. You need to use the *unified* diff format, via one of the following commands: cvs diff -u acme.java patchfile.txt diff -u acme.java.orig acme.java patchfile.txt and then add the patchfile as an attachment to an enhancement request (or bug report) in the bug tracking system. The cvs diff version is preferred, because it unambiguously identifies the version of the source file that your patch is against -- if you use the regular diff command, please be explicit about which version of the source you are patching. -- Peter Pilgrim Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [Contributing] Re: all this traffic
This is for Craig. I believe you are at home today. Can we do a better job of listing companies that are in process of developing applications in struts or already have applications in production. This helpes in convincing managements to take a more closer look at sturt. Thanks -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Sunday, September 29, 2002 9:05 PM To: Struts Users Mailing List Subject: Re: [Contributing] Re: all this traffic On Mon, 30 Sep 2002, Peter A. J. Pilgrim wrote: http://jakarta.apache.org/site/getinvolved.html What is the format of the patches that developers /contributer patches submit? Is it a context difference? diff -c acme.java acme.java.orig The specific instructions on submitting patches are on the following page: http://jakarta.apache.org/site/bugs.html which is accessible from the page I quoted above. You need to use the *unified* diff format, via one of the following commands: cvs diff -u acme.java patchfile.txt diff -u acme.java.orig acme.java patchfile.txt and then add the patchfile as an attachment to an enhancement request (or bug report) in the bug tracking system. The cvs diff version is preferred, because it unambiguously identifies the version of the source file that your patch is against -- if you use the regular diff command, please be explicit about which version of the source you are patching. -- Peter Pilgrim Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [Contributing] Re: all this traffic
On Sun, 29 Sep 2002, Khan, Manuchehar A (ACF) wrote: Date: Sun, 29 Sep 2002 21:14:50 -0400 From: Khan, Manuchehar A (ACF) [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Subject: RE: [Contributing] Re: all this traffic This is for Craig. I believe you are at home today. Can we do a better job of listing companies that are in process of developing applications in struts or already have applications in production. This helpes in convincing managements to take a more closer look at sturt. Thanks Well, this certainly sounds like an opportunity for you to submit a patch that improves the website (which is just the struts-documentation web app :-). Companies that want to be listed can do so, if they obey the requirements about advertising the fact that they use Struts and/or Apache Software Foundation software packages. Of course, none of this helps if the companies using Struts cannot be listed (because the usage is on internal company webapps), or don't *want* to be listed (because they consider their choice of Struts to be a strategic advantage that they don't want their competitors to know about :-). As with code changes, patches to the resources pages (including the Powered by Struts page) are welcome. Craig -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Sunday, September 29, 2002 9:05 PM To: Struts Users Mailing List Subject: Re: [Contributing] Re: all this traffic On Mon, 30 Sep 2002, Peter A. J. Pilgrim wrote: http://jakarta.apache.org/site/getinvolved.html What is the format of the patches that developers /contributer patches submit? Is it a context difference? diff -c acme.java acme.java.orig The specific instructions on submitting patches are on the following page: http://jakarta.apache.org/site/bugs.html which is accessible from the page I quoted above. You need to use the *unified* diff format, via one of the following commands: cvs diff -u acme.java patchfile.txt diff -u acme.java.orig acme.java patchfile.txt and then add the patchfile as an attachment to an enhancement request (or bug report) in the bug tracking system. The cvs diff version is preferred, because it unambiguously identifies the version of the source file that your patch is against -- if you use the regular diff command, please be explicit about which version of the source you are patching. -- Peter Pilgrim Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [Contributing] Re: all this traffic
I agree, from observing what others are developing, it seems that about 80% of the applications are for intranets. I know even our campus is using struts for various project management applications. Could we offer links to the sites? No. Is the presentation layer what counts? No. What would be advantagous is a case study page-- how struts helped us do what we needed in a timely manner. I believe that would be much more practical than a bunch of links to web sites to check out the pretty graphics. I remember reading a great article in Java Developer about Cocoon a little while back, the guy went on for nearly 2 pages on how he was able to use cocoon to help a law firm manage documents. Something like that is 10 fold more beneficial than having the author just post a link to the site he did. Regards Jacob Hookom University of Wisconsin, Eau Claire -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Sun 9/29/2002 8:29 PM To: Struts Users Mailing List Cc: Subject: RE: [Contributing] Re: all this traffic On Sun, 29 Sep 2002, Khan, Manuchehar A (ACF) wrote: Date: Sun, 29 Sep 2002 21:14:50 -0400 From: Khan, Manuchehar A (ACF) [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Subject: RE: [Contributing] Re: all this traffic This is for Craig. I believe you are at home today. Can we do a better job of listing companies that are in process of developing applications in struts or already have applications in production. This helpes in convincing managements to take a more closer look at sturt. Thanks Well, this certainly sounds like an opportunity for you to submit a patch that improves the website (which is just the struts-documentation web app :-). Companies that want to be listed can do so, if they obey the requirements about advertising the fact that they use Struts and/or Apache Software Foundation software packages. Of course, none of this helps if the companies using Struts cannot be listed (because the usage is on internal company webapps), or don't *want* to be listed (because they consider their choice of Struts to be a strategic advantage that they don't want their competitors to know about :-). As with code changes, patches to the resources pages (including the Powered by Struts page) are welcome. Craig -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Sunday, September 29, 2002 9:05 PM To: Struts Users Mailing List Subject: Re: [Contributing] Re: all this traffic On Mon, 30 Sep 2002, Peter A. J. Pilgrim wrote: http://jakarta.apache.org/site/getinvolved.html What is the format of the patches that developers /contributer patches submit? Is it a context difference? diff -c acme.java acme.java.orig The specific instructions on submitting patches are on the following page: http://jakarta.apache.org/site/bugs.html which is accessible from the page I quoted above. You need to use the *unified* diff format, via one of the following commands: cvs diff -u acme.java patchfile.txt diff -u acme.java.orig acme.java patchfile.txt and then add the patchfile as an attachment to an enhancement request (or bug report) in the bug tracking system. The cvs diff version is preferred, because it unambiguously identifies the version of the source file that your patch is against -- if you use the regular diff command, please be explicit about which version of the source you are patching. -- Peter Pilgrim Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] winmail.dat -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Security bug in the sample application?
Hi, I was playing with the sample application that comes with struts and I noticed a strange behavior. I just wanted to check out if this is expected, and if so what is the best way to solve this problem. When I log on with a valid user the application takes me to the page: http://localhost:8080/struts-example/logon.do Here I choose the Log off MailReader Demonstration Application link which logs me off from the application. Then I use BACK button of my browser to go to the logon.do page and reload this page. I expect the application to send me back to the logon page (and it does so for all the other pages). On the browser I get a message like this page can not be refreshed without resending the information. I hit retry and volla I'm logged back to the application without even being prompted for username and password. I modified the code to trace this in server logs and noticed that both username and the password are actually kept in the memory and sent back to the server. Is there a nice way to prevent this behavior? Thanks Cuneyt Karul
RE: Pre-populating ActionForms
Hi, I have actually set up a 'Setup' form and action. After login, I forward to setup.jsp, that doesn't show anything(though is is a jsp) but pre-populates the form. How do you forward from there to the JSP that shows the pre-populated form ? There is no submit action on setup.jsp. bye, Mohan -Original Message- From: David Graff [mailto:[EMAIL PROTECTED]] Sent: Saturday, September 28, 2002 9:06 PM To: [EMAIL PROTECTED] Subject: Re: Pre-populating ActionForms Override the 'reset' method of the ActionForm descendant, set your initial values in there, then (most likely) when you want to reference the page, reference the .do that would forward you out to that page. Hope that helps. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Help Re: cancel and session-scope form
You can add another action without a form-bean that will implement the cancel functionality and in all other cases forward the request to your real action where the ActionForm will be populated. Tal Lev-Ami Trivnet Ltd. -Original Message- From: Angie Lin [mailto:[EMAIL PROTECTED]] Sent: Sun, September 29, 2002 10:26 PM To: Struts Users Mailing List Subject: Re: Help Re: cancel and session-scope form Thanks for the tip, but I'm trying to avoid javascript as much as possible. It looks like I'll have to go ahead and manage my session form manually, and use a request-scoped form so that the auto-population doesn't blow away the properties. Thanks again, Angie Eddie Bush wrote: Actually ... I've never done this before, but ... Why couldn't you invoke a javascript method on your Cancel button that invoked the forms reset method? That might be the easiest solution ... Eddie Bush wrote: Just quickly thinking it over ... When your form submits, you're going to hit an action. Your action is going to look and see what the user told you they wanted to do and act appropriately. Now, that doesn't help you keep the form from being populated, but you can certainly keep from updating your persistent storage using this information - and know that, instead, you should request fresh data to repopulate the form with. I like to rename my buttons to something like action or userAction - and give all of them the same name - so I can judge off the value of that parameter what the user is telling me they'd like to have happen. That's my spontaneous, first-cut answer. I can't think of a way to circumvent the population ... -- Angie Lin [EMAIL PROTECTED] 408.519.9250 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
