from:"Michael"

On 6/8/06, Scott Van Wart <[EMAIL PROTECTED]> wrote:

I have two different pages that call the same action. I'm using
validate="true" in the action mapping. Can I specify the 'input'
attribute dynamically (or set it somewhere while the action is being
called, before validation?).

You cannot change config information that has been defined in
struts-config.xml file. If you try, you will likely get "The
configuration is frozen" exception.

You may want to try using wildcards [1], but it looks that wildcards
are not the answer to your question.

I suggest to look at your issue from another perspective. Do you
really need the functionality you are asking for? First, a small
clarification. There is no input page for an action, "input" attribute
is poorly named, it should be called "error" or "errorTarget", because
Struts forwards to that location if input data does not validate. Your
request is always sent to action/actionform.

It appears to me that you have two different HTML forms that are
submitted to one action. After many years of using Struts this
page-oriented approach seems convoluted and inflexible to me. If these
forms are different views of one web resource, they should be rendered
by one action, and a proper page is chosen depending on resource
state. If these forms are views of different resources, then they
should be served by different action classes belonging to different
web resources, that is, you simply should not submit to one action
class from views that represent different web resources.

So, to display the first form you call FirstAction and tell it to
render itself. It shows the form, you fill it out, submit, in case of
error it redisplays the form. Do display the second form you call
SecondAction and tell it to render itself. It shows the form, you fill
it out, submit, in case of error it redisplays the form. :-) This is
it, all you need is two actions, not two "input" attributes.

If you have time, the DataEntryForm page [2] explains my opinion on that matter.

[1]
http://struts.apache.org/struts-action/userGuide/building_controller.html#action_mapping_wildcards
[2] http://wiki.apache.org/struts/DataEntryForm

Michael.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ActionForm and EJB


On 6/8/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:

On 6/8/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:



* Annotations are not a good idea when the configuration concept should
  not be a concern of the person actually writing the code.  In webapps, for
  example, I don't believe in configuring page navigation rules (Struts
forwards,
  JSF navigation rules and cases, etc) directly into the action methods.
The
  actions should describe what happened, not where to go next -- and this is
  something I personally don't care for, even at the code level, the way
that
  WW2 does Results (or Spring MVC does ModelAndView) that combine
  the two concerns together.  But that's a separate issue from whether
  the encoding should be with annotations or not :-).


I don't think that framework should define the navigation at all.
Well, maybe in some specific cases like redirecting a non-logged-in
user to a login page. But generally, a user navigates to a certain
resource himself by clicking links. Resources have states; depending
on state they render themselves differently, but this is not
navigation, this is just views/subviews. Programmatic navigation seems
like a wrong concept altogether to me.

Michael.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ActionForm and EJB

On 6/8/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:

On Thu, June 8, 2006 2:12 pm, Craig McClanahan wrote:
> * Enhance the user experience by catching errors as quickly
>   as possible (ideally client side in a webapp), with error messages that
>   are relevant to the user's context in that particular application.

Absolutely agree.

> * Minimize the number of times I need to specify the same
>   validation in source code, metadata, or whatever.  Ideally, every
>   such requirement should be stated exactly once.

Absolutely agree.

So your argument is basically that database roundtrips will degrade
performance. This should not (ideally) bother an application
developer. A framework should care about that. Metadata retrieval, its
caching, converting metadata to validation rules, combining these
rules with custom rules, this should be performed by a framework. If
database has already defined the rules, they should be used. Whether
it is database itself, or in DAO, or on business layer, or by
validator - does not matter for me as an application developer. But I
don't want to repeat the same rules again and again.On the other hand
I want to be able to add/modify/hide rules or object relationships.
These tasks have been implemented and reimplemented so many times by
many framework/tool developers (not only for Java) that I wonder why
it took 8 years or so for JSR 299 to appear. Still, EJBs as they are
defined now, do not automatically pull and use database metadata (or
do they? I should check out EJB 3.0 spec). So I will be able to use
EJBs as backing beans. BFD. Unless I use several databases or design a
clustered system, I am not tempted to use EJBs at all. If EJB
penetrated deeper in database metadata, then I would have a better
incentive to use them (again, have to check the spec. Maybe it already
does what I want).

I'm still not sold on the whole concept of annotations myself... it seems
to encourage scattering things throughout the code base that otherwise
would be centralized.

Check out Stripes, great stuff.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ActionForm and EJB


On 6/8/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:

Second, an ActionForm is, usually, used to repopulate an HTML form on a
page when an error occurs, or when a page is initially shown.  Since HTML
forms only deal in Strings, another recommendation you frequently hear is
to only have Strings in your ActionForms.  For example, if you have a
textbox in your HTML form for a user to enter a date, having a real Date
field in the ActionForm can lead to problems because of the conversions
that have to take place back and forth (and if I remember correctly, no
conversion is done when redisplaying the HTML form anyway, so you'll get
the default toString() of the Date object, which is almost certainly not
what you want).  If you instead make it a String field, the only
conversion is when you ultimately need to pass it to the business layer,
in which case you have more full control over it.  So, since you probably
want to be dealing with real Java data types in your business classes, but
an ActionForm was designed to deal with HTML forms and therefore only
Strings, trying to make an ActionForm serve both purposes can lead to
problems, so its easier to just avoid the situation altogether.


Plugins like FormDef help with that. FormDef allows to nest a BO/DTO
inside a dynamic form bean, and to define conversion rules. FormDef
also integrates with validator.

On the other hand, the whole idea of Struts/Commons Validator sucks
big time, because database already has all necessary validations,
domains, triggers, etc. Since most apps use database anyway, input
data should either be validated directly by a database or by DAO; DAO
should pull metadata from database to build validation/conversion
rules. Seems that Ruby on Rails is closer to this approach, while most
other frameworks do the same job twice or even three times.

Michael.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ActionForm and EJB


On 6/8/06, chamal desilva <[EMAIL PROTECTED]> wrote:

Hi,

I read few articles on struts. They recommend not to
send action form class to EJBs as data holders. They
recommend we should use general classes for holding
data to decople web tier with EJBs.

What they say must be correct but I still have few
doubts (Maybe b'cause I am not experienced).

Don't we have to modify two classes, if we use both
ActionForms and normal java classes to store data.For
example we will have modify two classes to add a new
attribute, remove attribute etc.

Please help me to understand this more clearly.


It is not a good practice for persistence layer to know details about
presentation layer.

What you can do is to use our business objects as nested object within
a form bean. When you submit an HTML form, Struts will automatically
populate your nested business object, which you can persist.

Btw, new web beans JSR will allow to use EJBs directly as JSF backing
beans. So maybe this could be a reason for you to switch to JSF.

Michael.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Organizing action classes


On 6/7/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:

You ask a question that is frequently debated around here :)  I can say
with quite a bit of confidence that Michael Jouravlev will be around
shortly to say DispatchActions are the ONLY way to go :)


Not the only way, just the one preferred by me :)

1) First off, it is possible to have several mappings and one action
class, using MappingDispatchAction. Speaking of Frank and me, there
are no real benefits in this approach:

* Frank does not like having one large action class
* I don't like having several mappings

2) My approach is having one mapping and one action class. This is not
just  "more simple actions" vs "more methods in one action" debate.

* With one mapping you have one URL, that may be important for some,
especially if you redirect an action to itself.
* With one action class and one form bean and possibly with one nested
business object you have clear relationship between a business object,
a web resource and a web-related code, sort of code-behind class in
.Net-speak. If your form bean is session-scoped, then it is very easy
to keep the conversation, and to send different events to the same web
resource, updating its state.
* Conceptually, a dispatch action represents a whole web resource,
while its methods represent possible actions on the web resource, a
clean paradigm.
* Less mappings in xml file, less clutter.

I prefer to have one action class and one mapping for all submit
events as well as for rendering, but many find it too complex.

It may be simpler to use dispatch action to submit events, and to use
another regular action to render a view. Thus, a web resource would be
served with two actions.

Chamal, if you decide to use a dispatch action, I suggest
EventDispatchAction, or ActionEventDispatcher if your action class
must inherit from your custom class. See these links:

http://wiki.apache.org/struts/EventActionDispatcher
http://wiki.apache.org/struts/DataEntryForm

Michael.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: displaying ActionMessages.GLOBAL_MESSAGE messages only

On 6/7/06, Niall Pemberton <[EMAIL PROTECTED]> wrote:

On 6/7/06, Chris Cheshire <[EMAIL PROTECTED]> wrote:
> In my actions I have messages stored in the session either under
> ActionMessages.GLOBAL_MESSAGE, or my own key (eg 'search').
>
> In my jsp I have a section to display the search specific messages.
> 
> 
> 
>
> I also need to display the global messages at the top of the page,
> however this displays everything, including the search messages:
>
> 
> ...
> 
>
> What do I set for the property to ONLY display the messages keyed by
> ActionMessages.GLOBAL_MESSAGE?

You can do this in different ways:

1) Store the two different sets of messages in different
ActionMessages objects under different keys in the request or session.

2) The second option is to save both sets of messages in one
ActionMessages object and use the "property" attribute to filter the
two different types. So add search messages with a property of
"search" and global messages with a property of "global":

The first approach seems more logical to me. After all, the first
parameter in ActionMessages.add() is supposed to be a property name.

On 6/7/06, Joe Germuska <[EMAIL PROTECTED]> wrote:

me, I just think someone who's been thinking about trying to
contribute to Struts ought to take this one and run with it :-)

I hope they won't jump on this right away :-)

1) Struts 1.3.x misses the implementation corresponding to
processCachedMessages() from 1.2, this must be fixed.

2) Alongside with the fix, the code should be expanded in the following areas:

2.1) processCachedMessages() implements a short-term storage between
requests that is called FlashScope in other frameworks (Tapestry,
Stripes). processCachedMessages() uses a specific
ActionMessages.isAccessed() method to distinguish whether a message
should be removed from the session or not. We need to create a generic
FlashScope storage that would be able to store any arbitrary object
not just messages. My first take is to create Flashable interface with
isAccessed() method or something like it.

2.2) processCachedMessages() cleans up only messages stored under
Globals.MESSAGE_KEY and Globals.ERROR_KEY keys, it does not clean
messages stored under custom keys. This should be fixed too.

2.3) The previous issue is important, because different keys are
needed for component-oriented development. When a page is a solid
thing then one key is ok. When a page consists out of several
components, every particular component should display only messages
that correspond to it.

2) After FlashScope is created, the Redirect-After-Post pattern will
be simpler to use.

3) Would be nice to design FlashScope as a first-class scope object
that could be used in struts-config.xml file too,  for example to
store ActionForms. But this is a longer shot.

So I would like that whoever tackles message-related issues keeps eye
on the above tasks as well. I myself will start working on this,
hopefully I will be able to do something till next Monday. Since I
don't know yet how to modify Struts SVN trunk :) , I will be
submitting regular patches.

Michael.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Passing parameters between chained actions.


Whenever you call an action via action mapping, the standard
create/reset/populate/validate sequence is fired. You can avoid it by
not associating OtherForm with OtherAction, but in this case Struts
will not automatically populate OtherForm if you submit request from
browser to OtherAction.

Since you created OtherForm and put it in proper context with proper
name, Struts does not recreate it, but calls reset() nevertheless (I
hate when it does stuff for me automatically, but this is how it
works.) It is up to you what to do in reset(). You do not have to
reset the form. If you call OtherAction (1) directly from browser or
(2) from SomeAction, you can use a token in request scope, that you
initialize in SomeAction. If OtherForm().reset() finds token in the
request, this is a chained call so you do nothing in reset(),
otherwise you clear the form. Also, if you use request scope, you do
not really need to clear the form, it is created with every request.

If you use OtherForm for output only, then you can skip the setters,
and initialize the form in constructor or directly accessing the
fields, or using setters with different names. Struts is honest in
this regard, it uses setters only to populate the form. No setters, no
changes to the form.

The best way to avoid these problems is not to chain actions ;-)

Michael.

On 6/7/06, Scott Van Wart <[EMAIL PROTECTED]> wrote:

Hi All,

I'm having trouble forwarding one action to another and sending
properties on through.  Let's say I have two actions, "SomeAction" and
"SomeOtherAction", and two form beans, "SomeForm" (with property
"someProp") and "SomeOtherForm" (with property "someOtherProp").  If I
want one action to go to the other, here's how I do it:

---[ struts-config.xml ]---


  
  



  



  
  


---

Having fun so far?  Good!

---[ SomeAction.java ]---

public class SomeAction extends Action
{

  public ActionForward execute( ActionMapping mapping, ActionForm form,
  HttpServletRequest request, HttpServletResponse response )
throws Exception
  {
SomeForm theForm = (SomeForm)form;
SomeOtherForm newForm = new SomeOtherForm();
newForm.setSomeOtherProp( theForm.getSomeProp() );
request.setAttribute( "someOtherForm", newForm );
return mapping.findForward( "success" );
  }
}

-

Almost done...

---[ SomeOtherAction.java ]---

public class SomeOtherAction extends Action
{

