RE: reality? CoR was Re: Struts or SpringFramework
At 3:03 PM -0500 2/19/05, David G. Friedman wrote: Joe, Your comment on testing CoR (Struts v1.3 or struts-chains) interests me. How would that be done? Do you suggest JUnit, TestNG, or something else? sI looked a little at StrutsTestCase and something about it bothers me, but what I can't exactly identify. Well, I guess I would just use JUnit. I've looked briefly at StrutsTestCase but never felt like plugging through to get the full test environment set up. The main point being that, if you know what your action is supposed to do, you can set up the simplest possible test environment to test it, rather than needing to set up an entire servlet container (or mock servlet container). Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: reality? CoR was Re: Struts or SpringFramework
At 11:49 PM -0500 2/18/05, Rick Reumann wrote: Joe Germuska wrote the following on 2/18/2005 5:37 PM: Well, I think you're blurring things here. When I talk about http-free components, I'm talking about your business logic, not your controllers (actions or commands). But for most developers, the business logic usually is already self contained somewhere else (hopefully we don't still don't see people coding JDBC from within their actions:). So for example, in an Action method someone might do: In so far as it is, then they've already achieved the http-free components. I'm afraid I don't believe that's as widespread as you do, although I'm not saying that no one has figured it out. What I seem to be seeing in the examples of CoR and Struts is the removal of the Action class and instead using a chain of Commands. Hm. I don't think many people are really pushing this as the future or best practice, but just pointing out that it's available. At least, that's how I feel about it. This is fine and I like the idea because it does allow for the concept of coding pre and post processors without IoC, but I still each of them having a lot of ties to the Servlet model. For example, maybe before leaving all of the typical CRUD events you need to call a populate Command that will populate your Request with some needed Lists for drop downs. No longer do you have to remember to make sure to include the populate(..) method call in each of your dispatch methods since you could just add that to the end of the chain. Well, if we postulate (as ActionContext does) that any request/response model will have a few maps for scopes (request/session/application) and another for request parameters, then you've already insulated yourself against the servlet API. Now, in your test class, you can just make a Map with the parameters you want to handle, without having to mess around with MockServletThis and MockServletThat. I'm just wondering if someone could provide some more examples of possible real world benefits of the CoR used to replace Actions. I can see the standard chain looking like... -somePreCommand (probably does your initially logging) -someActionCommand (replaces the meat of your Action dispatch method) -somePostCommand (maybe ensures some things are put into Req scope) I'd be curious on seeing some other examples of the possible Commands you would likely see in a typical web app? Thanks again for any additional light. I'm afraid we will still have to wait and see. What I would suggest first would be replacing the kind of chaining people currently do with requestDispatcher.forward(/to/another/StrutsAction.do) -- say to have one command for processing a submitted form and another for prepping the page -- but I'm actually thinking I'd prefer to be able to hang Commands off of ActionForwards -- the net result would be the same, but you'd have less tangled configuration if you simply said always execute this command 'on the way' to this forward rather than having to repeat that configuration for each action mapping that might need that page preparation behavior. Again, I think using commons-chain Commands (or Chains) in place of an Action have yet to prove their superiority. The biggest gain I would see out of it would be a further step towards reducing dependencies on the HTTP API, which, despite your skepticism ;-) I think is a worthy goal in itself. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: reality? CoR was Re: Struts or SpringFramework
Joe Germuska wrote the following on 2/19/2005 11:56 AM:
The biggest gain I would
see out of it would be a further step towards reducing dependencies on
the HTTP API, which, despite your skepticism ;-) I think is a worthy
goal in itself.
Oh trust me, I'm all for it reducing dependency on the HTTP API and I
really like the introduction for CoR, 100%. That's why I really like the
backing-bean concept of JSF. Without Struts having that, yes, I am
skeptical that you'll end up being that far removed from the HTTP API.
The biggest 'ugliness' in my opinion that I don't like looking at in
even my own Struts apps is the application logic stuff that gets put in
my Actions. Somewhere down the line, something comes up and you end up
having to call different business class methods based on ActionForm
parameters or session/request parameters.
For example
someDispatchMethod(...) {
(User)request.getSession().getAttribute(user);
if ( user.isSomething() ) {
//call this business method
//if you get something odd back...
//we need to add some flag into scope
reuqest.setAttribute(something,whatever);
else {
//do the usual
//call business method
//look at return and realize we need to set up the next
//page we go to with something unique bc X condition was met
//if something
//so call some other business method to get me this List and pop
request.setAttribute(neededList, list )
//else maybe return from business was fine no need to set up request
//leave
}
We can say we don't like this stuff above and I agree, it's ugly. But it
does come up. Sometimes I push this kind of stuff off to an intermediate
class but since this class still is totally struts and HTTP dependent it
doesn't help me that much. (Again I think using a regular backing bean
like JSF does goes a long way to making this all much cleaner, but I'm
not willing to start using JSF full time for anything yet, since Struts
does the job for me.)
--
Rick
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: reality? CoR was Re: Struts or SpringFramework
Obviously it's tough not to be too academic when you're not actually
cutting code, but the general tack I like to take is to wrap those
dependencies in classes of my own. So, in this case:
someDispatchMethod(...) {
(User)request.getSession().getAttribute(user);
you could instead have arranged to use a trivial subclass of
ComposableRequestProcessor which overrides the contextInstance
method to produce RicksOwnActionContext which implements the
ActionContext interface, but which also has this method:
public User getUser() {
return (User) this.getSessionScope().get(user);
}
Is this a huge gain? I don't know. But it's possible. And it means
that you could test your class without needing to have a mock
HttpServletRequest.
if ( user.isSomething() ) {
//call this business method
//if you get something odd back...
//we need to add some flag into scope
reuqest.setAttribute(something,whatever);
else {
//do the usual
//call business method
//look at return and realize we need to set up the next
//page we go to with something unique bc X condition was met
//if something
//so call some other business method to get me this List and pop
request.setAttribute(neededList, list )
//else maybe return from business was fine no need to set up request
//leave
}
For these, I am moving towards defining simple beans which represent
a use case scope and which, like the example above, provide
typesafety and encapsulation. So, instead of sticking two different
things into the request under different keys, you'd put only one
(this UseCaseBean), and it would manage the references to any of the
things your case is likely to need. (If it's a significant use case,
then perhaps you'd keep it in session scope instead.) Then, rather
than having to do a whole lot of coordination so that everyone knows
the right names (and sometimes scopes) of attributes, you just ensure
that the one bean is in the right place at the right time, and
everything else operates purely on a need-to-know basis.
Joe
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
Narrow minds are weapons made for mass destruction -The Ex
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: reality? CoR was Re: Struts or SpringFramework
snip
On Fri, 18 Feb 2005 15:44:18 -0500, Rick Reumann
I'm wondering if you
could do something like this in a Command...
public boolean execute(Context context) throws Exception{
context.setAttribute(someList,someList);
...
}
and then from a JSP be able to somehow have reference to this context...
c:forEach items=${handleToConntext.emloyees}
Can you do the above?
/snip
I would encourage people to look for an architecture that maximizes a
use of the Strategy Design Pattern:
public class DefaultSomeInterface implements SomeInterface {
private Helper helper;
public void setHelper(Helper helper) {
this.helper = helper;
}
public void doStuff() {
//
String value = helper.addOrSomething(args);
//'
}
}
You can lead a horse to water but you cannot make it float on its back.
Heaven has changed. The Sky now goes all the way to our feet.
~Dakota Jack~
This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: reality? CoR was Re: Struts or SpringFramework
I probably should have intimated more strongly that SomeInterface
could be Action. Helper could be Command/Chain, etc.
On Sat, 19 Feb 2005 10:31:26 -0800, Dakota Jack [EMAIL PROTECTED] wrote:
snip
On Fri, 18 Feb 2005 15:44:18 -0500, Rick Reumann
I'm wondering if you
could do something like this in a Command...
public boolean execute(Context context) throws Exception{
context.setAttribute(someList,someList);
...
}
and then from a JSP be able to somehow have reference to this context...
c:forEach items=${handleToConntext.emloyees}
Can you do the above?
/snip
I would encourage people to look for an architecture that maximizes a
use of the Strategy Design Pattern:
public class DefaultSomeInterface implements SomeInterface {
private Helper helper;
public void setHelper(Helper helper) {
this.helper = helper;
}
public void doStuff() {
//
String value = helper.addOrSomething(args);
//'
}
}
You can lead a horse to water but you cannot make it float on its back.
Heaven has changed. The Sky now goes all the way to our feet.
~Dakota Jack~
This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation.
--
You can lead a horse to water but you cannot make it float on its back.
Heaven has changed. The Sky now goes all the way to our feet.
~Dakota Jack~
This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts or SpringFramework
Thanks, Vic. I would suggest that they are not competitors for the same job under normal circumstances. IoC might be seen as for a plumbing strategy (architecture), e.g. Action, RequestProcessor, ActionForm, etc. as interfaces and CoR for implementation strategies (application). I personally would not use CoR where IoC was needed or where AOP was needed. I hope I am not being repetitive, but I think that having RequestProcessor as an interface and using CoR in a default implementation of that interface would be good. Am I clear? Am I nuts? ;-) On Fri, 18 Feb 2005 18:01:32 -0600, Vic [EMAIL PROTECTED] wrote: So the short answer is... I can't! You use a QuickSort and a BubleSort in 2 diferent scenarios, one is good for semi sorted data, the other for large sorts. I used IoC to organize and configure classes after the fact. With CoR I can re-use comands in a diferent context and still be able to configure them. Seemed to me like 2 was too much, one had to go. It's possible that IoC will be added in later versions of Struts, but I likely will chose to use only to use CoR. This is a begining of Vi vs Emacs that will last for years. Spring is more complicated than Struts 1.3... hmmm. .V Shey Rab Pawo wrote: What I don't quite see is how they or CoR replace IoC. IoC seems to me to address a completely different and consistent set of solutions to a completely different and consistent set of problems. So, if you could explain this, I would appreciate it. -- Forums, Boards, Blogs and News in RiA http://www.boardVU.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. Heaven has changed. The Sky now goes all the way to our feet. ~Dakota Jack~ This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts or SpringFramework
Does it mean I'm going made if Jack starts making sense? :) Regards, David -Original Message- From: Dakota Jack [mailto:[EMAIL PROTECTED] Sent: Saturday, February 19, 2005 2:14 PM To: Struts Users Mailing List Subject: Re: Struts or SpringFramework Thanks, Vic. I would suggest that they are not competitors for the same job under normal circumstances. IoC might be seen as for a plumbing strategy (architecture), e.g. Action, RequestProcessor, ActionForm, etc. as interfaces and CoR for implementation strategies (application). I personally would not use CoR where IoC was needed or where AOP was needed. I hope I am not being repetitive, but I think that having RequestProcessor as an interface and using CoR in a default implementation of that interface would be good. Am I clear? Am I nuts? ;-) On Fri, 18 Feb 2005 18:01:32 -0600, Vic [EMAIL PROTECTED] wrote: So the short answer is... I can't! You use a QuickSort and a BubleSort in 2 diferent scenarios, one is good for semi sorted data, the other for large sorts. I used IoC to organize and configure classes after the fact. With CoR I can re-use comands in a diferent context and still be able to configure them. Seemed to me like 2 was too much, one had to go. It's possible that IoC will be added in later versions of Struts, but I likely will chose to use only to use CoR. This is a begining of Vi vs Emacs that will last for years. Spring is more complicated than Struts 1.3... hmmm. .V Shey Rab Pawo wrote: What I don't quite see is how they or CoR replace IoC. IoC seems to me to address a completely different and consistent set of solutions to a completely different and consistent set of problems. So, if you could explain this, I would appreciate it. -- Forums, Boards, Blogs and News in RiA http://www.boardVU.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. Heaven has changed. The Sky now goes all the way to our feet. ~Dakota Jack~ This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. - 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: Struts or SpringFramework
Er... mad, not made. See, I got so excited about understanding someone that I forgot to check my syntax (spellcheck missed it, how evil!). Jokingly: Can StrutsTestCase be used to syntax my grammar before posting to the list? Regards, David -Original Message- From: David G. Friedman [mailto:[EMAIL PROTECTED] Sent: Saturday, February 19, 2005 2:50 PM To: Struts Users Mailing List Subject: RE: Struts or SpringFramework Does it mean I'm going made if Jack starts making sense? :) Regards, David -Original Message- From: Dakota Jack [mailto:[EMAIL PROTECTED] Sent: Saturday, February 19, 2005 2:14 PM To: Struts Users Mailing List Subject: Re: Struts or SpringFramework Thanks, Vic. I would suggest that they are not competitors for the same job under normal circumstances. IoC might be seen as for a plumbing strategy (architecture), e.g. Action, RequestProcessor, ActionForm, etc. as interfaces and CoR for implementation strategies (application). I personally would not use CoR where IoC was needed or where AOP was needed. I hope I am not being repetitive, but I think that having RequestProcessor as an interface and using CoR in a default implementation of that interface would be good. Am I clear? Am I nuts? ;-) On Fri, 18 Feb 2005 18:01:32 -0600, Vic [EMAIL PROTECTED] wrote: So the short answer is... I can't! You use a QuickSort and a BubleSort in 2 diferent scenarios, one is good for semi sorted data, the other for large sorts. I used IoC to organize and configure classes after the fact. With CoR I can re-use comands in a diferent context and still be able to configure them. Seemed to me like 2 was too much, one had to go. It's possible that IoC will be added in later versions of Struts, but I likely will chose to use only to use CoR. This is a begining of Vi vs Emacs that will last for years. Spring is more complicated than Struts 1.3... hmmm. .V Shey Rab Pawo wrote: What I don't quite see is how they or CoR replace IoC. IoC seems to me to address a completely different and consistent set of solutions to a completely different and consistent set of problems. So, if you could explain this, I would appreciate it. -- Forums, Boards, Blogs and News in RiA http://www.boardVU.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. Heaven has changed. The Sky now goes all the way to our feet. ~Dakota Jack~ This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. - 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: reality? CoR was Re: Struts or SpringFramework
Joe,
Your comment on testing CoR (Struts v1.3 or struts-chains) interests me.
How would that be done? Do you suggest JUnit, TestNG, or something else? sI
looked a little at StrutsTestCase and something about it bothers me, but
what I can't exactly identify.
public User getUser() {
return (User) this.getSessionScope().get(user);
}
Is this a huge gain? I don't know. But it's possible.
And it means that you could test your class without
needing to have a mock HttpServletRequest.
Regards,
David
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts or SpringFramework
Yes! ///;-) On Sat, 19 Feb 2005 14:49:38 -0500, David G. Friedman [EMAIL PROTECTED] wrote: Does it mean I'm going made if Jack starts making sense? :) Regards, David -Original Message- From: Dakota Jack [mailto:[EMAIL PROTECTED] Sent: Saturday, February 19, 2005 2:14 PM To: Struts Users Mailing List Subject: Re: Struts or SpringFramework Thanks, Vic. I would suggest that they are not competitors for the same job under normal circumstances. IoC might be seen as for a plumbing strategy (architecture), e.g. Action, RequestProcessor, ActionForm, etc. as interfaces and CoR for implementation strategies (application). I personally would not use CoR where IoC was needed or where AOP was needed. I hope I am not being repetitive, but I think that having RequestProcessor as an interface and using CoR in a default implementation of that interface would be good. Am I clear? Am I nuts? ;-) On Fri, 18 Feb 2005 18:01:32 -0600, Vic [EMAIL PROTECTED] wrote: So the short answer is... I can't! You use a QuickSort and a BubleSort in 2 diferent scenarios, one is good for semi sorted data, the other for large sorts. I used IoC to organize and configure classes after the fact. With CoR I can re-use comands in a diferent context and still be able to configure them. Seemed to me like 2 was too much, one had to go. It's possible that IoC will be added in later versions of Struts, but I likely will chose to use only to use CoR. This is a begining of Vi vs Emacs that will last for years. Spring is more complicated than Struts 1.3... hmmm. .V Shey Rab Pawo wrote: What I don't quite see is how they or CoR replace IoC. IoC seems to me to address a completely different and consistent set of solutions to a completely different and consistent set of problems. So, if you could explain this, I would appreciate it. -- Forums, Boards, Blogs and News in RiA http://www.boardVU.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. Heaven has changed. The Sky now goes all the way to our feet. ~Dakota Jack~ This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. Heaven has changed. The Sky now goes all the way to our feet. ~Dakota Jack~ This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts or SpringFramework
Hello, You can use both of them at same time, for example using Struts for weblayer and Spring for persistence layer (if you have one..) Regards marco -Original Message- From: Eric Chow [mailto:[EMAIL PROTECTED] Sent: 18 February 2005 01:18 To: Struts User List Subject: Struts or SpringFramework Hello, I have used Struts for four years. And I am evaluating SpinrgFramework. Anybody can give me some suggestions on them ?? Eric - 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: Struts or SpringFramework
Marco Mistroni wrote: You can use both of them at same time, for example using Struts for weblayer and Spring for persistence layer (if you have one..) Huh? I thought Spring didn't have it's own persistence layer (as far as I know, Spring persists through iBatis or Hibernate). Vamsee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts or SpringFramework
HI, Yes I was not clear.., I was meaning, handle your persistence layer using Spring along With Hibernate/ whatever spring supports... :-) Sorry for being so short :-) Regards marco -Original Message- From: Vamsee Kanakala [mailto:[EMAIL PROTECTED] Sent: 18 February 2005 09:23 To: Struts Users Mailing List Subject: Re: Struts or SpringFramework Marco Mistroni wrote: You can use both of them at same time, for example using Struts for weblayer and Spring for persistence layer (if you have one..) Huh? I thought Spring didn't have it's own persistence layer (as far as I know, Spring persists through iBatis or Hibernate). Vamsee. - 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: Struts or SpringFramework
Hello, Whats the advantage of using spring for your persitence layer when you can do it with struts? Thanks On Fri, 18 Feb 2005 09:36:28 -, Marco Mistroni [EMAIL PROTECTED] wrote: HI, Yes I was not clear.., I was meaning, handle your persistence layer using Spring along With Hibernate/ whatever spring supports... :-) Sorry for being so short :-) Regards marco -Original Message- From: Vamsee Kanakala [mailto:[EMAIL PROTECTED] Sent: 18 February 2005 09:23 To: Struts Users Mailing List Subject: Re: Struts or SpringFramework Marco Mistroni wrote: You can use both of them at same time, for example using Struts for weblayer and Spring for persistence layer (if you have one..) Huh? I thought Spring didn't have it's own persistence layer (as far as I know, Spring persists through iBatis or Hibernate). Vamsee. - 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: Struts or SpringFramework
Richard Reyes wrote: Whats the advantage of using spring for your persitence layer when you can do it with struts? I had the good fortune to read Rod Johnson Juergen Hoeller's J2EE developement without EJB. From what I can glean from the book, Spring is much more than a MVC or a Persistenece layer. As Dakota Jack already said, it's a light-weight j2ee application framework. It uses 'Dependency Injection' or 'Inversion of Control' to make configuration and testing of web-apps much more simpler. Good starting point: http://www.martinfowler.com/articles/injection.html Also, it uses AOP to handle security concerns and other aspects. A lot of the book is also devoted to giving arguments to support EJB is way too complex for most web applications and open-source alternatives are easier to use and maintain and don't distribute your objects. Ofcourse I can't do full justice to the book, but it convinced me enough to try out Spring sometime in my next project. Regards, Vamsee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts or SpringFramework
Kris, as others have already mentioned, you can use Struts and Spring together. Since you have four years of Struts you can leverage that knowlege in the presentation layer and use Spring for a light-weight container in the business/integration tier allowing it to provide services such as declarative transaction and dependency injection. Spring comes with built in support for Hibernate and JDBC. It has a terrific built in API for working with various persistence solutions. Spring allows you to wire up dependencies between those objects which collaborate with one another within a configuration file. These dependencies are established at application start up time so that your objects are all ready to go when they are invoked. Spring also provides the ability to declaratively define objects as singletons or as prototypes (non-singletons). The thing that impressed me the most was that it is non-intrusive. Your objects don't have to extend or implement any special interfaces to work with Spring (although they can implement certain Spring life cycle interfaces if they want to). To learn more about how to use Spring, you might want to download the Spring reference manual. Its easy to read and understand and will give you some great insight into those features it provides. http://www.springframework.org/docs/reference/index.html Good luck. /robert Eric Chow wrote: Hello, I have used Struts for four years. And I am evaluating SpinrgFramework. Anybody can give me some suggestions on them ?? Eric - 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: Struts or SpringFramework
Without exception, every developer I have talked to personally that has tried SpringMVC said it was way more complex than struts, and ended up going back (almost all the way) to struts. What I have heard is a killer combination is Spring-managed Struts. In this permutation, you use struts with a Spring-based request processor instead of the default struts one. Then, you get much of the benefit of using spring (managed beans, IoC, etc...) and continue to use vanilla struts for the remainder of your application. I have been hoping to use this model for the last month or so, but have been too busy to try it myself. Stupid job. ;-) Larry On Thu, 17 Feb 2005 17:34:24 -0800, Dakota Jack [EMAIL PROTECTED] wrote: I assume you know this but just in case: Struts (a web application framework) is not a rival not for the Spring Framework (which is a lightweight j2ee applicatoin framework). I assume, then, that you must mean the standard web application framework that comes with Spring? Is that right? Jack snip On Fri, 18 Feb 2005 09:17:33 +0800, Eric Chow I have used Struts for four years. And I am evaluating SpinrgFramework. Anybody can give me some suggestions on them ?? Eric /snip -- You can lead a horse to water but you cannot make it float on its back. Heaven has changed. The Sky now goes all the way to our feet. ~Dakota Jack~ This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. - 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: Struts or SpringFramework
Richard Reyes wrote: Hello, Whats the advantage of using spring for your persitence layer when you can do it with struts? Well, you don't really use Spring for your persistence layer, you use Spring to simplify using your persistence layer, whether it's Hibernate, Ibatis, or straight JDBC. It provides nice convenience methods, a way to transparently manage Sessions, Datasources, etc, declarative transactions, etc. You can use it WITH struts (you don't really do a persistence layer in struts do you?). In fact, it provides some nice conveniences for Struts. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts or SpringFramework
You can put your toe in Spring(Tapestry or JSF) and see how it feels becuase you know the Struts side. Or. you can start doing commons-chain now! And then plug it into anything. What Ted Husted said on dev list was words to the effect: people should be no longer be writing Struts applications. They should be writing commons-chains (CoR) applications. Then just plug it into Struts. . I chose to write commons-chain applications, that I plug into... Swing. .V Larry Meadors wrote: Without exception, every developer I have talked to personally that has tried SpringMVC said it was way more complex than struts, and ended up going back (almost all the way) to struts. What I have heard is a killer combination is Spring-managed Struts. In this permutation, you use struts with a Spring-based request processor instead of the default struts one. Then, you get much of the benefit of using spring (managed beans, IoC, etc...) and continue to use vanilla struts for the remainder of your application. I have been hoping to use this model for the last month or so, but have been too busy to try it myself. Stupid job. ;-) Larry -- Forums, Boards, Blogs and News in RiA http://www.boardVU.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts or SpringFramework
You seem to be thinking of upgrading from Struts while also deploying your web application in Spring. If you search this list, I believe you will find Mr. McClanahan saying that Struts is inferior to other existing request based MVC web frameworks. You might want to chase that down and to consider the alternatives. I cannot remember if he cited the web framework that comes with Spring or not. On Fri, 18 Feb 2005 09:17:33 +0800, Eric Chow [EMAIL PROTECTED] wrote: Hello, I have used Struts for four years. And I am evaluating SpinrgFramework. Anybody can give me some suggestions on them ?? Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- The radiance of all the stars does not equal a sixteenth part of the moon's radiance, likewise, good deeds giving us merit, all these do not equal a sixteenth part of the merit of loving-kindness.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts or SpringFramework
One approach to building applications that is supported by Struts 1.3+ is to write a commons-chain based application and plug it into Struts, however, that is only one approach while the existing Action class approach still exists and will exist for a very long time. Personally, I favor using either MappingDispatchAction, Struts Flow, or a custom POJO action class ala JSF. Therefore, Joe's statement is correct. If you never messed with RequestProcessor, the chain-based processor implementation will not affect you. It is kinda confusing, but the chain used for Struts is not the same chain that Ted was talking about, and in fact, I believe we are trying to separate the two to ensure a clean separation between Struts and application logic. Don On Fri, 18 Feb 2005 09:33:16 -0700, Wendy Smoak [EMAIL PROTECTED] wrote: From: Vic [EMAIL PROTECTED] Or. you can start doing commons-chain now! And then plug it into anything. What Ted Husted said on dev list was words to the effect: people should be no longer be writing Struts applications. They should be writing commons-chains (CoR) applications. Then just plug it into Struts. . Wait... I think it was Joe who said that if we had never cared about the Struts RequestProcessor up to now, we could ignore 'chain' since it is just replacing things behind the scenes inside Struts. Is this something different? -- Wendy - 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: Struts or SpringFramework
Exactly, Wendy, what is intended is very hard to track. Jack snip Wait... I think it was Joe who said that if we had never cared about the Struts RequestProcessor up to now, we could ignore 'chain' since it is just replacing things behind the scenes inside Struts. Is this something different? -- Wendy /snip -- You can lead a horse to water but you cannot make it float on its back. Heaven has changed. The Sky now goes all the way to our feet. ~Dakota Jack~ This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts or SpringFramework
Thanks, Don. Much appreciated. The problem is that there is no consistency on this. I tried, for example, to discuss naming and the Struts chain and got severely stomped on for having the stupidity to think that Struts and Commons could be considered seperately. I have a real interest in chain, IF it is intended to make the request processor pluggable, because I would like to use the standard Struts with some changes. For example, I would like to get away from the way the request processor treats multipart form uploads, tying you to an implemenation I don't care for that much. Because business decisions need to be made, whether people care or not, it would be good if one could tell what is intended for Struts 1.3 in fact. I hope that this does not once again generate heat instead of light. Unless someone says something different, I am going to assume that this is a correct statement of what is happening. Maybe I am not understanding you correctly, however, since I am not sure that you are talking about 1.3 essentially changing only the request processor or something else. I know I don't have any difficulty in the uptake department and find the whole discussion very confusing and confused. Do you have a statement somewhere that you would take to be a bit definitive. (Please don't tell me this is open source and that anything can happen, etc.) snip On Fri, 18 Feb 2005 08:50:02 -0800, Don Brown [EMAIL PROTECTED] wrote: One approach to building applications that is supported by Struts 1.3+ is to write a commons-chain based application and plug it into Struts, however, that is only one approach while the existing Action class approach still exists and will exist for a very long time. Personally, I favor using either MappingDispatchAction, Struts Flow, or a custom POJO action class ala JSF. Therefore, Joe's statement is correct. If you never messed with RequestProcessor, the chain-based processor implementation will not affect you. /snip So, from the below I understand that you have one sort of chain supplanting the present request processor in order to make that pluggable (right?) and another chain that will be used in the application (model?) logic (right?). snip It is kinda confusing, but the chain used for Struts is not the same chain that Ted was talking about, and in fact, I believe we are trying to separate the two to ensure a clean separation between Struts and application logic. /snipo Don /snip So, the present talk about chains vis-a-vis Ted is just some work on applilcation logic that is essentially unrelated to Struts? Is this right? And that is to be distinguished from chain talk that is about the logic in the request processor? Is this right? If this is all correct or not, this is reallly confusing. If there is an application logic application being built that has nothing really to do with Struts, that is cool. How do people intend to discuss these things so that a reader on the lists can tell what you are talking about without having been involved in the inner sanctum? Thanks. (Please refrain from flames on this. I really would like to tell what is happening and am tired of the wrestling.) Jack -- You can lead a horse to water but you cannot make it float on its back. Heaven has changed. The Sky now goes all the way to our feet. ~Dakota Jack~ This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts or SpringFramework
At 8:50 AM -0800 2/18/05, Don Brown wrote: One approach to building applications that is supported by Struts 1.3+ is to write a commons-chain based application and plug it into Struts, however, that is only one approach while the existing Action class approach still exists and will exist for a very long time. Personally, I favor using either MappingDispatchAction, Struts Flow, or a custom POJO action class ala JSF. Therefore, Joe's statement is correct. If you never messed with RequestProcessor, the chain-based processor implementation will not affect you. It is kinda confusing, but the chain used for Struts is not the same chain that Ted was talking about, and in fact, I believe we are trying to separate the two to ensure a clean separation between Struts and application logic. Yes. If I may, what Ted, Vic, Don, and I are saying is that you should treat Struts as an adapter between HTTP requests and an application which has nothing to do with HTTP. Minimal business logic should be embedded in the Struts layer, whether embedded in Actions, ActionForms, or chain Commands. Struts should do input validation, interface flow control, and translation from HTTP request parameters to application objects and from application objects and data to HTML views. Ted and Vic, in particular, are saying that commons-chain is a good way to write one of these applications-which-has-nothing-to-do-with-HTTP. In my experience, relevant to this thread, Spring Framework is a pretty nice way to assemble one of these applications-w-h-n-t-d-w-H; I just used a PlugIn to invoke Spring to assemble the application and put it into the Servlet Application Scope. One could certainly use both together, but I haven't had cause to design a big app since I've become more familiar with commons Chain (and I am still quite a novice user of Spring.) I hope I didn't distort anyone's statements or views! Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts or SpringFramework
Vic wrote: You can put your toe in Spring(Tapestry or JSF) and see how it feels becuase you know the Struts side. Or. you can start doing commons-chain now! And then plug it into anything. What Ted Husted said on dev list was words to the effect: people should be no longer be writing Struts applications. They should be writing commons-chains (CoR) applications. Then just plug it into Struts. . I chose to write commons-chain applications, that I plug into... Swing. .V Hello Vic: I have looked at jdic and JNLP application and want to explore further for off-line applications. Hope you may share your experience in using commons-chain in Swing (and possibly with Spring IoC) under JDesktop Integration Component. This is your favorite topic isn't it? BaTien DBGROUPS Larry Meadors wrote: Without exception, every developer I have talked to personally that has tried SpringMVC said it was way more complex than struts, and ended up going back (almost all the way) to struts. What I have heard is a killer combination is Spring-managed Struts. In this permutation, you use struts with a Spring-based request processor instead of the default struts one. Then, you get much of the benefit of using spring (managed beans, IoC, etc...) and continue to use vanilla struts for the remainder of your application. I have been hoping to use this model for the last month or so, but have been too busy to try it myself. Stupid job. ;-) Larry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts or SpringFramework
The inherent problem with following a developer list is you will hear many different opinions, usually with the goal of coming to an agreed solution or direction, but that direction, once agreed upon, usually isn't clearly laid out. If you want clear direction, look at the user guide, release notes, or one of the many Struts books. If you want to see all the discussion, debate, and exploration that is required to arrive at those directions, then follow the dev list. :) I felt you described the goal of using chain in the Request Processor very well - a pluggable process that the user can customize to their hearts content. If you want to handle population through OGNL, then rewrite the PopulateActionForm command. If you want to add a command that pulls a user profile out of the database and puts it in the request, go ahead and stick it in there. If you don't want to use Actions at all, write your own Create/ExecuteAction commands. In your case, if you don't want multi-part support, cut those actions out of your chain. On Fri, 18 Feb 2005 09:30:49 -0800, Dakota Jack [EMAIL PROTECTED] wrote: Thanks, Don. Much appreciated. The problem is that there is no consistency on this. I tried, for example, to discuss naming and the Struts chain and got severely stomped on for having the stupidity to think that Struts and Commons could be considered seperately. I have a real interest in chain, IF it is intended to make the request processor pluggable, because I would like to use the standard Struts with some changes. For example, I would like to get away from the way the request processor treats multipart form uploads, tying you to an implemenation I don't care for that much. Because business decisions need to be made, whether people care or not, it would be good if one could tell what is intended for Struts 1.3 in fact. I hope that this does not once again generate heat instead of light. Unless someone says something different, I am going to assume that this is a correct statement of what is happening. Maybe I am not understanding you correctly, however, since I am not sure that you are talking about 1.3 essentially changing only the request processor or something else. I know I don't have any difficulty in the uptake department and find the whole discussion very confusing and confused. Do you have a statement somewhere that you would take to be a bit definitive. (Please don't tell me this is open source and that anything can happen, etc.) snip On Fri, 18 Feb 2005 08:50:02 -0800, Don Brown [EMAIL PROTECTED] wrote: One approach to building applications that is supported by Struts 1.3+ is to write a commons-chain based application and plug it into Struts, however, that is only one approach while the existing Action class approach still exists and will exist for a very long time. Personally, I favor using either MappingDispatchAction, Struts Flow, or a custom POJO action class ala JSF. Therefore, Joe's statement is correct. If you never messed with RequestProcessor, the chain-based processor implementation will not affect you. /snip So, from the below I understand that you have one sort of chain supplanting the present request processor in order to make that pluggable (right?) and another chain that will be used in the application (model?) logic (right?). Exactly, although I would add that second chain is optional as it might work well for some, but others, like me, would perfer other routes. snip It is kinda confusing, but the chain used for Struts is not the same chain that Ted was talking about, and in fact, I believe we are trying to separate the two to ensure a clean separation between Struts and application logic. /snipo Don /snip So, the present talk about chains vis-a-vis Ted is just some work on applilcation logic that is essentially unrelated to Struts? Is this right? And that is to be distinguished from chain talk that is about the logic in the request processor? Is this right? It isn't unrelated to Struts, only highlighting a different approach to per-request processing ala Actions. Ted likes the idea of application logic written using commons-chains, so he and others have improved the Struts action mapping to support a chain being called instead of an Action class. Again, on the dev list, you'll find a lot of ideas and little direction. That's what you get for trying to be on the cutting edge :) Don Jack -- You can lead a horse to water but you cannot make it float on its back. Heaven has changed. The Sky now goes all the way to our feet. ~Dakota Jack~ This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply
Re: Struts or SpringFramework
Thanks, Don. This is really, really, helpful. One last little question, given this much, when there is talk that seems to envision put action as a part of the chain, what does that relate to? That seemingly could not be the part that has a chain supplanting the request processor in the action servlet. However, that really does not seem to be appropriate for the application logic chain either. What is that about? That is one place where I get confused. snip On Fri, 18 Feb 2005 09:48:19 -0800, Don Brown [EMAIL PROTECTED] wrote: The inherent problem with following a developer list is you will hear many different opinions, usually with the goal of coming to an agreed solution or direction, but that direction, once agreed upon, usually isn't clearly laid out. If you want clear direction, look at the user guide, release notes, or one of the many Struts books. If you want to see all the discussion, debate, and exploration that is required to arrive at those directions, then follow the dev list. :) I felt you described the goal of using chain in the Request Processor very well - a pluggable process that the user can customize to their hearts content. If you want to handle population through OGNL, then rewrite the PopulateActionForm command. If you want to add a command that pulls a user profile out of the database and puts it in the request, go ahead and stick it in there. If you don't want to use Actions at all, write your own Create/ExecuteAction commands. In your case, if you don't want multi-part support, cut those actions out of your chain. Exactly, although I would add that second chain is optional as it might work well for some, but others, like me, would perfer other routes. /snip Jack -- You can lead a horse to water but you cannot make it float on its back. Heaven has changed. The Sky now goes all the way to our feet. ~Dakota Jack~ This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
reality? CoR was Re: Struts or SpringFramework
Joe Germuska wrote the following on 2/18/2005 12:32 PM: Yes. If I may, what Ted, Vic, Don, and I are saying is that you should treat Struts as an adapter between HTTP requests and an application which has nothing to do with HTTP. Minimal business logic should be embedded in the Struts layer, whether embedded in Actions, ActionForms, or chain Commands. Struts should do input validation, interface flow control, and translation from HTTP request parameters to application objects and from application objects and data to HTML views. Ted and Vic, in particular, are saying that commons-chain is a good way to write one of these applications-which-has-nothing-to-do-with-HTTP. The problem I run into is this above always sounds great in theory. Reality though is (when dealing with web applications) is that we need handles to HTTP (or at least a handle to a pojo that works with it in the background) and I don't see that ending - unless you go with a different framework like JSF or ww2 which seems to hide the HTTP out of the way and lets you use standard backing beans. Sure you want a seperation between business logic and view presentation, but there are too many times that these are often very related to each other. In other words, sometimes you need stick stuff into the Request or Session based on the results of business logic. So in a case where you coded a set of chains without using an Action class, how do you accomplish this? Let me create a dumb example to illustrate... 1) user submit form data 2) log the user's form data he submitted 2) run a query based on form data. build List of query results, make available in request for display 3) After looking at the query if X condition ends up coming back in the query results, I need to peform another query and make an ojbect from the results and stuff this object into the request 4) Else just stick the initial query into a List of objects, stick in Request. Another example is imagine a chain set up A_chainEvent B_chainEvent C_chainEvent D_chainEvent To summarize my question, what if you need to stuff different things into the Request/Session based on things that happen in chains like B_chainEvent and C_chainEvent? The problem I see is many times you'll be stuck in the middle of a chain cycle and you then need to interact with Request or Session (HTTP). It's this kind of ambigous logic that I find the most frustrating in web apps and I think ends up creating the most headaches for developers. The logic that deals with setting stuff up for display based on certain 'if logic' concerns that need to be looked at. In a pure commons-chain scenario (no Action, no Http tie in?) how are these kinds of things accomplished? If I add stuff from a chain component into the Context object, will my front-end view have access to it? If so, then the commons-chain would be perfect. Without a concept of a backing bean in the Context (which ultimately I guess will be in Session or Request yet transparent to the user), I don't see how using a pure chain set up will be that useful in many situations. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts or SpringFramework
We used the bean framework portion of Spring in a couple applications. It was very nice when the client decided to not use EJB Facades we could very simply (less than 10 minutes) switch the whole app over to a POJO Façade. Granted we wrote the POJO Facades at the time we were developing, and the EJB Facades delegated to the POJO, but it was still an amazing turn around. Also it was nice to have the façades pack around an instance of the necessary DAO(s) that were automagically instantiated when the façade was instantiated at startup. I haven't dug into the web framework of Spring, but I do not plan on switching to it anyway. The IOC aspects of Spring are enough for me. Larry Meadors wrote: Without exception, every developer I have talked to personally that has tried SpringMVC said it was way more complex than struts, and ended up going back (almost all the way) to struts. What I have heard is a killer combination is Spring-managed Struts. In this permutation, you use struts with a Spring-based request processor instead of the default struts one. Then, you get much of the benefit of using spring (managed beans, IoC, etc...) and continue to use vanilla struts for the remainder of your application. I have been hoping to use this model for the last month or so, but have been too busy to try it myself. Stupid job. ;-) Larry -- Forums, Boards, Blogs and News in RiA http://www.boardVU.com - 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: Struts or SpringFramework
It is by far my favorite topic (and for all early RiA adaters). Email me a vin at friendvu.com or at (hardly used) forums at sandraSF.com. I use chain for SoA dispatching from hessian, not on JDNC side (becuase JNLP classloader looks at digester as a security violation :-( ) On JDNC I had to do some MVC work, I think they have a junior group from Sun on this on their side. (They don't even have a DTO concept :-P ) .V Hello Vic: I have looked at jdic and JNLP application and want to explore further for off-line applications. Hope you may share your experience in using commons-chain in Swing (and possibly with Spring IoC) under JDesktop Integration Component. This is your favorite topic isn't it? BaTien DBGROUPS -- Forums, Boards, Blogs and News in RiA http://www.boardVU.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts or SpringFramework
There are 2 chains. One is the request processor chain, the heart of Struts that Joe is donating design and implementation. Most users in Struts never touched it before, and likely will never touch it now; I stay away from it (other than to see how it works so I can do mutlri row CRUD). So now that leave the Action. You can keep doing what you do. But... you can create user commands (a user chain) if you like CoR. (and ... some of us love it, it's KISS and powerfull). If you do user chain or CoR Actions... you could switch to any framework with a lot less pain. (Shale if you like). I also take my use CoR action and run them from command line: ex: java -jar run.jar SEND_MAIL This starts my action to send an email to all the new users. So ... my same CMD I wrote for WebTier... now has a char input. Or SoA, or RiA, or XML-RPC. So that's good. Also, it provide a good framework on it's own. One thing Struts had is that I can look at somone elses struts-config and have an idea how to maintain their code. Commons-chain has that, a map of comands, that I can even configure. Now ... let me get contraversial, (because I am usualy so shy) I used to do IoC in place of CoR. In IoC you have diferent signatures ... and they you can configure/inejct. In CoR the singature is allways the same. So ... what happend last summer is I ended up having like 70 CoR commands built. One of my develops had work (imagine) and... he started pluging in cmds from diferent chains, in his own chain... and built something without code!! My jaw was on the floor. I asked how he inveted this? He said he assumed that's what I wanted!!! (I then told everyone to rewrite IoC into CoR - at least no thinking about the signature, and pull it out it's gone now - Hivemind) The point is... that once you have a lot of commands.. you may notice that you can just plug comands in to each other, like Lego. I think you play some w/ Digester this is just another variation on it. So becuase 1.3 is legacy, you can keep using old action singature, 0 learning. But... if you want, you can try CoR for your commands. It works in anything, event old Struts. It goes by many names for now, user chain is one name (even for me at least most of the time... it's only one command in the chain. Oh... cmd= = chain ) Over time, we will start calling it one thing. .V Wendy Smoak wrote: Wait... I think it was Joe who said that if we had never cared about the Struts RequestProcessor up to now, we could ignore 'chain -- Forums, Boards, Blogs and News in RiA http://www.boardVU.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: reality? CoR was Re: Struts or SpringFramework
To summarize my question, what if you need to stuff different things into the Request/Session based on things that happen in chains like B_chainEvent and C_chainEvent? The problem I see is many times you'll be stuck in the middle of a chain cycle and you then need to interact with Request or Session (HTTP). It's this kind of ambigous logic that I find the most frustrating in web apps and I think ends up creating the most headaches for developers. The logic that deals with setting stuff up for display based on certain 'if logic' concerns that need to be looked at. In a pure commons-chain scenario (no Action, no Http tie in?) how are these kinds of things accomplished? The ActionContext interface defines three maps, requestScope, sessionScope, and applicationScope. We decided that these were logically relevant to any Struts application, regardless of the request/response API. Thus, as long as you're using one ActionContext, you can use these logical maps without being bound to their implementations. The fact is that the ServletActionContext class uses the HttpServletRequest, its Session, and the initiating Servlet's ApplicationContext to implement these scope maps, but most of your code should be insulated from it. Does that help? Or did I dodge the real issue? Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts or SpringFramework
At 1:48 PM -0600 2/18/05, Vic wrote: There are 2 chains. One is the request processor chain, the heart of Struts that Joe is donating design and implementation. Hey, I'm just a follower here, refining stuff that was blasted out by others (Craig, Don, Ted, I think... no offense to anyone I'm missing...) Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: reality? CoR was Re: Struts or SpringFramework
Joe Germuska wrote the following on 2/18/2005 2:42 PM:
The ActionContext interface defines three maps, requestScope,
sessionScope, and applicationScope. We decided that these were
logically relevant to any Struts application, regardless of the
request/response API. Thus, as long as you're using one ActionContext,
you can use these logical maps without being bound to their
implementations.
The fact is that the ServletActionContext class uses the
HttpServletRequest, its Session, and the initiating Servlet's
ApplicationContext to implement these scope maps, but most of your code
should be insulated from it.
Does that help? Or did I dodge the real issue?
I believe that helps:) I know some of my questions are lame without
having really looked at the source code at all, but I'm wondering if you
could do something like this in a Command...
public boolean execute(Context context) throws Exception{
context.setAttribute(someList,someList);
...
}
and then from a JSP be able to somehow have reference to this context...
c:forEach items=${handleToConntext.emloyees}
Can you do the above?
I think using commons-chain is a very cool idea, I just think the
reality is you'll end up still seeing much use of the
ServletActionContext from within the Command objects which goes against
your comment that you'll be able to write http-free components as the
chain events. I don't really see how you are going to avoid this in a
web application. Take for instance something as simple as wanting to
create custom ActionMessages based on the result of something that
happened in a Command or even worse - across multiple Commands?
--
Rick
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: reality? CoR was Re: Struts or SpringFramework
I think using commons-chain is a very cool idea, I just think the reality is you'll end up still seeing much use of the ServletActionContext from within the Command objects which goes against your comment that you'll be able to write http-free components as the chain events. I don't really see how you are going to avoid this in a web application. Take for instance something as simple as wanting to create custom ActionMessages based on the result of something that happened in a Command or even worse - across multiple Commands? Well, I think you're blurring things here. When I talk about http-free components, I'm talking about your business logic, not your controllers (actions or commands). It's true that right now almost none of the base request processor commands are independent of the Servlet API, but that's because of Struts' old dependencies. If we refactored Action and ActionForm to use ActionContext, then the base commands could be independent of the Servlet API, while some implementations of Action and ActionForm might still have their own dependencies. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts or SpringFramework
Vic wrote: It is by far my favorite topic (and for all early RiA adaters). Email me a vin at friendvu.com or at (hardly used) forums at sandraSF.com. I use chain for SoA dispatching from hessian, not on JDNC side (becuase JNLP classloader looks at digester as a security violation :-( ) On JDNC I had to do some MVC work, I think they have a junior group from Sun on this on their side. (They don't even have a DTO concept :-P ) .V Thanks. As i go along in the next 2 months i will probably email you privately and/or join your forums. BaTien DBGROUPS Hello Vic: I have looked at jdic and JNLP application and want to explore further for off-line applications. Hope you may share your experience in using commons-chain in Swing (and possibly with Spring IoC) under JDesktop Integration Component. This is your favorite topic isn't it? BaTien DBGROUPS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts or SpringFramework
I understand how a chain works. Filters in the servlet API are a good example. They are as you say, Vic, very useful. And I have some idea of what the Struts chain is all about: http://www.theserverside.com/news/thread.tss?thread_id=28092. What I don't quite see is how they or CoR replace IoC. IoC seems to me to address a completely different and consistent set of solutions to a completely different and consistent set of problems. So, if you could explain this, I would appreciate it. On Fri, 18 Feb 2005 13:48:39 -0600, Vic [EMAIL PROTECTED] wrote: I used to do IoC in place of CoR. In IoC you have diferent signatures ... and they you can configure/inejct. In CoR the singature is allways the same. (I then told everyone to rewrite IoC into CoR - at least no thinking about the signature, and pull it out it's gone now - Hivemind) -- No one ever went blind looking at the bright side of life. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts or SpringFramework
So the short answer is... I can't! You use a QuickSort and a BubleSort in 2 diferent scenarios, one is good for semi sorted data, the other for large sorts. I used IoC to organize and configure classes after the fact. With CoR I can re-use comands in a diferent context and still be able to configure them. Seemed to me like 2 was too much, one had to go. It's possible that IoC will be added in later versions of Struts, but I likely will chose to use only to use CoR. This is a begining of Vi vs Emacs that will last for years. Spring is more complicated than Struts 1.3... hmmm. .V Shey Rab Pawo wrote: What I don't quite see is how they or CoR replace IoC. IoC seems to me to address a completely different and consistent set of solutions to a completely different and consistent set of problems. So, if you could explain this, I would appreciate it. -- Forums, Boards, Blogs and News in RiA http://www.boardVU.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: reality? CoR was Re: Struts or SpringFramework
Joe Germuska wrote the following on 2/18/2005 5:37 PM: Well, I think you're blurring things here. When I talk about http-free components, I'm talking about your business logic, not your controllers (actions or commands). But for most developers, the business logic usually is already self contained somewhere else (hopefully we don't still don't see people coding JDBC from within their actions:). So for example, in an Action method someone might do: someClass.doUpdate( employeeValueOject ) the SomeClass instance handles the business logic of doing the update. What I seem to be seeing in the examples of CoR and Struts is the removal of the Action class and instead using a chain of Commands. This is fine and I like the idea because it does allow for the concept of coding pre and post processors without IoC, but I still each of them having a lot of ties to the Servlet model. For example, maybe before leaving all of the typical CRUD events you need to call a populate Command that will populate your Request with some needed Lists for drop downs. No longer do you have to remember to make sure to include the populate(..) method call in each of your dispatch methods since you could just add that to the end of the chain. I'm just wondering if someone could provide some more examples of possible real world benefits of the CoR used to replace Actions. I can see the standard chain looking like... -somePreCommand (probably does your initially logging) -someActionCommand (replaces the meat of your Action dispatch method) -somePostCommand (maybe ensures some things are put into Req scope) I'd be curious on seeing some other examples of the possible Commands you would likely see in a typical web app? Thanks again for any additional light. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Struts or SpringFramework
Hello, I have used Struts for four years. And I am evaluating SpinrgFramework. Anybody can give me some suggestions on them ?? Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts or SpringFramework
I assume you know this but just in case: Struts (a web application framework) is not a rival not for the Spring Framework (which is a lightweight j2ee applicatoin framework). I assume, then, that you must mean the standard web application framework that comes with Spring? Is that right? Jack snip On Fri, 18 Feb 2005 09:17:33 +0800, Eric Chow I have used Struts for four years. And I am evaluating SpinrgFramework. Anybody can give me some suggestions on them ?? Eric /snip -- You can lead a horse to water but you cannot make it float on its back. Heaven has changed. The Sky now goes all the way to our feet. ~Dakota Jack~ This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts or SpringFramework
You might profit from dropping into you local bookstore and perusing through Rod Johnson's J2EE Development without EJB which is really good. Chapter 13 covers web tier design and the Web MVC that comes with Spring. (Rod is the primary author of the ideas behind as well as the code behind the Spring framework.) 'Hope this is helpful. Jack -- You can lead a horse to water but you cannot make it float on its back. Heaven has changed. The Sky now goes all the way to our feet. ~Dakota Jack~ This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
