Feature request for html:javascript tag
I am using the html java script tag in two parts, but some of it seems more cumbersome then it needs to be. I have a validation.jsp file that contains: html:javascript dynamicJavascript=false staticJavaScript=true/ it sole purpose is to provide the java script functions that are constant for all forms/validations in this application. In the jsp where I want a for validates I have the required onSubmit handler etc, and I need to do two other things: 1) Generate the dynamic portion, which I do like this: html:javascript formName=myform staticJavascript=false/ 2) Make sure the static stuff is included. The obvious below does not work: SCRIPT language=Javascript1.1 src=validation.jsp/SCRIPT It does not work because I store the validation.jsp file where I store all my other jsps, meaning they need to be addressed within the web app context. It is impossible to know this before hand, so one need's to resort to some java scriptlet inside the src attribute to dynamically construct the correct path. Many of the other struts taglibs have options to have this transformation done for you (html:link comes to mind as one of them). It would be nice if one could write: html:javascript dynamicJavascript=false staticJavascript=false src=validation.jsp/ and have the above requested behavior happen. The idea here is that if both attributes are false, the only reasonable meaning would be to create an empty SCRIPT tag with the dynamically created src tag. Of course this dynamic behavior would mess up existing code which depends on src's static implementation. I believe the check for both javascript attributes being false addresses this, but I would gladly accept a different/new attribute to use for this purpose. In fact, many custom java script approaches have exactly such a script tag at the top of JSPs, and also need the scriptlet work around to allow the files themselves to be stored inside the context resources. Therefore, this could be a very useful feature without the validator even. Godo idea, or am I missing something? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[SCAFFOLD] StorageBeanBase feature request
I am in the middle of the process of defining the data access layer to be used for a new Struts-based application, for which we already use Scaffold's ProcessBeans. We decided not to go with Hibernate as a persistence layer (to my disappointment) and to choose Scaffold Access/StorageBean approach instead. Reading on this list I found an email by Ted Husted saying that he was (maybe still is?) not happy with the StorageBean deployment. So my question is what should I do? I quite like the Scaffold data access layer and more importantly my DBA trusts it too. I'd prefer to go with StorageBeanBase, but in this case I should make minor modifications to the Scaffold code (which I will give back to the community of course). The other option is the Access approach, but it is deprecated and it is not nice to compile an application with lots of warnings. The modifications I have to introduce in the StorageBeanBase are: replace all calls to StatementUtils.executeUpdate(null,etc); with: StatementUtils.executeUpdate(getResource(),etc); and add a static String resource=null; with getters and setters that can be overriden by subclasses. This is motivated by tha fact that I have tables located in many different schemas/db hosts and want ConnectionAdaptor to return the right connection for that schema/db host. Thank you, Umberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SCAFFOLD] StorageBeanBase feature request
I have submitted a patch to Bugzilla (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21433) for this issue. Is there anyone interested in it? Thanks, Umberto Umberto Nicoletti wrote: I am in the middle of the process of defining the data access layer to be used for a new Struts-based application, for which we already use Scaffold's ProcessBeans. We decided not to go with Hibernate as a persistence layer (to my disappointment) and to choose Scaffold Access/StorageBean approach instead. Reading on this list I found an email by Ted Husted saying that he was (maybe still is?) not happy with the StorageBean deployment. So my question is what should I do? I quite like the Scaffold data access layer and more importantly my DBA trusts it too. I'd prefer to go with StorageBeanBase, but in this case I should make minor modifications to the Scaffold code (which I will give back to the community of course). The other option is the Access approach, but it is deprecated and it is not nice to compile an application with lots of warnings. The modifications I have to introduce in the StorageBeanBase are: replace all calls to StatementUtils.executeUpdate(null,etc); with: StatementUtils.executeUpdate(getResource(),etc); and add a static String resource=null; with getters and setters that can be overriden by subclasses. This is motivated by tha fact that I have tables located in many different schemas/db hosts and want ConnectionAdaptor to return the right connection for that schema/db host. Thank you, Umberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [SCAFFOLD] StorageBeanBase feature request
Umberto, You may be better served by directing your queries to the struts-dev mailing list. [EMAIL PROTECTED] -= J -Original Message- From: Umberto Nicoletti [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 09, 2003 8:04 AM To: [EMAIL PROTECTED] Subject: Re: [SCAFFOLD] StorageBeanBase feature request I have submitted a patch to Bugzilla (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21433) for this issue. Is there anyone interested in it? Thanks, Umberto Umberto Nicoletti wrote: I am in the middle of the process of defining the data access layer to be used for a new Struts-based application, for which we already use Scaffold's ProcessBeans. We decided not to go with Hibernate as a persistence layer (to my disappointment) and to choose Scaffold Access/StorageBean approach instead. Reading on this list I found an email by Ted Husted saying that he was (maybe still is?) not happy with the StorageBean deployment. So my question is what should I do? I quite like the Scaffold data access layer and more importantly my DBA trusts it too. I'd prefer to go with StorageBeanBase, but in this case I should make minor modifications to the Scaffold code (which I will give back to the community of course). The other option is the Access approach, but it is deprecated and it is not nice to compile an application with lots of warnings. The modifications I have to introduce in the StorageBeanBase are: replace all calls to StatementUtils.executeUpdate(null,etc); with: StatementUtils.executeUpdate(getResource(),etc); and add a static String resource=null; with getters and setters that can be overriden by subclasses. This is motivated by tha fact that I have tables located in many different schemas/db hosts and want ConnectionAdaptor to return the right connection for that schema/db host. Thank you, Umberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SCAFFOLD] StorageBeanBase feature request
I'm not using the SQL parts of Scaffold in new development. For new development, I'm now using Hiberate. I'm away next week, but later this month, I'll apply some outstanding patches to Scaffold, and look at providing a direct alternative to the SQL package using either Commons SQL/Dynabeans, the new Mapping package in the Jakarta Commons sandbox, or Ibatis. There are just too many other likely alternatives now to keep this package alive. Of course, you can always check-out the code yourself and use as part of in-house development. The Access paradigm is not strongly linked to the StorageBeans. Essentially, it's just a facade, and you could use anything you like behind the facade. (Say Hibernate, for example.) -Ted. Umberto Nicoletti wrote: I am in the middle of the process of defining the data access layer to be used for a new Struts-based application, for which we already use Scaffold's ProcessBeans. We decided not to go with Hibernate as a persistence layer (to my disappointment) and to choose Scaffold Access/StorageBean approach instead. Reading on this list I found an email by Ted Husted saying that he was (maybe still is?) not happy with the StorageBean deployment. So my question is what should I do? I quite like the Scaffold data access layer and more importantly my DBA trusts it too. I'd prefer to go with StorageBeanBase, but in this case I should make minor modifications to the Scaffold code (which I will give back to the community of course). The other option is the Access approach, but it is deprecated and it is not nice to compile an application with lots of warnings. The modifications I have to introduce in the StorageBeanBase are: replace all calls to StatementUtils.executeUpdate(null,etc); with: StatementUtils.executeUpdate(getResource(),etc); and add a static String resource=null; with getters and setters that can be overriden by subclasses. This is motivated by tha fact that I have tables located in many different schemas/db hosts and want ConnectionAdaptor to return the right connection for that schema/db host. Thank you, Umberto -- Ted Husted, Struts in Action http://husted.com/struts/book.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SCAFFOLD] StorageBeanBase feature request
Thanks Ted,
I already generated an in-house version of Scaffold with my patch, but
got into another trouble.
I got my StorageBeanBase working, but get ResourceExcptions when
executing findCollection(), which in turns call getCollection.
What I see is that the prepared statement is closed before the
collection is populated from the ResultSet.
So when ResultSetUtils call getMetaData() the resultSet throws
SQLException: connection closed.
What am I missing? Please bear with me, even though I am posting on the
wrong ml (but I knew you were here).
Code snippet from StatementUtils:
public static final ResultSet executeQuery(
Connection connection,
String command,
Object[] parameters)
throws SQLException {
Statement statement = null;
PreparedStatement preparedStatement = null;
ResultSet resultSet = null;
try {
if ((parameters==null) || (parameters.length==0)) {
statement = connection.createStatement();
resultSet = statement.executeQuery(command);
}
else {
preparedStatement = connection.prepareStatement(command);
for (int i=0; iparameters.length; i++) {
preparedStatement.setObject(i+1, parameters[i]);
}
resultSet = preparedStatement.executeQuery();
}
}
finally {
try {
//
// WHY ARE YOU CLOSING THE STATEMENT HERE
// CLOSING THE STATEMENT HERE RELEASE THE RESULTSET TOO...
//
if (statement != null) statement.close();
if (preparedStatement != null) preparedStatement.close();
}
catch (SQLException sqle) {}
}
return resultSet;
} // end executeQuery
Thank you in advance,
Umberto
Ted Husted wrote:
I'm not using the SQL parts of Scaffold in new development. For new
development, I'm now using Hiberate.
I'm away next week, but later this month, I'll apply some outstanding
patches to Scaffold, and look at providing a direct alternative to the
SQL package using either Commons SQL/Dynabeans, the new Mapping package
in the Jakarta Commons sandbox, or Ibatis. There are just too many other
likely alternatives now to keep this package alive.
Of course, you can always check-out the code yourself and use as part of
in-house development.
The Access paradigm is not strongly linked to the StorageBeans.
Essentially, it's just a facade, and you could use anything you like
behind the facade. (Say Hibernate, for example.)
-Ted.
Umberto Nicoletti wrote:
I am in the middle of the process of defining the data access layer to
be used for a new Struts-based application, for which we already use
Scaffold's ProcessBeans.
We decided not to go with Hibernate as a persistence layer (to my
disappointment) and to choose Scaffold Access/StorageBean approach
instead.
Reading on this list I found an email by Ted Husted saying that he was
(maybe still is?) not happy with the StorageBean deployment.
So my question is what should I do? I quite like the Scaffold data
access layer and more importantly my DBA trusts it too.
I'd prefer to go with StorageBeanBase, but in this case I should make
minor modifications to the Scaffold code (which I will give back to
the community of course). The other option is the Access approach, but
it is deprecated and it is not nice to compile an application with
lots of warnings.
The modifications I have to introduce in the StorageBeanBase are:
replace all calls to
StatementUtils.executeUpdate(null,etc);
with:
StatementUtils.executeUpdate(getResource(),etc);
and add a static String resource=null; with getters and setters
that can be overriden by subclasses. This is motivated by tha fact
that I have tables located in many different schemas/db hosts and want
ConnectionAdaptor to return the right connection for that schema/db host.
Thank you,
Umberto
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SCAFFOLD] StorageBeanBase feature request
Umberto Nicoletti wrote: So when ResultSetUtils call getMetaData() the resultSet throws SQLException: connection closed. Yes, that's one of the patches I need to apply. The JDBC driver I was using is buggy and allowed it to be closed early than the specification permits. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Another Struts Console feature request
I would also like to see a New item on the File menu! -- Steven Valin [EMAIL PROTECTED]
RE: (architectural issue/feature request) JavaBeans in Struts aren't flexible enough
How you feel about type safety and having a/the compiler help you out will also play into your choice here. For all of the pain that creating JavaBean classes causes, they do create a well-defined interface that developers of JSPs can use to rely on to know what data is available. If all you're passing back is a Hashmap, then there needs to be an agreement between the JSP develper and the Action developer as to what that Hashmap will contain. If those developers happen to be the same person, that's usually not a problem (unless you tend to forget what you tell yourself ;-) If they are different people, then you might want the agreement to be more than just a verbal agreement during a hallway meeting. Which leads to documenting what the Hashmap will contain, which leads to having to maintain the documentation... Having JavaBeans as the format of your data also means that the JSP compiler can tell you when you try to refer to a property that isn't there, or is misspelled. The compiler can be your friend here. However, if your JSP refers to an entry in a Hashmap and gets it wrong, it's harder to track down the problem. Is the field on the form blank because there isn't any data there, or because you asked for the wrong entry name? There's definite flexibility advantages to using dynamic collections of data, but realize that it comes at a certain cost. John -Original Message- From: Stephen Schaub [SMTP:[EMAIL PROTECTED]] Sent: Thursday, April 26, 2001 6:52 AM To: [EMAIL PROTECTED] Subject: Re: (architectural issue/feature request) JavaBeans in Struts aren't flexible enough I have been pondering this very issue myself recently. For example, I would like to be able to display the results of a query in an HTML table. I don't want to have to create a Javabean to hold the attributes for the result set, because every time I want to tweak the result set, I have to 1. Add/remove/change getters and setters for the JavaBean to conform to the new result set 2. Change the code that takes the data from the result set and puts it in the JavaBean 3. Update the jsp to reflect the changes In your dynamic Javabean = hashmap approach, I could easily write a generic routine that takes a result set and converts it into a collection of dynamic Javabeans. Then, when I tweak the result set, the only thing I have to do is #3. I think I've read somewhere on the list about an effort to improve the scenario I just described, but there are a lot of other scenarios where dynamic JavaBeans would come in handy, and I hope it is officially addressed. Stephen Schaub - Original Message - From: Iraklis Kourtidis [EMAIL PROTECTED] Sent: Wednesday, April 25, 2001 12:27 PM Subject: (architectural issue/feature request) JavaBeans in Struts aren't flexible enough Hi all, I was wondering what your views on the following are: JavaBeans seem to only allow fixed properties (say foo and bar), and the tags that operate on them (e.g. bean:write) essentially call getters getFoo() and getBar(). However, this means that any time we're in the action class and we want to package some information to send to the JSP, we need to write a Java class with the appropriate properties and getters. This quickly becomes tiresome and causes code bloating; if I want to avoid scriptlets in my JSP, I have to use Javabeans, so for pretty much every Action class I need to add such a new Java class. A better way would be for Javabeans to be (essentially) some sort of subclass of java.util.Map, so that I can add properties at runtime. Here's some sample code: GenericJavabean jb = new GenericJavabean(); jb.addProperty(foo, value of foo); jb.addProperty(bar, value of bar); Then, there could be some other tag, say bean:write2 whose property attribute will not correspond to a getter function, but will instead call (internally) bean.getProperty(foo). In short, Javabeans, the current mechanism of passing information to the JSP for display purposes, are limiting because they have to be defined at *compile* time. It is not practical (in terms of efficiency and complexity) to add getter functions to a class at runtime (we've considered that), so we need to essentially create new Javabean classes. Am I the only one who gets bothered by this? I was wondering what the rest of you do. Do you just resign to creating new Java classes every time you want to put something on the request and send it to the JSP? thanks for your input, Iraklis
Re: (architectural issue/feature request) JavaBeans in Struts aren't flexible enough
I have been pondering this very issue myself recently. For example, I would like to be able to display the results of a query in an HTML table. I don't want to have to create a Javabean to hold the attributes for the result set, because every time I want to tweak the result set, I have to 1. Add/remove/change getters and setters for the JavaBean to conform to the new result set 2. Change the code that takes the data from the result set and puts it in the JavaBean 3. Update the jsp to reflect the changes In your dynamic Javabean = hashmap approach, I could easily write a generic routine that takes a result set and converts it into a collection of dynamic Javabeans. Then, when I tweak the result set, the only thing I have to do is #3. I think I've read somewhere on the list about an effort to improve the scenario I just described, but there are a lot of other scenarios where dynamic JavaBeans would come in handy, and I hope it is officially addressed. Stephen Schaub - Original Message - From: Iraklis Kourtidis [EMAIL PROTECTED] Sent: Wednesday, April 25, 2001 12:27 PM Subject: (architectural issue/feature request) JavaBeans in Struts aren't flexible enough Hi all, I was wondering what your views on the following are: JavaBeans seem to only allow fixed properties (say foo and bar), and the tags that operate on them (e.g. bean:write) essentially call getters getFoo() and getBar(). However, this means that any time we're in the action class and we want to package some information to send to the JSP, we need to write a Java class with the appropriate properties and getters. This quickly becomes tiresome and causes code bloating; if I want to avoid scriptlets in my JSP, I have to use Javabeans, so for pretty much every Action class I need to add such a new Java class. A better way would be for Javabeans to be (essentially) some sort of subclass of java.util.Map, so that I can add properties at runtime. Here's some sample code: GenericJavabean jb = new GenericJavabean(); jb.addProperty(foo, value of foo); jb.addProperty(bar, value of bar); Then, there could be some other tag, say bean:write2 whose property attribute will not correspond to a getter function, but will instead call (internally) bean.getProperty(foo). In short, Javabeans, the current mechanism of passing information to the JSP for display purposes, are limiting because they have to be defined at *compile* time. It is not practical (in terms of efficiency and complexity) to add getter functions to a class at runtime (we've considered that), so we need to essentially create new Javabean classes. Am I the only one who gets bothered by this? I was wondering what the rest of you do. Do you just resign to creating new Java classes every time you want to put something on the request and send it to the JSP? thanks for your input, Iraklis
RE: (architectural issue/feature request) JavaBeans in Struts are n't flexible enough
Hi Iraklis I did alot of experimenting with this approach on my previous project about four months ago i.e. a generic JavaBean that was an extension of the HashMap object with generic getProperty/setProperty methods. I hit upon the idea of storing the properties and meta data for the JavaBeans in XML files, with an instance of the generic JavaBean being created from a given XML file. So I got the advantages of: * being able to modify properties at deploy time by modifying the XML files * programmers knowing what was in the Maps by looking at the XML files * not needing to create explicit get/set methods I also wanted the XML files to doubled as property-to-RDBMS column mappings so I could construct SQL queries from them and populate the JavaBean that way, but I couldn't get that part to work generically enough. It mostly worked but I stopped after a few runs because of the really bad performance problems I was experiencing (especially in an iterate situation) compared to normal JavaBeans. I never did completely figure out why, but I thought it might have had to do with the amount of Object creations that were going on because you can only store objects in HashMaps, whereas you can use primitive types in normal JavaBeans, and there also seemed to be some sort of built-in optimization possible with normal JavaBeans, especially with the JSP Engine I was using anyway (WebLogic 5.1). I also realized how much work would be involved in changing the Struts tag libs to make the generic JavaBean work. I did end up creating some custom tags but that didn't help with the performance, even though the code was significantly simpler than the Struts version. It was really mysterious. So I've gone back to using normal JavaBeans. Your welcome to some of my code if you want to do your own experimenting. I hope this helps Jason -Original Message- From: Brugge, John To: '[EMAIL PROTECTED]' Sent: 04/26/2001 10:29 AM Subject: RE: (architectural issue/feature request) JavaBeans in Struts are n't flexible enough How you feel about type safety and having a/the compiler help you out will also play into your choice here. For all of the pain that creating JavaBean classes causes, they do create a well-defined interface that developers of JSPs can use to rely on to know what data is available. If all you're passing back is a Hashmap, then there needs to be an agreement between the JSP develper and the Action developer as to what that Hashmap will contain. If those developers happen to be the same person, that's usually not a problem (unless you tend to forget what you tell yourself ;-) If they are different people, then you might want the agreement to be more than just a verbal agreement during a hallway meeting. Which leads to documenting what the Hashmap will contain, which leads to having to maintain the documentation... Having JavaBeans as the format of your data also means that the JSP compiler can tell you when you try to refer to a property that isn't there, or is misspelled. The compiler can be your friend here. However, if your JSP refers to an entry in a Hashmap and gets it wrong, it's harder to track down the problem. Is the field on the form blank because there isn't any data there, or because you asked for the wrong entry name? There's definite flexibility advantages to using dynamic collections of data, but realize that it comes at a certain cost. John -Original Message- From: Stephen Schaub [SMTP:[EMAIL PROTECTED]] Sent: Thursday, April 26, 2001 6:52 AM To: [EMAIL PROTECTED] Subject: Re: (architectural issue/feature request) JavaBeans in Struts aren't flexible enough I have been pondering this very issue myself recently. For example, I would like to be able to display the results of a query in an HTML table. I don't want to have to create a Javabean to hold the attributes for the result set, because every time I want to tweak the result set, I have to 1. Add/remove/change getters and setters for the JavaBean to conform to the new result set 2. Change the code that takes the data from the result set and puts it in the JavaBean 3. Update the jsp to reflect the changes In your dynamic Javabean = hashmap approach, I could easily write a generic routine that takes a result set and converts it into a collection of dynamic Javabeans. Then, when I tweak the result set, the only thing I have to do is #3. I think I've read somewhere on the list about an effort to improve the scenario I just described, but there are a lot of other scenarios where dynamic JavaBeans would come in handy, and I hope it is officially addressed. Stephen Schaub - Original Message - From: Iraklis Kourtidis [EMAIL PROTECTED] Sent: Wednesday, April 25, 2001 12:27 PM Subject: (architectural issue/feature request) JavaBeans in Struts aren't flexible enough Hi all, I was wondering what your views on the following are: JavaBeans seem to only allow fixed
(architectural issue/feature request) JavaBeans in Struts aren't flexible enough
Hi all, I was wondering what your views on the following are: JavaBeans seem to only allow fixed properties (say foo and bar), and the tags that operate on them (e.g. bean:write) essentially call getters getFoo() and getBar(). However, this means that any time we're in the action class and we want to package some information to send to the JSP, we need to write a Java class with the appropriate properties and getters. This quickly becomes tiresome and causes code bloating; if I want to avoid scriptlets in my JSP, I have to use Javabeans, so for pretty much every Action class I need to add such a new Java class. A better way would be for Javabeans to be (essentially) some sort of subclass of java.util.Map, so that I can add properties at runtime. Here's some sample code: GenericJavabean jb = new GenericJavabean(); jb.addProperty(foo, value of foo); jb.addProperty(bar, value of bar); Then, there could be some other tag, say bean:write2 whose property attribute will not correspond to a getter function, but will instead call (internally) bean.getProperty(foo). In short, Javabeans, the current mechanism of passing information to the JSP for display purposes, are limiting because they have to be defined at *compile* time. It is not practical (in terms of efficiency and complexity) to add getter functions to a class at runtime (we've considered that), so we need to essentially create new Javabean classes. Am I the only one who gets bothered by this? I was wondering what the rest of you do. Do you just resign to creating new Java classes every time you want to put something on the request and send it to the JSP? thanks for your input, Iraklis
RE: (architectural issue/feature request) JavaBeans in Struts aren't flexible enough
I agree 100%. We do the same thing. Most of our DBAccessor classes fill a HashMap from the DB tables and we use bean.getProperty(name) to access them. This means we do not need to do maitenance on the classes to add new properties. Just add it to the database and use it in the JSP. This is much more extensible and maintainable. Frank Lawlor Athens Group, Inc.
Re: (architectural issue/feature request) JavaBeans in Struts aren't flexible enough
Have u thought of using XML for passing generic data around. A Tag using XPath can be used to access the data from this generic XML document. --- Iraklis Kourtidis [EMAIL PROTECTED] wrote: Hi all, I was wondering what your views on the following are: JavaBeans seem to only allow fixed properties (say foo and bar), and the tags that operate on them (e.g. bean:write) essentially call getters getFoo() and getBar(). However, this means that any time we're in the action class and we want to package some information to send to the JSP, we need to write a Java class with the appropriate properties and getters. This quickly becomes tiresome and causes code bloating; if I want to avoid scriptlets in my JSP, I have to use Javabeans, so for pretty much every Action class I need to add such a new Java class. A better way would be for Javabeans to be (essentially) some sort of subclass of java.util.Map, so that I can add properties at runtime. Here's some sample code: GenericJavabean jb = new GenericJavabean(); jb.addProperty(foo, value of foo); jb.addProperty(bar, value of bar); Then, there could be some other tag, say bean:write2 whose property attribute will not correspond to a getter function, but will instead call (internally) bean.getProperty(foo). In short, Javabeans, the current mechanism of passing information to the JSP for display purposes, are limiting because they have to be defined at *compile* time. It is not practical (in terms of efficiency and complexity) to add getter functions to a class at runtime (we've considered that), so we need to essentially create new Javabean classes. Am I the only one who gets bothered by this? I was wondering what the rest of you do. Do you just resign to creating new Java classes every time you want to put something on the request and send it to the JSP? thanks for your input, Iraklis __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
RE: (architectural issue/feature request) JavaBeans in Struts aren't flexible enough
Thanks for the response. Whether we use XML and access elements through XPath, or use a Hashmap of Hashmaps, the idea is still the same: Javabeans are not flexible enough to allow you to codify display information - which is an irony considering that's what Javabeans were created for. What we'll end up doing is creating a Hashmap of Hashmaps and then ditching the logic:iterate tag (which operates on a Javabean) and either (a) write our own tags that operate on our own objects, or (b) using scriptlets to perform the loops. If the developers of Struts were to add this as a standard feature, then different groups would not need to implement the same idea in a non-standard way... Just a thought. Iraklis -Original Message- From: Rajan Gupta [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 25, 2001 2:33 PM To: [EMAIL PROTECTED] Subject: Re: (architectural issue/feature request) JavaBeans in Struts aren't flexible enough Have u thought of using XML for passing generic data around. A Tag using XPath can be used to access the data from this generic XML document. --- Iraklis Kourtidis [EMAIL PROTECTED] wrote: Hi all, I was wondering what your views on the following are: JavaBeans seem to only allow fixed properties (say foo and bar), and the tags that operate on them (e.g. bean:write) essentially call getters getFoo() and getBar(). However, this means that any time we're in the action class and we want to package some information to send to the JSP, we need to write a Java class with the appropriate properties and getters. This quickly becomes tiresome and causes code bloating; if I want to avoid scriptlets in my JSP, I have to use Javabeans, so for pretty much every Action class I need to add such a new Java class. A better way would be for Javabeans to be (essentially) some sort of subclass of java.util.Map, so that I can add properties at runtime. Here's some sample code: GenericJavabean jb = new GenericJavabean(); jb.addProperty(foo, value of foo); jb.addProperty(bar, value of bar); Then, there could be some other tag, say bean:write2 whose property attribute will not correspond to a getter function, but will instead call (internally) bean.getProperty(foo). In short, Javabeans, the current mechanism of passing information to the JSP for display purposes, are limiting because they have to be defined at *compile* time. It is not practical (in terms of efficiency and complexity) to add getter functions to a class at runtime (we've considered that), so we need to essentially create new Javabean classes. Am I the only one who gets bothered by this? I was wondering what the rest of you do. Do you just resign to creating new Java classes every time you want to put something on the request and send it to the JSP? thanks for your input, Iraklis __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
Re: Feature request
hi all. i wonder who can help me resolve this problem. i am making a program based on struts. there are some circumstances that serval pages invoke one same action. and if some errors occured i want to show these errors in the previous page, but i cannot judge where the page is, cuz, there are many pages can invoke this action. thanks alot redbeebird.
RE: Feature request
One thing you can do is use a meta tag which contains the name of the jsp page. When you submit to the same action, and when you want to show errors to the input page, get this value out of the meta tag and forward to that page. I would strongly suggest you use a separate action class for every jsp . That way it woule be easier to maintain and debug. If you think all the pages perform almost the same action(s) i would suggest you use an inheritance mechanism. cheers, Amar.. -Original Message- From: alex [mailto:[EMAIL PROTECTED]] Sent: Monday, April 23, 2001 2:26 AM To: [EMAIL PROTECTED] Subject: Re: Feature request hi all. i wonder who can help me resolve this problem. i am making a program based on struts. there are some circumstances that serval pages invoke one same action. and if some errors occured i want to show these errors in the previous page, but i cannot judge where the page is, cuz, there are many pages can invoke this action. thanks alot redbeebird.
RE: Feature request
On Mon, 23 Apr 2001, Nanduri, Amarnath wrote: One thing you can do is use a meta tag which contains the name of the jsp page. When you submit to the same action, and when you want to show errors to the input page, get this value out of the meta tag and forward to that page. I would strongly suggest you use a separate action class for every jsp . That way it woule be easier to maintain and debug. If you think all the pages perform almost the same action(s) i would suggest you use an inheritance mechanism. You can actually have it both ways ... It is entirely legal to have more than one action element that uses the same Action class for the type attribute. Then, you still get the benefits of having all the code in one place, but you can also configure the input attribute of each action individually. If you do this, the standard validation performed by Struts will return to the corret input page, *and* you can do so programmatically from within the common Action by saying: String inputPath = mapping.getInput(); return (new ActionForward(inputPath)); cheers, Amar.. Craig
Re: Feature request
On Wed, 18 Apr 2001, James Howe wrote: I'm using the bean:write tag to add parameters to a dynamically generated URL used by some javascript on my JSP page. The problem with bean:write is that it doesn't URL encode the result. In general, this is probably a good thing. However, there are times when it would be nice to have the value encoded. Would it be possible to add an additional optional tag to WriteTag which would indicate whether the result was to be URLEncoded? The default would be false which would not require any changes in current code. Also, if there is an alternative way to get this functionality, please let me know. Unfortunately I can't use the link tag in this circumstance. Basically I have a line in my file which looks like this: input type=button ... onClick=self.location=foo.do?key='bean:write ...' In other words, I'm building up the parameters to the location URL based on property values in a particular bean. Thanks. Just to avoid confusion, are you talking about calling response.encodeURL() to make sure that the session id is included for clients that do not use cookies? If so, doing it only on the value of the key parameter (as shown in your example above) would not be sufficient even if it was supported -- you can only call encodeURL() with the *entire* URL you want to have encoded. However, that doesn't mean an encode=true option might not be useful. It would go along with the filter attribute (to filter out characters sensitive in HTML) that defaults to true. Craig
Feature request
I'm using the bean:write tag to add parameters to a dynamically generated URL used by some javascript on my JSP page. The problem with bean:write is that it doesn't URL encode the result. In general, this is probably a good thing. However, there are times when it would be nice to have the value encoded. Would it be possible to add an additional optional tag to WriteTag which would indicate whether the result was to be URLEncoded? The default would be false which would not require any changes in current code. Also, if there is an alternative way to get this functionality, please let me know. Unfortunately I can't use the "link" tag in this circumstance. Basically I have a line in my file which looks like this: input type="button" ... onClick="self.location="foo.do?key='bean:write ...'" In other words, I'm building up the parameters to the location URL based on property values in a particular bean. Thanks.