  public Washroom execute( ... ) throws AFit
  {
SomeOtherForm theForm = (SomeOtherForm)form;
if ( theForm.getSomeOtherProp().equals( "" ) )
{
   return mapping.findForward( "failure" );
}
else
{
   return mapping.findForward( "success" );
}
  }
}

-

The "failure" forward always gets hit because someOtherProp is always
null.  The form gets reset() after I prepopulate someOtherForm and loses
the value I set!  So I suspect the typical response to this might be
"well, duh," but this is how I've taken to passing parameters across
actions.  Looks like I've been fooling myself with my other Action
classes because most of the properties have the same name, so the
reset() doesn't matter!  My questions are:

1. Am I chaining the actions together properly (with the path="/blah.do"?)
2. Is this the appropriate way to prepopulate ActionForms?
3. Did anyone see my action throw a fit in the public washroom?

Thanks,
  Scott

(It's been a long day, I suspect my silliness in this public post will
come back to haunt me in a few decades)

-
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: Retrieve values


Struts does not serialize and deserialize complex objects for you. If
you need to serialize vector into string and to deserialize it back
you need to do it yourself.

Another approach is to keep the vector in the session instead of
sending it to client and then back to server.

On 6/7/06, Maya menon <[EMAIL PROTECTED]> wrote:

Can anyone please help here ?

  1. request.setAttribute -> sets a vector in Action class 1
  2. In jsp, displays the values in vector using iterate tag and theres a hidden field with value 
as values in vector. In this jsp, the next .do is getting called like 

  3. In the next action class, I want to get it
  String x = request.getParameter("data");
  and again create a vector, to set it to the request

  If I do that, in the jsp, it says: no getter method found.
  please suggest me where I am wrong


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: processCachedMessages in 1.3.x

2006-06-06 Thread Michael Jouravlev


On 6/6/06, Niall Pemberton <[EMAIL PROTECTED]> wrote:

On 6/6/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
> What action or command in 1.3.x corresponds to
> RequestProcessor.processCachedMessages() from 1.2.x ? I looked at the
> source code of 1.3.2 snapshot but could not find the appropriate
> class.

Good catch, its missing.


Added to JIRA: http://issues.apache.org/struts/browse/STR-2883

Michael.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

processCachedMessages in 1.3.x

2006-06-06 Thread Michael Jouravlev


What action or command in 1.3.x corresponds to
RequestProcessor.processCachedMessages() from 1.2.x ? I looked at the
source code of 1.3.2 snapshot but could not find the appropriate
class.

Thanks,
  Michael.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ProductCatalog Tree and Session Scope

2006-06-02 Thread Jan Michael

Hi Dave,

Dave Newton  pingsite.com> writes:
> If the thing you're looking for is already in session why would you want
> to access it in an ActionForm? Just display it and capture the form
> selections in the ActionForm.

This won't work for my example. The ActionForm is needed to set the properties 
of the tree via an Action. For example I can toggle with an image if the 
product category shows their children or not. 

Is it possible to create an ActionForm during the LoginAction, which later can 
referenced by an actionmapping?

Jan

> 
> Jan Michael wrote:
> > How Can I access the productgroup catalog in the session context in an 
> > ActionForm because I want to use the monkeyTree example by Arron Bates to 
> > display the tree structure.
> >   

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

ProductCatalog Tree and Session Scope

2006-06-02 Thread Jan Michael

Hello,

actually I try to code an eshop using struts and hibernate technologies.
I need some help with my product categories.
I want to create a tree where the user (customer) can toggle hrough the product 
categories of the shop. This has already been done via the MonkeyTree tutorials 
by Arron Bates.

When the first user logs into the shop the productgroup catalog is generated 
via hibernate and additionally put into users session scope and for future uses 
(users) into the servlet context. 

How Can I access the productgroup catalog in the session context in an 
ActionForm because I want to use the monkeyTree example by Arron Bates to 
display the tree structure.

Any help will be appreciated.
Thanks,

Jan






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: struts token

2006-05-19 Thread Michael Jouravlev


Search for renderToken() in FormTag.java:

http://svn.apache.org/viewvc/struts/action/trunk/taglib/src/main/java/org/apache/struts/taglib/html/FormTag.java?view=markup

Michael.

On 5/19/06, temp temp <[EMAIL PROTECTED]> wrote:

What hidden field should I use in jsp to pass the generated token to next 
action class?
Thanks & Regards

Manfred Wolff <[EMAIL PROTECTED]> wrote:  Hi mr. temp.temp

1. The Action calls saveToken(request);
2. A unique token will be generated and saved in the session and in the
jsp as a hidden field.
3. The next action calls |*isTokenValid
(request,
true);
4. If the token in the request match the token in the session everything
is alright. Otherwise the user has gone back and the token in the
request is not valid.
5. True means, the token will be reseted. Otherwise you have to reset it
on your own with the method resetToken(request).

Manfred*|


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
New Yahoo! Messenger with Voice. Call regular phones from your PC and save big.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Finalize back hitting the "back"-button?

2006-05-17 Thread Michael Jouravlev


On 5/17/06, Emilia Ipate <[EMAIL PROTECTED]> wrote:

Hello!

Could you be more explicit? What do you understand when saying action? Are you 
referring to a HTTP request action?

Anyway, you should remember that, when the user hits the "back" button of the 
browser, there is no interaction (no request sent) between the client (browser) and the 
server.


Unless page is not cached.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: - Design Issue with Struts Validation

2006-05-16 Thread Michael Jouravlev


On 5/16/06, Dave Newton <[EMAIL PROTECTED]> wrote:


Remember the days when newsgroups had a daily or weekly FAQ posting?
Whaddya think?



We have wiki now. (I believe that wiki needs a bit of reorganization)

* Any more or less important/frequent issues should be reflected in
wiki. I believe that if a person cared about replying with an
informative and a long answer, he can make another effort and put the
answer into wiki.
* Users should  be referred to wiki
* Wiki solutions should be voted as best/good/ok/bad practice (by
whom? I don't know.)
* Best/good practices from wiki should make their way into official docs.
* Users should be refferred to the docs if issue is explained in the docs.

Struts users stumble upon the same issues and ask the same questions.
This does not seem right to me.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Shale: onclick="disabled='true';" not calling Action Method. (stopping double click)

2006-05-11 Thread Michael Jouravlev

On 5/11/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:

On 5/11/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
>
> On 5/11/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> > On 5/11/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
> > > Also, is it possible to lock the server-side bean on a framework
> > > level, so it would be guaranteed that the bean won't get second
> > > request until the first one is serviced and responded to? Will a
> > > simple "synchronized" do?
> >
> >
> > Synchronizing might work *if* you were talking about the same instance
> of
> > the backing bean -- but that is not going to be effective if you are
> using
> > request scoped backing beans.  In Struts terms, it would be like trying
> to
> > synchronize on a property setter of a request-scoped ActionForm -- that
> will
> > not catch the "duplicate submit" scenario because each request woud get
> its
> > own instance.
>
> Yep, I meant session-scoped beans. JSF is more tolerant to
> session-scoped beans than Struts, or even prefers them over request
> scoped. So this might work.

Might indeed (although you would still need the server side logic to detect
the second submit and ignore it somehow), but I'd likely want to have a
client side solution in place too, even if I implemented this, to improve
the user experience.

Is it possible to put all incoming requests into the map, so after a
request has been serviced (response has been returned to the browser),
it is removed from the map. When another request comes, we can use
either soft comparison (same base URL) or strong comparison (same URL
+ params + method). If the incoming request is in the map already, we
wait for response and return it in the same thread as the latter
request (client has abandoned the first request anyway). So, we would
need a separate map-controlling thread. Incoming threads would wait on
request instance in the map. When response is ready, all threads but
the last one would be terminated, the last one would return the
response. Um, maybe instead of a map of requests it should rather be a
map with lists of similar requests...

Just a thought. The point is: do not process the "same" (whatever
"same" is) request until the prior one has been serviced.

only store session scoped state for cases where I need it for a
defined period of time (i.e. the conversational state in a Shale Dialog, for
example, where it'll get thrown away for me when the dialog is completed).

How do you know that dialog is completed? :-) What if a user hasn't
clicked "Done" or "Cancel"? Do you have a window close event listener
or something or a page change listener? Anyway, Struts Dialogs wizard
sample works the same ;-)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Shale: onclick="disabled='true';" not calling Action Method. (stopping double click)

2006-05-11 Thread Michael Jouravlev

On 5/11/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:

On 5/11/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
> Also, is it possible to lock the server-side bean on a framework
> level, so it would be guaranteed that the bean won't get second
> request until the first one is serviced and responded to? Will a
> simple "synchronized" do?

Synchronizing might work *if* you were talking about the same instance of
the backing bean -- but that is not going to be effective if you are using
request scoped backing beans.  In Struts terms, it would be like trying to
synchronize on a property setter of a request-scoped ActionForm -- that will
not catch the "duplicate submit" scenario because each request woud get its
own instance.

Yep, I meant session-scoped beans. JSF is more tolerant to
session-scoped beans than Struts, or even prefers them over request
scoped. So this might work.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Shale: onclick="disabled='true';" not calling Action Method. (stopping double click)

2006-05-11 Thread Michael Jouravlev


On 5/11/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:

On 5/11/06, Jason Vincent <[EMAIL PROTECTED]> wrote:
According to the HTML specification, disabled input controls
are *not* included in the request attributes submitted to the server.
Therefore, disabling the submit button will mean that the request parameter
telling the server which button was clicked is not included


Unless Javascript is used for form's data collection and submission.


I'd look for a strategy involving capturing the *second* click rather than
the first one, so you can make sure the original request is submitted with
no modifications.


You mean, to resubimit the same request? What is the point? Will not
it be the same anyway? Isn't it the task of the business layer to
decide what to do with the second submit (say, "add CD to the basket"
then again "add CD to the basket" to make two of them, etc). Nah, I
would not like that. I don't use Struts token feature for the same
reason: my buseness rules may allow resubmit as "add one more".

Seems that Shale (JSF?) uses Javascript anyway, so why not to use it
to collect data from the form? It will allow to make sync and async
requests to be processed alike.

Also, is it possible to lock the server-side bean on a framework
level, so it would be guaranteed that the bean won't get second
request until the first one is serviced and responded to? Will a
simple "synchronized" do?

Or maybe to somehow "swallow" all identical (up to params) requests to
the same resource while the resource services the first request? Kind
of like Windows "compresses" several mouse events into one.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Mouse rollover

2006-05-10 Thread Michael Immerman

I need a simple mouse rollover within a JSP condition (choose).   Along with 
changing from image1 to image2 upon rollover, the code  invokes an action and 
passes a value.  The following code snippet  shows two examples within the same 
program, one presents 'analyze' with  a rollover, the second presents 
'unlimited' with a rollover
  
  The unlimited works fine, the analyze will not 'rollover'.   Both function 
properly regarding the action.
  
  I have tried every combination to see why the unlimited rollover works and 
