RE: Design question: Model component using Business logic beans
Thanks for all that help. Anyway I guess I'll opt for using custom exception, like mentioned in an early post, in my business logic components. Seems easier to do in the interim and I wonder why i didn't think of that solution myself in the beginning... light...light... throw new MyBusinessLogicException(error.something.wrong) then I'll catch it in the calling execute() and generate an ActionError with an ActionMessage that I get from the Exceptions getMessage(). At least this works for me as long as I only have one exception message per problem because business logic won't be processed any further after that exception, of course. But why should I bother a user with a list of a 10 issues he did wrong at one time ;-) Let him try again and again until he got it... Should have read the usage notes in the view before clicking like mad. ;-) The simple input validation stuff can still be done in the form's validate() to notify about all those hundreds of dumb mistakes with ActionErros.add(). So the business logic usually shouldn't throw so many different problems at one time after validate(). I guess if my database connection is dead or the transaction had to rollback there's not much more to say than bad luck, try again and further processing makes no sense anyway. Michael -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Dienstag, 4. Februar 2003 04:49 To: Struts Users Mailing List Cc: [EMAIL PROTECTED] Subject: Re: Design question: Model component using Business logic beans On Mon, 3 Feb 2003, BaTien Duong wrote: Date: Mon, 3 Feb 2003 20:02:41 -0700 From: BaTien Duong [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Design question: Model component using Business logic beans We use chained exception from jdk1.4, commons.logging, and factoring out 4 components that are independent on Struts [MessageResources, MessageResourcesFactory, PropertyMessageResources, and PropertyMessageResourcesFactory]. I heard somewhere that these 4 components will eventually be in commons. ActionErrors and ActionError are used at the web layer. With many TilesAction(s) in 1 page, we coordinate the error handling of the page via the ERROR_KEY attribute of the request. The refactoring of the resources code to make it independent of Struts has been completed: http://jakarta.apache.org/builds/jakarta-commons/nightly/commons-resourc es However, it was too late in the 1.1 release cycle to make Struts use this new code itself. That will happen in a future version, but you can use commons-resources for your business tier message resource needs in the interim. Hope this may help. BaTien Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Design question: Model component using Business logic beans
Great. Thanks. BaTien - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, February 03, 2003 8:49 PM Subject: Re: Design question: Model component using Business logic beans On Mon, 3 Feb 2003, BaTien Duong wrote: Date: Mon, 3 Feb 2003 20:02:41 -0700 From: BaTien Duong [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Design question: Model component using Business logic beans We use chained exception from jdk1.4, commons.logging, and factoring out 4 components that are independent on Struts [MessageResources, MessageResourcesFactory, PropertyMessageResources, and PropertyMessageResourcesFactory]. I heard somewhere that these 4 components will eventually be in commons. ActionErrors and ActionError are used at the web layer. With many TilesAction(s) in 1 page, we coordinate the error handling of the page via the ERROR_KEY attribute of the request. The refactoring of the resources code to make it independent of Struts has been completed: http://jakarta.apache.org/builds/jakarta-commons/nightly/commons-resources However, it was too late in the 1.1 release cycle to make Struts use this new code itself. That will happen in a future version, but you can use commons-resources for your business tier message resource needs in the interim. Hope this may help. BaTien Craig - 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]
Design question: Model component using Business logic beans
Hi, currently I'm doing all my business logic in my Action classes. So besides the execute() method I might have some helper methods like populateFormBean() or I even put those stuff in the execute() directly if it wasn't to much. I have to do quite a lot of database queries to populate the form bean for the views. So actually the Action class should only do the controlling. So far so good and since things got to much in my Action classes I planned to move the code out into business logic beans to be accessed within execute() in order to do all the populate form stuff there. It's no problem to use a setter method to give my business logic beans the reference to my struts connection pool. Also fine to do it with the form bean. One thing, I'm having a bit trouble with migration is the ActionError stuff. Since most of the errors, like lost DB connections or the rollbacks of db transactions usually happen in my business logic beans then, I wonder what could be a good practice to pass those errors back to the Action execute() as I need those information in html:errors/ in my views. I guess if I import org.apache.struts.action.ActionError in my business logic, I'm doing a bad job to untie business logic from my controller, right? I guess it would be similar bad like including the servlet packages as mentioned as a warning in the Struts documentation. But on the other hand, it's quite useful to say errors.add(ActionErrors.GLOBAL_ERROR, new ActionError(error.something.happend)); in my business logic bean in order to log an error at the place where it occurs, right? But to use a setter method in my business logic bean writting all those errors and retrieving them with a getter method in the calling execute() requires importing Struts packages... Does anyone have good ideas how to untie business logic from all web-related stuff while still being able to pass errors in a sophisticated way back to the caller, like it can be done with the ActionError classes. I would appreciate any design hints from everybody who doesn't put all his business logic code into the Action classes or it's execute() method, since most books speak about not to tie business logic with the controller, but usually do the opposite in the sample code. ;-) Thanks Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Design question: Model component using Business logic beans
Michael, I have been putting my data logic into DAO classes that throw their own custom exceptions. Based on the exception thrown, I append to the ActionError object in the Action class. I don't think this answers the specific question you asked regarding use of the ActionError object in your business logic but it could be an alternative path that you could opt for. -Original Message- From: mech [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 1:05 PM To: [EMAIL PROTECTED] Subject: Design question: Model component using Business logic beans Hi, currently I'm doing all my business logic in my Action classes. So besides the execute() method I might have some helper methods like populateFormBean() or I even put those stuff in the execute() directly if it wasn't to much. I have to do quite a lot of database queries to populate the form bean for the views. So actually the Action class should only do the controlling. So far so good and since things got to much in my Action classes I planned to move the code out into business logic beans to be accessed within execute() in order to do all the populate form stuff there. It's no problem to use a setter method to give my business logic beans the reference to my struts connection pool. Also fine to do it with the form bean. One thing, I'm having a bit trouble with migration is the ActionError stuff. Since most of the errors, like lost DB connections or the rollbacks of db transactions usually happen in my business logic beans then, I wonder what could be a good practice to pass those errors back to the Action execute() as I need those information in html:errors/ in my views. I guess if I import org.apache.struts.action.ActionError in my business logic, I'm doing a bad job to untie business logic from my controller, right? I guess it would be similar bad like including the servlet packages as mentioned as a warning in the Struts documentation. But on the other hand, it's quite useful to say errors.add(ActionErrors.GLOBAL_ERROR, new ActionError(error.something.happend)); in my business logic bean in order to log an error at the place where it occurs, right? But to use a setter method in my business logic bean writting all those errors and retrieving them with a getter method in the calling execute() requires importing Struts packages... Does anyone have good ideas how to untie business logic from all web-related stuff while still being able to pass errors in a sophisticated way back to the caller, like it can be done with the ActionError classes. I would appreciate any design hints from everybody who doesn't put all his business logic code into the Action classes or it's execute() method, since most books speak about not to tie business logic with the controller, but usually do the opposite in the sample code. ;-) Thanks Michael - 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: Design question: Model component using Business logic beans
This is why Java has exceptions. In our case the backend mostly throws standard EJB exceptions (RemoveException, CreateException, etc), the business delegate translates those into our custom application exceptions, many of which are handled by our base action class, otherwise they bubble up to the specific action class and we generate the appropriate ActionErrors. -- Voytek Jarnot Quidquid latine dictum sit, altum viditur. -Original Message- From: mech [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 12:05 PM To: [EMAIL PROTECTED] Subject: Design question: Model component using Business logic beans Hi, currently I'm doing all my business logic in my Action classes. So besides the execute() method I might have some helper methods like populateFormBean() or I even put those stuff in the execute() directly if it wasn't to much. I have to do quite a lot of database queries to populate the form bean for the views. So actually the Action class should only do the controlling. So far so good and since things got to much in my Action classes I planned to move the code out into business logic beans to be accessed within execute() in order to do all the populate form stuff there. It's no problem to use a setter method to give my business logic beans the reference to my struts connection pool. Also fine to do it with the form bean. One thing, I'm having a bit trouble with migration is the ActionError stuff. Since most of the errors, like lost DB connections or the rollbacks of db transactions usually happen in my business logic beans then, I wonder what could be a good practice to pass those errors back to the Action execute() as I need those information in html:errors/ in my views. I guess if I import org.apache.struts.action.ActionError in my business logic, I'm doing a bad job to untie business logic from my controller, right? I guess it would be similar bad like including the servlet packages as mentioned as a warning in the Struts documentation. But on the other hand, it's quite useful to say errors.add(ActionErrors.GLOBAL_ERROR, new ActionError(error.something.happend)); in my business logic bean in order to log an error at the place where it occurs, right? But to use a setter method in my business logic bean writting all those errors and retrieving them with a getter method in the calling execute() requires importing Struts packages... Does anyone have good ideas how to untie business logic from all web-related stuff while still being able to pass errors in a sophisticated way back to the caller, like it can be done with the ActionError classes. I would appreciate any design hints from everybody who doesn't put all his business logic code into the Action classes or it's execute() method, since most books speak about not to tie business logic with the controller, but usually do the opposite in the sample code. ;-) Thanks Michael - 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: Design question: Model component using Business logic beans
I would have the business components handle their own DB connections (they shouldn't rely on the presentation layer for that). As far as your errors coming back to the presentation layer, I usually have a BusinessDelegate class that the action makes business calls into. That business delegate is responsible for catching exceptions like SQL, Remote, IO, etc. and then wrapping them into more application/business specific exceptions. Here is a good description of the BD pattern: http://java.sun.com/blueprints/corej2eepatterns/Patterns/BusinessDelegate.ht ml -Original Message- From: mech [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 12:05 PM To: [EMAIL PROTECTED] Subject: Design question: Model component using Business logic beans Hi, currently I'm doing all my business logic in my Action classes. So besides the execute() method I might have some helper methods like populateFormBean() or I even put those stuff in the execute() directly if it wasn't to much. I have to do quite a lot of database queries to populate the form bean for the views. So actually the Action class should only do the controlling. So far so good and since things got to much in my Action classes I planned to move the code out into business logic beans to be accessed within execute() in order to do all the populate form stuff there. It's no problem to use a setter method to give my business logic beans the reference to my struts connection pool. Also fine to do it with the form bean. One thing, I'm having a bit trouble with migration is the ActionError stuff. Since most of the errors, like lost DB connections or the rollbacks of db transactions usually happen in my business logic beans then, I wonder what could be a good practice to pass those errors back to the Action execute() as I need those information in html:errors/ in my views. I guess if I import org.apache.struts.action.ActionError in my business logic, I'm doing a bad job to untie business logic from my controller, right? I guess it would be similar bad like including the servlet packages as mentioned as a warning in the Struts documentation. But on the other hand, it's quite useful to say errors.add(ActionErrors.GLOBAL_ERROR, new ActionError(error.something.happend)); in my business logic bean in order to log an error at the place where it occurs, right? But to use a setter method in my business logic bean writting all those errors and retrieving them with a getter method in the calling execute() requires importing Struts packages... Does anyone have good ideas how to untie business logic from all web-related stuff while still being able to pass errors in a sophisticated way back to the caller, like it can be done with the ActionError classes. I would appreciate any design hints from everybody who doesn't put all his business logic code into the Action classes or it's execute() method, since most books speak about not to tie business logic with the controller, but usually do the opposite in the sample code. ;-) Thanks Michael - 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: Design question: Model component using Business logic beans
Thanks... custom exceptions... of course...! I must have been blind. Thanks for the light! Michael -Original Message- From: Pani, Gourav [mailto:[EMAIL PROTECTED]] Sent: Montag, 3. Februar 2003 19:11 To: 'Struts Users Mailing List' Subject: RE: Design question: Model component using Business logic beans Michael, I have been putting my data logic into DAO classes that throw their own custom exceptions. Based on the exception thrown, I append to the ActionError object in the Action class. I don't think this answers the specific question you asked regarding use of the ActionError object in your business logic but it could be an alternative path that you could opt for. -Original Message- From: mech [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 1:05 PM To: [EMAIL PROTECTED] Subject: Design question: Model component using Business logic beans Hi, currently I'm doing all my business logic in my Action classes. So besides the execute() method I might have some helper methods like populateFormBean() or I even put those stuff in the execute() directly if it wasn't to much. I have to do quite a lot of database queries to populate the form bean for the views. So actually the Action class should only do the controlling. So far so good and since things got to much in my Action classes I planned to move the code out into business logic beans to be accessed within execute() in order to do all the populate form stuff there. It's no problem to use a setter method to give my business logic beans the reference to my struts connection pool. Also fine to do it with the form bean. One thing, I'm having a bit trouble with migration is the ActionError stuff. Since most of the errors, like lost DB connections or the rollbacks of db transactions usually happen in my business logic beans then, I wonder what could be a good practice to pass those errors back to the Action execute() as I need those information in html:errors/ in my views. I guess if I import org.apache.struts.action.ActionError in my business logic, I'm doing a bad job to untie business logic from my controller, right? I guess it would be similar bad like including the servlet packages as mentioned as a warning in the Struts documentation. But on the other hand, it's quite useful to say errors.add(ActionErrors.GLOBAL_ERROR, new ActionError(error.something.happend)); in my business logic bean in order to log an error at the place where it occurs, right? But to use a setter method in my business logic bean writting all those errors and retrieving them with a getter method in the calling execute() requires importing Struts packages... Does anyone have good ideas how to untie business logic from all web-related stuff while still being able to pass errors in a sophisticated way back to the caller, like it can be done with the ActionError classes. I would appreciate any design hints from everybody who doesn't put all his business logic code into the Action classes or it's execute() method, since most books speak about not to tie business logic with the controller, but usually do the opposite in the sample code. ;-) Thanks Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Design question: Model component using Business logic beans
Hi, What i have been doing is the following, I wrote a simple class , which will hold all the errors in the business class (An ArrayList whoes each row is an error or message ) , and then send back this class to the Action class, and then in the Action class i have written logic to build ActionErrors , if there are any. So the call to my business class looks some thing like this ProcessError error = myBusinessClass.doIt(); where processerror is the place for holdin all messages The advantage i got buy doing this, is that i was able to pass on errors as well information messages to Action class which will forward them to the view Ashish --- John Espey [EMAIL PROTECTED] wrote: I would have the business components handle their own DB connections (they shouldn't rely on the presentation layer for that). As far as your errors coming back to the presentation layer, I usually have a BusinessDelegate class that the action makes business calls into. That business delegate is responsible for catching exceptions like SQL, Remote, IO, etc. and then wrapping them into more application/business specific exceptions. Here is a good description of the BD pattern: http://java.sun.com/blueprints/corej2eepatterns/Patterns/BusinessDelegate.ht ml -Original Message- From: mech [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 12:05 PM To: [EMAIL PROTECTED] Subject: Design question: Model component using Business logic beans Hi, currently I'm doing all my business logic in my Action classes. So besides the execute() method I might have some helper methods like populateFormBean() or I even put those stuff in the execute() directly if it wasn't to much. I have to do quite a lot of database queries to populate the form bean for the views. So actually the Action class should only do the controlling. So far so good and since things got to much in my Action classes I planned to move the code out into business logic beans to be accessed within execute() in order to do all the populate form stuff there. It's no problem to use a setter method to give my business logic beans the reference to my struts connection pool. Also fine to do it with the form bean. One thing, I'm having a bit trouble with migration is the ActionError stuff. Since most of the errors, like lost DB connections or the rollbacks of db transactions usually happen in my business logic beans then, I wonder what could be a good practice to pass those errors back to the Action execute() as I need those information in html:errors/ in my views. I guess if I import org.apache.struts.action.ActionError in my business logic, I'm doing a bad job to untie business logic from my controller, right? I guess it would be similar bad like including the servlet packages as mentioned as a warning in the Struts documentation. But on the other hand, it's quite useful to say errors.add(ActionErrors.GLOBAL_ERROR, new ActionError(error.something.happend)); in my business logic bean in order to log an error at the place where it occurs, right? But to use a setter method in my business logic bean writting all those errors and retrieving them with a getter method in the calling execute() requires importing Struts packages... Does anyone have good ideas how to untie business logic from all web-related stuff while still being able to pass errors in a sophisticated way back to the caller, like it can be done with the ActionError classes. I would appreciate any design hints from everybody who doesn't put all his business logic code into the Action classes or it's execute() method, since most books speak about not to tie business logic with the controller, but usually do the opposite in the sample code. ;-) Thanks Michael - 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] = A$HI$H __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Design question: Model component using Business logic beans
On Mon, 3 Feb 2003, mech wrote: One thing, I'm having a bit trouble with migration is the ActionError stuff. One of the things we wanted to do in Struts 1.1, but ran out of time for, was to switch to using commons-resources for the underlying message resources stuff, and then build ActionError and ActionMessage in Struts on top of that API. This would have made it trivially easy to use the same sort of thing for business logic error message management. Alas, we ran out of time ... In the interim, though, you might want to investigate using commons-resources directly for your business logic (so you don't have to depend directly on Struts APIs), and then write variants of the errors and messages tags to display them. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Design question: Model component using Business logic beans
Craig McClanhan wrote:
In the interim, though, you might want to investigate using
commons-resources directly for your business logic (so you don't have
to depend directly on Struts APIs)
+1
What I'm doing is having the business tier bring back a MessageList and
then just pumping it into ActionErrors. Next go around, we won't even
have to bother with that =:0)
protected void mergeAlerts(
HttpServletRequest request,
ActionErrors alerts,
MessageList list) {
if ((null != list) (!list.isEmpty())) {
Iterator properties = list.properties();
while (properties.hasNext()) {
String property = (String) properties.next();
Iterator messages = list.get(property);
// special case
if (MessageList.GLOBAL_MESSAGE_KEY.equals(property)) {
if (isStruts_1_0()) property =
ActionErrors.GLOBAL_ERROR;
else property = ActionMessages.GLOBAL_MESSAGE;
}
while (messages.hasNext()) {
Message message = (Message) messages.next();
// :FIXME: In 1.1, use ActionMessage
alerts.add(property, new ActionError(
message.getKey(),
message.getValues()
));
}
}
}
} // end mergeAlerts()
-T.
--
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: Design question: Model component using Business logic beans
We use chained exception from jdk1.4, commons.logging, and factoring out 4 components that are independent on Struts [MessageResources, MessageResourcesFactory, PropertyMessageResources, and PropertyMessageResourcesFactory]. I heard somewhere that these 4 components will eventually be in commons. ActionErrors and ActionError are used at the web layer. With many TilesAction(s) in 1 page, we coordinate the error handling of the page via the ERROR_KEY attribute of the request. Hope this may help. BaTien --- - Original Message - From: mech [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, February 03, 2003 11:05 AM Subject: Design question: Model component using Business logic beans Hi, currently I'm doing all my business logic in my Action classes. So besides the execute() method I might have some helper methods like populateFormBean() or I even put those stuff in the execute() directly if it wasn't to much. I have to do quite a lot of database queries to populate the form bean for the views. So actually the Action class should only do the controlling. So far so good and since things got to much in my Action classes I planned to move the code out into business logic beans to be accessed within execute() in order to do all the populate form stuff there. It's no problem to use a setter method to give my business logic beans the reference to my struts connection pool. Also fine to do it with the form bean. One thing, I'm having a bit trouble with migration is the ActionError stuff. Since most of the errors, like lost DB connections or the rollbacks of db transactions usually happen in my business logic beans then, I wonder what could be a good practice to pass those errors back to the Action execute() as I need those information in html:errors/ in my views. I guess if I import org.apache.struts.action.ActionError in my business logic, I'm doing a bad job to untie business logic from my controller, right? I guess it would be similar bad like including the servlet packages as mentioned as a warning in the Struts documentation. But on the other hand, it's quite useful to say errors.add(ActionErrors.GLOBAL_ERROR, new ActionError(error.something.happend)); in my business logic bean in order to log an error at the place where it occurs, right? But to use a setter method in my business logic bean writting all those errors and retrieving them with a getter method in the calling execute() requires importing Struts packages... Does anyone have good ideas how to untie business logic from all web-related stuff while still being able to pass errors in a sophisticated way back to the caller, like it can be done with the ActionError classes. I would appreciate any design hints from everybody who doesn't put all his business logic code into the Action classes or it's execute() method, since most books speak about not to tie business logic with the controller, but usually do the opposite in the sample code. ;-) Thanks Michael - 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: Design question: Model component using Business logic beans
On Mon, 3 Feb 2003, BaTien Duong wrote: Date: Mon, 3 Feb 2003 20:02:41 -0700 From: BaTien Duong [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Design question: Model component using Business logic beans We use chained exception from jdk1.4, commons.logging, and factoring out 4 components that are independent on Struts [MessageResources, MessageResourcesFactory, PropertyMessageResources, and PropertyMessageResourcesFactory]. I heard somewhere that these 4 components will eventually be in commons. ActionErrors and ActionError are used at the web layer. With many TilesAction(s) in 1 page, we coordinate the error handling of the page via the ERROR_KEY attribute of the request. The refactoring of the resources code to make it independent of Struts has been completed: http://jakarta.apache.org/builds/jakarta-commons/nightly/commons-resources However, it was too late in the 1.1 release cycle to make Struts use this new code itself. That will happen in a future version, but you can use commons-resources for your business tier message resource needs in the interim. Hope this may help. BaTien Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Business logic beans
The Struts User's Guide suggests that business logic be encapsulated in beans. Business logic modules are generally stateless, so one would generally implement them as static utility classes (with only static methods) or singletons (with private constructors and static factory methods), neither of which can be beans (which, by definition, have public constructors). To effectively manage stateless classes as beans (without re-instantiating them for each use), one would have to implement a lookup/mapping mechanism (an EJB-lite). Are the Struts developers suggesting that we develop such mechansisms? Might such a mechanism be slated for a future version of Struts? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Business logic beans
Perhaps the term business logic is misleading to an extent. To some, business logic in JavaBeans can mean that a JavaBean is a stateful representation of data in a database, that also has 'logic' in it for other means, such as validation, computation, etc. The term used like you suggest would fit in a model like stateless session beans, although something could be developed that isn't EJB. Now you mention a lookup/mapping mechanism, well look at Avalon (http://jakarta.apache.org/avalon). It has just such a mechanism. I believe in using both approaches, using beans as data and logic as well as stateless logic components. We use both for our eQ! product and (slowly) I'm convincing others that we should build it upon Avalon. Our Struts adapters and our scripting engine (both of which I wrote) use Avalon for looking up other components. I'm trying to convince the boss to let me port our persistence layer to use the same framework. - Robert -Original Message- From: Daniel Steinberg [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 20, 2002 12:06 PM To: '[EMAIL PROTECTED]' Subject: Business logic beans The Struts User's Guide suggests that business logic be encapsulated in beans. Business logic modules are generally stateless, so one would generally implement them as static utility classes (with only static methods) or singletons (with private constructors and static factory methods), neither of which can be beans (which, by definition, have public constructors). To effectively manage stateless classes as beans (without re-instantiating them for each use), one would have to implement a lookup/mapping mechanism (an EJB-lite). Are the Struts developers suggesting that we develop such mechansisms? Might such a mechanism be slated for a future version of Struts? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Question about struts application model (DataSource, Business Logic beans)
My problem is that access to the DataSource is through the servlet.findDataSource() call. Struts stores the JDBC Connection pools as servlet context attributes (in JSP terms, application-scope beans). You can also access them that way. If you do not specify a name in the Struts-config file, it uses a constant value. If you specify null to findDataSource(), it uses the same constant. But you can also access the pools using your own labels (or the Struts constant) without using the servlet method. Carles Pi-Sunyer wrote: Hi, I'm using Struts for a new application that I'm developing. I have a question about the separation between the Action classes and the Business Logic beans. My Business Logic beans are making database accesses to manipulate the underlying data model. I am planning on using the struts db connection pool, which is supplied through the DataSource. My problem is that access to the DataSource is through the servlet.findDataSource() call. How do I make the Business Logic beans unaware of the servlet/http layer (as suggested in the developers guide) while still making the DataSource available to the Business Logic beans? Do I have to pass a reference to the DataSource on every call the Business Logic beans (not an option that I like), or is there a cleaner way to do this? I also have a similar issues with logging services. I believe that a common way to solve this problem is to bind the DataSource to a jndi service. I am using tomcat 3.2.1, and I don't believe that this functionality is supplied in either Tomcat or Struts. Thank You, Carles
Question about struts application model (DataSource, Business Logic beans)
Title: Question about struts application model (DataSource, Business Logic beans) Hi, I'm using Struts for a new application that I'm developing. I have a question about the separation between the Action classes and the Business Logic beans. My Business Logic beans are making database accesses to manipulate the underlying data model. I am planning on using the struts db connection pool, which is supplied through the DataSource. My problem is that access to the DataSource is through the servlet.getDataSource() call. How do I make the Business Logic beans unaware of the servlet/http layer (as suggested in the developers guide) while still making the DataSource available to the Business Logic beans? Do I have to pass a reference to the DataSource on every call the Business Logic beans (not an option that I like), or is there a cleaner way to do this? I also have a similar issues with logging services. I believe that a common way to solve this problem is to bind the DataSource to a jndi service. I am using tomcat 3.2.1, and I don't believe that this functionality is supplied in either Tomcat or Struts. Thank You, Carles
Question about struts application model (DataSource, Business Logic beans)
Title: Question about struts application model (DataSource, Business Logic beans) Hi, I'm using Struts for a new application that I'm developing. I have a question about the separation between the Action classes and the Business Logic beans. My Business Logic beans are making database accesses to manipulate the underlying data model. I am planning on using the struts db connection pool, which is supplied through the DataSource. My problem is that access to the DataSource is through the servlet.findDataSource() call. How do I make the Business Logic beans unaware of the servlet/http layer (as suggested in the developers guide) while still making the DataSource available to the Business Logic beans? Do I have to pass a reference to the DataSource on every call the Business Logic beans (not an option that I like), or is there a cleaner way to do this? I also have a similar issues with logging services. I believe that a common way to solve this problem is to bind the DataSource to a jndi service. I am using tomcat 3.2.1, and I don't believe that this functionality is supplied in either Tomcat or Struts. Thank You, Carles
