Re: Creating a session with predefined values
Does your user have direct access to HttpSession object from a browser? On 7 Oct 2005 05:54:30 -, vineesh . kumar [EMAIL PROTECTED] wrote: Hi all, I have to maintain some information throuh out whole session from a user login to user logout. For accomplishing this, I hav to maintain a userid and permission values throughout the whole session. So what i need to know is, is there any way so that i can create a session with these values and retrieve these values from the session, so that the user will not come to know that the session contains his uid and permissions? regards vineesh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Base action class
On 10/6/05, Frank W. Zammetti [EMAIL PROTECTED] wrote: Leon Rosenberg wrote: Well you shouldn't have anything with Database in the name in your action, it should be encapsulated in a service POJO. I'm not so sure about this... I understand the motivation for saying it and agree with that motivation, but it's a bit to hard-and-fast for my tastes. :) As an example, I have one application where there are quite a few Actions that call on a number of business delegates to perform their duties. Those delegates are the POJOs you are referring to. If I let each of them get a database connection on their own, than a particular user could wind up using a couple of connections per request (or the developer would have to ensure that each delegate is used, cleaned up, including the connection, before the next one is used). Keep in mind that we aren't using a real persistence layer for any of this, and that would certainly handle such a concern. But many people are still not using persistence layers, so it's not exactly unusual. If by persistance layers you mean things like hibernate and/or ibatis, I would 100% agree with you. But if you mean that if you have a BL POJO, say IMessagingService, which uses two DBs (at least logical) like the user db and the db for messages, and you are acessing the DBs direct from the BL instead of defining a IUserPersistenceService and IMessagingPersistenceService and providing DB-based Implementations for this, than I must say, you are too lazy, and will pay the bill one day :-) The way we solved this problem is this... We have a base Action. It performs a number of common functions, one of which is to instantiate a BusinessDelegateFactory. This factory has the responsibility for getting a connection through the database (by using a DatabaseConnectionManager class). Then, the base Action calls an overloaded version of execute() in the extending Action that has the factory as an extra parameter. In the Actions themselves, you will see things like: ClientBD = (ClientBD)factory.get(CliemtBD); ArrayList clients = clientBD.getClients(); Doesn't look unusual I'm sure :) The part that is really nice here though is that if an Action uses a number of business delegates, the factory ensures that they all share the same database connection. So we're always only using one per request, which is ideal. Also, the factory has sole responsibility for setting up and cleaning up the business delegates, the Action doesn't have to be concerned with any of that (as it shouldn't). I don't see the point. Wouldn't using a stateless-session-bean-like-Singleton-POJO with a ConnectionPool to DB (which it manages by itself, or is managed by a central ConnectioXYZManagementClass, but in backend) ensure the same? Is this mixing of layers or otherwise a bad design? I'm not arguing it's the best thing ever done, but I don't see it as bad either. The business delegates still are POJOs, and the Actions themselves aren't really dealing with the database connection directly, they are delegating to a class that does that. In fact, the Actions are doing only what they are suppose to as far as I'm concerned: they are traffic cops, passing things (data, connections, whatever) between objects that do the real work. I'd still consider this not optimal because your actions know things they shouldn't. And if something knows a thing it shouldn't know, your system is more complex than it could be. Agreed? You can't switch from the DB to FileSystem for example without changing the Actions... Incidentally, I use the declarative exception handling as well. Everything bubbles up to the common handler and is dealt with appropriately there. No try/catch in the Actions, or the business delegates for that matter (except where there are exceptions that you know you can handle immediately, everything else just bubbles up). Makes for *very* clean code, and from my experience I don't find it to be any less robust. In fact, the consistency with which exceptions get handled I think is *more* robust... I log A TON of information, send eMail alerts and construct a nice page for the user (we take the tact by the way that an exception should never happen and therefore is probably not a recoverable situation, so just being as kind to the user as possible is the goal, as well as making it as easy for us as possible to track down what happened later). Well, Rick Reumanns site, which was unfortunately down is last time, had a good example for that. However it's said to be common rule, that in a well designed application each layer can only see exceptions from previous layers. Example: Something in the jdbc driver throws an SQLException, like connection is lost or whatever The persistence layer catches it, logs it and rethrows a PersistencePOJOs Exception, like: DB is generally unavailable or something. The business layer catches it and rethrows: Persistencelayer is
Strange Problem with logic:equals!
Hi, we have a strange Problem with logic:equal Look at the following code: //-- first we create a bean bean:define id=myBeanValue value=1/ //-- changing the value is this possible in the way??? % myBeanValue = 2; % // tests with the logic:equals tags logic:equal name=myBeanValue value=1 bris equal/br /logic:equal logic:notEqual name=myBeanValue value=1 bris notequal/br /logic:notEqual After running the jsp we are getting the result= is equal!!! But Why?? Is it not possible to redefine the variable in the way that we try this in the example! What makes us even more worried is that when we debug, it neither jumps in the first nor in the second logic:equal tag. Please help me! Nice Greetings Starki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Strange Problem with logic:equals!
On 10/7/05, starki78 [EMAIL PROTECTED] wrote: Hi, we have a strange Problem with logic:equal Look at the following code: //-- first we create a bean bean:define id=myBeanValue value=1/ //-- changing the value is this possible in the way??? % myBeanValue = 2; % change this to % pageContext.setAttribute(myBeanValue,2); the point is, that bean:define puts the defined object in the page scope AND ties a scripting variable to it. Your % ... % line changes the value of the scripting variable but not the value of the object in the pageContext (page scope). The logic:equal tag (and all other tags) looks in the 4 scopes for the beans, starting with the page scope, and finds your initially defined value. Hence the output is correct. Actually % myBeanValue = 2; % is incorrect usage, if you use tags, you don't script. // tests with the logic:equals tags logic:equal name=myBeanValue value=1 bris equal/br /logic:equal logic:notEqual name=myBeanValue value=1 bris notequal/br /logic:notEqual After running the jsp we are getting the result= is equal!!! But Why?? Is it not possible to redefine the variable in the way that we try this in the example! no, it isn't possible, see above. What makes us even more worried is that when we debug, it neither jumps in the first nor in the second logic:equal tag. Heh? You have the output is equal in your jsps, as you stated above, so it must have jumped in the first tag. I think your debugging techniques need tuning. A general advice, if you don't know why a jsp behaves like it does, look at the generated source code (which is normally under TOMCAT_HOME/work for tomcat and RESIN_HOME/webapps/yourwebapp/WEB-INF/work for resin). Please help me! Nice Greetings Starki Leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
html:image as cancel button
Hello, My application uses image buttons, based on html:image tag. I'd like to add a cancel button, that may skip javascript validation. I didn't find any attribute to set this on html:image. Do I have to set myself the javascript bCancel = true ? Thanks, Nico. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: Managing All Session from context
Note: Forwarded message attached -- Original Message -- From: Dixa M [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Managing All Session from context ---BeginMessage--- Hi All, I have an application in struts. Here I want to send Messege to all the alive sessions.I have managed doing this by adding a attribute in Application context.All sessions read this Attribute and respond if it is meant for them. Now my problem is if a user is not using the browser(eg Window is minimised) He can never get this attribute.I want to Alert/focus this window explicitly.How can I do this? ---End Message--- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Strange Problem with logic:equals!
Do you have the struts-bean tag library defined in your jsp:? Something like %@ taglib uri=/WEB-INF/struts-bean.tld prefix=bean % Aymeric. On 10/7/05, starki78 [EMAIL PROTECTED] wrote: Hi, we have a strange Problem with logic:equal Look at the following code: //-- first we create a bean bean:define id=myBeanValue value=1/ //-- changing the value is this possible in the way??? % myBeanValue = 2; % // tests with the logic:equals tags logic:equal name=myBeanValue value=1 bris equal/br /logic:equal logic:notEqual name=myBeanValue value=1 bris notequal/br /logic:notEqual After running the jsp we are getting the result= is equal!!! But Why?? Is it not possible to redefine the variable in the way that we try this in the example! What makes us even more worried is that when we debug, it neither jumps in the first nor in the second logic:equal tag. Please help me! Nice Greetings Starki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Shale] getClientIdsWithMessages in FacesContext doesn't seem to work..?
Hmm, I have used the 1.1_01 and the messages definitly work. Does your bean extend the abstract one from shale (AbstractFacesBean)? Or is the error method one you wrote? On 06/10/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Ronald Holshausen [EMAIL PROTECTED] wrote on 10/06/2005 11:53:08 AM: Hi Geeta, Which JSF implementation are you using? And are you running it in a servlet or portlet enviroment? Hi Ronald, I had been using Sun's implementation (version 1.1) but after I got your note, I downloaded their latest 1.1_01 jars and tried with those, but unfortunately I get the same results. And I am working in a servlet environment. Thank you for your time! Geeta - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Strange Problem with logic:equals!
bean:define creates BOTH
- a script variable (a Java variable you can use in % ... % java blocs)
- a bean in specified scope (defaults to page)
So you have a myBeanValue variable set to 1 and a myBeanValue String
put into page scope.
% myBeanValue = 2; % changes value of script variable. myBeanValue bean in
page scope is not impacted
logic:equal name=myBeanValue value=1 checks the bean in page scope, witch equals
1.
To solve this, you may :
- use scriptlet, not logic tag, to check script variables (NOT RECOMENDED) :
% if (1.equals(myBeanValue)) { % ...% } %
- reuse bean:define to change myBeanValue, but be carreful some servlet
container don't accept multiple use of this tag with the same id, - so NOT RECOMENDED
- not use scriptlets anymore ! Change myBeanValue by using tags, especially use
EL struts tags and JSTL :
c:set var=myBeanValue value=1/
...
c:set var=myBeanValue value=2/
...
c:choose
c:when test=${myBeanValue == '1'}.../c:when
c:otherwise.../c:otherwise
/c:choose
Nico.
Aymeric Alibert a écrit :
Do you have the struts-bean tag library defined in your jsp:?
Something like %@ taglib uri=/WEB-INF/struts-bean.tld prefix=bean %
Aymeric.
On 10/7/05, starki78 [EMAIL PROTECTED] wrote:
Hi, we have a strange Problem
with logic:equal
Look at the following code:
//-- first we create a bean
bean:define id=myBeanValue value=1/
//-- changing the value is this possible in the way???
% myBeanValue = 2; %
// tests with the logic:equals tags
logic:equal name=myBeanValue value=1
bris equal/br
/logic:equal
logic:notEqual name=myBeanValue value=1
bris notequal/br
/logic:notEqual
After running the jsp we are getting the result= is equal!!!
But Why?? Is it not possible to redefine the variable
in the way that we try this in the example!
What makes us even more worried is that
when we debug, it neither jumps in the first nor
in the second logic:equal tag.
Please help me!
Nice Greetings
Starki
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message contains information that may be privileged or confidential and is
the property of the Capgemini Group. It is intended only for the person to whom
it is addressed. If you are not the intended recipient, you are not authorized
to read, print, retain, copy, disseminate, distribute, or use this message or
any part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionForm validate() - what Action does the controller call?
If the validate method returs non empty ActionErrors object, the control will go to the JSP specified in the input attribute of the corresponding action element in struts-config.xml . Thanks, Rajasekhar Cherukuri Please respond to Struts Users Mailing List user@struts.apache.org To Struts Users Mailing List user@struts.apache.org cc Subject ActionForm validate() - what Action does the controller call? When my ActionForm returns a non-empty ActionErrors object, where does control go to? i.e. i read from the struts site: When the properties of this bean have been populated, but before the executemethod of the Action is called, this bean's validate method will be called, which gives the bean a chance to verify that the properties submitted by the user are correct and valid. If this method finds problems, it returns an error messages object that encapsulates those problems, and the controller servlet will return control to the corresponding input form. Otherwise, the validatemethod returns null, indicating that everything is acceptable and the corresponding Action.execute method should be called. (my bold) I guess I don't understand what 'corresponding input form' means? Presumably the controller needs to call some Action, how do I know / specify which one? Thanks ForwardSourceID:NT591E Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you
Re: Strange Problem with logic:equals!
Thank you all for your help!
Now I've understood the problem
-- Initial Header ---
From : Nicolas De Loof [EMAIL PROTECTED]
To : Struts Users Mailing List user@struts.apache.org
Cc :
Date : Fri, 07 Oct 2005 11:07:16 +0200
Subject : Re: Strange Problem with logic:equals!
bean:define creates BOTH
- a script variable (a Java variable you can use in % ... % java blocs)
- a bean in specified scope (defaults to page)
So you have a myBeanValue variable set to 1 and a myBeanValue String
put into page scope.
% myBeanValue = 2; % changes value of script variable. myBeanValue bean
in page scope is not impacted
logic:equal name=myBeanValue value=1 checks the bean in page scope,
witch equals 1.
To solve this, you may :
- use scriptlet, not logic tag, to check script variables (NOT RECOMENDED) :
% if (1.equals(myBeanValue)) { % ...% } %
- reuse bean:define to change myBeanValue, but be carreful some servlet
container don't accept multiple use of this tag with the same id, - so NOT
RECOMENDED
- not use scriptlets anymore ! Change myBeanValue by using tags, especially
use EL struts tags and JSTL :
c:set var=myBeanValue value=1/
...
c:set var=myBeanValue value=2/
...
c:choose
c:when test=${myBeanValue == '1'}.../c:when
c:otherwise.../c:otherwise
/c:choose
Nico.
Aymeric Alibert a écrit :
Do you have the struts-bean tag library defined in your jsp:?
Something like %@ taglib uri=/WEB-INF/struts-bean.tld prefix=bean %
Aymeric.
On 10/7/05, starki78 [EMAIL PROTECTED] wrote:
Hi, we have a strange Problem
with logic:equal
Look at the following code:
//-- first we create a bean
bean:define id=myBeanValue value=1/
//-- changing the value is this possible in the way???
% myBeanValue = 2; %
// tests with the logic:equals tags
logic:equal name=myBeanValue value=1
bris equal/br
/logic:equal
logic:notEqual name=myBeanValue value=1
bris notequal/br
/logic:notEqual
After running the jsp we are getting the result= is equal!!!
But Why?? Is it not possible to redefine the variable
in the way that we try this in the example!
What makes us even more worried is that
when we debug, it neither jumps in the first nor
in the second logic:equal tag.
Please help me!
Nice Greetings
Starki
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message contains information that may be privileged or confidential and
is the property of the Capgemini Group. It is intended only for the person to
whom it is addressed. If you are not the intended recipient, you are not
authorized to read, print, retain, copy, disseminate, distribute, or use
this message or any part thereof. If you receive this message in error,
please notify the sender immediately and delete all copies of this message.
-
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]
set different attribute according to the change of parameter
Can I do the following?
Same action class sets different attribute
according to the change of parameter?
Thanks
action path=/userProfileMaint
type=com.erp.struts.SetRoleHref
parameter=userProfileMaint
action path=/quotationMaint
type=com.erp.struts.SetRoleHref
parameter=quotationMaint
public class SetRoleHref extends Action {
String myValue = request.getParameter(parameter);
session.setAttribute(rolehref, myValue);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Shale] getClientIdsWithMessages in FacesContext doesn't seem to work..?
Ronald Holshausen [EMAIL PROTECTED] wrote on 10/07/2005 05:03:23 AM:
Hmm, I have used the 1.1_01 and the messages definitly work. Does your
bean extend the abstract one from shale (AbstractFacesBean)? Or is the
error method one you wrote?
Thanks for your note Ronald. My bean extends AbstractViewController and so
it's defintely using shale's AbstractFacesBean's error method. If this is
working well for you it's doubtless something wrong I'm doing; though I
really cannot figure out what since I am seemingly setting the error
message and rightwaay checking for it using getClientIdsWithMessages (both
in the same bean - so there's no question of config problems or issues
with my jsp..)
Hmm.. ok, can you easily throw in this code:
Iterator itt =
FacesContext.getCurrentInstance().getClientIdsWithMessages();
while (itt.hasNext()) {
System.out.println(nextOne is:
+ itt.next());
}
right after you set your error message in your bean and see if you get
anything..? I am wondering now if there's something off with
getClientIdsWithMessages()... in that case, there must be something wrong
elsewhere in my code..
Thank you for your time and patience!
Geeta
Re: Base action class
On Fri, October 7, 2005 3:05 am, Leon Rosenberg said: If by persistance layers you mean things like hibernate and/or ibatis, I would 100% agree with you. Yep, that's what I meant :) But if you mean that if you have a BL POJO, say IMessagingService, which uses two DBs (at least logical) like the user db and the db for messages, and you are acessing the DBs direct from the BL instead of defining a IUserPersistenceService and IMessagingPersistenceService and providing DB-based Implementations for this, than I must say, you are too lazy, and will pay the bill one day :-) I'm not sure I'd call it laziness, but I don't disagree with your underlying point, so I won't argue the terminology too much :) I don't see the point. Wouldn't using a stateless-session-bean-like-Singleton-POJO with a ConnectionPool to DB (which it manages by itself, or is managed by a central ConnectioXYZManagementClass, but in backend) ensure the same? It might. I should note that our connection pool is container-managed, but that probably doesn't change the equation much. I'm in no way saying that what we implemented is perfect, or that there aren't a gazillion other ways to do it. My only point was to illustrate the approach we took, which has served us well, and which I don't feel breaks the separation of layers, at least not to a degree I am uncomfortable with. :) I don't know about you, but I see *WAY TOO MUCH* overengineering in many projects. People are so anal about coming up with the absolute perfect architectural solution. I'm not saying we shouldn't strive for perfection, of course we should, but it's no wonder so many projects run over deadline and/or over budget... sometimes bending a rule here or there isn't the worst thing. The trick is knowing when bending becomes breaking to the detriment of the future, as you alluded to earlier :) The app I was describing has been in production under heavy usage for almost 3 years now, was originally not even Struts-based (it is now), has given us very little trouble along the way and has been very extensible to boot in terms of new client usage and new feature implementation. It is a big success story by any measure that matters in my mind. I don't feel bad about the decisions we made, even if they aren't 100% best practices :) I'd still consider this not optimal because your actions know things they shouldn't. And if something knows a thing it shouldn't know, your system is more complex than it could be. Agreed? 99 times out 100, absolutely agreed. You can't switch from the DB to FileSystem for example without changing the Actions... Not really true, although I have admittedly never had to do it. Because the factory is responsible for the persistence essentially, the Actions actually wouldn't have to change at all. The Actions don't know from database connections, they only know to instantiate a factory and pass it along to the real execute(). To illustrate the point, here's the import list for the base Action: import com.company.app.BDFactory; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import javax.servlet.http.HttpSession; import org.apache.commons.logging.Log; import org.apache.commons.logging.LogFactory; import org.apache.struts.action.Action; import org.apache.struts.action.ActionForm; import org.apache.struts.action.ActionForward; import org.apache.struts.action.ActionMapping; And, the minimum set of imports an extending Action must include: import com.company.app.BDFactory; import com.company.app.ClientsBD; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import javax.servlet.http.HttpSession; import org.apache.commons.logging.Log; import org.apache.commons.logging.LogFactory; import org.apache.struts.action.ActionForm; import org.apache.struts.action.ActionForward; import org.apache.struts.action.ActionMapping; See? Only the factory is common, and the extending Action of course imports the business delegate(s) that it uses. No mention of persistence in there. You are right though if I extend this further... the BUSINESS DELEGATES know too much about persistence. That *is* a flaw in the design that I didn't recognize when they were written. Hey, live and learn :) It's not as big a problem as the Actions knowing too much, but it's still a problem. Hasn't burnt us in 3 years, but it's a mistake I haven't made in subsequent projects. Well, Rick Reumanns site, which was unfortunately down is last time, had a good example for that. However it's said to be common rule, that in a well designed application each layer can only see exceptions from previous layers. Example: Something in the jdbc driver throws an SQLException, like connection is lost or whatever The persistence layer catches it, logs it and rethrows a PersistencePOJOs Exception, like: DB is generally unavailable or something. The business layer catches it and rethrows:
Re: [Shale] getClientIdsWithMessages in FacesContext doesn't seem to work..?
aah! There is a bug with the AbstractFacesBean message functions. They
do not set the client id when adding the messages. It was fixed in
nightly build 20050921, but I don't think it has been tested yet.
I never used the methods in AbstractFacesBean, but it is easy to test.
You can add the messages yourself by using
context.addMessage(clientId, message).
On 07/10/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Ronald Holshausen [EMAIL PROTECTED] wrote on 10/07/2005 05:03:23 AM:
Hmm, I have used the 1.1_01 and the messages definitly work. Does your
bean extend the abstract one from shale (AbstractFacesBean)? Or is the
error method one you wrote?
Thanks for your note Ronald. My bean extends AbstractViewController and so
it's defintely using shale's AbstractFacesBean's error method. If this is
working well for you it's doubtless something wrong I'm doing; though I
really cannot figure out what since I am seemingly setting the error
message and rightwaay checking for it using getClientIdsWithMessages (both
in the same bean - so there's no question of config problems or issues
with my jsp..)
Hmm.. ok, can you easily throw in this code:
Iterator itt =
FacesContext.getCurrentInstance().getClientIdsWithMessages();
while (itt.hasNext()) {
System.out.println(nextOne is:
+ itt.next());
}
right after you set your error message in your bean and see if you get
anything..? I am wondering now if there's something off with
getClientIdsWithMessages()... in that case, there must be something wrong
elsewhere in my code..
Thank you for your time and patience!
Geeta
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Shale] getClientIdsWithMessages in FacesContext doesn't seem to work..?
Ronald Holshausen [EMAIL PROTECTED] wrote on 10/07/2005 11:30:21 AM: aah! There is a bug with the AbstractFacesBean message functions. They do not set the client id when adding the messages. It was fixed in nightly build 20050921, but I don't think it has been tested yet. I never used the methods in AbstractFacesBean, but it is easy to test. You can add the messages yourself by using context.addMessage(clientId, message). *Fantastic*, thanks so much, Ronald! Certainly that was the problem.. though my solution as suggested by you is a bit ironic, since I went down the path of AbstractFacesBean.errors(...) mainly since I wanted to avoid having to get the clientId in the first place..:) So my code now is the rather ugly: FacesContext.getCurrentInstance().addMessage(password.getClientId(FacesContext.getCurrentInstance()), new FacesMessage(messages.getMessage(password.mismatch))); instead of the sleek: errors(password, messages.getMessage(password.mismatch)); But I guess it works beats good looks any day, huh? ;) Thank you again! Geeta
Re: [Shale] getClientIdsWithMessages in FacesContext doesn't seem to work..?
If you get a later version of shale, you can then use the message functions :-) They just do what your code does anyway. On 07/10/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Ronald Holshausen [EMAIL PROTECTED] wrote on 10/07/2005 11:30:21 AM: aah! There is a bug with the AbstractFacesBean message functions. They do not set the client id when adding the messages. It was fixed in nightly build 20050921, but I don't think it has been tested yet. I never used the methods in AbstractFacesBean, but it is easy to test. You can add the messages yourself by using context.addMessage(clientId, message). *Fantastic*, thanks so much, Ronald! Certainly that was the problem.. though my solution as suggested by you is a bit ironic, since I went down the path of AbstractFacesBean.errors(...) mainly since I wanted to avoid having to get the clientId in the first place..:) So my code now is the rather ugly: FacesContext.getCurrentInstance().addMessage(password.getClientId(FacesContext.getCurrentInstance()), new FacesMessage(messages.getMessage(password.mismatch))); instead of the sleek: errors(password, messages.getMessage(password.mismatch)); But I guess it works beats good looks any day, huh? ;) Thank you again! Geeta - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Re: [Shale] getClientIdsWithMessages in FacesContext doesn't seem to work..?
Ronald Holshausen [EMAIL PROTECTED] wrote on 10/07/2005 11:57:00 AM: If you get a later version of shale, you can then use the message functions :-) They just do what your code does anyway. so guess what i am doing *right* now..? :)
Re: Base action class
Leon, I have a question about this one: You don't need to care for exceptions you don't understand (layer-technically, someone who writes an action doesn't care whether its an SQLException or a FileNotFoundException) If you say, that it should be easy to switch layers, then persistence layer should not know about SQLException, should it? JDBC persistence sublayer (driver, connection pool, actual SQL statements, etc) should catch SQLException and return something like StoreException or UpdateException to more generic persistence layer. In this case JDBC sublayer can be switched. What I am trying to say, is that each layer that can be potentially substituted, should catch layer-specific exception itself, and rethrow more generic exceptions, instead of throwing layer-specific exception to calling layer. Does it make sense? Michael J. On 10/7/05, Leon Rosenberg [EMAIL PROTECTED] wrote: Something in the jdbc driver throws an SQLException, like connection is lost or whatever The persistence layer catches it, logs it and rethrows a PersistencePOJOs Exception, like: DB is generally unavailable or something. The business layer catches it and rethrows: Persistencelayer is unavailable (all names are just examples). This is caught by the action, which then presents it to the user (which can be done by throwing a presentation-layer exception and proceeding it with your general error handler) Sorry, currently we can't proceed your request, try again later or whatever. The good thing about it: - You don't need to import classes from other layers - You don't need to care for exceptions you don't understand (layer-technically, someone who writes an action doesn't care whether its an SQLException or a FileNotFoundException) - You can change the implementation of the complete layer without changes in other layers (like switching from JDBC to JDO or FS, or like changing from corba to rmi or ejb). - You still can log at any point (or at all points) and mail and notification will work even better. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Development philosophy and such (was: Base action class)
On 10/7/05, Frank W. Zammetti [EMAIL PROTECTED] wrote: I think we unintentionally hijacked a thread, so just in case we discuss any further, a topic change is probably in order... Tell me about hijacking ;) On 10/7/05, Leon Rosenberg [EMAIL PROTECTED] wrote: But I'm absolutely with you, if you say that the layer should only throw general-style exception to the caller. The caller isn't interested why an operation can't be performed, if the db ran out of disk space or is simply tired. The caller is interested in: was the call sucessful? Well, thinking about it, it is not that different from real life. (I hope I did not post this joke before) friday Army garrison. A Colonel walks around the regimen, and sees a soldier, polishing his boots with red shoe polish. He approaches and asks: - Soldier, what are you doing? - You don't give a damn about that,- replies soldier - What? Answer as required! - Sir, the garrison is out of black shoe polish, so we are using red polish for out boots, sir! - I don't give a damn about that!- shouts the colonel out. - Yes, this is what I just said. /friday So, the caller does not care what exactly happened, it cares in resolving it :-) Michael. P.S. The last soldier's reply does not exist in original joke, but many people I told it to could not get the joke without it ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Development philosophy and such (was: Base action class)
On Fri, October 7, 2005 1:27 pm, Michael Jouravlev said: P.S. The last soldier's reply does not exist in original joke, but many people I told it to could not get the joke without it ;-) You really need to find some different people to talk to... the type of people that wouldn't get it without the last line are the type of people that just randomly stop breathing because their brain is at full capacity and the lowest item in the stack had to be discarded :) Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
More questions on exception handling
Once again a question about best practices. So I setup an error page, referenced in struts-config.xml that shows the error. My problem is this. #1 - I want to log the error and print out to the console in addition to going to the error page. This isn't happening. Does this mean that I need to override the Struts ExceptionHandler in order to explicitly make sure that before the error page gets the exception, that it's logged, printed to the console, then passed on? #2 - There are some 500 errors, obviously, that aren't struts-related. If I put an error page handler in the web.xml the exception is swallowed and the page doesn't print out the error the same way. The stack trace doesn't go back to the root of the problem or doesn't seem to. So how do I handle 500 exceptions at the container level without ruining my struts-level exception handling? Or should they just never make it to the container if I'm doing it right? Preston - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
invalid paths - how are they handled
Two of our existing apps are built with different Struts versions: 1.1 and 1.0 I am not able to find information on how Struts framework handles invalid paths or where to tweak the existing capability. If this is a valid path: /en/ca/home.do what is going to be returned to the user in this case: www.ourApplication.com/app/en/ca/homeF.do Some kind of existing HTTP error (404 or similar) or something else? thanks ...
OT: RE: Development philosophy and such (was: Base action class)
Hi Frank, Here's the thing about technology, it *evolves*... and it comes as really odd that you *belive* that people introduce new technology solution, architecture, design changes, to just make them more market-able!!. I don't subscribe to this idea, but I would like to add however that:- - it is a by-product of, working with the current state of technologies - also if the change/... doesn't buy anything, then people simply don't stick to it... (reminds me of the Origin of Species) Further - it is not a bad thing to continously evaluate the solution/approach to see how well it could handle anticipated changes, scale to new/additional/changed requirements... - if you want you can always develop your apps for any particular platform say DOS or Win 3.1 (just to name some of the non-*nixes!) and then worry about the GPFs blowing the fuse!! ;), or, perhaps worry about the database getting corrupted (I have actually seen this!!), when, say the application's data grows substantially over time... or any other factors necessitating the change..too many to list them all.. The point is that the applications need to grow and be adapted to changes, in innumerous ways possible, which impact it's usability/stability/maintainability/... I have seen OO Perl/CGI application written for three people grow to a user base of 600 in 3 years, at which point it just wasn't cutting it, as well as changes were much harder to make, taking more time, and to maintain bugs, at that point it was retired and redesigned from ground up and implemented in the latest and greatest technology known at that time (aka J2EE...) I have an analogy, perhaps it's just like, after a while it's just *too much* to keep patching up an old car..it's much simpler to just get a brand new one instead (perhaps to avoid worrying about the gas(money!?)-guzzling monster, which sits in the mechanic's garage more than in your garage!)!!! ;-) So there you have it... again it's getting into the philosophical zone and way-off topic!, so I'd leave it at this... In summary, I'm not saying that your methodology/approach is wrong, just that it helps to keeps ones eyes and ears open! and anticipate and be *open* to ideas/changes and change is not necessarily a bad thing. Regards, Dharmendra ps: have a good day! -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Friday, October 07, 2005 1:10 PM To: Leon Rosenberg Cc: Struts Users Mailing List Subject: Development philosophy and such (was: Base action class) I think we unintentionally hijacked a thread, so just in case we discuss any further, a topic change is probably in order... On Fri, October 7, 2005 12:14 pm, Leon Rosenberg said: My leitmotif is always: keep it simple. No ibatis, no hibernate, no ejb, no nothing unless you explicitely can prove that you need it. You and I would get along very well I think :) That has always been my approach as well. I don't like people that throw new technology in the mix just to get experience. Wendy Smoak turned me on to an acronym that I think is great (she got it from someone else, I forget who): ROP... Resume-Oriented Programming. I can't STAND people that take that approach. I don't like re-inventing the wheel, but if you can't prove to me that I need the wheel to begin with, I prefer to walk :) I often hear, exchangeability of the database is not needed, noone ever exchanges the db in the real world, and if they do, the have to change everything either way. I've never bought this argument either, and I've heard it plenty. Here at work we're a Websphere/Oracle shop, and most of the other architects and developers have no problem building Websphere-specific or Oracle-specific applications. I don't agree with that. I strive for complete independency from those things. Now, I'm not saying it's *always* bad to be tied to Websphere or Oracle... it *always* comes down to what's required. But, I go into things trying to not be tied to anything. I develop on Tomcat and deploy on Webpshere specifically for this reason. I can be *reasonably* sure I'm not tied to Websphere. As far as the DB goes, I develop against Oracle as well, but I'm very careful not to use anything Oracle-specific, or if I have to I try and do it in the DB itself (SP's and such, which I generally try and avoid too). In addition, I develop on Windows but deploy to Linux. OS transparency is important too, and sometimes you can blow it in very subtle ways. We actually really do exchange the db daily. Our complete application runs in production on about 25 servers. I can reconfigure it to use filesystem based persistences and run it on my notebook if I want to work on the road. It runs with corba in production but I can reconfigure it to use direct java calls (with local instantiation) or RMI, or whatever SOAP, or whatever we will decide (and implement) tomorrow.
Problem displaying available choices in Select option list when Validator send me back to my input page
Using Struts 1.1 Problem: Problem displaying available choices in Select option list when using Validator sends me back to my input page. Details: I have 2 html select dropdown boxes on my web page. The values that appear inside come from my database, and are sent to my form inside my form bean. On the initial JSP rendering my page displays fine. My problem occurs when the page doesn't pass a struts validation rule, and formbean is sent back to my input page. My formbean property that was holding my List of objects is now null, and I need to redisplay the list of available choices back on my page. struts html that I am using html:select name=UserProfileForm property=select1 styleClass= standardText multiple=true html:optionsCollection name=UserProfileForm property=unSubscribedGroupDisplay value=grpId label=grpDesc / /html:select Note: UserProfileForm.getUnSubscribedGroupDisplay() returns a List of Objects, and these objects have a set/getGrpId and set/getGrpDesc The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message.
Re: OT: RE: Development philosophy and such (was: Base action class)
On Fri, October 7, 2005 2:33 pm, [EMAIL PROTECTED] said: Hi Frank, Here's the thing about technology, it *evolves*... and it comes as really odd that you *belive* that people introduce new technology solution, architecture, design changes, to just make them more market-able!!. It's not so much what I believe as I have seen a number of people who do exactly that. They are just trying to pad their resumes and not thinking about what solutions properly fit the requirements. I'm not talking about making a bad decision by the way, everyone does that on occassion. I'm talking about people that are constantly looking for situations to apply new technologies to, not because it will make things better but because they want to gain experience with those technologies. Gaining experience is a good goal, doing so with no vision of what makes a good solution isn't :) Further - it is not a bad thing to continously evaluate the solution/approach to see how well it could handle anticipated changes, scale to new/additional/changed requirements... If your talking about evaluation with each new project that comes along, I absolutely agree. What I'm talking about being a problem though is taking an existing application that is solid and robust and does everything it is required to do, and deciding to redo major parts of it just because some better technology comes along. From a technology standpoint, you always run the risk of making things worse when you refactor. That's not to imply that you shouldn't refactor, just that doing it on a whim to play with a new toy isn't the best motivation. From a business standpoint, why incur a risk that you don't have to? I have seen time and again where an application that worked well was deemed old, whatever that means, and was redone, and the result was worse. If you have a requirement that the application can't meet in its current form, *then* it is of course appropriate to rework it. But in the absence of such a requirement it seems to me very hard to justify that risk. - if you want you can always develop your apps for any particular platform say DOS or Win 3.1 (just to name some of the non-*nixes!) and then worry about the GPFs blowing the fuse!! ;), or, perhaps worry about the database getting corrupted (I have actually seen this!!), when, say the application's data grows substantially over time... or any other factors necessitating the change..too many to list them all.. Again, if the requirements change, so to the application may have to, and so to may the underlying technology have to. I don't have any problem with this, as long as it's not taken to the extreme... I've seen cases where people say ok, we need to add X to the application to meet this new goal, so while we're at it let's add Y and Z because it scratches an itch. X is good, Y and Z aren't. Maybe that's how I should put it... change for the sake of scratching a technological issue isn't (usually) a good thing. Change for the sake of meeting a new requirement is. The point is that the applications need to grow and be adapted to changes, in innumerous ways possible, which impact it's usability/stability/maintainability/... I have seen OO Perl/CGI application written for three people grow to a user base of 600 in 3 years, at which point it just wasn't cutting it, as well as changes were much harder to make, taking more time, and to maintain bugs, at that point it was retired and redesigned from ground up and implemented in the latest and greatest technology known at that time (aka J2EE...) And I wouldn't say there's anything wrong with that :) But think of this scenario... what if after 3 MONTHS someone decided that wow, J2EE is all the rage, let's rewrite this application because we want to get J2EE experience. Would that be OK? For you as a technology person it may be, but probably not for the business, and IT is here to service the business, not the other way around :) I see people forgeting that all the time too. I have an analogy, perhaps it's just like, after a while it's just *too much* to keep patching up an old car..it's much simpler to just get a brand new one instead (perhaps to avoid worrying about the gas(money!?)-guzzling monster, which sits in the mechanic's garage more than in your garage!)!!! ;-) Let's not talk about mechanics... sore subject around these parts right now :) I get your analogy of course though. Especially since I just bought a new car recently because my old one was too expensive to keep running. But what if this week, after having my new car for a month or so, I decide that the '06 model is cool and I want it, even though the car I have now is doing the job just fine and has some headroom to keep doing fine for a while. Good idea or not? :) So there you have it... again it's getting into the philosophical zone and way-off topic!, so I'd leave it at this... In summary, I'm not saying that your
improving JSP logic
I'm plunging into the world of JSP development and I'm
wanting to improve on this type of [messy] logic:
% int rowCount = 0; %
logic:iterate id=oi name=myForm property=stuff
% if (++rowCount % 2 == 0) { %
tr class=normalRow
% } else { %
tr class=altRow
% } %
tdbean:write name=oi property=group3Name //td
/tr
/logic:iterate
My attempts have been various incarnations (for the tr) of the
following, utilizing iterate's -indexId-:
logic:notEmpty name=myForm property=stuff
logic:iterate id=oi name=myForm property=stuff indexId=idx
tr class=% (idx.intValue()%2==0) ? altRow : normalRow; %
tdbean:write name=oi property=group3Name //td
/tr
/logic:iterate
Unfortunately, we arent using JSTL (and wont be), otherwise I
could use the solution found here:
http://cephas.net/blog/2004/02/25/jstl_vs_struts_taglib.html
Any suggestions for improvement ?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: invalid paths - how are they handled
Bosko Vukojevic wrote: Two of our existing apps are built with different Struts versions: 1.1 and 1.0 I am not able to find information on how Struts framework handles invalid paths or where to tweak the existing capability. If this is a valid path: /en/ca/home.do what is going to be returned to the user in this case: www.ourApplication.com/app/en/ca/homeF.do Some kind of existing HTTP error (404 or similar) or something else? If you don't have an action mapping that matches /en/ca/homeF.do (either explicitly or using wildcards) then Struts will do the same thing the Container would for an invalid URL not mapped to Struts: return a 404 error. I'm not sure where (or if) that's documented, but it's trivial to test and see for yourself. L. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: OT: RE: Development philosophy and such (was: Base action class)
Hi Frank, Sorry couldn't help but remark that... it seems some people are forgetting the software engineering basics.. :) There is no silver bullet! And you are absolutely right that there is no justification for using new technology just for the heck of it... (And there is a reason some of the banks still have those mainframes lying around!.) like they say if it ain't broken, don't fix it!. Here's wishing you Happy Friday!, Cheers!, Dharmendra ps: have a super day! -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Friday, October 07, 2005 3:08 PM To: Struts Users Mailing List Cc: user@struts.apache.org; [EMAIL PROTECTED] Subject: Re: OT: RE: Development philosophy and such (was: Base action class) On Fri, October 7, 2005 2:33 pm, [EMAIL PROTECTED] said: Hi Frank, Here's the thing about technology, it *evolves*... and it comes as really odd that you *belive* that people introduce new technology solution, architecture, design changes, to just make them more market-able!!. It's not so much what I believe as I have seen a number of people who do exactly that. They are just trying to pad their resumes and not thinking about what solutions properly fit the requirements. I'm not talking about making a bad decision by the way, everyone does that on occassion. I'm talking about people that are constantly looking for situations to apply new technologies to, not because it will make things better but because they want to gain experience with those technologies. Gaining experience is a good goal, doing so with no vision of what makes a good solution isn't :) Further - it is not a bad thing to continously evaluate the solution/approach to see how well it could handle anticipated changes, scale to new/additional/changed requirements... If your talking about evaluation with each new project that comes along, I absolutely agree. What I'm talking about being a problem though is taking an existing application that is solid and robust and does everything it is required to do, and deciding to redo major parts of it just because some better technology comes along. From a technology standpoint, you always run the risk of making things worse when you refactor. That's not to imply that you shouldn't refactor, just that doing it on a whim to play with a new toy isn't the best motivation. From a business standpoint, why incur a risk that you don't have to? I have seen time and again where an application that worked well was deemed old, whatever that means, and was redone, and the result was worse. If you have a requirement that the application can't meet in its current form, *then* it is of course appropriate to rework it. But in the absence of such a requirement it seems to me very hard to justify that risk. - if you want you can always develop your apps for any particular platform say DOS or Win 3.1 (just to name some of the non-*nixes!) and then worry about the GPFs blowing the fuse!! ;), or, perhaps worry about the database getting corrupted (I have actually seen this!!), when, say the application's data grows substantially over time... or any other factors necessitating the change..too many to list them all.. Again, if the requirements change, so to the application may have to, and so to may the underlying technology have to. I don't have any problem with this, as long as it's not taken to the extreme... I've seen cases where people say ok, we need to add X to the application to meet this new goal, so while we're at it let's add Y and Z because it scratches an itch. X is good, Y and Z aren't. Maybe that's how I should put it... change for the sake of scratching a technological issue isn't (usually) a good thing. Change for the sake of meeting a new requirement is. The point is that the applications need to grow and be adapted to changes, in innumerous ways possible, which impact it's usability/stability/maintainability/... I have seen OO Perl/CGI application written for three people grow to a user base of 600 in 3 years, at which point it just wasn't cutting it, as well as changes were much harder to make, taking more time, and to maintain bugs, at that point it was retired and redesigned from ground up and implemented in the latest and greatest technology known at that time (aka J2EE...) And I wouldn't say there's anything wrong with that :) But think of this scenario... what if after 3 MONTHS someone decided that wow, J2EE is all the rage, let's rewrite this application because we want to get J2EE experience. Would that be OK? For you as a technology person it may be, but probably not for the business, and IT is here to service the business, not the other way around :) I see people forgeting that all the time too. I have an analogy, perhaps it's just like, after a while it's just *too much* to keep patching up an old car..it's much simpler to just get a brand new one
Re: Problem displaying available choices in Select option list when Validator send me back to my input page
[EMAIL PROTECTED] wrote: Using Struts 1.1 Problem: Problem displaying available choices in Select option list when using Validator sends me back to my input page. Details: I have 2 html select dropdown boxes on my web page. The values that appear inside come from my database, and are sent to my form inside my form bean. On the initial JSP rendering my page displays fine. My problem occurs when the page doesn't pass a struts validation rule, and formbean is sent back to my input page. My formbean property that was holding my List of objects is now null, and I need to redisplay the list of available choices back on my page. struts html that I am using html:select name=UserProfileForm property=select1 styleClass= standardText multiple=true html:optionsCollection name=UserProfileForm property=unSubscribedGroupDisplay value=grpId label=grpDesc / /html:select Note: UserProfileForm.getUnSubscribedGroupDisplay() returns a List of Objects, and these objects have a set/getGrpId and set/getGrpDesc How is UserProfileForm instantiated and initialized? What do your action mappings and form bean definitions look like? Without more information it's impossible to say definitively what's wrong. The most likely explanation is that you are returning control directly to a JSP when validation fails rather than to the action that sets up the form bean. If you have an action that runs and then forwards to the JSP the first time it's shown, you need to name that action in the 'input' for the action that's executed on form submission, rather than the JSP itself. If that doesn't make sense, post the rest of your configuration and code, or at least describe how you have everything configured. L. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to minimize security related code in Action classes
Can someone point me to some articles or provide some examples on how to minimize security related code (authorization) in my Action classes? I am currently using container-managed, form-based security (Tomcat) for authentication and security-contraint and security-role elements in web.xml. The problem is that I'm not sure how best to have finer grained control of which roles can do what. For example, I have a UserAction class with methods that allow edit, add and delete of users. I want some roles to be able to add and edit but not delete. The urls might look something like this: http://www.myapp.com/do/user?Dispatch=add http://www.myapp.com/do/user?Dispatch=add http://www.myapp.com/do/user?Dispatch=editid=5 http://www.myapp.com/do/user?Dispatch=editid=5 http://www.myapp.com/do/user?Dispatch=deleteid=5 http://www.myapp.com/do/user?Dispatch=deleteid=5 But web.xml allows url-patterns based on actions: url-pattern/do/user/*/url-pattern So do I have to create a separate Action class for each one so that it is a different URL? Right now I have code that checks in edit, add and delete methods inside UserAction to see if the logged in user has the correct role. Any suggestions would be appreciated. TIA, Brian Barnett This email may contain confidential material. If you were not an intended recipient, Please notify the sender and delete all copies. We may monitor email to and from our network.
RE: OT: RE: Development philosophy and such (was: Base action class)
On Fri, October 7, 2005 4:10 pm, [EMAIL PROTECTED] said: And you are absolutely right that there is no justification for using new technology just for the heck of it... (And there is a reason some of the banks still have those mainframes lying around!.) like they say if it ain't broken, don't fix it!. By day I work for one of those banks, and most of my work has been in creating webapps that make use of legacy systems... did one where we had a Unix partition on the mainframe and Apache running in it talking to CICS. Sometimes painful, sometimes fun, always interesting :) Here's wishing you Happy Friday!, Cheers!, Dharmendra ps: have a super day! You too :) Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OT: RE: Development philosophy and such (was: Base action class)
I think this philosophical topics are SUPERB, specially on fridays. I don't have Ur xperience in development, but I'm a new tecnology skeptic. If someone in my team tells me to use X tecnology, because it's brand new, etc or if because it's a standard, I just tell him about the risks, the standards, the market standard, the learning curve, the productivity, etc... If I can't learn it in 2 or 3 days, we don't adopt it. The last one that I burned my tongue about was JSF, that I was a TOTAL skeptical, but I liked a lot. Best regards, and have a nice weekend. Rafael Mauricio Nami 2005/10/7, [EMAIL PROTECTED] [EMAIL PROTECTED]: Hi Frank, Sorry couldn't help but remark that... it seems some people are forgetting the software engineering basics.. :) There is no silver bullet! And you are absolutely right that there is no justification for using new technology just for the heck of it... (And there is a reason some of the banks still have those mainframes lying around!.) like they say if it ain't broken, don't fix it!. Here's wishing you Happy Friday!, Cheers!, Dharmendra ps: have a super day! -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Friday, October 07, 2005 3:08 PM To: Struts Users Mailing List Cc: user@struts.apache.org; [EMAIL PROTECTED] Subject: Re: OT: RE: Development philosophy and such (was: Base action class) On Fri, October 7, 2005 2:33 pm, [EMAIL PROTECTED] said: Hi Frank, Here's the thing about technology, it *evolves*... and it comes as really odd that you *belive* that people introduce new technology solution, architecture, design changes, to just make them more market-able!!. It's not so much what I believe as I have seen a number of people who do exactly that. They are just trying to pad their resumes and not thinking about what solutions properly fit the requirements. I'm not talking about making a bad decision by the way, everyone does that on occassion. I'm talking about people that are constantly looking for situations to apply new technologies to, not because it will make things better but because they want to gain experience with those technologies. Gaining experience is a good goal, doing so with no vision of what makes a good solution isn't :) Further - it is not a bad thing to continously evaluate the solution/approach to see how well it could handle anticipated changes, scale to new/additional/changed requirements... If your talking about evaluation with each new project that comes along, I absolutely agree. What I'm talking about being a problem though is taking an existing application that is solid and robust and does everything it is required to do, and deciding to redo major parts of it just because some better technology comes along. From a technology standpoint, you always run the risk of making things worse when you refactor. That's not to imply that you shouldn't refactor, just that doing it on a whim to play with a new toy isn't the best motivation. From a business standpoint, why incur a risk that you don't have to? I have seen time and again where an application that worked well was deemed old, whatever that means, and was redone, and the result was worse. If you have a requirement that the application can't meet in its current form, *then* it is of course appropriate to rework it. But in the absence of such a requirement it seems to me very hard to justify that risk. - if you want you can always develop your apps for any particular platform say DOS or Win 3.1 (just to name some of the non-*nixes!) and then worry about the GPFs blowing the fuse!! ;), or, perhaps worry about the database getting corrupted (I have actually seen this!!), when, say the application's data grows substantially over time... or any other factors necessitating the change..too many to list them all.. Again, if the requirements change, so to the application may have to, and so to may the underlying technology have to. I don't have any problem with this, as long as it's not taken to the extreme... I've seen cases where people say ok, we need to add X to the application to meet this new goal, so while we're at it let's add Y and Z because it scratches an itch. X is good, Y and Z aren't. Maybe that's how I should put it... change for the sake of scratching a technological issue isn't (usually) a good thing. Change for the sake of meeting a new requirement is. The point is that the applications need to grow and be adapted to changes, in innumerous ways possible, which impact it's usability/stability/maintainability/... I have seen OO Perl/CGI application written for three people grow to a user base of 600 in 3 years, at which point it just wasn't cutting it, as well as changes were much harder to make, taking more time, and to maintain bugs, at that point it was retired and redesigned from ground up and implemented in the latest and greatest
Re: set different attribute according to the change of parameter
梁炳場 wrote:
Can I do the following?
Same action class sets different attribute
according to the change of parameter?
Thanks
action path=/userProfileMaint
type=com.erp.struts.SetRoleHref
parameter=userProfileMaint
action path=/quotationMaint
type=com.erp.struts.SetRoleHref
parameter=quotationMaint
public class SetRoleHref extends Action {
String myValue = request.getParameter(parameter);
session.setAttribute(rolehref, myValue);
Sure, you can do that, except that the 'parameter' attribute in the
action mapping isn't exposed as a request parameter (those come from the
HTTP request). You need to call getParameter() on the ActionMapping
instance instead.
L.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: OT: RE: Development philosophy and such
Rafael Nami wrote: If I can't learn it in 2 or 3 days, we don't adopt it. If you can learn new technologies in 2-3 days you can afford to learn most anything. 2-3 hrs: Do I care about this technology (right now)? 2-3 days: Can I implement a minimal example and get a feel for it? 2-3 weeks: Should I use this technology for new projects? 2-3 months: I am comfortable with this technology. 2-3 years: I am the Lizard King. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Struts Tags examples and usage
Hi, Is there any good resource on the net that describes the usage of struts tag libraries (html,bean, logic etc) with examples? I saw the examples available on the http://struts.apache.org/userGuide/struts-bean.htm but there are no examples that describes how you can use it? Please reply. Thanks. Deep - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OT: RE: Development philosophy and such (was: Base action class)
On 10/7/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi Frank, Sorry couldn't help but remark that... it seems some people are forgetting the software engineering basics.. :) There is no silver bullet! Damned, and I actually thought I found one :-) But seriously, I think the silver bullet of the software development is not the technology but the process. _Listen_ to the customer, _understand_ the problem (your customer's problem, no what you think he's problem is) , _analyse_ the problem, provide best solution. This is of course very philosophical, but, sadly enough, not many developers actually master it. regards leon P.S. and its actually saturday here, since 11 minutes... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OT: RE: Development philosophy and such (was: Base action class)
_Listen_ to the customer, +1 that requriements is the silver bullet. I address is w/ both mock ups and prototypes... to demonstrate active listening. .V http://roomity.com (version 1.3 is live) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Cannot find a bean in the session
I am using Struts 1.1 deployed in Tomcat 4.1 running under JDK 1.3. I have a contact form I am building. It will get the user's email from an object called a UserInfoBean, which is not an ActionForm subclass, but does follow the JavaBean paradigm. It simply holds user info such as first name, last name, etc. Since it isn't associated with any particular form, I didn't make it subclass ActionForm. So my first question is, is this the correct pattern to follow? Secondly, in my ContactSupportAction class (subclass of struts Action), I attempt to retrieve this bean from the session and call it's getEmail() method. However, the result of (UserInfoBean) request.getAttribute(userInfoBean); returns a NULL reference. I don't understand why this is happening. I create this bean in a class called GetUserInfoAction, which gets fired right after a user logs in succesfully. The GetUserInfoAction will create a UserInfoBean and place it in the session under the name userInfoBean. The GetUserInfoAction will forward the user to the home.jsp. In this page I have some bean:write tags which reference information in the userInfoBean object. And this information displays just find. So I know the bean gets created and succesfully stored in the session. So how come I am not able to find a reference to this object when I attempt to retrieve from the session in my ContactSupportAction class? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fast war deployment
Hello all: Everytime I deploy my .war file on my server, restart Tomcat and access the JSPs and actions it will compile (make JSPs servlets) and load them. It takes a time the first time. This gets annoying as the application gets bigger. Is there any way to deploy the war and have a build file? Can I accomplish that with ant? If so, how? Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Tags examples and usage
TheServerSide.com has access to a free PDF download of Jakarta Struts Live. While I don't think the book is that great overall, there are some chapters on the Struts tag libs. http://www.theserverside.com/books/sourcebeat/JakartaStrutsLive/index.tss On 10/7/05, Leon Rosenberg [EMAIL PROTECTED] wrote: maybe http://wiki.apache.org/struts/StrutsTutorials will help you. regards Leon On 10/8/05, Deep Chand [EMAIL PROTECTED] wrote: Hi, Is there any good resource on the net that describes the usage of struts tag libraries (html,bean, logic etc) with examples? I saw the examples available on the http://struts.apache.org/userGuide/struts-bean.htm but there are no examples that describes how you can use it? Please reply. Thanks. Deep - 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] -- http://www.quidprocode.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fast war deployment
http://localhost/manager/reload?path=/ above should do. Have eclipse point to where you app.xml points (to root of WEB-INF) .V C.F. Scheidecker Antunes wrote: Hello all: Everytime I deploy my .war file on my server, restart Tomcat and access the JSPs and actions it will compile (make JSPs servlets) and load them. It takes a time the first time. This gets annoying as the application gets bigger. Is there any way to deploy the war and have a build file? Can I accomplish that with ant? If so, how? Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [JSF] Is it possible to submit to different URL/page?
It does not submit a form. I guess, by default, JSF does not allow that. On 10/6/05, Eduardo Ribeiro da Silva [EMAIL PROTECTED] wrote: Try outputLink -Mensagem original- De: Michael Jouravlev [mailto:[EMAIL PROTECTED] Enviada em: quinta-feira, 6 de outubro de 2005 15:10 Para: Struts Users Mailing List Assunto: [JSF] Is it possible to submit to different URL/page? I looked up for an attribute of h:commandButton which would allow to submit to another URL, and I could not find it. All I found was action and actionListener, which should evaluate to methods, not to URLs: http://java.sun.com/j2ee/javaserverfaces/1.1/docs/tlddocs/h/commandButton.html ASP.NET 1.x does not allow posting to another page. MS fixed this issue in ASP.NET 2.0 Michael J. - 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]