the analyze fails.
  
  Thanks in advance,
  
  Michael  (code to follow)
  


   
 
   

  

   
  
  
  
  

  
  
 
  
 


 





  


   
 
   

  

   
  
  
  
  

  
  
 
  
 

  
  Javascript--
  
  <!--
  // copyright 1999-2001 Idocs, Inc. <a  rel="nofollow" href="http://www.idocs.com/tags/">http://www.idocs.com/tags/</a>
  // Distribute this script freely, but keep this 
  // notice with the code.
  
  
  var submitRolls = new Object();
  
  function submitroll(src, oversrc, name)
  {
  this.src=src;
  this.oversrc=oversrc;
  this.name=name;
  this.alt="cancel";
  this.write=submitroll_write;
  }
  
  function submitroll_write()
  {
  var thisform = 'document.forms[' + (document.forms.length - 1) + ']';
  submitRolls[this.name] = new Object();
  submitRolls[this.name].over = new Image();
  submitRolls[this.name].over.src = this.oversrc;
  submitRolls[this.name].out = new Image();
  submitRolls[this.name].out.src = this.src;
  
  document.write
  (
  '<A  onMouseOver="if (document.images)document.images[\'' + 
this.name +  "'].src=submitRolls['" + this.name + '\'].over.src"' + 
  '  onMouseOut="if (document.images)document.images[\'' + 
this.name +  "'].src=submitRolls['" + this.name + '\'].out.src"' + 
  ' HREF="javascript:'
  );
  
  if (this.sendfield)
  {
  if (! this.sendvalue)
  this.sendvalue = 1;
   document.write(thisform, ".elements['", this.sen

Re: Make base Action class a dispatch action

2006-05-09 Thread Michael Jouravlev

On 5/9/06, Niall Pemberton <[EMAIL PROTECTED]> wrote:

On 5/4/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
> What we has been brought from the stone ages:
>
> * Base Action class does not dispatch events
> * DispatchAction and its flavors do, but they do not allow a user to
> derive an action class from some another user's base action
>
> What we got now in 1.2.9 and 1.3.1+ :
>
> * ActionDispatcher resolves the inheritance issue, allowing any action
> to dispatch events
> * EventActionDispatcher makes dispatching an easy and fun task; it
> also allows to separate input phase from render phase, at the same
> time it allows to trigger event with links (GET), not only with
> buttons (POST).
>
> What appears to be a logical next step:
>
> * Stick dispatching features in base Action, thus making all actions
> to be dispatch actions.
>
> Benefits:
>
> * ActionDispatcher will not be needed.
> * Any action will be able to dispatch events.
> * This makes a mind shift, making people think more in terms of events
> and independent webresources, kind of like .NET's code-behind.
>
> Minor drawback:
>
> * only one dispatching behavior can be chosen. Considering all job
> done before, we how have best-of-breed EventDispatchAction. Its
> features (maybe in some modified manner) should be pushed to base
> Action class. For those who rely on old-style DispatchAction or
> MappingDispatchAction, they will still be available.
>
> So, the proposed feature changes nothing for regular Action users, it
> changes nothing for old DispatchAction users, but it makes things a
> lot simpler for those who want to switch to event-based paradigm with
> as little efforts as possible.
>
> Thoughts? Objections? Suggestions?

Personally I'm against this because IMO it just adds
confusion/complexity to the Action class that is unnecessary for users
who don't want to use the "dispatch" style.

The idea is to add dispatching features to an action class (and, I
think, to Command as well) while keeping current apps working. I think
this is possible. Unless the dispatching mapping is defined, nothing
would change for a user.

I also think that the
current provision for "dispatch" flavours isn't a real barrier for
people to adopt the style that you're promoting here.

Most "flavors" of dispatch action have issues, so while they should
remain available, I believe that they should be deprecated. If not
deprecated, their location at "Extras" Gulag is quite appropriate. I
believe that at this moment SAF1 has one dispatching action
(EventDispatchAction) that solves most of the issues of DispatchAction
or LookupDispatchAction while providing more features.

For people not limited/restricted by having to inherit from a "base"
action class, they can simply inherit from one of the DispatchAction
falvours.

Well, they won't have to do that. Every action will be a dispatching
action (if needed). This is logical, especially considering that
according to Front Controller spec, Action has Dispatcher role :) This
will also allow to debunk the claim that Struts has no notion of
events ;-)

For people limited/restricted by having to inherit from a "base"
action class, they can use the ActionDispatcher (or
EventActionDispatcher) to easily plug in dispatch behaviour.

Instead of using/learning bunch of classes people can have only one class.

Simply making the code changes you suggest will not shift people's
mindset - you would need to document the choices available. IMO
documentation is more important than merging the dispatch logic into
the Action class and if Action and DispatchAction flavours were better
documented you could achieve the same without changing the code at
all.

Better documentation will surely help, as well as easier access to
these features, like having them right in the core instead of in
Extras module, as well as recommending this approach as a good
practice. Users prefer "official" recommendations.

I don't use any of the DispatchAction/ActionDispatcher flavours and am
happy with "simple" Actions. If we do document this better I would
prefer we didn't promote one style over the other - but simply layout
what the choices people have and let them decide.

Niall, do you use separate setup/render and submit actions? Dispatch
action is basically the same thing, only you have one submit action
instead of several. Less classes, less mappings, is not it a good
thing? Maybe your use cases are different...

Considering that it is possible to use Command instead of Action in
1.3.x, I agree that dispatching functionality should be either
external to actions/commands, so both Command and Action could be used
for dispatch, or should be implemented in the core for both actions
and co

Re: Session lost in filter after redirect while using URL-rewrite

2006-05-09 Thread Michael Jouravlev


On 5/9/06, Andreas Hartmann <[EMAIL PROTECTED]> wrote:

Hello Dave,

Dave Newton wrote:
> Andreas Hartmann wrote:
>> I implemented two filters which work fine if session handling is done with
>> cookies. If the session-handling is done by URL-rewriting, the session
>> seems to be lost after the sendRedirect().
>>
>> [snipalottatext]
>>
>> I would be glad to get some help,
>>
>
> Are you adding the ";jsessionid=[whatever]" to the path? I don't know if
> the getContextPath() will automagically include the session id bit.

No, that's not done. I thought, this would be done in the "background" by
struts automatically. I added the jsessionid and now, it works fine too
with URL rewriting.


Thank you for your quick help,
kind regards,
Andreas Hartmann


http://java.sun.com/webservices/docs/1.6/api/javax/servlet/http/HttpServletResponse.html#encodeRedirectURL(java.lang.String)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: NullPointerException when using DynaActionForm

2006-05-09 Thread Michael Jouravlev


On 5/9/06, fea jabi <[EMAIL PROTECTED]> wrote:













public class NewEligibilityForm extends DynaActionForm implements
Serializable {

public NewEligibilityForm() {
}

/**
 * Resets the form bean attributes
 *
 * @param mapping - are the action mapings.
 * @param request - is the Servlet Request
 */
public void reset(ActionMapping mapping,
  javax.servlet.ServletRequest request) {

}

}


PrepareAction

public ActionForward execute(ActionMapping mapping,
   ActionForm form,
   HttpServletRequest request,
   HttpServletResponse response)
   throws ServletException, IOException {
DynaActionForm newEligibilityForm = (DynaActionForm) form;

newEligibilityForm.set("name", "Tom");
}

Getting NullPointerException at statement
newEligibilityForm.set("name", "Tom");

When I debug the code I see the newEligibilityForm is null.

I don't see any bug in the above created formbean.

What am I missing here? thanks.


You did not post your action mapping, therefore it is hard to say what
is wrong. Have you set name="NewEligibilityDynaForm" in the action
mapping for PrepareAction?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: page validation in wizzard app

2006-05-08 Thread Michael Jouravlev


On 5/8/06, Jakub Milkiewicz <[EMAIL PROTECTED]> wrote:

Up to now the best soulution ( as i think) is to turn off autovalidation and
validate in Action classes calling actionForm validate(). Obviously i will
set proper value of page property in each action before validation.


Turning off autovalidation is a first step to gain more control on
your wizard's flow.

You may want to check out wizard example in Struts Dialogs 2.0 [1].
The live demo is available [2] It does not use Validator, though.

[1] 
https://sourceforge.net/project/showfiles.php?group_id=49385&package_id=154597
[2] http://www.superinterface.com/strutsdialog/wizardaction.do

Michael.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Change Input parameter at run time

2006-05-06 Thread Michael Jouravlev


Frank's way is simple, declarative and it works. You can also try the
one that I replied with two days ago:

-- Forwarded message starts --
From: Michael Jouravlev <[EMAIL PROTECTED]>
Date: May 4, 2006 12:25 PM
Subject: Re: Change Input parameter at run time part 2...
To: Struts Users Mailing List 

I suggest that instead of hacking "input" property
you abandon it altogether as well as autovalidation. If you turn
autovalidation off, your action.execute() method will always be
called, so you can call actionform.validate() manually and then make a
decision where to forward.
-- Forwarded message ends --

On 5/6/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:

Not sure if anyone said this already, but... if the validation failures
are mutually exclusive, i.e., type 1 cannot occur when submission was
from page 2, and type 2 cannot occur when submission was from page 1,
then I think all you need to do is create another mapping in
struts-config, both identical except for different input parameters.

Even if the errors are not mutually exclusive, you can interrogate the
incoming request to see which mapping was triggered, and only perform
the validation appropriate to the mapping.

Frank

Jakub Milkiewicz wrote:
> Hi
> I am not sure if you can do it easily. Maybe some plubing will be needed.
> Anyway
> concern validation in Action and then forward or redirect wherever you
> want.
>
>
> 2006/5/4, Troy Bull <[EMAIL PROTECTED]>:
>>
>> Greetings
>>
>> I have an application i have inherited.  There is a situation where 2
>> jsp's submit to the same action with the same form bean.  In the
>> validation function inside the form bean if there is one type of error I
>> want to set the input parameter to /jsp1.jsp and put an ActionError on
>> the ActionErrors.  If there is an error of type 2 I want to set the
>> input parameter to /jsp2.jsp and put an error on the ActionsErrors.
>>
>> The just of all this is: the input parameter is set in struts-config.xml
>> and it validation fails it goes back to this jsp for the user to fix
>> it.  I need to change the input jsp page dynamically from inside the
>> form bean.
>>
>> Please help
>> thanks
>> troy
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>

--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!

-
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: EventDispatchAction and wizard

2006-05-06 Thread Michael Jouravlev


Check out the wizard sample from Struts Dialogs 2.0 It uses
EventActionDispatcher renamed to EventDispatcher, but you can use
standard EventActionDispatcher with the same result:
https://sourceforge.net/project/showfiles.php?group_id=49385&package_id=154597

It behaves like this one:
http://www.superinterface.com/strutsdialog/wizardaction.do

Maybe you like it.

On 5/6/06, Jakub Milkiewicz <[EMAIL PROTECTED]> wrote:

Hi
I am creating wizzard application that contains 5 screens. It looks like:
Action -> jsp ->Action -> jsp ->Action ->jsp ...
I also use autovalidation.
All my actions are setup actions (as Michael Jouravlev suggests).
So if i submit a form from jsp to some Action and validation fails struts
forwards me where input parameter for Action points.
I need to be forwarder to previous action (to setup Action) that will
prepare my view (for example retrieve some data from DB) and then shows me
my invalid form/jsp.
Because all my jsps contain 2 buttons: next and back i decided that all my
actions will extends EventDispatchAction, so if validations fails i wanna to
be forwarded to previous
action next() method.
One soultion i found is to add extra parameters to forward paths in struts
configuration file:









Is it good idea??
Does anyone have another solution??
Maybe EventDispatchAction shouldn't be used in my case...




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Jsp Tabs

2006-05-05 Thread Michael Jouravlev


On 5/5/06, Patil, Sheetal <[EMAIL PROTECTED]> wrote:

Hello friends
I am using ditchnet tab taglib . However it works fine for
normal text in tagPane


Hello 1


Hello 2


Hello 3



This code works.
when I enter some table in  it works fine

But when I put this  in  of any table it dosent
work. Means it only shows any one pane and rest dosent work

Can anybody tell me that is there any problem in tabPane while writing
in table rows/colemns.


You probably should ask Todd Ditchendorf about this.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to use LookupdispatchAction

2006-05-05 Thread Michael Jouravlev


On 5/5/06, DOUILLARD David <[EMAIL PROTECTED]> wrote:

Hi,

I have a form that create a user in my database. I use a simple action
class.
After the création, i forward to a jsp (viewuser.jsp) that show my users.

Now, i want to add two buttons on viewuser.jsp (Button.edit, button.delete)
for each raw of my table. Can i avoid to have an action by button but have
one action for add, delete, view ?
How to do this ?
My problem is that in struts-config.xml, my create action is linking with a
jsp (input attribut) and with a form bean.


I suggest you not to use LookupDispatchAction, and to use
EventDispatchAction or EventActionDispatcher instead. These classes
were introduced in Struts 1.2.9 and Struts 1.3.1.

See here for details:
http://wiki.apache.org/struts/EventActionDispatcher

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Two mysteries: ;jsessionid and bad img tag


On 5/4/06, Bryce Nesbitt <[EMAIL PROTECTED]> wrote:

I've just been gifted with a struts application to maintain.
 Things are pretty good, but here are two little mysteries I
need a little help on.  The struts jsp looks like:



And the resulting HTML is like this:



Why the ";" in the jessionid, instead of &?


Because this is session ID, not a query parameter. You cannot read it
from Request object as a query parameter or as a mere substring of a
whole URL (this, it is not considered as a part of URL).


And why is there no "/" at the end of the img tag, which is
inconsistent with the rest of the XHTML markup.


Try wrapping your JSP page into

Re: What To Do If Users Use the Browser "Back" Button?


On 5/4/06, Rob Manthey <[EMAIL PROTECTED]> wrote:

Caroline Jen wrote:

>...etc... But, we are getting in trouble if users use the
>browser "Back" button.  After several clicks on the
>browser "Back" button, we get "system errors".
>
>What to do to handle the situation?
>...etc...
>
This must be one of the most frequently asked questions on this list.
Is it worth someone putting a FAQ on the Struts website so that askers
of this much-repeated question can be directed there?
Pretty much goes hand in hand with equally notorious "My site works
fine, until I open another browser window" aka "multiple browser
windows" problem.  Also worth a FAQ?
I know they're not expressly Struts question, but are very commonly
asked here ...
If no one else is interested I might throw together something and post
it on a domain elsewhere for public FAQing, but I'd need some time for
self-education and assistance to proof read whatever I would put up.
Also I'm buried in "real" (and home!) work at present.


Um, there is no one silver bullet that is simple, works for developers
and works for users. Also, developers who do implement some sort of
Back Button support, have very different opinions on how exactly an
application should behave :-)

Here is one way of doing that, but by no means the only way:

http://www.theserverside.com/articles/article.tss?l=RedirectAfterPost
http://www.theserverside.com/articles/article.tss?l=RedirectAfterPost2

Michael.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to avoid lots of "if else" in Action class.


On 5/4/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:

