RE: reality? CoR was Re: Struts or SpringFramework

[Joe Germuska]

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: Struts or SpringFramework

[Dakota Jack]

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: reality? CoR was Re: Struts or SpringFramework

[David G. Friedman]

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

[David G. Friedman]

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: Struts or SpringFramework

[David G. Friedman]

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

[Dakota Jack]

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 
> 
> -
> 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: reality? CoR was Re: Struts or SpringFramework

[Dakota Jack]

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:
> 
> 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?
> 
> 
> 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: reality? CoR was Re: Struts or SpringFramework

[Dakota Jack]

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?


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

[Joe Germuska]

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

[Rick Reumann]

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

[Joe Germuska]

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

[Rick Reumann]

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]

Re: Struts or SpringFramework

[Vic]

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 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts or SpringFramework

[Shey Rab Pawo]

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

[Duong BaTien]

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: reality? CoR was Re: Struts or SpringFramework

[Joe Germuska]

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: reality? CoR was Re: Struts or SpringFramework

[Rick Reumann]

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: Struts or SpringFramework

[Joe Germuska]

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]

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

[Vic]

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 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: reality? CoR was Re: Struts or SpringFramework

[Shey Rab Pawo]

Since this is a theoretical discussion, maybe stating some of the
basics regarding HTTP would not be unwelcome.

1.  WEB MVC STRUCTURE: The difference between standalone and web
applications in relationship to the MVC framework is that standalone
applications have components on screens which communicate with the
rest of the framework but the entire screen (page) communicates with
the rest of the framework.

2.  WEB MVC DATA: Since this is so, very different types of
information are sent back in a sort of "flood" to the framework, e.g.
(a) "plain" data such as credit card numbers, how many widgets the
user wants, etc.; (b) "controller" data such as what handler should be
used; (c) "processing" data such as what method to call on the
handler; (d) "presentation" data such as what colors to make the
screen, what layout to use on the screen, etc., which can take many
different forms and which can relate to the serverside in many
different ways; (e) etc.   The types of data breakdown here is
indefinite and framework related.

Given this much, what does the following mean?

> Joe Germuska wrote the following on 2/18/2005 12:32 PM:
> > 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.

-- 
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

[Vic]

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 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Struts or SpringFramework

[Fogleson, Allen]

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 


-
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]

reality? CoR was Re: Struts or SpringFramework

[Rick Reumann]

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

[Don Brown]

There was talk during a brainstorming session on the future of
Actions, where the idea was put out that perhaps Action could go away
and everything could be in the same chain catalog.   I believe that
idea was eventually abandoned as Struts chain commands are going to
have the "execute(ActionContext ctx)" signature where the
ActionContext class is specific to Struts, and we do _not_ want user
applications to be tied to Struts.  The application logic should be
independent of Struts and having that tight of coupling would
encourage developers to just code most of their application in those
Struts-specific commands.  As a general rule, we are trying to make
Struts less intrusive, not more.

HTH,

Don


On Fri, 18 Feb 2005 09:55:41 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote:
> 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.
> 
> 
> 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.
> >
> 
> 
> 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

[Dakota Jack]

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.


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.
> 


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

[Don Brown]

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.)
> 
> 
> 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.
> 
> 
> 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.

> 
> 
> >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
> 
> 
> 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 rece

Re: Struts or SpringFramework

[Duong BaTien]

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

[Joe Germuska]

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

[Dakota Jack]

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.)


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. 


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?).


>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


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

[Dakota Jack]

Exactly, Wendy, what is intended is very hard to track.

Jack



> 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

-- 
"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

[Don Brown]

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

[Wendy Smoak]

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]

Re: Struts or SpringFramework

[Shey Rab Pawo]

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

[Vic]

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 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts or SpringFramework

[Bryce Fischer]

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

[Larry Meadors]

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
> 
> 
> 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
> 
> --
> "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

[Robert Taylor]

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

[Vamsee Kanakala]

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

[Richard Reyes]

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

[Marco Mistroni]

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

[Vamsee Kanakala]

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

[Marco Mistroni]

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

[Dakota Jack]

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]

Re: Struts or SpringFramework

[Dakota Jack]

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


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

-- 
"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]