No, sorry, never did get around to reading it... I meant to, but the
book is all I've had time for since pretty much January.


Yeah, yeah, yeah ;-)


I actually
really can't wait to be done with it, at least the initial writing.


Will it be available online? For free? :-)


There's so many things I'd like to be working on right now!  The current
project, while being really fun, has been a TON of work (an AJAX-based
adventure game).  I can't remember the last time I got a full nights' sleep.


I saw some Ajax games. I don't play much lately. I like to replay some
old LucasArts games from 1991-1992 :-)


I see you've been busy :)  Be careful, they might make you a committer :)


What about you? Would you accept it if they offered you a committer
position? Or "the train has gone" ? ;) I believe that they move to
WW/Shale and need people for 1.x. Incidentally, this is where my
interest is. I don't know about you.

Well, hope your book will be released soon!

Michael.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: SAF 1.3.x, chain naming and arbitrary chains


On 5/4/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:

On 5/4/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
> How exactly can I set the chain for a particular request?

Stupid me, "catalog" and "command" attributes of "action", of course.
Still, this choice is made declaratively on a mapping level. What if I
wanted to make it programmatically?


Well, there were some dumb questions I asked in the first message of
this thread :-)

Now a less stupid question: how chain works with dispatch actions? A
command has only one execute() method, so we are back to what we had
in bare Action class, only less parameters. To have dispatching
features, one either should use either a dispatch action "on top" of
the chain, or should process and dispatch request manually in
Command.execute() method.

Wolfgang Gehner from infonoia.com writes:

"We are fans of grouping *related* actions in one action class, one
thing that the DispatchAction
(org.apache.struts.action.DispatchAction) allows. For example, we
consider all CRUD actions on a bean as related actions. So what we did
is create a BaseCmd class that works similiarly to DispatchAction;"
[1]

He does not explain how they implemented the dispatching functions,
but apparently they did some proprieatery coding for Command.

So if one wants to ditch Action class completely, he would have to
implement dispatching functions. Not that I think that Action class is
evil, I like Action class and its servlet API - related parameters.

I was thinking about implementing dispatching functions in base
Action, but now when we have Command as well, maybe it makes sense to
utilize ActionDispatcher that would dispatch to methods of either
Command or Action?

Michael.

[1] http://infonoia.com/en/content.jsp?d=inf.05.06

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: SAF 1.3.x, chain naming and arbitrary chains


On 5/4/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:

How exactly can I set the chain for a particular request?


Stupid me, "catalog" and "command" attributes of "action", of course.
Still, this choice is made declaratively on a mapping level. What if I
wanted to make it programmatically?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

SAF 1.3.x, chain naming and arbitrary chains


chain-config.xml is not referenced in config files
--

I look at the content of struts-cookbook-1.3.2.war right now. I see
chain-config.xml file present, but it is not referenced anywhere in
the config files. For ease-of-learning purposes I suggest that it is
explicitly referenced in web.xml file. I filed a "trivial" ticket on
that.

servlet-standard chain name is not referenced in config files
-

chain-config.xml defines the "servlet-standard" chain. The chain is
not referenced explicitly anywhere in config files, it referenced by
ControllerConfig file. Again, I would prefer everything to be
explicitly defined in web.xml or struts-config.xml and in other
related config files to reduce amount of "magic" for a regular user.

CATALOG_NAME and COMMAND_NAME seem to be not used
-

The comment to ComposableRequestProcessor (CRP ) in says (Struts 1.3.2):

"ComposableRequestProcessor uses the Chain Of Resposibility design
pattern (as implemented by the commons-chain package in Jakarta
Commons) to support external configuration of command chains to be
used.  It is configured via the following context initialization
parameters:
* [org.apache.struts.chain.CATALOG_NAME] - Name of the Catalog in
which we will look up the Command to be executed for each request.  If
not specified, the default value is struts.
* org.apache.struts.chain.COMMAND_NAME - Name of the Command which we
will execute for each request, to be looked up in the specified
Catalog.  If not specified, the default value is servlet-standard."

I am not fond of having literal strings looking like a constant that
is buried deep in the class hierarchy. The comment should explicitly
mention that these are literal strings.

[org.apache.struts.chain.CATALOG_NAME] is in brackets, while
org.apache.struts.chain.COMMAND_NAME is not. Does this mean anything?
;-)

Default command for ControllerConfig seem to be hardcoded
-

Now the interesting part: these strings are never referenced anywhere.
The command is initialized in ControllerConfig class:

   protected String command = "servlet-standard";

It has getter and setter, but setter does not seem to be called from anywhere.

Now the original question that I had


How exactly can I set the chain for a particular request? Where
ControllerConfig.setCommand() should be called from?

Is it possible to use different chains for different conditions, say
for differnt types of requests (GET vs POST) or just for some
arbitrary condition? Where would I stick the code that validates the
condition and chooses a chain?

What if the condition can be checked in an action class in a
specifically designated method like preExecute() or something? Having
a strict correspondence of URL -> action mapping -> action class it
should be possible to hold off chain execution (at least after the
point when action class is initialized), to call the action class, to
evaluate the condition, then to choose an appropriate chain and then
to execute it and then to pass control to the action class again. Sort
of programmatic interceptors. Can I do something like that?

I don't know is dev@ the right mailing list for this kind of stuff. If
not, I will be using user@ for further emails that pertain to 1.3.*
architecture and functionality.

Michael.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to avoid lots of "if else" in Action class.


My article is out:

 http://today.java.net/pub/a/today/2006/05/04/almost-portlets.html

I bet you haven't read the draft that I've sent you :-) How's your
book going? This [EMAIL PROTECTED] article took me almost a month. I updated it
15 times or so. The book... oh, this should be really tough :)

Michael.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to avoid lots of "if else" in Action class.

On 5/4/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:

On Thu, May 4, 2006 1:59 pm, Michael Jouravlev said:
> Code-wise:
>
> one action class per one logical web resource seems more natural to
> me. Say, Employee. I would have one EmployeeForm, one EmployeeAction
> and several JSP pages for different modes. All compact and observable
> with as little stuff in config file as possible. But this is just a
> preference.

Agreed, it's a preference :)  I can certainly see where your coming from.

> Usability-wise:
>
> One action and one action mapping make one URL. This may be important
> for some (me), and not important for others. Combined with some other
> development approaches, one URL may help to solve stale page problems
> or implicit double submit problems. But then again, if you have one
> render mapping, but you use redirection, then even with several submit
> mappings you can get away with only one visible URL. So again, the
> matter of taste :-)

This one may not always be a matter of taste... what if you had a
situation (and I can tell you, I have in the environment I work in) where
you want to apply different security roles to different URIs?  If you
always have a single URL, how can you do this?  I.e., you want
/showAccount.do accessible to the AccountManager and Customer roles, but
you only want /updateAccount.do accessible to the AccountManager role?  As
I understand it, you would have something like /accountResource.do, and
dispatch to a particular method... how could I secure one but not the
other based on role?

Frank

I see the value of a dispatch action primarily as input (post-,
submit, accept) action, not as a render (pre-, setup) action. Your
/showAccont.do mapping is a render action, therefore it will likely
not be covered by dispatch action.

/updateAccount.do is an input action, you would likely protect this one.

On the other hand, the above "*.do" things are not actions, they are
action _mappings_. Two mappings can refer to the same action class.
The roles protect URLs, not actual Java classes (roles do not have to
know anything about Struts). So here you are: you can have two or more
mappings in a struts-config.xml file that refer to the same action
class, which it turn, combines all needed functionality.

Michael.

P.S. You should've rather hijaacked this thread ;-)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Change Input parameter at run time part 2...


Oh, and by the way, I suggest that instead of hacking "input" property
you abandon it altogether as well as autovalidation. If you turn
autovalidation off, your action.execute() method will always be
called, so you can call actionform.validate() manually and then make a
decision where to forward. Much cleaner if you ask me.

On 5/4/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:

It is not possible (at least legally). You should create a new
ActionMapping object.

On 5/4/06, Troy Bull <[EMAIL PROTECTED]> wrote:
> I found mapping.setInput but i get an error when i try to change it
> telling me
>
> java.lang.IllegalStateException: Configuration is frozen
>
> How do u temporarily unfreeze my configuration so I can change my input ??
>
> thanks
> troy
>
>
>
> Troy Bull said the following on 5/4/2006 1:37 PM:
> > Greetings
> >
> > I have an application i have inherited.  There is a situation where 2
> > jsp's submit to the same action with the same form bean.  In the
> > validation function inside the form bean if there is one type of error
> > I want to set the input parameter to /jsp1.jsp and put an ActionError
> > on the ActionErrors.  If there is an error of type 2 I want to set the
> > input parameter to /jsp2.jsp and put an error on the ActionsErrors.
> >
> > The just of all this is: the input parameter is set in
> > struts-config.xml and it validation fails it goes back to this jsp for
> > the user to fix it.  I need to change the input jsp page dynamically
> > from inside the form bean.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Change Input parameter at run time part 2...

It is not possible (at least legally). You should create a new 
ActionMapping object.


On 5/4/06, Troy Bull <[EMAIL PROTECTED]> wrote:

I found mapping.setInput but i get an error when i try to change it
telling me

java.lang.IllegalStateException: Configuration is frozen

How do u temporarily unfreeze my configuration so I can change my input ??

thanks
troy



Troy Bull said the following on 5/4/2006 1:37 PM:
> Greetings
>
> I have an application i have inherited.  There is a situation where 2
> jsp's submit to the same action with the same form bean.  In the
> validation function inside the form bean if there is one type of error
> I want to set the input parameter to /jsp1.jsp and put an ActionError
> on the ActionErrors.  If there is an error of type 2 I want to set the
> input parameter to /jsp2.jsp and put an error on the ActionsErrors.
>
> The just of all this is: the input parameter is set in
> struts-config.xml and it validation fails it goes back to this jsp for
> the user to fix it.  I need to change the input jsp page dynamically
> from inside the form bean.
>
> Please help
> thanks
> troy
>
> -
> 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: How to avoid lots of "if else" in Action class.

Code-wise:

one action class per one logical web resource seems more natural to
me. Say, Employee. I would have one EmployeeForm, one EmployeeAction
and several JSP pages for different modes. All compact and observable
with as little stuff in config file as possible. But this is just a
preference.

Usability-wise:

One action and one action mapping make one URL. This may be important
for some (me), and not important for others. Combined with some other
development approaches, one URL may help to solve stale page problems
or implicit double submit problems. But then again, if you have one
render mapping, but you use redirection, then even with several submit
mappings you can get away with only one visible URL. So again, the
matter of taste :-)

I will think on more benefits of dispatch actions :)

On 5/4/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:

And of course the simple option: separate action :)

It's absolutely true that a Dispath-type action will get rid of all the
if's, and that's good... but you will still be left with a potentially
large Action that performs a number of different (hopefully at least
related!) functions.

Me, I still prefer individual Actions that are only a few lines of actual
code a piece.  I'd rather have more smaller Actions than fewer larger
Actions.  I find it easier to comprehend an application constructed that
way, and I also find it easier to make incremental changes.  It also
potentially makes working in a team environment less contentious, although
this isn't to me a major concern.

Frank

--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!

On Thu, May 4, 2006 1:20 pm, Michael Jouravlev said:
> Dispatching action. Do not use old and crusty DispatchAction.
> See these links:
>
> http://wiki.apache.org/struts/EventActionDispatcher
> http://wiki.apache.org/struts/DataEntryForm
>
> Michael.
>
> On 5/4/06, Joey Watson <[EMAIL PROTECTED]> wrote:
>> hello everybody.
>>
>>   When I was working a big project. I always met this problem. coz the
>> sometimes there are a lot of event need to be handled in a single jsp
>> page. so programer need to use lots of "if - else" to deal with
>> different event  in Action.execute method. of cause. I think those
>> codes is not hard to be understant,  but sometimes it make the action
>> class too big.  Any suggestion?
>>
>> Thanks.
>>
>> Joey.
>>
>> -
>> 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]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Make base Action class a dispatch action


What we has been brought from the stone ages:

* Base Action class does not dispatch events
* DispatchAction and its flavors do, but they do not allow a user to
derive an action class from some another user's base action

What we got now in 1.2.9 and 1.3.1+ :

* ActionDispatcher resolves the inheritance issue, allowing any action
to dispatch events
* EventActionDispatcher makes dispatching an easy and fun task; it
also allows to separate input phase from render phase, at the same
time it allows to trigger event with links (GET), not only with
buttons (POST).

What appears to be a logical next step:

* Stick dispatching features in base Action, thus making all actions
to be dispatch actions.

Benefits:

* ActionDispatcher will not be needed.
* Any action will be able to dispatch events.
* This makes a mind shift, making people think more in terms of events
and independent webresources, kind of like .NET's code-behind.

Minor drawback:

* only one dispatching behavior can be chosen. Considering all job
done before, we how have best-of-breed EventDispatchAction. Its
features (maybe in some modified manner) should be pushed to base
Action class. For those who rely on old-style DispatchAction or
MappingDispatchAction, they will still be available.

So, the proposed feature changes nothing for regular Action users, it
changes nothing for old DispatchAction users, but it makes things a
lot simpler for those who want to switch to event-based paradigm with
as little efforts as possible.

Thoughts? Objections? Suggestions?

Michael.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Conditional validation

On May 4, 2006, at 11:27 AM, Adam Hardy wrote:

> In the last couple of days someone said that they separated the two
> flows using GET and POST - or at least I thought so.
>
> It sounded interesting but on looking at the struts-config DTD,
> there seems no way to do this.
>
> I can't find the thread in the archive now. Did I misread that
> previous posting?

I am doing this in Struts Dialogs 1.x [1]. Here is, for example, the
snippet from the config file of one of the active users of Struts
Dialogs (he uses Tiles as well):

If event is found, method handler is called. If POST and event is not
found, execute() is called. If GET and event is not found, the
location in the "view" attribute is called.

 element selects method handler for an event.
 is basically , used to
transfer control to another webresource.
 is basically , used to render a page.

At present point, I am not sure that differentiating by POST/GET is
the best, because it does not allow to sent event via link.
EventActionDispatcher in Struts 1.2.9 does not differentiate by
POST/GET.

On 5/4/06, James Mitchell <[EMAIL PROTECTED]> wrote:

I don't think that would be the best solution (but that's just my 2c)
-- I would opt for the declarative approach, with wildcards for
"verbosely declarative simplicity" -- now there's an oxymoron for ya :)

Is the mapping above decrarative enough for ya? ;-)

[1] http://struts.sourceforge.net/strutsdialogs/index.html

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to avoid lots of "if else" in Action class.


Dispatching action. Do not use old and crusty DispatchAction.
See these links:

http://wiki.apache.org/struts/EventActionDispatcher
http://wiki.apache.org/struts/DataEntryForm

Michael.

On 5/4/06, Joey Watson <[EMAIL PROTECTED]> wrote:

hello everybody.

  When I was working a big project. I always met this problem. coz the
sometimes there are a lot of event need to be handled in a single jsp
page. so programer need to use lots of "if - else" to deal with
different event  in Action.execute method. of cause. I think those
codes is not hard to be understant,  but sometimes it make the action
class too big.  Any suggestion?

Thanks.

Joey.

-
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: Loosely coupled pages and actions


On 5/3/06, Rob Manthey <[EMAIL PROTECTED]> wrote:

> If you care about where your action is called from,

Only so much as to have a page for the server to send back to the user -
ie: the page that they were on - not some other interim page.


So we have two concepts:

* A certain page sends request to the server; server does stuff; then
it redisplays the page where it was called from
* A request is sent to server from whoever it might be (aliens);
server does stuff; then it selects a view according to its current
state and displays it.

The second approach is simpler and is more mainstream. The first
approach is more service-oriented, where an action just does some job,
but does not choose a view.

On the other hand, when you display a page, you need to supply data
for this page, right? Unless you stashed session-scoped data
somewhere, your action has to prepare output data for your page. So,
it has to know what page it was called from, and this page cannot be
an arbitrary page, it should be one of the pages that the action can
provide data for...

Um, I see what you are saying. You call an action which has to support
the page you call it from... Yes, this is another way of doing things,
but I would say, not very popular.

Either you stick source page name into link parameters, or you set it
on the server during previous call. But then if a user goes back using
browser's Back button, your page on a browser and your remembered page
on the server won't match. This is why sticking page name and other
related info into a link is more robust. A link by definition is
always in sync with the page it is defined in :-)

Michael.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Loosely coupled pages and actions

On 5/3/06, Rob Manthey <[EMAIL PROTECTED]> wrote:

Thanks Michael.  I'm just picking my way through your answer ...
Ok, the  bit is interesting ... and I'm going to consume
that in detail later, that's a lesser case at present.
One question on the non-include side ... ->

Michael Jouravlev wrote:

> On 5/3/06, Rob Manthey <[EMAIL PROTECTED]> wrote:
>
>> ... action knowing dynamically what jsp it's called from ...
>
> Unless it is the case of , I personally believe that
> action should not know or care to know where the request came from.

I'm anticipating that this is on the back of an MVC axiom that the
action updates the model and then the jsp just fetches the assets it
wants from the model, so the "which assets does the action need to
populate" is catered for by not anticipating which page you are heading
for, just update all assets that the action has tainted.  (I'm probably
still missing the finer points, as this seems not to be as "lightweight"
an approach as updating the assets that were tainted by the action *and*
are going to be wanted in the next jsp, but ok it would solve the asset
selection problem.)  However (correct me please), surely *something*
needs to know which jsp to fetch to return to the user ... ?  If this is
removed from the action's responsibility, how do I configure the Struts1
framework to dynamically route back to the right page when an action can
be called from multiple jsps ... ?  struts-config.xml seems to only
allow one page for an action to anonymously default back to after
completion ... .

First, about input="pagename" bit. I personally believe that

* "input" property should be deprecated
* if it is not deprecated, then it should be at least renamed to
"error", because "input" is a misleading name

"input" property is not an input page, it is the location where
control is forwarded in case of error. I think that "input page that
preceds an action" and "the target location for situation when error
occurred" are totally different concepts.

The request always comes to an action class, not to some related page
like "input". Well, except the situation when you have
validate="true", your request data does not validate, and control goes
to "input" page without your action class being called at all. This
sucks if you ask me.

Now, try to abstract from input pages and such. You have HTTP
protocol, client on this side and an application on the server side.
The request is just a call from client to server. Forget about pages,
think in terms of web services, for example. Why would the server care
where there request came from? What it should care is the request
data. Despite that HTTP is stateless, the application has its state,
which is defined by

* state stored on the server, like session-scoped data
* input data that was submitted with request

Based on this information, application updates the Model (and its
state) if needed (that is, updates session objects or writes to a
database, database being a part of server state), and displays a view.
It may choose a view out of several possible views based on current
state (again, if you do not use session-scoped objects, current state
is completely defined by input data and maybe by some stuff that you
pulled from the database).

I believe that this concept provides more freedom and less
dependencies between actions.

If you care about where your action is called from, just pass this
info along as request parameter, this is the easiest thing. Or,
instead of passing something like "calledFrom=SearchPage" you can pass
something like "searchCriteria=...". The action would know that it
needs to perform a search and to return found.

Try this as well: http://wiki.apache.org/struts/DataEntryForm

The above link needs some polishing, but it already has some usable
ideas. Write (or curse) back if my babbling was not clear ;-)

Michael.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Loosely coupled pages and actions


On 5/3/06, Rob Manthey <[EMAIL PROTECTED]> wrote:

Hi,
I have some actions that I have decoupled from their jsps, so that I can
use the corresponding html components on various pages and move them
around as the client changes their mind about requirements.
I have implemented a programmatic mechanism for the action to know which
assets to populate and which jsp to render after the action has
completed, but it's getting a little tricky with some boundary fault
cases, as I've also implemented a window uniquifier to permit multiple
browser windows being acted in without session collisions.
Anyway, can someone point out what I've overlooked?  Is there a simpler
(framework) way of a loosely coupled action knowing dynamically what jsp
it's called from (esp: note the cases of the component being or not
being in a jsp:include) so that it can populate the right assets and
render the right jsp?


Unless it is the case of , I personally believe that
action should not know or care to know where the request came from.
Anyway. In case of , you can either pass a request
parameter using , or you can check for
"javax.servlet.include.request_uri" attribute of request object to see
if the action is included and what is the address of included fragment
as well as of parent page. See servlet spec or check out Caucho FAQ
[1].


Using the struts-config.xml action input entry
only allows one point of origin, and using request.getRequestURI()
returns the last *action* not the originating jsp to forward back to
(not helpful when the last action is itself one of these decoupled
actions, as opposed to an inital jsp entry action).


If you think of it, this is logical. When you click on the link in the
browser, there is no JSP anymore, there is just an HTML page
containing the location where the request is about to be sent. How
browser would know about your last JSP? If you like, you can stick
your last location into your HTML forms as a hidden field, or into all
links as a parameter in a rewrite-URL manner.

[1] http://www.caucho.com/resin-3.0/webapp/faq.xtp

Michael.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: validation breaks my form prepopulation


Kyle, this is not exactly what you are looking for, but maybe it can
help a little:

http://wiki.apache.org/struts/DataEntryForm

(as you might have noticed, I like to draw pictures with blocks and arrows).

Michael.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: validation breaks my form prepopulation


Are you saying that you've tried to call two mappings, one with an
associated actionForm and another without, and when calling action
without associated form you get a valid reference to a form? Are you
sure? Because it does not sound right, you should get null.

On 5/3/06, Kyle W. Cartmell <[EMAIL PROTECTED]> wrote:

So in a Struts web application if I supply two mappings for a single
action, one that has a form and one that does not, and I call the one
with the form and then a few seconds later call the one without, the
form parameter to the execute method is not null on the second call. I
don't understand why this would be so...

Michael Jouravlev wrote:
> On 5/3/06, Kyle W. Cartmell <[EMAIL PROTECTED]> wrote:
>> I did some tinkering and found that even though my setup action is
>> indeed associated with a form bean, and my reset method is defined and
>> sets my values to null, when I return to an action from a validation
>> failure or forwarded from another action, the form that I originally
>> used to populate the data on that page is present and intact.
>>
>> 1. Is it reasonable to simply make use of this mechanic to allow this
>> data to persist?
>
> How many forms do you have: one or two? If two, do they have
> properties with the same names? If I remember correctly, this should
> work somewhat like this:
>
> * You submit an HTML form to a submit action, well, actually to an
> action mapping
> * If actionform is defined for the mapping, it is initialized. That
> means, that if it has request scope, it is created. If it has session
> scope it is usually reused (this is not guaranteed, but I've yet to
> encounter the situation when session-scoped form was not reused).
> * reset() is called on form
> * form is populated from request parameters
> * if "validate" attribute of the action mapping is set to true,
> validate() is called
> * if validate() returns non-empty object and you have "input"
> attribute set, then control is forwarded to the location defined in
> the "input". (Hmm, what happens if you have validate="true" but do not
> have "input" attribute?) By the way, it is possible to redirect to
> "input" location instead of forwarding, but this is done globally for
> all mappings in the config file.
> * If you do a regular forward using "input" attribute, the
> request/response sequence has not been finished yet, so all objects
> that were created when you submitted the request, are still there,
> including request-scoped actionform and request object itself. So, if
> you forward to a regular JSP page, you can pull data from the
> actionform or from request object.
> * Now, the fun part. If you forward to a setup action, then Struts
> will look for an actionform associated with this mapping, and will
> call reset() on it, then it will try to populate it from the request
> object, then it will call validate() if you have validate="true". So,
> if you forward to a setup action and you have changed content of the
> actionform, you should either NOT associate a form with an action.
> Because otherwise your changes to actionform fields will be
> overwritted from the request object. Does it make sense? ;-)
>
>> 2. I find that I am shocked by some astounding discovery regarding
>> Struts functionallity, and I have gone through all of the documentation
>> on the website, can anyone direct me toward comprehensive (or as close
>> as possible) documentation of Struts internals in hopes that I can stop
>> posting silly questions here and not have to resort to reading source?
>
> I think that it all clears when you understand how scoped objects are
> managed, and how the request/response cycle works. The key here is
> that Struts runs its portion of request/response code whenever you
> call an action mapping, even if you make a server-side forward.
>
> I wrote a small article on that topic [1]. It is not perfect and,
> frankly, needs a rewrite (I introduced my own names to some of the
> action/form combinations), I would do some things differently. But
> some sections of it are still valuable. Take a look at "Two actions,
> one form" and "Two actions, two forms" sections. Currently I prefer to
> use only one actionform and two action classes (input and render) for
> one web resource.
>
> Oh yeah, and as the article says, use the same scope if you use the
> same form name :-) Otherwise you'll get some funny results.
>
> Michael.
>
> [1]
> http://www.theserverside.com/articles/article.tss?l=StrutsActionMapping
--
Kyle W. Cartmell
Sr. Software Developer
LAP Holdings, LLC dba First Finance
Phone: (480) 222-0050
Toll Free: (800) 355-3135
[EMAIL PROTECTED]
www.efirstfinance.com


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Are throwing RuntimeExceptions in a struts app 'that evil'?


On 5/3/06, Rick Reumann <[EMAIL PROTECTED]> wrote:

I think I've read over most of the conventional wisdom that talks
about how throwing aRuntimeExceptions are a bad idea, especially from
within a catch in a finally block (at least IDEA is warning me about
it:) But my question is it really 'that' bad?


Won't you lose your first RTE when you throw another one from finally block?


Do I really want to have to wrap that with a try/catch or declare that
it throws WhateverException?  What does that really gain me?


I guess this is religion/style thing. I would never return SQLwhatever
exceptions to business/web layer, I would convert it.

If situation is correctable, you should catch the exception somewhere,
where you can correct the situation (I don't know, you wanted to
update, but there is no such row, so you can automatically call insert
right away). In this case you might rethrow it as a specific
exception, like PersistentObjectNotFoundException.

If situation is fatal, throw RTE and don't bother much to catch, the
thing blew up anyway.

If this is a business-related exception (say, all new hires must be
single girls from 18 to 29 yr old), return checked business exception.
Well, I guess this situation arises if you have business rules in the
database.

Michael.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: validation breaks my form prepopulation


On 5/3/06, Kyle W. Cartmell <[EMAIL PROTECTED]> wrote:

I did some tinkering and found that even though my setup action is
indeed associated with a form bean, and my reset method is defined and
sets my values to null, when I return to an action from a validation
failure or forwarded from another action, the form that I originally
used to populate the data on that page is present and intact.

1. Is it reasonable to simply make use of this mechanic to allow this
data to persist?


How many forms do you have: one or two? If two, do they have
properties with the same names? If I remember correctly, this should
work somewhat like this:

* You submit an HTML form to a submit action, well, actually to an
action mapping
* If actionform is defined for the mapping, it is initialized. That
means, that if it has request scope, it is created. If it has session
scope it is usually reused (this is not guaranteed, but I've yet to
encounter the situation when session-scoped form was not reused).
* reset() is called on form
* form is populated from request parameters
* if "validate" attribute of the action mapping is set to true,
validate() is called
* if validate() returns non-empty object and you have "input"
attribute set, then control is forwarded to the location defined in
the "input". (Hmm, what happens if you have validate="true" but do not
have "input" attribute?) By the way, it is possible to redirect to
"input" location instead of forwarding, but this is done globally for
all mappings in the config file.
* If you do a regular forward using "input" attribute, the
request/response sequence has not been finished yet, so all objects
that were created when you submitted the request, are still there,
including request-scoped actionform and request object itself. So, if
you forward to a regular JSP page, you can pull data from the
actionform or from request object.
* Now, the fun part. If you forward to a setup action, then Struts
will look for an actionform associated with this mapping, and will
call reset() on it, then it will try to populate it from the request
object, then it will call validate() if you have validate="true". So,
if you forward to a setup action and you have changed content of the
actionform, you should either NOT associate a form with an action.
Because otherwise your changes to actionform fields will be
overwritted from the request object. Does it make sense? ;-)


2. I find that I am shocked by some astounding discovery regarding
Struts functionallity, and I have gone through all of the documentation
on the website, can anyone direct me toward comprehensive (or as close
as possible) documentation of Struts internals in hopes that I can stop
posting silly questions here and not have to resort to reading source?


I think that it all clears when you understand how scoped objects are
managed, and how the request/response cycle works. The key here is
that Struts runs its portion of request/response code whenever you
call an action mapping, even if you make a server-side forward.

I wrote a small article on that topic [1]. It is not perfect and,
frankly, needs a rewrite (I introduced my own names to some of the
action/form combinations), I would do some things differently. But
some sections of it are still valuable. Take a look at "Two actions,
one form" and "Two actions, two forms" sections. Currently I prefer to
use only one actionform and two action classes (input and render) for
one web resource.

Oh yeah, and as the article says, use the same scope if you use the
same form name :-) Otherwise you'll get some funny results.

Michael.

[1] http://www.theserverside.com/articles/article.tss?l=StrutsActionMapping

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: request scope & paging

On 5/3/06, Y. Thomas Gan <[EMAIL PROTECTED]> wrote:

Dave Newton wrote:
> Kyle W. Cartmell wrote:
>
>> I understand the concept behind this, but does anyone actually use
>> this in production code? Seems more trouble than it's worth since the
>> user could simply start multiple sessions.
>>
>
> How? Isn't that browser-dependent?
>
And OS dependent too. On a Mac (which is what many of our user use) or
linux, you can not  start two windows
on different sessions from the same browser, while on Windows, I can
easily start two windows on one or two sessions.

You can configure MSIE (at least on Windows) to either start a new
process for a new window (default), or to run all windows in one
process. MSIE associates session with a process.

Instead of saving result list in session, we decided to carry all form
inputs through request params from page to page
and make the result for that page.

Thanks all for responding.

This ties your second action to the first action, so your second
action won't work properly if you navigate to it directly, just by
typing its address in the browser, because it won't have needed
parameters. I guess this is ok with you.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to POST data to an external site from an action?


On 5/3/06, Martin Kindler <[EMAIL PROTECTED]> wrote:

Thank you all for answering!

But I seem not to have stated my problem clearly: I know how I can POST to
an uri using Java.
My problem is that I want the user to be redirected (or forwarded) to the
page my action has posted the data to.

The easy way to handle this is:
put a button on my page by which the customer selects his preferred payment
service.
creati an action which prepares the values needed by this payment service.
This action forwards to a little jsp-page which contains a form with all the
data.
When the user submits the form, he is transferred to the payment service
with all neccessary information.


When a user is transferred to a payment service right from the
browser, how does your application know about this?


This means two clicks by the user for just selecting a payment service. I do
want to make a one-click procedure from this. A solution found by googling
automates the second submit by javascript. This is what I now have
implemented. The question is: is there a more elegant way?

If I use any of the http client approaches (either using java.net or commons
httpclient) I get the response somewhere in my action, but it should be in
the user's browser.
Probably one could say that I need sort of (transparent) proxy like
behaviour.


Yep, your action behaves as proxy. Also, your application is in the
know of what is happening.

Michael.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: request scope & paging


On 5/3/06, Y. Thomas Gan <[EMAIL PROTECTED]> wrote:

Is there a way in struts to chain a series of requests (paging through a
list) and pass data through request scope?
In my scenario, I keep the a result list in session, but this prevents
me from opening two windows (same session)
and paging through two different lists (one in each window)
independently. Thanks in advance for insights. -Thomas


If you have one list but you want to see different pages in different
windows, pass page number parameter in request, and set list offset
somewhere in the request as well.

If you want to have two different session-scoped lists, then you need
to take care of it yourself. Obviously, you cannot store one list on
an actionform, so you either store a collection of lists, or you store
a nested container object, that in turn contains the collection of
lists. The container would take a list ID and maybe a page number as
parameters, and returns a particular list and maybe an offset in the
list.

Unless you have a Javascript hooked up to window close event, you
cannot detect when a list is not needed anymore, so you can set a
limit for number of simultaneously created lists.

Michael.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: validation breaks my form prepopulation

2006-05-02 Thread Michael Jouravlev


On 5/2/06, Kyle W. Cartmell <[EMAIL PROTECTED]> wrote:

Within my web application (using the Struts action framework) when
validation of an ActionForm fails and control is returned to the JSP
indicated by struts-config.xml, any request attributes that were passed
to that JSP originally are lost because a new request object has been
created.


"input" attribute of "action" element in struts-config.xml does not
have to refer to JSP page directly, it can point to setup action of
your JSP page.

Michael.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Is Action Chaining Strongly Discouraged?

2006-04-30 Thread Michael Jouravlev

From HTTP/RequestProcessor point of view, redirection is not chaining.

On 4/30/06, Leon Rosenberg <[EMAIL PROTECTED]> wrote:

maybe you should give us a use-case where you plan use action chaining?
Also the kind of chaining (redirect, direct call, forward) is important.

regards
leon

On 4/30/06, Caroline Jen <[EMAIL PROTECTED]> wrote:
> I have seen some discussions on this forum regarding
> action chaining.  Primarily, the advices are to think
> through the business logic before making decision on
> chaining actions.
>
> What are the disadvantages of action chaining?  Why
> action chaining is not a good practice?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Combo Selection

2006-04-26 Thread Michael Jouravlev

Do you store selected country? Struts does not do it for you.
This link may help: http://wiki.apache.org/struts/StrutsWidgets

Michael.

On 4/26/06, Marisol Opreni <[EMAIL PROTECTED]> wrote:
> I have a textbox (empty) and a dropdown list (countries from a database).
> The user completes the textbox and selects a country from the dropdown list.
>
> When he submits, I validate the textbox (validator framework).
> If there's an invalid input in the textbox, the drop down list doesn't show
> the previously country selected by the user... therefore he has to selected
> again.
>
> How can I prevent this?
> THANKS!
> Marisol.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tiles vs. + XHTML/CSS

On 4/25/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> On 4/25/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
> >
> > On 4/25/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> > > According to the APIs, it is actually one Controller per Tile, not one
> > > Controller per page ... doesn't that give you (Michael) the hook you'd
> > need
> > > to grab the dynamic data for each fragment?
> >
> > I guess it does. But how is this better/different than simply
> > including Struts actions or any other resources?
>
> I found a pointer to Cedric's old web site[1] from the days before Tiles was
> contributed into Struts.  The "advanced features" link there has some
> extended discussion of controllers (as well as a bunch of the other features
> of Tiles).

I've looked at this doc. If I undertand it correctly, a tile is this
whole thing:

I can have only one controller per tile, but I cannot have controllers
for, say, header.jsp or body.jsp separately. This is what I had in
mind and Greg Reddin got me right. I would prefer if something like
this was possible:

In this case header and body can be separate independent entities. I
believe that in most cases a composite page is built from only one
tile, so this would make real sense.

Reading further, section 5.2.2 One Controller - Multiple Views:

"Sometimes, the controller does some kind of logic and depending of
some result selects the appropriate view to render data. For example,
the controller processes user requests, if all is ok, data is shown,
if an error occurs, the appropriate error page is shown.

The current Tiles version doesn't directly support one controller
associated to multiple views, but this can be done with Struts' Action
Forward mechanism.

The solution consists of writing a Tile with its attributes (insert or
definition), and specify a Struts Action as page URL instead of a JSP
page. The action plays the role of the controller and then forwards to
the appropriate JSP page, which can either be an URL or a definition
name."

The action mapping follows:

What? How this is different from simply including
"/actionAsController.do" and then forwarding to an appropriate JSP
fragment? The problem here is that forwarding (to a JSP fragment) from
an included resource does not work, as I learned a year ago. While
this pattern does not work with , Paul Benedict reported
that it works with . I don't know how exactly JSTL handles
it, but if it works, than what is the difference from above Tiles
example? Granted, there was no JSTL in 2001. But there is now.

Going further to section 8, Advanced Usages. It talkes about
components. Here is the example:

How is that really different from

Is not this similar to above Tiles sample?

Again, I am not bashing Tiles, I am just looking for justification of
using it in a new project now in 2006, when we have pretty solid CSS
implementation in browsers, better XTML/CSS knowledge overall, and
JSTL.

Michael.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tiles vs. + XHTML/CSS

On 4/25/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> According to the APIs, it is actually one Controller per Tile, not one
> Controller per page ... doesn't that give you (Michael) the hook you'd need
> to grab the dynamic data for each fragment?

I guess it does. But how is this better/different than simply
including Struts actions or any other resources?

Also, can I submit to a particular controller? Does a controller have URL?

I guess I have to go read the docs one more time. Please excuse me for
heating up the discussion without checking the facts.

Michael.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tiles vs. + XHTML/CSS

On 4/25/06, Greg Reddin <[EMAIL PROTECTED]> wrote:
> > if I have a
> > composite page out of three JSP files, how would I run their
> > corresponding setup actions before the page is composed?
> >
> > Instead of including JSP pages I would include Struts actions (Will it
> > work with Tiles? I haven't tried it yet) like this (seems that I can
> > use include directive instead of dynamic include tag here):
>
> The thought scares me :-)  I haven't tried it like that.  Tiles used
> to allow you to specify a Struts action as a controller.  It probably
> still does but I haven't used that pattern in a long time and I can
> guarantee that Standalone Tiles will not support that.

I don't see why Tiles would care what kind of resource I want to use
to compose my page. At the higher abstraction level, I want to provide
a URL, and Tiles should obtain response generated by resource at this
URL, be it JSP fragment or Struts action or whatever else.

> You should
> really check out the Controller interface.  Sorry, the documentation
> is non-existent currently, but it's in the pipeline.  It allows you
> to specify a controller class that will be executed before the
> definition is rendered.  In that class you have access to the Tiles
> Context and whatever else you need.  The only drawback is that I
> don't believe you can specify a controller for each piece of the
> composite page.

Having one controller is better than having nothing.

Consider this. Say, most fragments do not contain dynamic data, like
static header or footer. I can use Tiles or I can use two JSP includes
in a separate file, and include this file. Same thing?

Now, I have header and footer, and both require dynamic data from
database. Who is going to pull it out? Apparently, Struts action.
Which one? You said I can specify one controller. So this controller
should know that it pulls data for two specific fragments. Now I have
a controller tied to two fragments. Is this a good programming
practice? What if I later decide to add, say, an advertisement block?
Should I modify the controller to pull info from the database with ads
as well? What if I want to use this ad block only on some pages.
Should I have two different controllers? See, this is what I am
talking about. Tiles combines view sections, not components.

The point I am trying to make, it seems to me that Tiles helps with
composing a page from simple subviews. But when a subview requires
dynamic data, Tiles does not really help. With Tiles, actions and JSP
fragments are separated. There are mostly independent JSP fragments,
there are controllers (one per page), there are input actions, that
process submitted data. This arraingment does not seem observable and
manageable to me, contrary to what Rick and you say. Maybe I am
missing something. Please excuse me if I sound pushy, I just really
try to understand the benefit of Tiles.

But returning back to my original question, I did not intend to
badmouth Tiles and to push my own ideas. I just asked, how Tiles
compares to XHTML+CSS. As I understood, the major Tiles benefit is
handling "dynamic" data, and encapsulating it in one single place like
definition file. But my example with dynamic data from database seems
to show that this setup is not possible with Tiles, Struts actions
must be involved.

Therefore, for static headers/footers regular JSP includes seem fine.
On the other hand, if I have highly dynamic data for every fragment, I
need to call respective setup actions, and it is not possible with
Tiles right now. As you stated, I can have only one controller per
definition. In both cases, Tiles is either on par with JSP includes,
or has some serious constraints.

What am I missing?

Michael.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tiles vs. + XHTML/CSS

On 4/24/06, Rick Reumann <[EMAIL PROTECTED]> wrote:
> Michael Jouravlev wrote:
>
> > So, the question I am asking: what are the real benefits of using
> > Tiles if I use JSP includes + XHTML/CSS for layout/styling? Can most
> > of Tiles features be implemented with XHTML/CSS?
>
> I guess some of it comes to a personal preference in regard to the
> dynamic content stuff that I didn't see you mention (or I read over your
> post too quickly).

No, I haven't mentioned it, thanks for taking time to explain it.

> For example what about things where your "header" section needs a title
> to display in the html, or what if you quickly want to change around
> what pages get 'injected' (for lack of a better word) with a particular
> div? To accomplish this without something like tiles, you 1) have to set
> up certain things in the request in your Action before you go to your
> page and  2) you have to have jstl logic to decide whether or not to
> display the information. Personally I find it much cleaner to have this
> stuff defined in one place. So for example, lets look at your master
> layout...
>
> 
> 
> //all your content
> 
>
> masterlayout.jsp
> 
> 
> 
>
> header.jsp
> --
> SOME COOL LOGO
>
> { Dynamic "MY SUPER TITLE" }
>
> SOME OTHER LOGO
> more other images
> ---
>
> Now in the above, how are you going to get your title into this header
> jsp? The only way I know of is that you'd have to set it up ahead of
> time in your action. What if someone decides that title needs to change?
> Personally I'd rather find all the titles in one place
> (tiles-definitions.xml) than have to find what Action it it is in and
> where in the Action you set it up.

If it is in the xml file, it is not dynamic anymore, is it? Or are you
saying that I can set title for every composite page? (I am
researching Tiles now, haven't worked with it before). In the latter
case, how is this better than setting a request-scoped variable right
in the composite page before 
tag? Ok, maybe it is better, because all dynamic or semi-dynamic stuff
is kept off the pages. But if the value is a really dynamic one, say
you read it from a database, then you cannot set it in the definition
file anyway, can you?

I think this is the problem with Tiles, it is not a component
technology, it is a view composition technology. It allows me to
combine JSPs, but in Struts JSPs are considered as data-aware dynamic
HTML, so JSPs are pretty dumb in terms that they do not contain
controller code or business-related code. Therefore JSPs should be
fronted with Struts action. Now can you explain me, if I have a
composite page out of three JSP files, how would I run their
corresponding setup actions before the page is composed?

Instead of including JSP pages I would include Struts actions (Will it
work with Tiles? I haven't tried it yet) like this (seems that I can
use include directive instead of dynamic include tag here):

somepage.jsp:
-

<%@ include file="masterLayout.jsp" %>

  //all your content

masterlayout.jsp

header.jsp
--
SOME COOL LOGO

${headerForm.mySuperTitle}

SOME OTHER LOGO
more other images
---

This way all my dynamic stuff is encapsulated into respective Struts
action/JSP pairs. I am guaranteed that setup action is always called,
and I can pull out whatever dynamic data I want, say from the
database.

> The other thing is that I'm still not convinced of the magic and wonders
> of css for layout. Personally to me it's often black magic voodoo. Sure,
> I'm sure some will say it's easy ...bla blah... BS I say. Complex
> layouts with css is ANYTHING but easy or intuitive. Sure for simple
> stuff it's fine, but I'll be willing to race almost any average css user
> in designing some complex layouts. They can use only css and divs. I can
> use tables. I bet you I'll be done much faster and it'll work in all
> browsers and it will be easy to understand (ok yes it will 'look' more
> cluttered, but it'll still be intuitive.) Ok done ranting about css
> positioning:)

I won't get into this, but csszengarden or alistapart are convincing
enough. Yes, CSS takes different skills, but this is the price that
has to be payed for better separating content and styling.

> PS: when you mention:
>
> Michael>>>>>
> <%@ taglib uri="http://struts.apache.org/tags-tiles"; prefix="tiles" %>
> 
>
>
>
> 
>
> I still have to specify all these  tags that refer to
> particular header/footer files (Definition solves that, see below).
> <<<< /michael
>
> The &quo

Tiles vs. + XHTML/CSS

2006-04-24 Thread Michael Jouravlev

Does using Tiles still makes sense in 2006? Please correct me if I am
wrong, but if I understand correctly, main Tiles featurs are:

* Uniform L&F (block layout, colors, etc)
* Tile definitions

Uniform L&F
---

The layout is defined in a layout file. Follows is the layout style
pulled right from Tiles page [1]:

<%@ taglib uri="http://struts.apache.org/tags-tiles"; prefix="tiles" %>

  

  

  
  

  
  

  


This antiquated sample does not promote good HTML design. It uses
table instead of div or span elements, and it uses HTML attributes
like "bgcolor".

The concrete page would use code like this [1]:

<%@ taglib uri="http://struts.apache.org/tags-tiles"; prefix="tiles" %>

  
  
  


I still have to specify all these  tags that refer to
particular header/footer files (Definition solves that, see below).

What if instead of using

  

one would use something like this:

  

and would have an appropriate set of rules for "header" class in a CSS
file? Would not it be the same without using Tiles layout file?

Tile definitions


Specifying  tags that refer to particular header/footer
files does not make a lot of sense, so Tiles allows to have
definitions in a JSP file or in XML. If I have definition in a JSP
file, I would include it with "include" directive.

Again, what if a JSP file with definitions contained just a list of
regular JSP includes for the header, menu and footer, and every
include would be wrapped into a div or span with specific CSS
id/class? Would not it be quite similar?

So, the question I am asking: what are the real benefits of using
Tiles if I use JSP includes + XHTML/CSS for layout/styling? Can most
of Tiles features be implemented with XHTML/CSS?

Michael.

[1] http://struts.apache.org/struts-action/struts-tiles/examples.html

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

回覆： RE: Session without cookies

Hi,

The test is done within the same tab in firefox.

Thanks.

Michael

--- abdurrahman sahin
<[EMAIL PROTECTED]> 說：

> are you sure that u did not start a new browser
> process each time.?
> because sessions are browser process based.
> starting a new process and opening a new window
> within a browser window are
> different things.
> 
> http://asahin.net
> 
> 
> -Original Message-
> From: Chan Michael
> [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 24, 2006 12:18 PM
> To: user@struts.apache.org
> Subject: Session without cookies
> 
> 
> Hi All,
> 
> I have been searching for hours and still cannot
> find
> any useful info. Hope you can help.
> 
> I am building a Struts app. (Struts 1.2.4 + Tomcat
> 5.5
> + Apache 2.0.55 + Spring 1.2.6) and want to use
> session without
> enabling cookies. I use  to create links
> so
> ;jsessionid is appended to the end. Fine. The
> problem
> I have is every time I access a page, a new session
> id
> is created so essentially everything stored in
> session
> is lost. Here is some output from my test action,
> test.do:
> 
> test.do
> =
> HttpSession session = request.getSession();
> System.out.println("Is session new? " +
> session.isNew());
> System.out.println("Session id: " +
> session.getId());
> 
> First access
> =
> Is session new? true
> Session id: B9F9E135DCBAC90AB2B5AEBCE901FAA5
> 
> Second access
> =
> Is sesssion new? false
> Session id: 8CCE7A388E76C0F56016E8F41E29E0E5
> 
> The session is not new but the id is different...I
> already set in Tomcat server.xml
> 
> 
> 
> What am I missing??
> 
> Thanks in advance.
> 
> Michael
> 
> ___
>  YM - 離線訊息
> 
>
就算你沒有上網，你的朋友仍可以留下訊息給你，當你上網時就能立即看到，任何說
> 話都冇走失。
>  http://messenger.yahoo.com.hk
> 
>
-
> 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]
> 
> 


___
 YM - 離線訊息
 就算你沒有上網，你的朋友仍可以留下訊息給你，當你上網時就能立即看到，任何說話都冇走失。
 http://messenger.yahoo.com.hk

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE： RE: Session without cookies

Hi Chandra,

As far as I know, the attribute "cookies" of the
"Context" node in Tomcat server.xml is the only place
I need to set. From the doc,

http://tomcat.apache.org/tomcat-5.5-doc/config/context.html

cookies:
Set to true if you want cookies to be used for session
identifier communication if supported by the client
(this is the default). Set to false if you want to
disable the use of cookies for session identifier
communication, and rely only on URL rewriting by the
application.

Thanks.

Michael

--- [EMAIL PROTECTED] 說：

> Michael,
> 
> isNew() is mostly depends on how server manages the
> session.
> Returns true if the client does not yet know about
> the session or if the client
> chooses not to join the session. For example, if the
> server used only cookie based
> sessions, and the client had disabled the use of
> cookies, then a session
> would be new on each request.
> 
> May be its worth checking your server session
> management.
> 
> Chandra
--- Chan Michael <[EMAIL PROTECTED]> 說：

> Hi Chandra,
> 
> Thanks for your prompt reply.
> 
> I have checked many many times and I have 100% sure
> there is no 
> 
> Request.getSession(true);
> 
> in all my action classes.
> 
> Thanks.
> 
> Michael
> 
> --- [EMAIL PROTECTED] ：
> 
> > I think some where(may be in the action class
> > association with the action /test.do) you are
> > creating new session each time for each request.
> > Most possible mistake could be using
> > 
> > Request.getSession(true);
> > 
> > See below documentation from Servlet
> Specifications
> >
>
**
> > getSession()
> > public HttpSession getSession()
> > Returns the current session associated with this
> > request, or if the request does not have a
> session,
> > creates one.
> > Returns: the HttpSession associated with this
> > request
> > See Also: getSession(boolean)
> > 
> > getSession(boolean)
> > public HttpSession getSession(boolean create)
> > Returns the current HttpSession associated with
> > this request or, if if there is no current session
> > and create is true, returns a new session. If
> create
> > is false andthe request has no valid
> HttpSession,
> > this method returns null.
> > 
> > To make sure the session is properly maintained,
> you
> > must call this method before the response is
> > committed. If the container is using cookies to
> > maintain session integrity and is asked to create
> a
> > new session when the response is committed, an
> > IllegalStateException is thrown.
> > 
> > Parameters:
> > true - to create a new session for
> this
> > request if necessary; false to return null if
> > there＊s no current session Returns: the
> HttpSession
> > associated with this request or null if create is
> > false and the request has no valid session
> > See Also: getSession() 
> >
>
**
> > 
> > Chandra
> > -Original Message-
> > From: Chan Michael
> > [mailto:[EMAIL PROTECTED] 
> > Sent: Monday, April 24, 2006 2:48 PM
> > To: user@struts.apache.org
> > Subject: Session without cookies
> > 
> > Hi All,
> > 
> > I have been searching for hours and still cannot
> > find any useful info. Hope you can help.
> > 
> > I am building a Struts app. (Struts 1.2.4 + Tomcat
> > 5.5
> > + Apache 2.0.55 + Spring 1.2.6) and want to use
> > session without
> > enabling cookies. I use  to create
> links
> > so ;jsessionid is appended to the end. Fine. The
> > problem I have is every time I access a page, a
> new
> > session id is created so essentially everything
> > stored in session is lost. Here is some output
> from
> > my test action,
> > test.do:
> > 
> > test.do
> > =
> > HttpSession session = request.getSession();
> > System.out.println("Is session new? " +
> > session.isNew()); System.out.println("Session id:
> "
> > + session.getId());
> > 
> > First access
> > =
> > Is session new? true
> > Session id: B9F9E135DCBAC90AB2B5AEBCE901FAA5
> > 
> >

回覆： RE: Session without cookies

Hi Chandra,

Thanks for your prompt reply.

I have checked many many times and I have 100% sure
there is no 

Request.getSession(true);

in all my action classes.

Thanks.

Michael

--- [EMAIL PROTECTED] ：

> I think some where(may be in the action class
> association with the action /test.do) you are
> creating new session each time for each request.
> Most possible mistake could be using
> 
> Request.getSession(true);
> 
> See below documentation from Servlet Specifications
>
**
> getSession()
> public HttpSession getSession()
>   Returns the current session associated with this
> request, or if the request does not have a session,
> creates one.
>   Returns: the HttpSession associated with this
> request
> See Also: getSession(boolean)
> 
> getSession(boolean)
> public HttpSession getSession(boolean create)
>   Returns the current HttpSession associated with
> this request or, if if there is no current session
> and create is true, returns a new session. If create
> is false and  the request has no valid HttpSession,
> this method returns null.
> 
> To make sure the session is properly maintained, you
> must call this method before the response is
> committed. If the container is using cookies to
> maintain session integrity and is asked to create a
> new session when the response is committed, an
> IllegalStateException is thrown.
> 
> Parameters:
> true - to create a new session for this
> request if necessary; false to return null if
> there＊s no current session Returns: the HttpSession
> associated with this request or null if create is
> false and the request has no valid session
> See Also: getSession() 
>
******
> 
> Chandra
> -Original Message-
> From: Chan Michael
> [mailto:[EMAIL PROTECTED] 
> Sent: Monday, April 24, 2006 2:48 PM
> To: user@struts.apache.org
> Subject: Session without cookies
> 
> Hi All,
> 
> I have been searching for hours and still cannot
> find any useful info. Hope you can help.
> 
> I am building a Struts app. (Struts 1.2.4 + Tomcat
> 5.5
> + Apache 2.0.55 + Spring 1.2.6) and want to use
> session without
> enabling cookies. I use  to create links
> so ;jsessionid is appended to the end. Fine. The
> problem I have is every time I access a page, a new
> session id is created so essentially everything
> stored in session is lost. Here is some output from
> my test action,
> test.do:
> 
> test.do
> =
> HttpSession session = request.getSession();
> System.out.println("Is session new? " +
> session.isNew()); System.out.println("Session id: "
> + session.getId());
> 
> First access
> =
> Is session new? true
> Session id: B9F9E135DCBAC90AB2B5AEBCE901FAA5
> 
> Second access
> =====
> Is sesssion new? false
> Session id: 8CCE7A388E76C0F56016E8F41E29E0E5
> 
> The session is not new but the id is different...I
> already set in Tomcat server.xml
> 
> 
> 
> What am I missing??
> 
> Thanks in advance.
> 
> Michael
> 
> ___
>  YM - 褩��洘
> 
>
憩呾斕�]衄奻鋒ㄛ斕腔攬衭゛褫眕隱狟�洘緻斕ㄛ�斕奻鋒�r憩夔蕾撈艘善ㄛ￤睡挲�飲�衿萯均�
>  http://messenger.yahoo.com.hk
> 
>
-
> 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]
> 
> 


___
 YM - 離線訊息
 就算你沒有上網，你的朋友仍可以留下訊息給你，當你上網時就能立即看到，任何說話都冇走失。
 http://messenger.yahoo.com.hk

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Session without cookies

Hi All,

I have been searching for hours and still cannot find
any useful info. Hope you can help.

I am building a Struts app. (Struts 1.2.4 + Tomcat 5.5
+ Apache 2.0.55 + Spring 1.2.6) and want to use
session without
enabling cookies. I use  to create links so
;jsessionid is appended to the end. Fine. The problem
I have is every time I access a page, a new session id
is created so essentially everything stored in session
is lost. Here is some output from my test action,
test.do:

test.do
=
HttpSession session = request.getSession();
System.out.println("Is session new? " +
session.isNew());
System.out.println("Session id: " + session.getId());

First access
=
Is session new? true
Session id: B9F9E135DCBAC90AB2B5AEBCE901FAA5

Second access
=
Is sesssion new? false
Session id: 8CCE7A388E76C0F56016E8F41E29E0E5

The session is not new but the id is different...I
already set in Tomcat server.xml



What am I missing??

Thanks in advance.

Michael

___
 YM - 離線訊息
 就算你沒有上網，你的朋友仍可以留下訊息給你，當你上網時就能立即看到，任何說話都冇走失。
 http://messenger.yahoo.com.hk

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Session lovers... how do you handle this 'common?' situation?

2006-04-22 Thread Michael Jouravlev

Since your forms are stateful, you can have a mode/status field with
either "view existing" or "edit existing" or "create new" or "empty".

You will have two clear phases: on input phase you send "create"
message, clear form and set status to "create new". Since you use
session scope, you can safely use redirect. You redirect to an action
that renders your object according to its state. So, for "create new"
it will render input form with "New item" header.

I use nested objects in the actionform and simply create a new
business object for "create new" operation.

So, whenever you navigate to your render action, it will check current
status and show an appropriate page.

Editing is the same, but you do not clean the form. Render works the
same, but the header says "update item". The idea is that you handle
create and update operations using the same render/submit code, you
only initialize form differently.

If interested, see Struts Dialogs sample:
https://sourceforge.net/project/showfiles.php?group_id=49385&package_id=154597

Also see http://wiki.apache.org/struts/DataEntryForm

Michael.

On 4/21/06, Rick Reumann <[EMAIL PROTECTED]> wrote:
> I haven't used Session scope for my ActionForms in a lo time,
> but now I need to for a particular scenario.
>
> The problem I'm running into is imagine you click on a link to "Create
> New" - in which case, after you pass through your Action, you'd go to
> a page backed by the session-scoped ActionForm. If the ActionForm has
> stuff already in it, form say an edit process done earlier, this will
> show up on your form which isn't what you want in a "create new"
> sencario. To avoid this on the "new" situations I thought I could just
> hava a setUpForNew(..) dispatch method and do something like...
>
> public ActionForward setUpForNew(ActionMapping mapping, ActionForm form, ...{
>   form = new MyForm();
>   //maybe set a few things before I leave
>   //return
> }
>
> Then I mistakingly thought when I return to my JSP, the backing
> ActionForm would be pointing to this new ActionForm instance and all
> my properties would be set to their defaults.
>
> However, that above apparently is not working and I think I remember
> way back running into this and I think I remember the problem maybe
> being related to that the form bean referenced in my action method
> isn't really a true reference to the one that is actually in Session
> scope .. I think Struts does some funky stuff behind the scenes..
> can't remember all the details.
>
> So for those of you that use Session scope a lot, what is the easiest
> way to get a 'blank reset' form? Obviously I could go and reset every
> single property in the reset method and call that from my Action, but
> that seems like a lot of work and could get sloppy and introduce
> errors (later on you forget to reset a prop there etc).
>
> Am I totally missing something simple to accomplish what I want?
>
> Thanks,
>
> --
> Rick
>
> -
> 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: Calling an action from another action

2006-04-20 Thread Michael Jouravlev

On 4/20/06, Rick Reumann <[EMAIL PROTECTED]> wrote:
> So again, really think about whether you need to go from one action to 
> another.
> Lastly, if you do need to it (which from the above I doubt you need
> to), I wouldn't do it in the Action class but simply still return as
> usual but have your action-mapping forward to the new action.

Won't work if you (1) want to redirect, (2) want to pass parameter
along, (3) do not want to use session.

On topic, no idea why session is invalidated.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

SAF2 interceptors/interfaces vs. explicit method calls (was: How to execute code in an Action when ActionForm validation fails?)

2006-04-19 Thread Michael Jouravlev

Dave, thanks for explanation. Now, can you explain this: how URLs are
mapped to actionbeans in WebWork? Looking at the example [1] on
OpenSymphony website, I see the same pattern as in SAF1:

  ...

The above means, that http://somesite/helloWorld.action will be
dispatched to HelloWorld actionbean. The same as in SAF1. So, we have
a location that a user can type in the browser, and the endpoint.
One-to-one relationship, which theoretically can be changed, but I
believe is done as rarely as in SAF1 apps, that is, almost never.

Now, if I know exactly which action bean will be called in respond to
a certain URL, what is the point in all these interceptors and
interfaces? Is not it easier to call something like

  populate();
  validate();
  prepare();

from an action bean? Why should I go through pain of configuring
interfaces instead of having a simple one-liner? I will not break
apart from typing one or two or even five lines of code, but my code
will be readable by me or everyone else. Instead of checking what
Validatable interface does, one would see a call to validate() method.

I want to be able to call *all and every* lifecycle and service
methods directly instead of implementing interfaces (of course, they
lifecycle methods should be well documented). For example, instead of
autopopulation I would prefer to call bean.populate() explicitly when
I consider it appropriate.

Same with interceptors. If the endpoint is known, what is the benefit
in interceptors vs. explicit call of one-two-three methods from an
actionbean?

[1] 
http://www.opensymphony.com/webwork/wikidocs/Basic%20configuration%20and%20your%20first%20action%20-%20Hello%20WebWorld.html

On 4/19/06, David Evans <[EMAIL PROTECTED]> wrote:
> I'm just getting started with Webwork and so am no expert, but here's
> a brief description of the interceptor business. :)
>
> So in struts a requests workflow is controlled by the
> RequestProcessor.process() method. And simplified it does something like
> this:
> 1. get path
> 2. get mapping from path
> 3. populate form bean
> 4. validate form bean
> 5. call execute method on action
> 6. process forward result
>
> Because struts has this all in a single method, hard coded in the above
> order, the workflow for struts is more or less predetermined. And so to
> get around it you had the two choices of extending RequestProcessor and
> overriding the calls in the process method, or just turning off the
> validation part of the flow and handling it yourself.
>
> In Webwork, the action config has a subelement that points to a
> interceptor reference, which may be a single interceptor, or collection
> of them called a "stack".  The interceptor is a class that wraps itself
> around the actions execution, like a filter, only it has access to the
> action itself. It can have functionality both before and after the
> action execute. So the populate and validate functionality of the
> RequestProcessor is implemented in Webwork as two interceptors, called
> params and workflow. For any particular action you can, in the main
> config file, configure which interceptors will be called and in what
> order.  Webwork also uses a set of flagging interfaces that when
> implemented mark an action as having special functionality that an
> interceptor can make use of. In the case of the workflow interceptor, it
> looks to see if the action implements a Validateable interface, which
> contains a single method, "validate". If so, it calls that method. It
> also looks to see if the action implements a second interface
> ValidationAware. If so, and there were errors in validation, the
> workflow interceptor shortcircuits the execution and forwards to the
> input. So this behaves just like struts, except that you have more fine
> grained control on a action by action basis. There is another
> interface/interceptor pair called Preparable/prepare. This one lets you
> run a prepare method in your action, and in the default interceptor
> stack, this one comes before the params and workflow interceptors. So
> all of the setup that you need for the elements of the form can be
> placed in the prepare method, so that even if validation fails, the form
> still has its elements correctly setup.
>
> So thats an overview from a Webwork newbie. I'm halfway through Webwork
> in Action, and am starting my first Webwork application, and i have to
> say, I'm really excited, and i think using Webwork is going to make life
> much easier. And the book is very well written.
>
> Dave

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to execute code in an Action when ActionForm validation fails?

> On 4/18/06, Dave Newton <[EMAIL PROTECTED]> wrote:
> > I just have a base Action class that will forward to the input on a GET
> > or validate and do the right thing based on the results of the validation.
> >
> > So, simplified, my subclasses may optionally override executeGet and/or
> > executePost (although I actually have the equivalent of preprocessForm
> > and postprocessForm methods, so I rarely need to do that) etc.

I was there a year ago ;-) It works well if all your input comes with
POST request, that is, from HTML forms, like in ASP.NET or JSF. What
if you need to trigger an event with a link? I believe that JSF (or
one of its implementations) has command link for that, but it requires
Javascript. With EventActionDispatcher class I can trigger event
without having to use Javascript.

On 4/18/06, Eric Rank <[EMAIL PROTECTED]> wrote:
> The idea of doing some logical branching within execute so the right
> thing happens makes sense.

> Unless anyone can convince me otherwise, from here on out it's
> validate = "false"

See these as well:
http://wiki.apache.org/struts/DataEntryForm
http://wiki.apache.org/struts/EventActionDispatcher

Michael

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to execute code in an Action when ActionForm validation fails?

On 4/18/06, Eric Rank <[EMAIL PROTECTED]> wrote:
> I agree that the manual validation approach is very good at keeping
> related code in one place. This is how I'm currently choosing to solve
> this problem.
>
> However, I feel that it's sloppy because it requires additional logic.
> I try to avoid using unecessary logic for the sake of keeping code
> readable. When I have a bunch of nested logic to sift through, it
> doesn't take more than 3 levels before I begin to lose my place in my
> own neural memory stack. Suddenly, 'execute' starts doing too much.
>
> In my mind, optionally implementing an interface / method designed to
> run when the form validation fails seems very elegant to me. The code
> is much more compartmentalized.

In my mind, the code is readable when I can read what it's doing. With
validate="true" I cannot.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to execute code in an Action when ActionForm validation fails?

On 4/18/06, Eric Rank <[EMAIL PROTECTED]> wrote:
> I have a problem, which I am certain you all face regularly:
>
> When validation fails for an ActionForm, I need to set attributes in
> the request object, but I can't because the 'execute' code doesn't
> run. How have you managed to set attributes on the request object when
> validation fails?
>
> I have a couple of solutions in mind.
>
> 1. Validating Manually:

I believe that this is the best solution. I use this one exclusively,
I don't use autovalidation and "input" attribute of "action" tag.
Works especially well with dispatch-style actions.

Michael.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: friday ha ha