Re: Session-scoped forms and synchronization...

[Jing Zhou]

- Original Message - 
From: "Bob Lee" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, October 28, 2003 10:00 AM
Subject: Re: Session-scoped forms and synchronization...


> Craig R. McClanahan wrote:
>
> > Well, you can get more than one *created*, but only one will actually
> > be stored as a session attribute if the attribute name is the same.
> > Synchronizing the session.setAttribute() method would be pointless;
> > the container guarantees that this won't break anything.  So, exactly
> > what portion of the code would you propose to synchronize?
>
> One will overwrite the other in the session, yes, but the
> RequestProcessor doesn't pull it back out of the session. It uses the
> instance it created, so both could be used concurrently.

The problem you are describing here is a real one. But synchronizing
a portion of RequestProcessor would not *cleanly* solve the problem:

1) Two concurrent threads could still corrupt the same session scoped
form bean after the threads leave the synchronized section.

2) The problem is due to concurrent threads from ONE user and
synchronizing a portion of RequestProcessor might have
impact to ALL users' threads. (You do not want to wait because
someone else is creating his/her form bean).

We just have this considered but our codes have not been
released with Carrier yet. The idea is to use a filter to synchronize
on a *personal* session scoped object. So nothing need to
be changed in the RequestProcessor.

But it requires Servlet 2.3 in place and could be *very* application 
specific due to our requirements. For example, we do not allow
the second thread to enter the RequestProcessor if the first one
has not been finished yet (very conservative except for cancel event).
We also have to deal with cases when the first thread is a long
running job.

I would suggest people consider filters when solving this problem 
in proposals. Filters can be used as options to protect system's
integrity.

Any other alternatives or ideas?

>
> Bob
>
>

Jing
Netspread Carrier
http://www.netspread.com


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

Re: Struts-chain Behavior Discussion

[Jing Zhou]

- Original Message - 
From: "PILGRIM, Peter, FM" <[EMAIL PROTECTED]>
To: "'Struts Developers List'" <[EMAIL PROTECTED]>
Sent: Thursday, October 16, 2003 5:09 AM
Subject: RE: Struts-chain Behavior Discussion


> > -Original Message-
> > From: Jing Zhou [mailto:[EMAIL PROTECTED]
> > 
> > - Original Message - 
> > From: "PILGRIM, Peter, FM" <[EMAIL PROTECTED]>
> > To: "'Struts Developers List'" <[EMAIL PROTECTED]>
> > Sent: Monday, October 13, 2003 5:39 AM
> > Subject: RE: Struts-chain Behavior Discussion
> > 
> > 
> > > *Question of Architecture*
> > > 
> > > Does this mean that we have solved the hideous Action 
> > Chaining debate?
> > > In theory an Struts Action could be refactored to be a type of 
> > > ``Command'' and therefor Actions could be chained.
> > 
> > Whenever there is a debate and each side seems to be very reasonable
> > in certain contexts, it is more likely the system itself is 
> > in-complete or
> > fails to meet the requirements. We use Controller Delegation Model
> > and/or Event Handler(s) to deal with such problems.
> >
> 
> What are you talking about here? What I am talking about or rather
> aiming the ability create common Struts components.

I am talking about the Action Chaining debate (if we refer to the
same problem) could be solved with fine grained controls in Action
if the extended Action classes could provide event handlers or 
delegation model, or other similar facility.

> > Commons-chain is not intended to solve that debate topic originally.
> > Last year, people found when they have two RequestProcessor(s), say
> > A and B, if they need to design a new RequestProcessor C that has
> > methods from both A and B, the best they can do is to let C extend
> > one of them, say A, and then copy the methods (possibly line by line)
> > from B. So a configurable RequestProcessor is somehow needed
> > to reuse portions of several RequestProcessor(s). This is what
> > commons-chain is intended to solve initially.
> > 
> 
> Ay Ay, Captain! I don't mean to rain on the parade. I was involved
> in the composable request processor discussion way way back in the
> summer. As the Expresso core committer who integrated Struts 1.1 
> I found also a futuristic design issues merging the 
> TilesRequestProcessor and our own ExpressoRequestProcessor.
> How would you merge the next processor, and the next one, and
> the next one after that.
> 
> > But the problems have not been cleanly solved in regard to 
> > reusability.
> > When a Command is deeply coupled with other Command(s) in a
> > chain through one or more flags/states in Context (say cancel flag,
> > invalid token flag, invalid validation flag, etc.) its 
> > reusability in a 
> > different chain is very low in theory or very difficult to 
> > use (you need
> > to configure many flags to get it work and subject to the condition
> > the new Context offers the same set of flags).
> >
> 
> I dont understand the reusability problems. To me having
> read the Gang of Four original book, the design of Chain
> of Responsibilty and Craig's code and what he has said
> to me (to us) on list makes this a non-issue. Actual design
> pattern is a linear path. The only difference I can see is 
> the context, which I guess you should treat it as opaque 
> object any way.

Since you involved in the composable RequestProcessor
discussion, the intention of such design is to *reuse* as
much as possible the portions of different RequestProcessor(s).
Instead of creating a new RequestProcessor for slightly
different requirements, commons-chain could help to
configure the new RequestProcessor in terms of a chain
with its commands borrowed from existing commands for
other RequestProcessor chains. So we could *reuse* the
commands without creating new RequestProcessor class.

> 
> If you write a Command that need various context setting
> that you should declare in the javadoc or documentation.
>  
> > I did a little exercise to reduce the command coupling degree by
> > introducing a NestCommand. Like LookupCommand to execute
> > a specified chain, NestCommand always return false regardless
> > what nested chain returns. So a termination of nested chains does
> > not force a termination of calling chains when NestCommand
> > is used. The following picture illustrates the idea:
> > 
> 
> You said your NestCommand always returns `false'

Correct! So it never terminates calling chains by definition.

> 
> > Main Chain:
> > Nest

Re: Struts-chain Behavior Discussion

[Jing Zhou]

- Original Message - 
From: "Ted Husted" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, October 16, 2003 4:37 AM
Subject: Re: Struts-chain Behavior Discussion


> Jing Zhou wrote:
> > Commons-chain is not intended to solve that debate topic originally.
> > Last year, people found when they have two RequestProcessor(s), say
> > A and B, if they need to design a new RequestProcessor C that has
> > methods from both A and B, the best they can do is to let C extend
> > one of them, say A, and then copy the methods (possibly line by line)
> > from B. So a configurable RequestProcessor is somehow needed
> > to reuse portions of several RequestProcessor(s). This is what
> > commons-chain is intended to solve initially.
> 
> The composable request processor is what finally got Craig to "scratch 
> the itch", but he's been mentioning the Chain of Responsibility pattern 
> for some time, in several contexts (so to speak).
> 
> I don't think it's fair to say Commons-Chain is intended to solve any 
> specific Struts issue. The request processor brought the work to a head, 
> but Chain speaks to the need for a business layer framework. The 
> RequestProcessor is an example of where Struts needs to utilize what 
> amounts to business logic. The rules we want the request processor to 
> follow are not uniform and subject to a RFP, but may differ from 
> application to application. In other words, we want to create arbitrary 
> request processors -- and "arbitrary" often indicates that some flavor 
> of business logic is in play. =:)
> 
> It's true that the RequestProcessor is an important proof of concept, 
> but, it's just the beginning. IMHO, Chain is intended to provide core 
> utility that many business layer implementations share, which happens to 
> include the request processor implementation. Another likely candidate 
> in Struts space would be chaining validation commands.

Yes. That's why I am saying it is intended to solve *initially*. Since
common-chains is in sandbox status, more new concepts could
be explored/debated and when it matures we'll have a solid foundation.

> 
> -Ted.
> 
> 

Jing

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

Re: Struts-chain Behavior Discussion

[Jing Zhou]

- Original Message - 
From: "PILGRIM, Peter, FM" <[EMAIL PROTECTED]>
To: "'Struts Developers List'" <[EMAIL PROTECTED]>
Sent: Monday, October 13, 2003 5:39 AM
Subject: RE: Struts-chain Behavior Discussion


> *Question of Architecture*
> 
> Does this mean that we have solved the hideous Action Chaining debate?
> In theory an Struts Action could be refactored to be a type of 
> ``Command'' and therefor Actions could be chained.

Whenever there is a debate and each side seems to be very reasonable
in certain contexts, it is more likely the system itself is in-complete or
fails to meet the requirements. We use Controller Delegation Model
and/or Event Handler(s) to deal with such problems.

Commons-chain is not intended to solve that debate topic originally.
Last year, people found when they have two RequestProcessor(s), say
A and B, if they need to design a new RequestProcessor C that has
methods from both A and B, the best they can do is to let C extend
one of them, say A, and then copy the methods (possibly line by line)
from B. So a configurable RequestProcessor is somehow needed
to reuse portions of several RequestProcessor(s). This is what
commons-chain is intended to solve initially.

But the problems have not been cleanly solved in regard to reusability.
When a Command is deeply coupled with other Command(s) in a
chain through one or more flags/states in Context (say cancel flag,
invalid token flag, invalid validation flag, etc.) its reusability in a 
different chain is very low in theory or very difficult to use (you need
to configure many flags to get it work and subject to the condition
the new Context offers the same set of flags).

I did a little exercise to reduce the command coupling degree by
introducing a NestCommand. Like LookupCommand to execute
a specified chain, NestCommand always return false regardless
what nested chain returns. So a termination of nested chains does
not force a termination of calling chains when NestCommand
is used. The following picture illustrates the idea:

Main Chain:
NestCommand
 Nested Chain:
 NestedCommand1
 NestedCommand2
 NestedCommand3
LastCommand

If any nested commands return true, the control flow will
*jump* to LastCommand. It seems to give an answer to my
original question without the notion of branch behavior :-)

NestedCommand2 does not need to check any flag set by
NestedCommand1 in this way and NestedCommand3 does
not need to check any flags set by NestedCommand1 and 2.
They could be reused in other chains without concerning about
flags.


Jing
Netspread Carrier
http://www.netspread.com






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

Re: Struts-chain Behavior Discussion

[Jing Zhou]

> >I could be convinced if I see a possible mechanism that deals with
> >the command coupling problem and state storage problem.
> >  
> >
> Jing, it is sounding more and more like what you want is a scripting 
> control flow language expressed in XML.  That is absolutely, totally, 
> *not* what commons-chain is about.  Feel free to invent your own package 
> for this purpose.  Feel free to popularize it all you want.  You're even 
> welcome to say "this is an extension to commons-chain that supports 
> branches and labels".  But commons-chain itself is going to stay focused 
> on the pure CoR pattern, which has absolutely no notion of branches or 
> labels in the fundamental APIs.  Such things, therefore, do not belong 
> in the fundamental commons-chain APIs.
> 
> I'm not going to bother to respond to any further discussion along this 
> line -- as far as I'm concerned, the case for adding branches and labels 
> has failed to illustrate that it has any technical merit (for 
> commons-chain), and I'm not interested in spending any more time 
> discussing it.  What you do in your own projects (open source or not) 
> is, of course, totally up to you.

I would agree we put the discussion aside because the idea
behind "branch behavior" is premature. I also agree the rational that
we do it all the way or do not do it at all. The "branch behavior"
gives us something that is done only half way.

When you roll back (no branches), the command coupling problem
through states is *my* (the chain designer) problem or is *my* fault
by definition if the new command is not correctly coupled with other
commands. This raises another question: How many chances
this command could be reused in another chain in general? I do not
believe we are going to have a clear answer very soon. Practice might
tell us. So, I put it on hold for further study of the chain's behaviors
until more feedback come from practices.

> Craig

Jing


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

Re: Struts-chain Behavior Discussion

[Jing Zhou]

> In the example, the L1 labeled chain is invoked by Class1 if it returns
> false.

Sorry, it should be changed to "if it returns true" (to terminate the
original
chain instance).

Jing


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

Re: Struts-chain Behavior Discussion

[Jing Zhou]

- Original Message - 
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, October 07, 2003 2:22 PM
Subject: Re: Struts-chain Behavior Discussion


> >
> >You do not need to determine Class4 was always run or not,
> >actually it is determined at runtime. Its definition is included
> >in every labeled chain by default.
> >
> It is absolutely necessary to understand the control flow if you want to
> customize it.  The above would support all of the following flows
> (assuming that no command returns true prematurely):
> * Class1 - Class2 - Class3 - Class4
> * Class1 - Class3 - Class4
> * Class1 - Class2 - Class4
>
> Now, if I want to add a new step that has to occur before Class3, but is
> ONLY executed if Class3 will be executed, how do I do that?  I have to
> change which command gets label L1, which is bad for the same reason
> that "goto" in programming languages is bad.

You could easily assign the label L1 to the new command before Class3
in the chain. A chain definition is normally very very small (5-30 lines)
comparing with programs (up to 8000 or more lines). I do not see any
difficulties to manipulate such a small section. Note that the thing we are
dealing with is a config file, not a program (with a "go to" from line 67 to
line 7598 :-)

>
> >
> >The idea is that you do not have to define a separate chain else where
> >if you could re-use a labeled chain in the current chain definition.
> >You could also ignore  labels if any, just use the chain as is.
> >
> >
> If you're going to (potentially) ignore the labels and branches, why
> have them in the first place?

In the example, the L1 labeled chain is invoked by Class1 if it returns
false. If you do not need the particular L1 labeled chain in the current
chain definition, you could ignore it. But the label could serve as
an entry point for other chains outside the scope to invoke the L1
labeled chain if they find it useful.

>
> Or, to put it differently, conditional behavior should be a feature of
> the Command implementation ("is the world in the correct state for me to
> perform this action?").  If the current state is not correct, it should
> just return false to let the chain continue.  That's why a change based
> on Ted's suggestion:
>
> (1) LookupCommand
> (2) ExceptionCatcher
> (3) SelectLocale
> (4) SelectAction
> (5) CreateActionForm
> (6) PopulateActionForm
> (7) ValidateActionForm (must save state in the Context)
> (NEW) SelectInput [skip if validation succeeded]
> (8) CreateAction [skip if validation failed]
> (9) ExecuteAction [skip if validation failed]
> (10) PerformForward
>
> is actually the cleanest overall approach.  The user should not have to
> even *know* what conditions the commands care about to determine whether
> they are executed.  Thus, you would end up with a clean and simple chain
> definition:
>
> 
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
> 
>
> Now, if I want to insert something that always happens before
> ValidateActionForm, I know exactly where it goes.  I don't have to worry
> about whether ValidateActionForm is going to branch or skip, because
> it's not ... SelectInput and friends decide for themselves whether they
> are relevant.
>
> OK, I've convinced myself that this is the right approach :-).  So I'll
> likely be changing struts-chain to this tonight, and adding the
> appropriate mechanisms for ValidateActionForm to pass on the success or
> failure state information.

I have not been fully convinced by this approach yet. Taking a general
chain definition as follows,


  
  
  
  ...
  
  


If I want to add a new command C before C19, I'll have to figure out
who set up a state before C19, even on one does it. Also,
I'll have to figure out where the state is located if any and see if the new
command C honor that state or not (command coupling problem).

Furthermore, assume the command C3 set up a state, but we could
see any commands between C3 and C19 could set up a second one
or third one. Where the states are stored systematically is another
question (state storage problem).

I could be convinced if I see a possible mechanism that deals with
the command coupling problem and state storage problem.

>
> Craig
>

Jing



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

Re: Struts-chain Behavior Discussion

[Jing Zhou]

> It's not so much about "complexity" as it is readability.

The "complexity" in my message refers to the verboseness of the
chain-config.xml file. What I am looking for is a possible
simpler syntax to do the job.

> If I care what Process Action is then I can see the detail.  Goto's
> were deemed dangerous because of the behavior that they hide.  They
> obfuscate the flow of the code.  It's not really any different here
> either.
> 
> > > 
> > > 
> > > 
> > > 
> 
> I had a longer response prepared to your other post, but decided it
> was too wordy. :)  One example where the obfuscation comes in is that
> I had to look at it for a bit before determining that Class4 was 
> always run.  If a few more commands are thrown in, it really gets
> confusing.

You do not need to determine Class4 was always run or not,
actually it is determined at runtime. Its definition is included 
in every labeled chain by default.

The idea is that you do not have to define a separate chain else where
if you could re-use a labeled chain in the current chain definition.
You could also ignore  labels if any, just use the chain as is.

> 
> -Paul
> 

Jing


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

Re: Struts-chain Behavior Discussion

[Jing Zhou]

- Original Message - 
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Monday, October 06, 2003 7:25 PM
Subject: Re: Struts-chain Behavior Discussion


> I actually think this is better, because you can customize *just* the B1
> path or *just* the B2 path if you want to, without having to mess with
> MAIN at all.

I believe people should use them as they see fit. Just like choosing inner
classes or regular classes in an application, if you want to take advantage
of surrounding environments, inner classes might be more suitable. Regular
classes give you independent customization, like what you point out here.
But I do not want to say which one is better without specific goals,
because sometime people want to centralize logics and keep
them in sync, instead of specifying Class4 in three different places.

> UI workflows across requests are not what commons-chain is really for --
My message might not be that clear. I did not intend to use commons-chain
for UI workflows across requests. I am considering to design UIs to
construct chains. UIs' necessary attributes must be identified at first. The
result chains will be used in application modules (in Struts). I did
an estimation and found many use cases are just to jump to the last
command. So I am asking the list if there is a direct "jump" for those
simple use cases.

> However, it's also feasible to build branches and labels in by subclass
> CommandBase and ChainBase appropriately, instead of modify Command and
> Chain.  That would be the suggested way to prototype something.

Yes. I need to look at CommandBase and ChainBase for possible
extensions.

Jing


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

Re: Struts-chain Behavior Discussion

[Jing Zhou]

- Original Message - 
From: "Paul Speed" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Monday, October 06, 2003 5:58 PM
Subject: Re: Struts-chain Behavior Discussion


> 
> 
> Jing Zhou wrote:
> > 
> > - Original Message -
> > From: "Paul Speed" <[EMAIL PROTECTED]>
> > To: "Struts Developers List" <[EMAIL PROTECTED]>
> > Sent: Monday, October 06, 2003 3:40 AM
> > Subject: Re: Struts-chain Behavior Discussion
> > 
> > >
> > > (1) LookupCommand
> > > (2) ExceptionCatcher
> > > (3) SelectLocale
> > > (4) Process Action
> > > (a) SelectAction
> > > (b) CreateActionForm
> > > (c) PopulateActionForm
> > > (d) ValidateActionForm
> > 
> > If validations fail in (d), the (e) and (f) are not necessary.
> 
> Right, but then it can just stop that particular chain.  I was under
> the impression that a chain can be aborted.  If validation fails
> then the "Process Action" chain could abort and the main chain would
> continue on to "PerformForward".
> 
> Incorporating Craig's comments about "SelectInput" on validation 
> failure are left as an exercise for the reader. ;)

I see what you mean. But the complexity is roughly the same
as or more than the original one in chain-config.xml. What I am 
looking for is a simpler syntax to do the same thing without explicitly
defining possible nested chains. See my previous message, an example 
is given.

> 
> -Paul

Jing


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

Re: Struts-chain Behavior Discussion

[Jing Zhou]

- Original Message - 
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Monday, October 06, 2003 11:26 AM
Subject: Re: Struts-chain Behavior Discussion


> >
> >Looks like you are asking less while I am asking more :-)
> >
> >
>
> Exactly.  More == Bloat unless you really need it.  And I can't see that
> I need it yet.

I did not see it until I was thinking a way to build user interfaces for
Chain.
If labeled commands could be regarded as implicitly defined chains, then
we have a shorter chain-config.xml for the following MAIN chain:
   
 




 
   
Where each labeld command defined a chain from
that command to the end. Thus the chain L1 contains
two commands and L2 contains one command.

Currently, to achieve the same behaviors, we have to
define two nested chains shown below. Note that the
chain B1 is equivalent to chain L1 and B2 is equivalent
to L2. The execution paths are identical between the
two MAIN chains, as I explained in the other
message. So "More" does not necessarily imply "Bloat"
and it is not my interests to bloat any systems
if not necessary.

   
 




 
 


 
 
 
 
   

> Please build something and show it to us, instead of talking about it.
> It won't necessarily be a "chain of responsibility" pattern any more,
> but it might well be interesting.  However, you still haven't even shown
> me a practical use case where the functionality you're talking about is
> required, and you still haven't shown me how you plan to get around the
> fragile nature of subscripts.

As I wrote in the other message, it should be exactly the CoR pattern
without skipping commands. Just need to do some feasibility research
before someone could actually build it. Now we learned that
index-based "jump behavior" is fragile. So label-based one seems to
be the right choice.

Looking at the possibility to do it without changing
core APIs is my first choice. Looks to me I need to store a label in
context per request thread for Chain.execute(), but what about
for non-web context is not clear to me yet (???) as well as how
I am going to add labeled commands to a chain (???)

Our real needs come from UI design requirements. We try our best
to give end users simple ways to do simple things first, such as
our phased validation model in Carrier. When we move to Chain,
we have to evaluate different UI design options.

>
> Craig
>

Jing
Netspread Carrier
http://www.netspread.com


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

Re: Struts-chain Behavior Discussion

[Jing Zhou]

- Original Message - 
From: "Paul Speed" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Monday, October 06, 2003 3:40 AM
Subject: Re: Struts-chain Behavior Discussion


> 
> (1) LookupCommand
> (2) ExceptionCatcher
> (3) SelectLocale
> (4) Process Action
> (a) SelectAction
> (b) CreateActionForm
> (c) PopulateActionForm
> (d) ValidateActionForm

If validations fail in (d), the (e) and (f) are not necessary.

> (e) CreateAction
> (f) ExecuteAction
> (8) PerformForward
> 
> > 
> > -Paul
> > 

Jing

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

Re: Struts-chain Behavior Discussion

[Jing Zhou]

- Original Message - 
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Saturday, October 04, 2003 1:02 PM
Subject: Re: Struts-chain Behavior Discussion


> 
> They could indeed be made part of the chain, and "checking the current 
> state to see if it's appropriate for me to do anything" is certainly 
> more in the spirit of the original CoR pattern.  However, I worry a 
> little that creating the need for that state information increases 
> coupling between commands, and therefore increases the complexity of 
> reusing commands in alternative chains.

Exactly. The index-based jumping creates the need for a command to
recognize a fixed position to jump to. That is why I said
they have a similar problem - coupling between commands. They
have to either honor a state/flag or a fixed position. And such coupling
can be easily destroyed by adding a command in between without
recognizing the state/flag or changing the target position.

> 
> In the real-life use case we actually have in the CVS repository (the 
> one in struts-chain, which actually does work :-), the case in question 
> was to deal with the fact that the Struts request processing lifecycle 
> has a branch in it, based on whether or not validation succeeds.  The 
> basic flow goes like this (using the class name of the command 
> implementation class, and presuming we're all pretty familiar with the 
> corresponding RequestProcessor behavior):
> 
> (1) LookupCommand (analogous to the processPreprocess() hook)
> (2) ExceptionCatcher (no direct analog - used to implement exception 
> mapping behavior)
> (3) SelectLocale
> (4) SelectAction
> (5) CreateActionForm
> (6) PopulateActionForm
> (7) ValidateActionForm
> (8) CreateAction
> (9) ExecuteAction
> (10) PerformForward
> 
> The conditional behavior happens in Step (7) -- if validation fails, an 
> alternative path is desired:
> (7a) SelectInput (uses the "input" attribute on the )
> (7b) PerformForward
> 
> At the moment, this is implemented as a branch, to a separate chain that 
> the author of ValidateActionForm need not even know the name of at 
> design time (it's a configuration property).  If ValidateActionForm 
> detects a failure, it looks up an alternate chain in the Catalog, 
> executes this chain, and then returns true (so that steps 8-10 of the 
> original chain are never executed).  Note that step (10) in the original 
> chain and step (7b) in the alternate chain share a single Command 
> implementation instance, because Struts ends up doing the same thing 
> either way (RequestDispatcher.forward() or redirect based on what 
> ActionForward it is passed).  Nothing had to be coded twice.
> 

My question is whether or not we could find a simpler
syntax in the chain-config.xml and implement "jump behavior".
This is because we could have a lot of "jump to the last command"
or "jump to the second to last command", etc.

It is very easy to relate "branch behavior" and "jump behavior" to
a rule engine or workflow engine, so people might get me wrong
in the early reactions.

Although we use the term "branch behavior" and "jump behavior"
in a chain, we should not see the "if" and "go to" statements in the
chain-config.xml file. So a chain is still a fully connected chain
(no skipping by definition).

The "if" statement is simulated by commands which
provide "branch behavior" by terminating the current chain and
invoking a nested chain.

Could we simulate the "go to" statement without breaking the chain?
Note that the chain's execution path should be remained connected
because we need to do post processing in the reversed order.

The answer, I deeply believe, is yes. We know that index-based
jumping is flawed, so we should use label-based jumping. When
a command is added to a chain, an optional label could be
specified which must be unique within the chain.

For example,

  
  
  
  
 
  


Now, in the ValidationFormAction class, we almost do the same
thing as before except in two statements:

> ActionErrors errors = validate(context, actionConfig, actionForm);
>
> // If there were no errors, proceed normally
> if ((errors == null) || (errors.isEmpty()) {
> return (false); // Proceed with the main chain
> }
>
> // Execute the specified validation failure command
> try {
> Catalog catalog = (Catalog)
>   context.get(getCatalogKey());

   // we get the main chain again
   Command command = catalog.getCommand("servlet-standard");
   // execute the main chain starting with the given label
  ((Chain)command).execute(context, getJumpLabel());

> } catch (Exception e) {
> ... deal with exception ...
> }
> return (true); // Terminate the main chain
> 
> Craig
> 

Here, we introduce a concept of implicit chains. Whenever
you add a command with its label in a chain, an implicit
chain is defined starting from that command to th

Re: Struts-chain Behavior Discussion

[Jing Zhou]

- Original Message - 
From: "Ted Husted" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Saturday, October 04, 2003 10:37 AM
Subject: Re: Struts-chain Behavior Discussion


> Jing Zhou wrote:
> > For me, "Simple thing should be simple" is the
> > top rule that supersedes any programming practices. 
> 
> Some of might say that this *is* a programming practice. Some might also 
> couch it as start with "the simplest thing that can possibly work", and 
> then let practice be your guide.

Only when the experiences they primarily have are coding (there are a lot
of other fields where the same rule is applied to).

> 
> > * If I have 15 commands that needs to jump to the last one in a chain,
> >if the branch way is used, then the last command must be repeatedly
> >   defined16 times in the config file. It loses the grace in expressions
> >   (although the sample config file does not reveal this problem).
> 
> Each Command can examine the Context to see if it can handle the current 
> state. If it can't then it returns false, and processing continues. You 
> don't need to "jump", you need a Command to define the appropriate state 
> in your Context.
> 
> The fundamental problem might be viewing the Chain as the brains of the 
> operation. It isn't. The Chain is just a composite of Commands. The 
> Context manages state, and so the Context is where any decision making 
> occurs.
> 
> 
> > * The "branch behavior" and "jump behavior" are complementary to
> >to each other in theory. Repeatedly executing a set of commands in
> >a chain can not be done gracefully in a *extreme* configurable
> >chain.
> 
> Yes, it's possible that the branch behavior might not be the best way to 
> go. I suspect that it might be better if a Command did not call other 
> Commands, either directly or through the Catalog. But, I do think we 
> should leave that door open so that people can experiment with this 
> extension. I know in similar implementations, I often found myself 
> having (the equivalent of) Commands calling Commands. But those 
> implementations did not have a Chain to work with, and once we have more 
> experience working with a real Chains, other strategies may become 
> evident. I believe that at some point we may be able to dispense with 
> branch behavior, so that very little happens behind the scenes. Or maybe 
> not. Practice will dictate.

Looks like you are asking less while I am asking more :-)

> > * If in the end, the fundamental APIs do not want to deal with
> >"jump behavior", I still could not successfully implement an
> >extended Chain to make up the capability. From the original
> >publication about the Chain of Responsibility, it does not
> >dictate "jump behavior" is prohibited or "branch behavior" is
> >only allowed. In my world view, the three behaviors are
> >equally important: "sequence behavior", "branch behavior",
> >and "jump behavior" in an extreme configurable chain.
> 
> IMHO, these behaviors out of scope for an implementation of the Chain of 
> Responsibility pattern. Many implementations don't even return false or 
> have the Filter backdoor. These are optimizations Craig made to help 
> with resource-intensive operations. In many implementations, every 
> Command on the Chain is visited, and there may not even be a guarantee 
> that any of the Commands handles the request. I don't see "jump 
> behavior" as an essential part of the CoR "world view". The 
> boolean/Filter behavior is a stretch as it is, and it is probably as far 
> we can go and still call it a GoF CoR.

Neither "sequence behavior" nor "branch behavior" are described
as essential parts of the CoR "world view". Since the three behaviors
are orthogonal to each other and commons-chain implements two
of them, thus in theory, it is *in-complete*. That is the research
direction I would like to point out to the community that we might
be able to complete it some how.

For some applications, just "sequence behavior" is enough as you
mentioned before. But from the research point of view,
it has very little gain than using a single RequestProcessor. Since
commons-chain is also designed to be used in other environments,
for example, in business tiers, the community should put more efforts
to extract maximum possible functionality out of Chain.

> 
> -Ted.
> 

Jing

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

Re: Struts-chain Behavior Discussion

[Jing Zhou]

- Original Message - 
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Friday, October 03, 2003 7:09 PM
Subject: Re: Struts-chain Behavior Discussion


> Jing Zhou wrote:
> 
> >It looks to me that I threw a disturbing idea. Now I change
> >the subject for more discussions of different opinions.
> >
> >Craig mentioned the "go to" statement in programming
> >languages and hinted it could be an evil if Chain implement
> >the semantics of "go to" (I just called it "jump behavior").
> >
> >If we recognize Chain as a high level pattern regulator,
> >I would not agree such a comparison is appropriate
> >unless someone could convince me the following
> >observations are questionable.
> >
> >* I studied several workflow engines (not page flow stuff, they
> >  manage persisted workload for people) They all implement,
> >  one way or another, the "jump behavior". I could not see
> >  they violate the OO design principles as high level
> >  regulators.
> >  
> >
> You seem to be assuming that commons-chain is, or is intended to be, a 
> workflow engine.  It's not.  It's fundamental plumbing that might or 
> might not be used in the creation of a workflow engine, but would 
> certainly not be the only API exposed to users.

I did not assume that commons-chain is (or intended to be) a
workflow engine here. The two observations (including the Struts
one below) tell me that there is nothing wrong to implement
"jump behavior" in high level pattern regulators (or systems). They are
not that kind of "evils" we see the "go to" in programming languages.

> 
> >* Struts itself, as a MVC pattern regulator in its core, 
> >  implements the "go to" semantics when Action returns a
> >  ForwardConfig. It does a "go to" the next page, right? -:)
> >
 
> Thus, Filter doesn't help you deal with control flow.

Got it clear. Thanks for the details.

> It's not just an issue of simplicity, it's an issue of necessity.  You 
> haven't yet shown me a use case where commons-chain is the right design 
> pattern for implementing something, but it cannot be done (or cannot be 
> done gracefully) without the "start at index" or "skip this step" 
> capability. 
> Additionally, basing starting and/or stopping points on indexes into the 
> chain is horribly fragile -- as soon as I add or remove steps elsewhere 
> in the chain, I've just broken your logic, and introduced a bug in 
> something I did not directly change.  That would be bad, so I'm also 
> opposed to the idea on technical grounds.
> 
> Finally, even if you do have a use case that needs this capability, 
> there's nothing stopping you from implementing an extended Chain that 
> does it.  I contend we should not put anything like that into the 
> fundamental APIs unless it's absolutely vital.
> 

Evaluating a requirement to see if it is vital or not depends on how you
order the rules to follow. For me, "Simple thing should be simple" is the
top rule that supersedes any programming practices. Here are the
issues I could see:

* If I have 15 commands that needs to jump to the last one in a chain,
   if the branch way is used, then the last command must be repeatedly
  defined16 times in the config file. It loses the grace in expressions
  (although the sample config file does not reveal this problem).

* The "branch behavior" and "jump behavior" are complementary to
   to each other in theory. Repeatedly executing a set of commands in
   a chain can not be done gracefully in a *extreme* configurable
   chain.

* Basing index values for "jump behavior" is fundamentally flawed.
   I was aware of that. It has the similar problems as in the pseudo
   controllers (where each commands in between must honor a flag).
   To be honest, I have not used commons-chain yet, this is just
   an analysis from what I understand so far. The potential problems
   here is about the index-based binding in the Chain interface.
   The Chain interface bind commands based on the order the
   commands are added. So we can not jump to a logically named
   command in a chain. This makes the index-based jump the only
   possible way.

* If in the end, the fundamental APIs do not want to deal with
   "jump behavior", I still could not successfully implement an
   extended Chain to make up the capability. From the original
   publication about the Chain of Responsibility, it does not
   dictate "jump behavior" is prohibited or "branch behavior" is
   only allowed. In my world

Struts-chain Behavior Discussion

[Jing Zhou]

It looks to me that I threw a disturbing idea. Now I change
the subject for more discussions of different opinions.

Craig mentioned the "go to" statement in programming
languages and hinted it could be an evil if Chain implement
the semantics of "go to" (I just called it "jump behavior").

If we recognize Chain as a high level pattern regulator,
I would not agree such a comparison is appropriate
unless someone could convince me the following
observations are questionable.

* I studied several workflow engines (not page flow stuff, they
  manage persisted workload for people) They all implement,
  one way or another, the "jump behavior". I could not see
  they violate the OO design principles as high level
  regulators.

* Struts itself, as a MVC pattern regulator in its core, 
  implements the "go to" semantics when Action returns a
  ForwardConfig. It does a "go to" the next page, right? -:)

In another word, IMHO, low level language principles
may not be applicable to high level pattern/structure
regulators. Hope people re-think it.

I also recognize the facts that we do not want to overgrow
Chain into an xml based rule engine. It should be just chain.
But for such a simple requirement, one way is to model it
as a "if" decision (Craig way), another way is to model it
as a pseudo controller (Ted way). They are kind of 
cumbersome to use. It violates the "Simple thing should
be simple" principle - a principle that supercedes other
programming principles. The Filter thing could offer a
simple solution, but I haven't looked it in details yet.

The "jump behavior" requirement is very obvious in 
Java Server Faces Specification too. When the 
renderResponse() is called on FacesContext, the control
is transferred to the Render Response phase after
the current phase. This is another evidence of the
"jump behavior" in high level pattern regulators.

I would like people to open mind and think, if we
add a method in Chain that allows us to execute
the chain starting with a given index (currently
the starting index is 0). Will that make the thing simple?
Or the idea is still disturbing somewhere?

Jing

Netspread Carrier
http://www.netspread.com

Re: [struts-chain] Writing a command to process a Tiles Definition

[Jing Zhou]

- Original Message - 
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, October 01, 2003 11:24 AM
Subject: Re: [struts-chain] Writing a command to process a Tiles Definition


>
> There's a "conditional behavior" use case in the existing code as well;
> when validation fails, we want to redisplay the input form.  Originally,
> I modelled this command as a Chain that conditionally executed its child
> commands, but that seemed a little hokey.  Now, this command definition
> says:
>
>failureCommand="servlet-validation-failure"/>
>
> so I'm declaring the name of another chain to go execute if validation
> fails.  The actual code that does the conditional execution looks like
> this (in the abstract base class):
>
> // Call the environment-specific protected validate() method in our
> implementation class
> ActionErrors errors = validate(context, actionConfig, actionForm);
>
> // If there were no errors, proceed normally
> if ((errors == null) || (errors.isEmpty()) {
> return (false); // Proceed with the main chain
> }
>
> // Execute the specified validation failure command
> try {
> Catalog catalog = (Catalog)
>   context.get(getCatalogKey());
> Command command = catalog.getCommand(getFailureCommand());
> command.execute(context);
> } catch (Exception e) {
> ... deal with exception ...
> }
> return (true); // Terminate the main chain
>
> This approach seems more scalable -- for example, you can have several
> different conditional options, you aren't binding all the behavior
> definitions into a single chain definition, and you can decide based on
> your needs whether to return false or true from the main command (which
> dictates whether the owning chain thinks processing is complete or not).
>
>
> Craig
>

I am wondering how I could implement a "jump behavior" in the main
chain. The use case for a "jump behavior" is that the main chain should
continue with several commands skipped over. For example, I would like
to jump to the last command in the main chain after the current command.
Any ideas?

Jing



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

Re: Reviving PageController (ViewController?) discussion?

[Jing Zhou]

- Original Message - 
From: "Ted Husted" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, September 30, 2003 6:29 AM
Subject: Re: Reviving PageController (ViewController?) discussion?


> Jing Zhou wrote:
> > - A well designed framework should not have overlapped
> >   concepts, or terms that lead to overlapped concepts.
> >   We have the concept of action controllers, we should not
> >   have more *controllers* when a view is under preparations.
>
> IMHO, a well-designed framework should provide extension points where
> developers need extensions points. Right now, we have one extension
> point where a developer can cleanly interject an Action.

Well, since the context switch is an interface, it is an
extension point by itself. What I am against here is that the context switch
could return a different target ForwardConfig (or changing its logical
destination page).

Determining a target ForwardConfig is the core business of Action(s)
before we reach the phase of preparing the view requirements for
the next page. It is not a good idea to overlap the Action semantics
in the context switch semantics in regard to returning a different
ForwardConfig. That is the reason I think we should not have more
*controllers*. Note that multiple Actions (or Commands) could be
allowed before the phase of preparing the view requirements.

>
>
> > - The class is responsible for switching module-wide
> >settings. A ModuleSwitch(Command) would be
> >closer to what it really does.
>
> IMHO, a large part of the problem is the assumption that "there can only
> be one" front controller. Many of the module use cases could be solved
> if multiple instances of the Struts controller were available in an
> application. One could handle the *.mod1 URIs andother another could
> handle the *.mod2 URIs. This approach was contrary to the initial Struts
> architecture, and we decided to pursue the "context-switching" strategy.
>

I am not aware of the design details in your projects, but I fully agree
with
the "context-switching" strategy. If you and any developers could advise
me about our plan to implement the strategy, that would be great. Here is
the pseudo definition:

Definition of ModuleSwitch (for the context switch interface):

1) Responsibility:

Prepare the context required by the underlying business
logic components for the incoming http request and the context
required by the presentation components for the outgoing http
response (typically a JSP page or template engine).

2) Relationship to ModuleConfig:

An instance of ModuleSwitch interface has a one to one
correspondence to an instance of ModuleConfig. ModuleConfig
provides immutable properties while ModuleSwitch provides
mutable properties for wider applicability.

3) Relationship to Chain:

There are two points in a request processor Chain that could
invoke the methods in ModuleSwitch.

- When an incoming http request is received and the current
   ModuleConfig and ActionMapping is identified, a Command
   in the Chain should invoke a method in ModuleSwitch to
   prepare the context required by following Commands that are
   responsible to execute business logic.

- When the final logical target is identified, typically in term of a
   ForwardConfig returned by previous Action Commands,
   a Command in the Chain should invoke a method in
   ModuleSwitch to prepare the context required by
   presentation components. The implementation of the method
   could just do in-module switch if the target is in the current
   module. If the target is in a different module, then out-module
   switch must be performed.

Remark: This is an alpha idea, my gut feeling is that the existence
of such interface is fully justified, of course, its name and its
method signatures are to be determined and there are a lot
of things to be filled. The concept of Logical Target is also
introduced. The  implementation could translate a logical target
to a physical target when it sees fit, much like selecting a
Renderer per JSF, or Theme per our project.

>
> -Ted.
>

Jing
Netspread Carrier
http://www.netspread.com



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

Re: Reviving PageController (ViewController?) discussion?

[Jing Zhou]

- Original Message - 
From: "Joe Germuska" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Monday, September 29, 2003 9:37 AM
Subject: Re: Reviving PageController (ViewController?) discussion?


> Thanks for the thorough and thoughtful response/contribution to the 
> discussion.  I want to point out that my post is presented in the 
> context of something that is reasonable to do in Struts 1.x, whether 
> or not it is the most ideal design.  I'm interested in talking about 
> Struts 2 also, but my proposal is intended more for "fitting-in" than 
> for being ideal.

I understand that. In the past, there were many things that people
thought very *important*. But after a while, the things could become
not that *important* or totally irrelevant. So sometime,
born-to-be-deprecated classes could be invented. That's the thing
I would like to avoid. People could produce something in Struts 1.x
that is still in line with Struts 2.x.

> I'm not sure I understand your distinctions between module and 
> application.  As Struts is now, I don't think things break down the 
> way you describe them.  Are you talking about Struts 2, or do we just 
> have different models of the responsibilities for the Application and 
> the Module?

The application here refers to a web application as defined by
the Java Servlet Specification which corresponds to a ServletContext.
The module here refers to the resources covered by a
ModuleConfig as defined in Struts. When you set up things
in a ServletContext, they are application-wide settings. When you set
up things in a ModuleConfig, they are considered as module-wide settings.
The important things for ModuleConfig is that better organized
solutions should be packaged in modules so that different packaged
solutions could work peacefully in one web application.

> 
> >Our research shows that every kind of presentation could
> >have two basic settings, application-wide settings and
> >module-wide settings. The Chain takes care of the
> >application-wide settings, the ModuleConfig (and some
> >other interfaces) takes care of the module-wide settings.
> >The vendors package their view components as a set of
> >modules with minimum requirements on application-wide
> >settings for maximum compatibility with other vendors.
> 
> OK, so am I to understand that you'd propose that any given Module 
> would be responsible for either "business" or "view" control, but not 
> both? 

No. Module-wide settings could serve both presentation components
and business logic components.

> >So the thing is not that *simple*. For example, what
> >the future ForwardConfig will look like in order to
> >accommodate a variety of presentation technologies?
> 
> Looking to Struts 2.x, I am thinking that the ForwardConfig would 
> merge with a ViewController, and that instead of the Struts action 
> returning a ForwardConfig, it would return a logical name (String); 
> then the details (and potential complexities) of dispatching to any 
> chosen view technology, including any view preparation, would be 
> entirely external to the action.  Then what I'm calling a merged 
> ForwardConfig/ViewController would actually just be another Command 
> in the processing chain and would actually have a much less defined 
> structure.

That could be possible. But in the meanwhile, we do not want Struts 2
to be reduced into a-few-line framework. Some heavy duty work
has to be done somewhere.

> Speaking of chains, given Ted's suggestion about just plugging in 
> another Action class as part of the ForwardConfig -- if that were to 
> be the case, I think I'd just be more interested in a 
> Commons-Chain/Struts-Chain solution -- which might be better anyway, 
> as it's more forward looking than any of my suggestions.

Yes. You could switch the module settings in a Command by invoking 
the method in the interface.

> 
> Joe
> 

Jing

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

Re: Reviving PageController (ViewController?) discussion?

[Jing Zhou]

>From an earlier discussion (Where is Struts 2 going?), I could see
people kind of agree with the following picture.

We have two adjacent layers around Struts 2, one above and
one below:

1) Presentation Layer:
   Struts html tags, JSF, Velocity, and many others.

2) Business Logic Layer:
   Horizontal and/or vertical logic components.

Upward, Struts 2 will integrate different presentations and
downward it will integrate different business logic components.
This is the way I see Struts' future - where its core role is
promoted beyond its traditional controller's role.

Some people would argue that Struts already *integrated*
many of technologies, but as you will see, the real integration
framework is not born yet if you realize the challenging
problems.

How we integrate them and in what ways when we want
our end users could use them in ONE web application?
This is part of our research areas at http://www.netspread.com
and I believe it also belongs to Struts' core interests.

The PageController/ViewController touches this area and I
would like to share what I learned over the years on this
topic with experts here.

The design goal of the PC/VC is to prepare the *required*
settings for the next view. The intention is fully justified, but
we have too many questions as Joe pointed out below.
Now I encourage people to think as a businessman. When
you are using a set of view components in a web application,
you find you need another set of view components
from a different vendor, how do you combine them in
one web application easily? Is this possible? Yes, if Struts 2
could provide an integratable environment along the
concept of modules.

Our research shows that every kind of presentation could
have two basic settings, application-wide settings and
module-wide settings. The Chain takes care of the
application-wide settings, the ModuleConfig (and some
other interfaces) takes care of the module-wide settings.
The vendors package their view components as a set of
modules with minimum requirements on application-wide
settings for maximum compatibility with other vendors.

Here I use the term, vendors, to denote possible
commercial vendors and/or open source project teams,
like Velocity/Cocoon. The granularity of module-wide
settings is also good enough: they could be there for many
pages, or one page, or even zero page.

What are the examples of module-wide settings?
For Struts 1.1, MessageResources, ModuleConfig (
ContentType, Nocache, ...) ActionMapping, etc.
When application flow run across module boundaries,
the module-wide settings MUST be automatically switched
to support possible different vendors' view components.
This is what we are missing in Struts 1.1.

For JSF, they could be RenderKit, VariableResolver,
PropertyResolver, etc. If anyone is interested in seeing how
a sample module switch is happening, check it out in the
GuideProcessor class. It is very primitive at present stage
without any fancy classes or interfaces, but the core idea is
there in hope Struts 2 will give us a true integratable environment.

If one buys the concepts illustrated above, we name such
a class as PageController/ViewController is inappropriate in
two aspects:

- A well designed framework should not have overlapped
  concepts, or terms that lead to overlapped concepts.
  We have the concept of action controllers, we should not
  have more *controllers* when a view is under preparations.

- The class is responsible for switching module-wide
   settings. A ModuleSwitch(Command) would be
   closer to what it really does.

The method name prepareView() is too narrow because
we may also switch module-wide settings for underlying
business logic components, for example, the root initial
context for the components in a module.

The prepareView() should not return ForwardConfig.
There should be no custom logic inside as I explained
before.

There is a technique problem. How do we switch
module-wide settings given only the target
ForwardConfig?

What we are doing is to add a prefix attribute in our
HyperActionForward class. Then we could look for
the target ModuleConfig according to the prefix. The
object only points to the next *logical* page, then the
*physical* page is looked up and finally forwarded to.
We need both current ForwardConfig and target
ForwardConfig and there is an equals() method to
compare two ForwardConfig(s).

So the thing is not that *simple*. For example, what
the future ForwardConfig will look like in order to
accommodate a variety of presentation technologies?

This is a very *vague* area that should draw many
experts from different view/logic technologies to work out
a common solution for all. When I was at school, my
supervisor always asked me what's the state-of-the-art
in your proposals. I think there is a state-of-the-art
somewhere, we need to find it. In the end, we should
be able to let the users to drop a jar file in WEB-INF/lib
and register some settings in web.xml for new
modules, and then see it wo

Re: Where is Struts 2 going?

[Jing Zhou]

> Personally, I'd like to start the work on 2.x by defining the use-cases
> or stories that we'd like the framework to realize. Ideally, we should
> be able to trace each feature back to its use-case. Then, I'd suggest we
> build the framework up, story by story, test by test.
>
> Here's some early work along those lines:
>
> http://nagoya.apache.org/wiki/apachewiki.cgi?StrutsUseCases
>
> Of all possible *features*, the one I would emphasize the most is
> testability.
>

Use-cases are very easy to be visualized and understood. I could try
to draw something to clarify the ideas, if possible.

> Personally, I'm uncomfortable defining an open source product in these
> terms. We're not a retail product looking for a market. We're a
> community of developers building the everyday tools we each need to use.

Perhaps I put my expectations too high. But we *need* some terms for average
users or non-technique people to understand quickly. For example, I
see such statement or similar ones in many places:
"Struts is all about controller."
Here is not about marketing a product in these places, it is about what
Struts is.
Of course, we could say, Struts 2 is to be a business logic integrator and
a view technology integrator. I expect both to be true.

> If people need Struts to be an integrator, then people will contribute
> integration code. Of course, that's already true. Stxx integrates Struts
> with XLST. The Velocity Tools integrate Struts with Velocity. Some of
> Don's packages integrate Struts with Cocoon and BSF. And so on. But
> people didn't do this because we put it on a whiteboard. People did this
> because it is functionality they needed to do their jobs.

That is the driving force for us to consider a *common* mechanism to
allow different view technologies to live peacefully in one web application.
The *problems* I envision now is that many view technologies assume
application-wide settings (with sub-settings adjustable by programs).
If an end user chooses one of such view technologies in a web application,
then the user would not be able to use a different view technology in
the same web application. For example, the PropertyResolver and the
RenderKit could be very vendor specific, once the user chooses that
vendor, the web application is tied to that vendor life time (or very hard
to configure a different PropertyResolver). That is really
bad for a component industry and bad for that user too.

To solve the *problem* (maybe not for all), I think the sub-settings
for PropertyResolver and/or RenderKit should be module-wide. We
create a ModuleContext, which is responsible to switch the sub-settings
when application flows run across module boundaries. For example,
when an application is landed in a Velocity module, the module context
for Velocity is prepared by Struts automatically. So the Velocity engine
could perform its rendering jobs. When the application leaves
the Velocity module and is landed in a Faces module, the module
context for that particular Faces' settings is prepared.

If this scenario could be materialized, we also need to find a way
to generalize the ActionForward and have a command to execute
the generalized ActionForward. For example, if it finds the
target module is Faces enabled, it will use the path as a tree id.
If it finds the target module is Struts 1.x module, it just does the
regular forward as it does today. (Something should be figured out
how to make the transition transparent between Faces and non-Faces,
from what I read and understand about JSF, it is very likely doable.
Could the same be done for Velocity and Cocoon?)

I am not sure the white board drawing could be proved true or not. But
I hope through healthy discussions maybe someone could bring us
a much better idea to integrate a variety of view technologies, including
the current Struts tag libraries.

Please regard this message as a user feedback, feel free to express
your opinions, useful or not, from the usability point of view, and then
doable or not, from the feasibility point of view.

Jing
Netspread Carrier
http://www.netspread.com
"Entertain your brain with different band widths."


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

Where is Struts 2 going?

[Jing Zhou]

I believe this topic has been discussed hundreds of times
in different subjects. One of important tasks for a new
version is to identify concept leaps. This is the place I
would like to entertain your brain - hope everyone to have
a brainstorm on what are really the innovative ideas to be
built in Struts 2.

To start, let's review what the innovative ideas are in
Struts 1.0. Struts is called a MVC framework. But that
is not enough, actually there are many other frameworks also
called MVC ones. What made Struts unique at its early
time is its defining characteristics between form beans and
web forms. They are symmetrical entities.

In Struts 1.1, another concept leap is introduced, we
called it application module. With this concept,
the developments of Struts applications scale up. There
are some other concept leaps, someone could add more.
Struts 1.0/1.1 is recognized as a Controller in general.

Now we have the Struts chain. I like the ideas of the chain.
In particular, I see the possibility we could transform
the Controller into an Integrator based on the chain
and the application module.

Integrator is a higher concept than Controller in my
opinion. Struts 2, as an Integrator, should be able to
1) Integrate faces components from different vendors.
2) Integrate other non-faces component easily, including
   existing 1.x tag libraries.
3) Integrate expression engines from different vendors.
4) We could add more... (like portlets)

The general expectation I have with the Integrator is
that application flows can smoothly move around modules
while underlying module-wide settings for a particular
vendor, say a PropertyResolver in one faces module,
can be switched to a different PropertyResolver in
another module (Expression engines can be switched
too).

This is a whiteboard idea. I like to see the idea to be
unfolded. One of reasons is that a Struts user may be
asked by his/her boss in the future
"If every controller function can be done in Faces or
other frameworks, what do we gain by using Struts 2?"

"Using Struts 2, our applications can cruise across
modules built from different vendors or teams. And
we could also develop modules for others."

Could we realize this dream? I know there are many
challenging problems there. Could we think about it
in terms of defining characteristics of Struts 2?

Jing
Netspread Carrier
http://www.netspread.com

Re: [Forward-Looking] Struts and JavaServer Faces

[Jing Zhou]

I learned your points and they are convincing under certain conditions.
But I could not reach a conclusion for myself to drop the "name"
attribute completely, because of some additional concerns.

- Original Message -
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, September 19, 2002 10:36 AM
Subject: Re: [Forward-Looking] Struts and JavaServer Faces


>
>
> On Wed, 18 Sep 2002, Jing Zhou wrote:
>
> > >[snip]
> > > * Transition one page at a time to use the new tag libraries,
> > >   making an appropriate modification to the  elements
> > >   for your pages (the URL needs to change to meet Faces requirements).
> > >
> >
> > Could you provide a simple example to show how 
> > should be modified? Will it require to change ActionForward class
itself,
> > or just the path attribute need to be changed?
> >
>
> No software change at all required -- only a change in the path attribute
> in struts-config.xml.  For example, from:
>
>   
>
> to
>
>   
>
> > I noticed that some *actions* in faces are for component's state
> > changes,
> > so there will be no populating, validating, and action things for them.
> > Are we going to use the ActionForward class to go to the same component
> > with changed states, is that correct? (For example, a tab pane is
changed
> > from visible tab item 0 to visible tab item 1)
> >
>
> The integration library will still offer full support for form beans and
> auto-population, with calls to reset() and validate() at the right times,
> and so on.  This is primarily to support existing code.  New apps will
> want to make a choice between using form beans (in the traditional Struts
> fashion) and just using Faces components (with their per-component
> pluggable validators) directly.
>
> > [snip]
> > One thing we had discussed sometime ago was about split
name/property
> > v.s. merged name/property. It is understandable to attempt to have a
merged
> > name/property so that we could map it to faces modelReference. I feel I
need
> > to do lobby works to reserve the split name/property version, if
necessary.
> >
> > The split version of name/property provides a better mapping and more
> > functions than merged modelReference:
> > 1) "name" is mapped to JSP attribute name in the four JSP scopes;
> > 2) "property" is mapped to JavaBean's property;
> > 3) "name" + "." + "property" is mapped to Faces modelReference;
> > 4) "name" and "property" can be evaluated by an EL engine independently;
> > 5) "name" and "property" completely hide HTML's name attribute;
> >
> > If one considers the RequestUtils.lookup() as a mini-evaluator, 4) give
us
> > a so called two-phase evaluations. While the merged modelReference can
> > only give us one-phase evaluation and thus we lost the function 4) So,
> > the "name" and "property" are well defined and well seperated in the
> > mapping, they shouldn't be deprecated ... I saw David's struts-el
> > contribution,
> > he's done a good job, we still have the split version. But I am not sure
> > if your Struts/JSF integration will keep it or not. I expect the
integration
> > will make Struts *stand on* JSF and bigger than JSF.
> >
>
> For making JSF do something like this, I suspect this one is going to be a
> hard sell to the EG, but you can try by submitting the feedback to
> [EMAIL PROTECTED]
>
> The reasons I think this way are as follows:
>
> * The split syntax is totally incompatible with variable references
>   in JSTL 1.0 and JSP 2.0, which don't support it.  It would not be
>   appropriate for JSF to be gratuitously incompatible with this
>   standard.
>

Agree with this one. Struts should implement modelReference to
cover standard requirements.

> * The split syntax is too restrictive, because it assumes the shape
>   of the graph of model beans matches the shape of the graph of
>   user interface components.  This has proven to be troublesome
>   to many Struts users already.
>

Not clear with this one. The "name" attribute in a general custom
action refers to a JSP scope attribute name, the "property" attribute
refers to the named bean's property. By definition, they do not have
direct relationship with user interfaces. Of cause, their combination can
produce whatever modelReference can do when used in JSF contexts.
But they are not necessary limited only to user interfaces.

> * The actu

Re: [Forward-Looking] Struts and JavaServer Faces

[Jing Zhou]

 to determine the effort required to
>   migrate your apps to the new JSF component architecture (I'm betting
>   that the extra functionality you gain by doing this will be well
>   worth the effort in many cases).  As described above, the actual
>   migration can be done piecemeal -- it doesn't need to happen all
>   at once.
>
> * For applications now (or about to be) under development that have
>   relatively short term schedules (i.e. the next few months), you
>   should probably stick with the existing HTML library.
>
> * For applications with a longer lead time, seriously consider waiting
>   for the ability to use JSF components instead of the Struts HTML
>   tag library.  Doing this will let you leverage not only the standard
>   HTML components that come with JSF out of the box, but also the rich
>   libraries of JSF components likely to be created by third parties in
>   the future (including Struts developers).
>
> For Struts after 1.1 is released, the developers haven't yet had formal
> conversations (which will happen on STRUTS-DEV) about what a future Struts
> will look like.  However, I'm going to continue to advocate a long term
> migration to using standards like JSF and JSTL when they are available,
> and de-emphasize the further development of the Struts proprietary tag
> libraries.
>
> The Struts tag libraries have had a tremendous positive impact on the
> development of the standard Java APIs for user interfaces.  I joked with
> the JSTL spec lead that Struts users would *never* accept JSTL without an
> expression language at least as powerful as the Struts one; and there is
> more than a little truth to that statement :-).  The same thing is
> happening now for the HTML tags -- and it's time for us to start migrating
> to the standards, which gives us the time to focus on extending Struts in
> other directions in the future.

One thing we had discussed sometime ago was about split name/property
v.s. merged name/property. It is understandable to attempt to have a merged
name/property so that we could map it to faces modelReference. I feel I need
to do lobby works to reserve the split name/property version, if necessary.

The split version of name/property provides a better mapping and more
functions than merged modelReference:
1) "name" is mapped to JSP attribute name in the four JSP scopes;
2) "property" is mapped to JavaBean's property;
3) "name" + "." + "property" is mapped to Faces modelReference;
4) "name" and "property" can be evaluated by an EL engine independently;
5) "name" and "property" completely hide HTML's name attribute;

If one considers the RequestUtils.lookup() as a mini-evaluator, 4) give us
a so called two-phase evaluations. While the merged modelReference can
only give us one-phase evaluation and thus we lost the function 4) So,
the "name" and "property" are well defined and well seperated in the
mapping, they shouldn't be deprecated ... I saw David's struts-el
contribution,
he's done a good job, we still have the split version. But I am not sure
if your Struts/JSF integration will keep it or not. I expect the integration
will make Struts *stand on* JSF and bigger than JSF.

>
> Comments?  Questions?  If it's about Struts, or Struts/JSF integration,
> feel free to ask about these issues on STRUTS-DEV or STRUTS-USER (although
> I'm going to be relatively incommunicado over the next week; I'll be in
> Yokohama at JavaOne Japan and only intermittently connected to email).
> Questions about JSF itself should be addressed to the JSF forum at the URL
> listed above.
>
> And thanks to all of you for your continued support and use of Struts --
> the community that has developed around this framework continues to amaze
> and humble me.
>
> Craig McClanahan
>
>

Jing Zhou

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


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

Re: Struts-EL: Ideas about "name" and indexed "name" attributes?

[Jing Zhou]

- Original Message -
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, August 01, 2002 5:10 PM
Subject: Re: Struts-EL: Ideas about "name" and indexed "name" attributes?


> See intermixed (well, it's really at the bottom).
>
> >
> > Assume someone is still using RequestUtils.lookup() to retrieve
> > value given form bean name and property when rendering the JSP pages, he
> > needs seperated name and property passed in the tag functions. In your
> > alternative
> > example, how do I figure out which part is for the orginal name
attribute,
> > and
> > which part is for the orginal property attribute? The first dot "." will
not
> > help
> > me to delimit the attribute into name/property pair. And if I got the
> > following
> > expression:
> > property="${foo[i].a.b.[j]}"
> > I could not tell which part is for name at all.
> >
> > Thinking about the assumption on using RequestUtils.lookup(), assume
> > somebody has a function that can take one argument, say "property", and
> > return
> > an object value. Somehow, he has to parse the argument to figure out the
> > JSP scoped attribute from it (which is exactly purpose of the name
attribute
> > in
> > Struts today) and the function will eventually call a function like
> > RequestUtils (maybe just a different function name)
> > So the parsing (from one argument into two at least) will cost
unnecessary
> > CPU time
> > since we already have seperated name/property pair today. Why not just
> > use it?
> >
> > I could be wrong. But I would like to be first convinced there is a
function
> > that
> > is faster than RequestUtils in principles and I could buy additional
power
> > when using seperated name/property expressions could not achieve. It is
not
> > an easy task for me to prove the two points.
> >
>
> I think any attempt to keep the current split name/property/scope
> parameters is going to be very confusing to someone already used to the
> JSTL EL syntax.  I'm afraid that it's us that really needs to change,
> rather than them ... and I'd like to see that process start in this
> transitional library.

I am not against to changes. In fact, our visual productivity tool will
allow end users to publish/withdraw action mappings (visual form
bean models, visual form view models, visual form controller models)
online. Behind the publishing mechanism, there is a stylesheet per
mapping that could transform struts taglibs into any other taglibs
where prefixes, element names, attribute names, can be
changed/combined according to needs (or future definitions)

When I saw the intension to combine the name/property/scope
into one attribute, I realized I had to extract out the JSP scope attribute
name from the combined attribute in some way inside the tag functions,
if you agree.

It is not clear to me if there is a clean way to extract out the JSP scope
attribute name from the combined attribute without adding new
syntax rules in addition to the standard JSTL EL syntax. Of course,
we can restrict the combined attribute in the format
${session.name.property}
But it is over restricted given a lot of additional capabilities of EL
engine.

If any body comes up a great idea to extract out the JSP scope
attribute name in a general way, I would like to see it. But remember,
any attempt to add additional rules on the attribute in addition to the
standard syntax rules is going to be very confusing too (from my experience)
and a check is needed to see if there are lost capabilities comparing with
the case using split name/property expressions.



>
> >
> >
> > Jing
> > >
> > > --
> > > To unsubscribe, e-mail:
> > 
> > > For additional commands, e-mail:
> > 
> > >
> > >
> >
> >
>
> Craig
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>
>


Jing


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Struts-EL: Ideas about "name" and indexed "name" attributes?

[Jing Zhou]

- Original Message -
From: "David M. Karr" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 01, 2002 11:55 AM
Subject: Re: Struts-EL: Ideas about "name" and indexed "name" attributes?


> See comments below.
>
> >>>>> "Jing" == Jing Zhou <[EMAIL PROTECTED]> writes:
>
> >> Therefore, I would say that "" (and similar tags)
wouldn't
> Jing> have a
> >> "name" or "indexed" attribute.  The "property" attribute (as I
described
> >> earlier) would be used both to get the current value and to specify
the
> Jing> request
> >> parameter name.  The current meaning of the "value" attribute
should still
> >> apply (overrides the property attribute for the current value).
>
> Jing> There could be a way to enhance the current html tags while
keeping the
> Jing> semantics of "name", "property" which is one of beautiful things
> Jing> in Craig's original thinking.
>
> Jing> Suppose we define EL based name, property by attributes
> Jing> _name, _property and initialize them to be null. Then we could
have
>
> Jing> protected String _name = null;
> Jing> public void setName(String name) {
> Jing> this._name = name;
> Jing> }
> Jing> protected String _property = null;
> Jing> public void setProperty(String property) {
> Jing> this._property = property;
> Jing> }
> Jing> public int doStartTag() throws JspException {
> Jing> if (_name == null) {
> Jing> name = Constants.BEAN_KEY; // so we do not need to
initialize name
> Jing> to be a non-null value any more
> Jing> } else {
> Jing> name = (String)
ExpressionEvaluationManager.evaluate("name", _name,
> Jing> String.class, this, pageContext);
> Jing> if (name == null) {
> Jing> name = Constants.BEAN_KEY;
> Jing> }
> Jing> }
> Jing> if (_property == null) {
> Jing> // throw new JspException("error message") or keep it
depends on
> Jing> particular tag implementations
> Jing> } else {
> Jing> property = (String)
ExpressionEvaluationManager.evaluate("property",
> Jing> _property, String.class, this, pageContext);
> Jing> if (property == null) {
> Jing> // some decisions here
> Jing> }
> Jing> }
>
> Jing> ...
>
> Jing> // make sure all RequestUtils.lookup will see only evaluated
name,
> Jing> property, scope
> Jing> Object value = RequestUtils.lookup(pageContext, name,
property, null);
>
> Jing> }
>
> Jing> Sometimes ago, I was trying to figure out if I could have a
"compact"
> Jing> attribute which
> Jing> combine name/property/scope altogether when I design my UI. When
I saw above
> Jing> possibility, I feel it is not a good idea to combine them into
one
> Jing> attribute, because:
>
> Jing> 1) The combined attribute could not provide enough additional
power I could
> Jing> buy:
> Jing> End users could put a tag in multi-level loop like this:
>
> Jing>  Jing>
property="p1[${loop2Status.index}].p2[${loop3Status.index}].p3" />
>
> I guess you've partially lost me.  Would the alternative for point (1) be:
>
> 
>
> ?
>
> Which are you saying is preferable?

I prefer it in the format 
In the example, the "some_name[" and "]" in the name attribute are
pass-through string literals.
"${" and "}" can not be removed from there. The same rule applied to the
property attribute.
But if you do this: property="${some_name[loop1Status.index]...}" that
is a different thing.

>
> (Will the ActionForm processing successfully parse that "property" value
so the
> value can be set in the ActionForm?)
>
> Jing> 2) If using combined attribute, I have to delemite the attribute
into name,
> Jing> property
> Jing> again, which cost unnecessary CPU time and depend on end users
correct
> Jing> input.
> Jing> I am very concerned about user experience: think about an UI for
City,
> Jing> State, Zip code,
> Jing> How would you feel if a site give you only one text field to
input the
> Jing> city, state, and zip code? It will depend on the end users to
input

Re: Struts-EL: Ideas about "name" and indexed "name" attributes?

[Jing Zhou]

I am trying to be more constructive, see my thoughts below.

- Original Message -
From: "David M. Karr" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, July 26, 2002 1:16 PM
Subject: Re: Struts-EL: Ideas about "name" and indexed "name" attributes?


> >>>>> "David" == David M Karr <[EMAIL PROTECTED]> writes:
>
> >>>>> "Jing" == Jing Zhou <[EMAIL PROTECTED]> writes:
> Jing> The convention (see JSTL spec 2.2.1) is to use the name "var"
for attributes
> Jing> that export information. As I do not think 
should do any
> Jing> export
> Jing> things, we could simplify Craig's example as follows:
>
> Jing> 
> Jing> 
> Jing> 
>
> Jing> Where we are only interested in the current iteration index
evaluated by
> Jing> an EL engine at run time and no changes are needed in the action
codes.
>
> David> It's funny to have "c:forEach" iterate over a collection, but
ignore the item,
> David> which is essentially what's happening here.  However, it does
make sense here.
>
> David> Just to summarize your example, the "property" attribute will
be used in two
> David> different ways.  It will be recursively wrapped by "${" and "}"
and passed to
> David> the EL engine to get the current value, and sent "raw" as the
request parameter
> David> name.  By "recursive", I mean that
"customers[${status.index}].id" would be
> David> evaluated, resulting in (say) "customers[2].id" to get the
request parameter
> David> value, and then wrapped with "${" and "}" to get the current
value.
>
> Jing> Will it be possible to keep the semantics of name/property
attributes
> Jing> and drop the "indexed" attribute when the EL engine is
available?
>
> David> I'd like to be sure exactly what you're asking here.  It's
obvious that we
> David> wouldn't need to use "indexed" if we directly construct the
index expression,
> David> as in this example.
>
> David> The "property" attribute could have two different
interpretations, depending on
> David> whether the "name" attribute was present.  The old meaning if
"name" was
> David> present, and the new meaning if "name" is not present.  The
"indexed" attribute
> David> could only be present if the "name" attribute was present.
>
> I'm just thinking out loud here in case someone has any thoughts about
where
> I'm heading here.
>
> I've realized that I can't use my strategy of having the behavior depend
on
> whether the "name" attribute is present.  That's because there's already
> conditional behavior that depends on that test, whether it checks the
"name"d
> form bean or the default form bean.
>
> Therefore, I would say that "" (and similar tags) wouldn't
have a
> "name" or "indexed" attribute.  The "property" attribute (as I described
> earlier) would be used both to get the current value and to specify the
request
> parameter name.  The current meaning of the "value" attribute should still
> apply (overrides the property attribute for the current value).
>

There could be a way to enhance the current html tags while keeping the
semantics of "name", "property" which is one of beautiful things
in Craig's original thinking.

Suppose we define EL based name, property by attributes
_name, _property and initialize them to be null. Then we could have

protected String _name = null;

public void setName(String name) {

this._name = name;

}

protected String _property = null;

public void setProperty(String property) {

this._property = property;

}


public int doStartTag() throws JspException {

if (_name == null) {
name = Constants.BEAN_KEY; // so we do not need to initialize name
to be a non-null value any more
} else {
name = (String) ExpressionEvaluationManager.evaluate("name", _name,
String.class, this, pageContext);
if (name == null) {
name = Constants.BEAN_KEY;
}
}
if (_property == null) {
// throw new JspException("error message") or keep it depends on
particular tag implementations
} else {
property = (String) ExpressionEvaluationManager.evaluate("property",
_property, String.class, this, pageContext);
if (property == null) {
// some decisions here
}
}

Re: Struts-EL: Ideas about "name" and indexed "name" attributes?

[Jing Zhou]

- Original Message -
From: "David M. Karr" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 22, 2002 11:45 PM
Subject: Re: Struts-EL: Ideas about "name" and indexed "name" attributes?


> > "Craig" == Craig R McClanahan <[EMAIL PROTECTED]> writes:
>
> Craig> I've been thinking about this issue as well, as you might
imagine.
>
> Craig> For general form field properties, I'm assuming that we would
have to make
> Craig> the existence of the form bean explict -- say, for example:
>
> Craig>   
>
> Craig> instead of assuming that you could just use username and "know"
that it
> Craig> was resolved against the form bean in the surrounding scope.
The property
> Craig> name can either be inferred from the expression (i.e. after the
first
> Craig> period), or we could allow an optional "property" attribute
that would
> Craig> provide the field name for the rendered  field.
>
> I'm very hesitant to start parsing the EL string, as there's a lot of
different
> ways to form a legal expression, and I don't want to try to restrict the
form
> of the EL expression in these situations.
>
> We could of course have the "var" attribute be an EL to get the current
value,
> and have the "property" attribute be the "name" attribute in the generated
> HTML, but then you have a disconnect between the value and the name,
whereas
> the current "name/property" pair allows a clean specification of both the
> current value and the request parameter name.
>
> Craig> For indexed things, remember that the subscript in an EL
expression can be
> Craig> a variable.  So something like this should work, where
"customers" is an
> Craig> array of customer objects, and we're inside a form with a field
per
> Craig> customer account number:
>
> Craig>   
> Craig>  Craig>  property="customers[${status.index}]"/>
> Craig>   
>
> Craig> could do the trick, as long as you scanned both the "var" and
"property"
> Craig> attributes for expressions.
>
> Yes, I had considered the array index possibility.  This will provide more
> flexibility, allowing the case of two nested "iterate" tags, and you want
the
> "property" attribute of the HTML tag to come from the OUTER iterate tag
(which
> someone on "struts-user" just asked about today).
>
> However, in the general case, we're still having the users specify more,
and
> redundant information, just to avoid the use of the "name/property" pair.
>
> I guess we could provide two ways to do this:
>
> If the "name" attribute is present, the "name" and "property" are combined
as
> usual.  However, if the "var" attribute is present, in place of the "name"
> attribute, then the "var" value is used for the current value, and the
> "property" attribute is used as the entire "name" attribute (of the
generated
> HTML).

The convention (see JSTL spec 2.2.1) is to use the name "var" for attributes
that export information. As I do not think  should do any
export
things, we could simplify Craig's example as follows:


 


Where we are only interested in the current iteration index evaluated by
an EL engine at run time and no changes are needed in the action codes.

Will it be possible to keep the semantics of name/property attributes
and drop the "indexed" attribute when the EL engine is available?

Jing

>
> (It's certainly confusing to have the "name" attribute mean two different
> things, one in JSP, and the other in HTML).
>
> Unfortunately, a change like this will require changing the base Struts
tag.
> In the case of "CheckboxTag" (and probably others), the current value
lookup is
> done directly in its "doStartTag()" method, with no comparison of "value"
> against null check to bypass it (which is the case in other tags, like
"size"
> and "message", for instance).
>
> --
> ===
> David M. Karr  ; Java/J2EE/XML/Unix/C++
> [EMAIL PROTECTED]
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

About the design of the ExceptionHandler base class

[Jing Zhou]

Declarative exception handling is a very welcome feature in struts b1, but
it receives very little comments. I put my little thought here and hope it will
help when b2 is coming out:

1. The 'scope' attribute in ExceptionConfig is possibly redundant.

According the current API doc, the 'scope' is to used to specify where
to store the ActionErrors resulted from this exception. But with a
careful examination of the machinery of the error handling and
propagation in both struts and tomcat, errors or exceptions if any,
*must* be resolved within life span of the request by either display
error messages back to users or log error messages, or something else.
there is almost no point to store ActionErrors in HttpSession.

2. There is a possibly missing attribute 'context relative' in ExceptionConfig
that describes the 'path' attribute needed when constructing 
ActionForward in ExceptionHandler.execute(...) method.

Although the current API doc indicates that the 'path' is a context
relative path, the implementation the ExceptionHandler.execute() method
does not really build a context relative ActionForward. Would that be a bug?

My thought to have a 'context relative' attribute in the ExceptionConfig is to
enforce the developer to honor it when they are constructing the 
ActionForward. The other benefit is for the tool users. If they see
context relative checkbox selected, they are sure they are going to have
the forward action behavior as expected. Otherwise, they would wonder how
developers implement it.

3. It would be very nice that ExceptionHandler has an attribute to hold the
reference to the ActionServlet instance.

Chuck and I once discussed the need to access non-default resource
bundles inside the ExceptionHandler.execute() method. In a bigger picture,
developers may also need to access some plugins, data sources, etc,
in the method. If the action servlet instance is set to the ExceptionHandler
right after its creation, the problem is resolved.

The above problems are not really bugs. They could be *fixed* in subclasses,
but they'd better belong to base class things, any thoughts?

Jing

Re: Security issues with Struts

[Jing Zhou]

- Original Message -
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, July 02, 2002 6:16 PM
Subject: Re: Security issues with Struts


>
>
> On Tue, 2 Jul 2002, Marcel Kruzel wrote:
>
> > Date: Tue, 02 Jul 2002 10:14:05 +0200
> > From: Marcel Kruzel <[EMAIL PROTECTED]>
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > To: Struts Developers List <[EMAIL PROTECTED]>
> > Subject: Re: Security issues with Struts
> >
> > >>I believe Struts have provide a basic mechanism to resolve
> > >>the problems associated with the multiple submits. But when
> > >>considering this in a security issue context, we might have rooms
> > >>to enhance the mechanism - here is my little thoughts:
> > >>
> > >>1) Since the transaction token is visible by client browser, users
> > >>could use the same token to cheat Struts by a client program.
> > >>
> > >>
> > >
> > > A snooper could make the initial submit for a particular form (if they
> > > could get it in faster), but couldn't do much else.  However, the
security
> > > implications of exposing the session id are *much* more serious than
> > > exposing the transaction token.  If data exposure is an issue, use an
SSL
> > > connection.
> > >
> > >
> > >>2) Even though request scoped form beans plus a transaction
> > >>token make Struts thread safe, but I observed developers still make
> > >>mistakes by assigning attributes from the request scoped form beans
> > >>to their own version of session scoped java objects, which is
> > >>possibly participating in a transaction from the previous request.
> > >>Any non-trivial application have session scoped objects, so this
> > >>is very likely to happen in general.
> > >>
> > >>
> > >
> > > I'm not sure what a framework can do about this in any general way.
Do
> > > you have some specific suggestions?  I fear that just "single thread
all
> > > access to the session" is going to cause more problems than it would
> > > solve.
> > >
> > >
> > >>3) The session scoped form bean plus a transaction token may not
> > >>work correctly all the time: Before the first request reach the
> > >>statement isTokenValid(request, true), the second request might
> > >>already corrupt the session scoped form bean by populating bad
> > >>data. Therefore it corrupts the transaction state of the first
request,
> > >>if the form bean is participating in that transaction.
> > >>
> >
> > Thanx for so many replies!
> >
> > Precisely! the transactionToken does help if You
> > want to detect multiple THE SAME submits. But this is not
> > our issue here. If the second submit contains different values,
> > the session scoped form bean will get populated
> > before I am able to detect that there is a second
> > submit! The handling (perform()) of the first
> > submit will continue with wrong parameters!
> >
> > The only solution here is to:
> > PREVENT from populating of the session scoped
> > form bean if there is still a work going on with the SAME form bean.
> > PERIOD.
> > (thus a locking mechanism, anyway).
> > The simplest one is utilization of the Java sync
> > mechanism on session object, however,
> > I understand, that there might be some problems doing so
> > (if done in each form of the application, the user
> > might lock himself for a while!
> > (and clicking and clicking :-))
> > Here commes a brilliant idea! Let's synchronize
> > on the form bean itself! That should work!
> > Of course, you still have to write
> > your own RequestProcessor as Jing Zhou suggests, so You
> > can DO something (sync or check transaction context)
> > before the form gets populated.
> >
>
> You can accomplish this for yourself by adapting the request processing
> lifecycle Struts supports.  In Struts 1.1, you just provide your own
> RequsetProcessor subclass, and override the relevant methods.  (In Struts
> 1.0, these methods are embedded in ActionServlet, but are named the same
> and do the same things).  It's not clear to me that a general purpose
> solution can be defined that would (a) meet nearly everyone's needs; (b)
> not get in the way of some people; and (c) not harm performance in the
> usual case where you really don&#

Re: Security issues with Struts

[Jing Zhou]

I believe Struts have provide a basic mechanism to resolve
the problems associated with the multiple submits. But when
considering this in a security issue context, we might have rooms
to enhance the mechanism - here is my little thoughts:

1) Since the transaction token is visible by client browser, users
could use the same token to cheat Struts by a client program.

2) Even though request scoped form beans plus a transaction
token make Struts thread safe, but I observed developers still make
mistakes by assigning attributes from the request scoped form beans
to their own version of session scoped java objects, which is
possibly participating in a transaction from the previous request.
Any non-trivial application have session scoped objects, so this
is very likely to happen in general.

3) The session scoped form bean plus a transaction token may not
work correctly all the time: Before the first request reach the
statement isTokenValid(request, true), the second request might
already corrupt the session scoped form bean by populating bad
data. Therefore it corrupts the transaction state of the first request,
if the form bean is participating in that transaction.

Here are what I am doing in our own project and hopefully it
will help Struts:

We created a client transaction context (relative to EJB server)
which manage both JDBC connection based transaction and JTA
UserTransaction based transaction. In our own version of the
RequestProcessor, we detect the transaction context before
populating the form bean. If an active client transaction context
found in the HttpSession, there are two choices, let the request
wait or throw an exception. I prefer the second one, which has a
consistent semantic with SessionBean defined by EJB 2.0 spec:
Container will throw exception if there is a concurrent access
to the business method of the same stateful SessionBean instance.
In other words, Struts could guard the container in early stage and
solve the potential problems 1-3, and many bad comments on
the session scoped form beans will be gone :-)

Is my thoughts valid? Any further thoughts?

Jing


- Original Message -
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Monday, July 01, 2002 11:54 AM
Subject: Re: Security issues with Struts


> There are at least a couple of issues that I can pull out of your problem
> description -- here's my thoughts on them.
>
> REUSE OF FORM BEANS
>
> You only have to worry about reuse of the same physical form bean on
> multiple requests if you are using session scope to save them in.  If you
> are using request scope (recommended for performance anyway, because it
> reduces the memory load on the server), a new bean gets created populated,
> and validated for each request.  That still leaves the problem of
> detecting when the user submits the "same" form twice ...
>
> DETECTING MULTIPLE SUBMITS
>
> This is a general issue for all web applications, not specific to Struts.
> However, Struts provides a solution based on the concept of a "transaction
> token" that can be used to easily detect when the user tries something
> like this.  It works as follows:
>
> * In your Action that sets up the input form, call the method:
>
> saveToken(request)
>
>   somewhere along the way, before forwarding to the actual page.
>   This records a serial number in the user's session.
>
> * When the  tag actually renders the form, it sees the
>   serial number and generates a hidden field to include it's value
>   along with the rest of your fields.
>
> * In the Action that receives the form (after validation), you can
>   call the method:
>
> isTokenValid(request, true);
>
>   to check the token included in the request (if any), and clear the
>   value saved in the session (which is normally what you want to do).
>   This method will return false if there is no token at all in the
>   form, or if the token doesn't match the saved value.  The fact that
>   you are resetting the saved value means that it will also return
>   false if the user submits a form, presses stop, and submits it again.
>
> I believe that your session synchronization approach isn't necessary to
> deal with the particular problem you've described (although it might be
> useful for other application-specific reasons).  I hesitate to add
> something like this to the framework itself, though -- managing
> simultaneous requests to the same session has such a wide range of
> possible impacts that I don't think a single simple solution is going to
> cover all of the use cases.  And using request scope for form beans covers
> quite a large subset of the possible impacts all by itself (at the cost,
> of course, of having to include hidden variables on your forms for
> multi-page form beans).
>
> Craig
>
>
>
> On Mon, 1 Jul 2002, Marcel Kruzel wrote:
>
> > Date: Mon, 01 Jul 2002 08:46:11 +0200
> > From: Marcel Kruzel <[EMAIL PROTECTED]>
> > Reply-To: Struts Developers Lis

ActionServlet.destroy() has destroyed all?

[Jing Zhou]

Craig and All,

When looking into the ActionServlet.destroy() and RequestProcessor.destroy()
methods, I could not find anywhere the RequestProcessor instance is
removed from the servlet context. This might cause problems after the
action servlet destroyed and re-initialized and the following requests would obtain
an invalid RequestProcessor instance left before (with null servlet instance)

In general, I believe it is safe to remove all Struts related objects
from the servlet context in the destroy() methods. For example, if a message
resource configuration is removed between the calls destroy() and init(),
undesired resource will remain in the servlet context until the next Tomcat restart.
I am not sure this task is already taken care of by Tomcat or something else.
Correct me if I am missing something.

Jing

Re: Retrieving messages from the default and non-default bundles

[Jing Zhou]

Basically I agreed with your concerns and felt that we are
probably probing the same problem, but from very different
perspectives.

Suppose I am in ExceptionHandler.execute() method, I would
like to access non-default bundles from here. So I need to
get the action servlet instance and then its context. The
*real* problem is that I am not guaranteed to get the
action servlet instance from the API's formInstance, because
it might be null at runtime! Even there is a RequestUtils utility
method, it will not help me here.

In my own world, I have four classes BasicFormController
(extends Action), BasicFormValidator (understands my UI),
BasicExceptionHandler (extends ExceptionHandler), and
another one (related to UI) I think the four belong to ONE category:
They all handle certain business logic but with different area and
at different times.

Since we all understand the semantic of Action class, it is
recycled, shared by multiple threads. Why not my
BasicFormValidator, BasicExceptionHandler? If there is no
very very negative side effect, they should be so. Therefore,
I got a consistent and united view: They all have the
getServlet() and setServlet() methods, and my RequestProcessor
will assign the action servlet instance to them after creation.

The BasicFormValidator will accept a parameter 'Theme' from
UI which includes user specified bundle if any. But I feel hard
to take advantage of the Struts validator regarding to the bundle.

Suppose you could get the action servlet instance in the
ExceptionHandler base class, will that resolve most of your
concerns in 2)?

Jing




- Original Message -
From: <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Friday, May 17, 2002 10:27 AM
Subject: Re: Retrieving messages from the default and non-default bundles


> Jing,
>
>  The issue that I was raising is a little different,
> although somewhat related. There are two issues that I
> was specifically looking for an answer to.
>
> 1) Even though the getServlet() method is present in the
> ActionForm and Action classes, it's still cumbersome to
> retrieve the messages from a bundle other than the
> default. The only way that I see is to get the Servlet,
> and then the ServletContext, and then get the specific
> MessageResources for the bundle based on the name that
> is configured for it, plus the name of the
> subapplication. Each message bundle is stored in the
> ServletContext based on the name that you gave it plus
> the sub-application name.
>
> What I was asking was is the best/only approach. Maybe
> the framework needs to do a little on behalf of the
> application?. For instance, a method could be added to
> the RequestUtils to aid in this task.
>
> 2) The second question I was asking was, suppose I
> extend the ExceptionHandler to do a little more
> customized exception handling. I think it would be
> appropriate to have access to the message bundle there.
> I believe I used to go through the ApplicationConfig to
> access the servlet, that's no longer possible. So,
> unless some utility method describe in (1) above is
> added, it's very difficult to access the bundles. The
> declarative exception handling is nice, but the
> framework still needs to allow for programmatic
> overrides. As I said in my post to the dev group, only
> the default MessageResources is stored in the request,
> thus it's not easy to get access to the messages in the
> additional bundles, reducing their overall benefit.
>
> Chuck
> >
> > - Original Message -
> > From: <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Thursday, May 16, 2002 12:14 PM
> > Subject: Retrieving messages from the default and non-default bundles
> >
> >
> > I'm posting this question to the dev group, because I'm not that many
are
> > using the multiple bundle support of 1.1 yet. I've noticed that several
of
> > the methods for getting access to the Servlet and thus the
ServletContext
> > have been removed from classes like ApplicationConfig. This has made it
a
> > little harder to get messages from the message bundles.
> >
> > The RequestUtils.selectApplication() method stores the default
> > MessageResources into the request, but what approach should be used to
get a
> > message from the bundle from someplace other than a JSP? Should we
recommend
> > that developers get the default MessageResources from the request and
use
> > that, or are there better alternatives? What about when you're using
> > multiple resource bundles for an application, and you need a message
from
> > one of the non-default bundles? It appears that only the default
> > MessageResources is being stored in the request.
> >
> > The addition of multiple bundles is a great new feature, but appears to
be a
> > little cumbersome to get access to the messages. Especially since a few
of
> > the strategic getServlet() methods have been removed.
> >
> > Here's an example for context. Suppose that you want to extend the
> > ExceptionHandler and get some

Re: Retrieving messages from the default and non-default bundles

[Jing Zhou]

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, May 16, 2002 12:14 PM
Subject: Retrieving messages from the default and non-default bundles


I'm posting this question to the dev group, because I'm not that many are
using the multiple bundle support of 1.1 yet. I've noticed that several of
the methods for getting access to the Servlet and thus the ServletContext
have been removed from classes like ApplicationConfig. This has made it a
little harder to get messages from the message bundles.

The RequestUtils.selectApplication() method stores the default
MessageResources into the request, but what approach should be used to get a
message from the bundle from someplace other than a JSP? Should we recommend
that developers get the default MessageResources from the request and use
that, or are there better alternatives? What about when you're using
multiple resource bundles for an application, and you need a message from
one of the non-default bundles? It appears that only the default
MessageResources is being stored in the request.

The addition of multiple bundles is a great new feature, but appears to be a
little cumbersome to get access to the messages. Especially since a few of
the strategic getServlet() methods have been removed.

Here's an example for context. Suppose that you want to extend the
ExceptionHandler and get some other values from one of the bundles, in
addition to the key that is configured with the exception mapping. How can
this be done within the ExceptionHandler for example? Should there be a
utility method in the RequestUtils for this? The ones that are there now are
tied to the JSP due to the PageContext.

If anyone can shed a little light on this, I would appreciate it.

Chuck

There are some *hidden rules* I discovered while I am finishing up
my struts visual module. Developers should not consult to
classes with their name ending with 'Config' for servlet (servlet context).
Those classes play a role of organizers and the servlet instance is
available in form bean and action classes. Since I buy this rule,
Craig's decision to remove getServlet() is easy to understand for me.

Another rule is to use request scoped ActionErrors/ActionMessages
as much as possible (for better scalability than 1.0?) Once I am in
ExceptionHandler or Validator or Action classes, I am in business
to create possible ActionErrors/ActionMessages and those messages,
if any,  will be consumed by the Errors/Messages tag in the next
JSP page. The scope property in ExceptionHandler looks to me is a
little redundant or inconsistent if I buy this rule. I am not very clear
what other values you want to get from one of the bundles,
if you mean the arguments to the ActionErrors/ActionMessages
when you build them, you could take a look at StrutValidatorUtil.

However Strut's validator APIs are not organized as flexible as rest
of the framework when handling multiple bundles. I could not find
any easy way to have the validator to use MessageResources other than
the default one. If anyone finds an easy way, please point it out.
I would appreciate it.

Jing

--
Posted via jApache.org

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Scalability question

[Jing Zhou]

I have another question in my mind that relates to the scalability
and performance:

What are the general guide lines to consider when deciding to
put my form beans into request scope vs. session scope?

My first cut thinking is as follows:
1) When session object is not available, request  scope is
the only option (simple);
2) When users have multiple browser windows that might
   access the same form bean, for thread safe purpose, it is
   better to put it into request scope (rare use cases)
3) When developing wizard like application, it looks to me
   session scoped form beans should be the primary option.
   (Is there someone out there using request scoped form
beans for a multi-page application? I would like to
know the reasons behind)
4) Conditions beyond 1 - 3. I feel hard to make decisions here.
   If I put form beans into request scope, then every request,
   Struts will create form beans and destroy them too.
   It mean slower performance, but good scalability.
   If I put form bean into session scope, I avoid the instance
   creation on every request, but I would end up large
   session scoped objects that impact session migration.
   I also heard that there might be some limit on the size
   of the session scoped objects, it that true in general?

   I could miss some other conditions to consider, and would
   like to hear any insights, project experiences, etc. regard to
   this question.

Jing

- Original Message -
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Monday, May 13, 2002 11:31 AM
Subject: RE: Scalability question


>
>
> On Mon, 13 May 2002, Steven D. Monday wrote:
>
> > Date: Mon, 13 May 2002 08:52:38 -0500
> > From: Steven D. Monday <[EMAIL PROTECTED]>
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > To: Struts Developers List <[EMAIL PROTECTED]>
> > Subject: RE: Scalability question
> >
> >
> > Hal,
> >
> > Thanks for the reply.  I don't think I was attempting to make a point as
> > much as learn some of the rationale behind the choice of a single action
> > instance as opposed to creating an action instance perhaps upon every
> > request for example.  A couple follow up questions.
> >
> > > Action classes aren't supposed to have any kind of serious business
> > process.
> >
> > I didn't mean to imply that an action class itself would implement
serious
> > business logic itself.  However, unless I'm misunderstanding the role of
an
> > action class I would assume that it would perhaps instantiate a business
> > object and ask it to perform some service.  My point was that in the act
of
> > performing a service the business object would likely exhaust more cpu
> > cycles/memory than would be expending creating an action class instance
and
> > garbage collecting it.
>
> In most large scale application environments, your business logic layer is
> very likely doing this kind of thing (allocating instances from a pool)
> already, whether we do it or not with Actions.  Session EJBs, for example,
> work exactly this way.  Doing it in the Actions, in that sort of an
> environment, doesn't buy you any improvement by avoiding the need to
> allocate instances in the back end.
>
> The crucial difference, though, is that with the EJBs this extra work can
> happen on your back end database server, instead of your front end web
> container.  You can scale the front end and back end independently, based
> on where the bottlenecks are in your application.
>
> This is not possible if you've tied everything together in the front end.
>
>
> >  What motivated me to ask this question was the
> > following verbage I found on Martin Fowler's site:
> > http://www.martinfowler.com/isa/frontController.html, regarding front
> > controller command classes and thread-safety:
> >
> > "Since you create new command object with each request, you don't have
to
> > worry about making the command classes thread safe. This can avoid the
> > headaches of multi-threaded programming. You do have to make sure that
you
> > don't share any other objects, such as the model objects."
> >
> > > Also, if you are creating an Action for every request, there isn't
much
> > > point in having  instance variables that might cause serialization
> > issues,
> > > so why have more than one instance?
> >
> > In principle I agree.  However, again in reality it many times is the
case
> > that developers don't consider thread safety issues as closely as they
> > should.  This reality coupled with Martin's comments above made me
curious
> > as to what maintaining a single instance of commands buys you.
> >
>
> Martin's quote doesn't really cover the entire issue -- you still have to
> deal with multiple threads even with per-request Action allocations.  Any
> thinking that you don't is an illusion.  Quite aside from the performance
> and scalability questions, I'd rather make the need to program in a
> thread-safe manner absolutely explicit in Struts, be

Re: Another way to find mapped properties

[Jing Zhou]

- Original Message - 
From: "Struts-dev Newsgroup" <@[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, April 26, 2002 6:10 PM
Subject: Re: Another way to find mapped properties


> Subject: Re: Another way to find mapped properties
> From: "Anand Jayaraman" <[EMAIL PROTECTED]>
>  ===
> Craig/Jihn.
> 
> Do you have a example of the ActionForm and JSP using mapped property.
> 
> Thanks,
> 
> Anand

I do not have actual working example for STRUTS.
Suppose you have a form bean class Customer with a method
String getAddress(String location) (or defined in its superclass),
then you could output customer's locations in your JSP 


That's my understanding.

Jing

> 
> 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Another way to find mapped properties

[Jing Zhou]

The clouds in my mind over the JSTL EL are finally cleaned up.
We are going to have a more compact set of attributes for STRUTS
(Actually it become easy for me to normalize screen objects,
if understanding correctly,  should have an extra
attribute to hold ${scope.name.property} in the future)

Thanks,

Jing


- Original Message -
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, April 25, 2002 4:01 PM
Subject: Re: Another way to find mapped properties


>
>
> On Thu, 25 Apr 2002, Jing Zhou wrote:
>
> > Date: Thu, 25 Apr 2002 15:09:31 -0500
> > From: Jing Zhou <[EMAIL PROTECTED]>
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > To: Struts Developers List <[EMAIL PROTECTED]>
> > Subject: Re: Another way to find mapped properties
> >
> > I browsed the Appendix A for EL and got the following
> > thoughts:
> >
> > Suppose STRUTS taglib is running in a JSTL environment
> > with EL engine enabled. We could have a construct like
> >
> > 
> >   
> > 
> >
> > I hope the EL will set the property attribute with string
> > literal address[0], address[1], ... at runtime.
> >
> > Craig, is the above construct legal in the future? It looks
> > to me pretty neat when considering arbitrary string literal
> > could be set by the EL engine (it also solves my problem)
> >
>
> We won't know for sure until we actually modify Struts to support the EL,
> but I anticipate that you would (in the future) code this example as
> follows:
>
>   
> 
>   
>
> The reasons for the changes:
>
> * I would like to use a new attribute ("value") on the Struts tags
>   for the places that EL expressions are legal, so that we don't
>   mess up the existing use of the "name" and "property" attributes
>   where the old syntax would continue to work as it always has.
>   In addition, use of "value" as an attribute is consistent with the
>   JSTL conventions for attribute names.
>
> * In the JSTL EL, once you are inside "${...}" then everything is
>   interpreted as an expression - you don't need nested "${i}" to
>   make "i" be treated as a variable reference.
>
> Until after Struts 1.1, this is all just drawing on a whiteboard, but it's
> definitely the direction I am thinking about.
>
> > Jing
>
> Craig
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
>


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

Re: Another way to find mapped properties

[Jing Zhou]

I browsed the Appendix A for EL and got the following
thoughts:

Suppose STRUTS taglib is running in a JSTL environment
with EL engine enabled. We could have a construct like


  


I hope the EL will set the property attribute with string
literal address[0], address[1], ... at runtime.

Craig, is the above construct legal in the future? It looks
to me pretty neat when considering arbitrary string literal
could be set by the EL engine (it also solves my problem)

Jing


- Original Message -
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, April 24, 2002 2:38 PM
Subject: Re: Another way to find mapped properties


>
>
> On Wed, 24 Apr 2002, Jing Zhou wrote:
>
> [snip]
> > > [Craig said]
> > > If we are going to adopt the JSTL (and JSP 1.3) expression language
> > > syntax, I believe we should adopt all of it, not just a subset.  For
> > > example, consider the  tag, where you use the "name" and
> > > "property" (plus optional "scope") attributes to identify the property
to
> > > be written.  The "property" attribute takes one of our proprietary
> > > expressions, so you can say something like:
> > >
> > >   
> > >
> > > The equivalent using a standard JSTL tag would look like this:
> > >
> > >   
> > >
> >
> > Can we have syntax like this in Struts?
> > 
>
> This is not curently legal.  Struts only accepts integer literals as
> subscripts, although you can fake it with a runtime expression:
>
>   property='<%= "address[" + key + "]" %>' scope="session"/>
>
> > or in JSTL
> > 
>
> In this case, it would actually be:
>
>   
>
> You don't really need to wonder what the JSTL expression language syntax
> is -- you can download the JSTL spec and read Appendix A.
>
>   http://jcp.org/aboutJava/communityprocess/first/jsr052/
>
> > Where the evaluated value of ${key} at runtime could be obtained from
> > a loop tag or a tool provided model. An example value of ${key} could be
> > 0, 1, 2 ... as a looped index, or "home", "ship_to", "charge_to", etc.
> >
> > I feel the true problems I am struggling for are better expressed in the
> > above
> > examples. A more agressive syntax may looks like:
> > 
> > or something like:
> > 
> >
> > I am not sure JSTL could understand the "nested expressions" or not and
> > how to express them in JSTL. The idea is somehow we could dynamically
> > assemble the string literal for the "property" attributes.
> >
>
> There are two variations of the JSTL library -- one that accepts runtime
> expressions (like the Struts case above) and one that does not.
>
> [snip]
>
> Craig
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
>


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

Re: Another way to find mapped properties

[Jing Zhou]

Thanks so much for providing detailed information on Struts.
It helps me to make sure my tool will stay in line with the
future features. See my response intermixed.

- Original Message -
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, April 23, 2002 7:56 PM
Subject: Re: Another way to find mapped properties


> See intermixed.
>
> On Tue, 23 Apr 2002, Jing Zhou wrote:
>
> > Date: Tue, 23 Apr 2002 18:09:33 -0500
> > From: Jing Zhou <[EMAIL PROTECTED]>
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > To: Struts Developers List <[EMAIL PROTECTED]>
> > Subject: Re: Another way to find mapped properties
> >
> >
> > - Original Message -
> > From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> > To: "Struts Developers List" <[EMAIL PROTECTED]>
> > Sent: Tuesday, April 23, 2002 3:04 PM
> > Subject: Re: Another way to find mapped properties
> >
> >
> > >
> > >
> > > On Tue, 23 Apr 2002, Jing Zhou wrote:
> > >
> > > > Date: Tue, 23 Apr 2002 13:29:40 -0500
> > > > From: Jing Zhou <[EMAIL PROTECTED]>
> > > > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > > > To: Struts Developers List <[EMAIL PROTECTED]>
> > > > Subject: Another way to find mapped properties
> > > >
> > > > Struts 1.1 will introduce mapped property in the form beans.
> > > > The PropertyUtils find it by looking for patterns:
> > > > property_name{mapped_key}
> > > >
> > > > I am not aware of any in depth discussion about using
> > > > { } as a mapped property key identifier before, but I have
> > > > several concerns about the use of { }.
> > > >
> > > > * In XSLT spec as well as JSTL spec, { } is used for
> > > >expressions.
> > > >
> > > > * We can use property_name[mapped_key] to identify
> > > >   a mapped property in the following algorithm:
> > > >
> > > >   When see property_name[string_literal], test the first
> > > >   character to see it is digit or not. if not, treat the
> > > >   string_literal as mapped key. Otherwise, parse the
> > > >   string_literal into int, if parsing successfully, treat it
> > > >   as int index. If exception occurs, treat it as mapped key.
> > > >
> > > >   I did this some time ago, because I see people can do
> > > >   document["href"] in JavaScript, and element[non_integer_index]
> > > >   in XML style sheet.
> > > >
> > > > * If we could reserve the { } for expression, we may see
> > > >   Struts addressing pattern like this in the future:
> > > >
> > > >   a.b[{$i}].c[{$j}], or simply a.b[$i].c[$j]
> > > >   where {$i}, {$j} come from JSP scoped variables or tool scoped
> > > >   variables. It solves multi-loop problems too. Implementation is
> > > >   relative easy, just like what you do for indexed attributes
> > > >   prepareIndex() in BaseHandlerTag. Another function
> > > >   prepareProperty(...) will evaluate any expressions in property
> > attributes.
> > > >
> > > > Could some Struts experts share your thinking on this subject
> > > > and advise me any pros or cons of this approach?
> > > >
> > >
> > > Well, the mapped property handlers actually use parentheses ("(" and
")")
> > > instead of curly braces ("{" and "}").  Does that alleviate your
concern?
> >
> > My mistake to take parentheses as curly braces. So I still have a chance
to
> > use { }, but not very encouraged on the existing attributes. But I still
> > have some additional questions, a little bit off Struts.
> >
> > >
> > > My belief is that we should ultimately migrate to using the same
> > > expression language used in JSTL (and what will be used in JSP 1.3).
For
> > > the most part, we can accomplish that by adding new attributes to
existing
> > > Struts tags that recognize the new syntax -- and leave the existing
> > > attributes alone.  The new attribute names would match (as much as
> > > possible) the JSTL conventions for names.
> > >
> > > Does that make sense?
> > >
> > > > Thanks,
> > > >
> > > > Jing
> > > >
> > >
> > > Craig

Re: Another way to find mapped properties

[Jing Zhou]

- Original Message -
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, April 23, 2002 3:04 PM
Subject: Re: Another way to find mapped properties


>
>
> On Tue, 23 Apr 2002, Jing Zhou wrote:
>
> > Date: Tue, 23 Apr 2002 13:29:40 -0500
> > From: Jing Zhou <[EMAIL PROTECTED]>
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > To: Struts Developers List <[EMAIL PROTECTED]>
> > Subject: Another way to find mapped properties
> >
> > Struts 1.1 will introduce mapped property in the form beans.
> > The PropertyUtils find it by looking for patterns:
> > property_name{mapped_key}
> >
> > I am not aware of any in depth discussion about using
> > { } as a mapped property key identifier before, but I have
> > several concerns about the use of { }.
> >
> > * In XSLT spec as well as JSTL spec, { } is used for
> >expressions.
> >
> > * We can use property_name[mapped_key] to identify
> >   a mapped property in the following algorithm:
> >
> >   When see property_name[string_literal], test the first
> >   character to see it is digit or not. if not, treat the
> >   string_literal as mapped key. Otherwise, parse the
> >   string_literal into int, if parsing successfully, treat it
> >   as int index. If exception occurs, treat it as mapped key.
> >
> >   I did this some time ago, because I see people can do
> >   document["href"] in JavaScript, and element[non_integer_index]
> >   in XML style sheet.
> >
> > * If we could reserve the { } for expression, we may see
> >   Struts addressing pattern like this in the future:
> >
> >   a.b[{$i}].c[{$j}], or simply a.b[$i].c[$j]
> >   where {$i}, {$j} come from JSP scoped variables or tool scoped
> >   variables. It solves multi-loop problems too. Implementation is
> >   relative easy, just like what you do for indexed attributes
> >   prepareIndex() in BaseHandlerTag. Another function
> >   prepareProperty(...) will evaluate any expressions in property
attributes.
> >
> > Could some Struts experts share your thinking on this subject
> > and advise me any pros or cons of this approach?
> >
>
> Well, the mapped property handlers actually use parentheses ("(" and ")")
> instead of curly braces ("{" and "}").  Does that alleviate your concern?

My mistake to take parentheses as curly braces. So I still have a chance to
use { }, but not very encouraged on the existing attributes. But I still
have some additional questions, a little bit off Struts.

>
> My belief is that we should ultimately migrate to using the same
> expression language used in JSTL (and what will be used in JSP 1.3).  For
> the most part, we can accomplish that by adding new attributes to existing
> Struts tags that recognize the new syntax -- and leave the existing
> attributes alone.  The new attribute names would match (as much as
> possible) the JSTL conventions for names.
>
> Does that make sense?
>
> > Thanks,
> >
> > Jing
> >
>
> Craig
>

I know it is possible too early to ask what the new syntax is going to look
like
in the future version of Struts. But I could provide what lead me to think
to
use a mini expression evaluator for the property attributes.

Our tool is for business professional, to make things simple, I would like
to
give them only the property, validation rules, and  html related attributes
on a screen for   as an example. When some advanced users
want to explore iteration tags, for example, they could easily do it by
entering the property field with some simple expressions. Therefore I do not
need to put a check box on the screen for the "indexed" attribute to confuse
majority of users.

Do I return to JSP 1.0 spec by allowing expressions in property attributes?
In our controlled environment, users only have ONE place, form bean model
to define variables with only two possible scopes, session, or shared.
Thanks to your multiple sub-application support, people could shared
variables
in a  sub-application. So there is no page scoped, no request scoped, and
no application scoped variables for average users (This is our security
requirement that allow thousands of users to build mini web forms on one
site)
Therefore, any expressions when evaluated will import or export values
from or to the form beans, no other places. As the result, I feel I could
build a
"perfect" MVC visual model for the mass, even they do not know what
MVC means.

When I looked at JSTL spec 1.0, this kind of "perfect" will lost in the
standard
implementations, because th

Another way to find mapped properties

[Jing Zhou]

Struts 1.1 will introduce mapped property in the form beans.
The PropertyUtils find it by looking for patterns:
property_name{mapped_key}

I am not aware of any in depth discussion about using
{ } as a mapped property key identifier before, but I have
several concerns about the use of { }.

* In XSLT spec as well as JSTL spec, { } is used for
   expressions.

* We can use property_name[mapped_key] to identify
  a mapped property in the following algorithm:
  
  When see property_name[string_literal], test the first
  character to see it is digit or not. if not, treat the
  string_literal as mapped key. Otherwise, parse the
  string_literal into int, if parsing successfully, treat it
  as int index. If exception occurs, treat it as mapped key.

  I did this some time ago, because I see people can do
  document["href"] in JavaScript, and element[non_integer_index]
  in XML style sheet.

* If we could reserve the { } for expression, we may see
  Struts addressing pattern like this in the future:

  a.b[{$i}].c[{$j}], or simply a.b[$i].c[$j]
  where {$i}, {$j} come from JSP scoped variables or tool scoped
  variables. It solves multi-loop problems too. Implementation is
  relative easy, just like what you do for indexed attributes 
  prepareIndex() in BaseHandlerTag. Another function
  prepareProperty(...) will evaluate any expressions in property attributes.

Could some Struts experts share your thinking on this subject
and advise me any pros or cons of this approach?

Thanks,

Jing

Re: form bean life cycle

[Jing Zhou]

- Original Message -
From: <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>; "Struts
Developers List" <[EMAIL PROTECTED]>
Sent: Monday, April 22, 2002 9:13 AM
Subject: Re: form bean life cycle


>
>
>
> Gee -
>
> No sooner did I fire off my response, then I read this response telling me
> I was all wrong.
>
> 
>
> I guess I'm specifying how I design code myself - not how struts does it.
>
> That being said, this limitation of having to specify a concrete class
only
> should be logged as an "enhancement request" in bugzilla. You should be
> able to either:
>
> 1. Have the form bean subclass an abstract form bean,
> 2. have the form bean implement a form bean interface you define, or
> 3. specify a specific class name.
>
> I'd say also that allowing it to implement an interface is my preferred
> approach over subclassing an abstract class. You can always define an
> Abstract class that implements the interface if you want. That is,
>
>  - an interface-based approach allows all of 1, 2, and 3.
>  - requiring subclassing allows only 1 and 3.
>
> Sorry for the cross post to the developers list -
>
>
> FWIW -
> Kevin
>
>
>
>
>
> "Nicolas De Loof" <[EMAIL PROTECTED]> on 04/22/2002 10:13:38 AM
>
> Please respond to "Struts Developers List" <[EMAIL PROTECTED]>
>
> To:   "Struts Users Mailing List" <[EMAIL PROTECTED]>
> cc:   "Struts Developers List" <[EMAIL PROTECTED]>
> Subject:  Re: form bean life cycle
>
>
>
> [send in copy on Struts-dev list]
>
> In ActionServlet (Struts 1.0.2) you can read that formBean object found in
> scope is compared to the form name declared in ActionMapping by testing
> class name, not testing it using an "isInstance" or any other reflection
> mecanism that could allow using inheritance or abstract FormBeans.
>
> instance = (ActionForm) session.getAttribute(attribute);
> ...
> className = formBean.getType();
> ...
> className.equals(instance.getClass().getName())) {
>
>
> Can any Struts developper explain if there is a technical reason to this
> limitation ?
>
I am guessing Struts developer's thinking. Struts use bean reflection
mechanisms to populate the form bean. The BeanInfo's method
getPropertyDescriptors() may not be able to return a subclass's
property. The same is true for Class.getMethod(). If this is the case,
then the class names must be matched exactly.

Struts users,
Jing
>
> > Hello all, I a mwondering about this ?
> >
> > I have a form bean declared abstract and I have subclassed it
> > into three concrete form bean classes that I use, this works OK.
> >
> > Then, I want now, to use an action that does not require to know
> > anything about these concretes implementations: I want my
> > action to work on the  interface of the abstract form, for this
> > I have declared an action-mapping to use a form bean
> > of the abstract class and from the session scope, I thought
> > that struts won't try to create the form again (actually it
> > can't because the form class is abstract), infortunatelly
> > the logs of struts told me that struts have tried to create
> > it.
> >
> > My question is why do struts try to recreate the action form
> > if it can be found from the session
> >
> > =
> > -- KeV --
> > =
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> 
> > For additional commands, e-mail:
> 
>
>
> --
> To unsubscribe, e-mail:
 >
> For additional commands, e-mail:
 >
>
>
>
>
>
>
>
> --
-
> This e-mail message (including attachments, if any) is intended for the
use
> of the individual or entity to which it is addressed and may contain
> information that is privileged, proprietary , confidential and exempt from
> disclosure.  If you are not the intended recipient, you are notified that
> any dissemination, distribution or copying of this communication is
> strictly prohibited.  If you have received this communication in error,
> please notify the sender and erase this e-mail message immediately.
> --
-
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Struts Validator: The Role of Page No.

[Jing Zhou]

- Original Message -
From: "David Winterfeldt" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, April 18, 2002 3:33 PM
Subject: Re: Struts Validator: The Role of Page No.


>
> --- Jing Zhou <[EMAIL PROTECTED]> wrote:
> > I am trying to normalize hundreds of screen objects
> > in
> > a struts related tool, so when the validator page
> > number
> > came into the picture, I feel I am not fully
> > understand its
> > implications from the perspective of business
> > scenarios.
> >
> > Basically I think the validator just validate the
> > current
> > page is *enough* in most of cases for a multi-page
> > application. The validator could refer to the data
> > entered in the previous pages when validating the
> > current page, but it does not need to re-validate
> > the
> > previous pages. If someone says the data from the
> > current page may invalidate the data in the previous
> > pages in his/her application, that could means the
> > order of page sequence is incorrect in the design.
> > To make a good design, the rule to follow is very
> > simple: The current page is validated according
> > to the data in the current page and the previous
> > pages,
> > but not the following pages. Could someone
> > give me a contradiction here? I am probably missing
> > something when considering this rule.
> If the way the page number works doesn't fit your
> need, you don't need to use it.  In a linear
> multi-page form where the Action keeps forwarding you
> to the next page as each form is validated, I think
> this behaviour makes sense.

It is my understanding that you could treat the multi-page forms
as ONE logical page. So validating everything on this
logical page will make sense.

The challenging constraint I have is that I have to
provide an automatic procedure for non-programming
business users to validate whatever properties they
specify on a view model. The procedure must be
completed within the phase of validation (not reaching
the Action.execute() phase yet.) In order to make things
simple for them, I could not let the business users to
specify another action to perform page validation.

A simple generic automatic procedure is in its early shape,
but I  havn't figure out how to connect it to your validator yet.
The page number bothers me. In your early reply, the
page number is optional, I am really happy with it.

Thanks lot!

Jing

>
> You could use the ValidatorActionForm if you want to
> associate your validation rules with an action.  Then
> you would have an separate action for each form.
>
> "Another alternative is to use the action mapping you
> are currently on by extending the ValidatorActionForm
> instead of the ValidatorForm. The ValidatorActionForm
> uses the action element's 'path' attribute from the
> struts-config.xml which should match the form
> element's name attribute in the validation.xml. Then a
> separate action can be defined for each page in a
> multi-page form and the validation rules can be
> associated with the action and not a page number as in
> the example of a multi-page form in the validator
> example."
>
> http://home.earthlink.net/~dwinterfeldt/overview.html
>
> David
>
> >
> > Another problem with the page number is when
> > users skip over several pages by choosing
> > certain check boxes or selections in an application,
> > should the skipped pages be validated? If yes, the
> > validator may have to take the burden to distinguish
> > the situations where the data had been specified
> > by users or skipped by users. Is that true?
> >
> > I hope my question is more clear this time and
> > someone could offer your judgements and
> > correct me if you think I am going to make
> > a fundamental mistake here.
> >
> > Thanks,
> >
> > Jing
> >
> >
> >
> >
> > - Original Message -
> > From: "Jing Zhou" <[EMAIL PROTECTED]>
> > To: "Struts Developers List"
> > <[EMAIL PROTECTED]>
> > Sent: Wednesday, April 17, 2002 7:55 PM
> > Subject: Struts Validator: The Role of Page No.
> >
> >
> > When looking into the validator codes, the page no.
> > of a wizard
> > like application is needed for validator to work. It
> > looks to me
> > that the validator will validate the current page
> > plus all pages
> > before the current one.
> >
> > Could someone provide some design thinking as why
> > developers
> > may need to validate all pages befo

Re: Struts Validator: The Role of Page No.

[Jing Zhou]

I am trying to normalize hundreds of screen objects in 
a struts related tool, so when the validator page number
came into the picture, I feel I am not fully understand its 
implications from the perspective of business scenarios.

Basically I think the validator just validate the current
page is *enough* in most of cases for a multi-page
application. The validator could refer to the data
entered in the previous pages when validating the
current page, but it does not need to re-validate the
previous pages. If someone says the data from the
current page may invalidate the data in the previous
pages in his/her application, that could means the
order of page sequence is incorrect in the design.
To make a good design, the rule to follow is very
simple: The current page is validated according
to the data in the current page and the previous pages,
but not the following pages. Could someone
give me a contradiction here? I am probably missing
something when considering this rule.

Another problem with the page number is when
users skip over several pages by choosing
certain check boxes or selections in an application,
should the skipped pages be validated? If yes, the
validator may have to take the burden to distinguish
the situations where the data had been specified 
by users or skipped by users. Is that true?

I hope my question is more clear this time and
someone could offer your judgements and
correct me if you think I am going to make
a fundamental mistake here.

Thanks,

Jing




- Original Message - 
From: "Jing Zhou" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, April 17, 2002 7:55 PM
Subject: Struts Validator: The Role of Page No.


When looking into the validator codes, the page no. of a wizard
like application is needed for validator to work. It looks to me
that the validator will validate the current page plus all pages
before the current one.

Could someone provide some design thinking as why developers
may need to validate all pages before the current page?
Or this feature is a kind of 'double checking' (or extra checking)
that could be turned on or off in configuration files?

Thanks,
Jing




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

Struts Validator: The Role of Page No.

[Jing Zhou]

When looking into the validator codes, the page no. of a wizard
like application is needed for validator to work. It looks to me
that the validator will validate the current page plus all pages
before the current one.

Could someone provide some design thinking as why developers
may need to validate all pages before the current page?
Or this feature is a kind of 'double checking' (or extra checking)
that could be turned on or off in configuration files?

Thanks,
Jing

The Exception/Bug in STRUTS B1 example

[Jing Zhou]

Hi, struts developers,

I posted the problem on 04/03 in struts user group and
hope the problem will be fixed in struts 1.1 final release.

Take a look at the example page html-link.jsp in
struts-exercise-taglib and click the 'Cancel' button.
An exception is thrown with message:
'array element type mismatch' 
by PropertyUtils.setIndexedProperty().

I looked at the root cause and found that
the TestBean has no indexed method for stringArray
while the PropertyUtils is invoking setIndexedProperty
method when it sees the property stringArray[0]
posted from the html-link.jsp.

A theoretical fix is to change BeanUtils.populate
method above the section '// Convert the parameter
value as required for this setter method'

Original section:
if(parameterTypes.length > 1)
parameterType = parameterTypes[1];   // Indexed or mapped setter

Change to:
 if(parameterTypes.length > 1) {
  parameterType = parameterTypes[1]; // Indexed or mapped setter
 } else {
  // The normal process will use parameterType from parameterTypes[0]
  // But we have a special case:
  int nestedDelim = name.lastIndexOf(PropertyUtils.NESTED_DELIM);
  int indexedDelim = name.lastIndexOf(PropertyUtils.INDEXED_DELIM);
  if(indexedDelim > nestedDelim) {
   // At this point, PropertyUtils will invoke setIndexedProperty later,
   // but it will use a wrong parameterType.
   // So, we change the parameter type to its component type,
   // then everything will follow the same processing.
if(parameterType.isArray()) {
parameterType = parameterType.getComponentType();
 }
   }
  }

I had tested the fix and no exception anymore and hope this will provide
a double checking for the developer who is fixing the problem on a
theoretical ground. Another way is that you have to change the
TestBean class to add an indexed method for stringArray (but that will
make struts less stable)

If anyone can confirm the bug, I can submit the bug to the database
for you.

Thanks,
Jing

Re: The Semantic of 'Cancel' Button

[Jing Zhou]

Thanks Craig and James. I can accept the original design
thinking. Raising the question is because I thought skipping
over populating form beans in canceling process is
a *common* behavior, and therefore it should be
implemented in base classes, instead of in sub classes.

The 'Are-you-sure-yes-no' dialog right after 'Cancel'
button is a *special* scenario. I observed a lot of
'Are-you-sure-yes-no' dialogs right after 'Exit' button
or 'Save' button, and haven't found any real application
giving me a 'Are-you-sure-yes-no' dialog after 'Cancel'
button. So I thought it is more a semantic problem
rather than an application specific problem.

I agree with Craig on the backwards compatibility issue
and like the ideas to add an attribute to the CancelTag
to allow both scenarios.

Thanks,
Jing


- Original Message -
From: "James Mitchell" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, April 10, 2002 10:05 PM
Subject: RE: The Semantic of 'Cancel' Button


> Sorry if I appear overly aggressive, but this reminds me of an argument I
> had with a former project manager (note the word *former* because he
didn't
> last too long)
>
> If you look at the source code
> http://jakarta.apache.org/builds/jakarta-struts/release/v1.0.2/src/
> (or) the developer guide
> http://jakarta.apache.org/struts/struts-html.html#cancel
> (or) the taglib documentation
> http://jakarta.apache.org/struts/struts-html.html#cancel
> it clearly states that using the html:cancel will render an  type="submit" name="..and so on and so forth.
>
> Therefore it is up to you (the developer) to decide what to do inside your
> action class.  If you have decided to give the user one last chance (Are
you
> sure?  Yes/No)  You certainly don't want your auto-magically populated
form
> bean to be "kicked-to-the-curb" (sorry, I'm from Georgia).
>
> On the other hand.  If you want to avoid the overhead (however little it
> might be) of having your form populated, then you could create a separate
> html:form on the page and stick your cancel where the sun don't
> shi.(sorry, getting off track here).have your cancel submit its
own
> form so that struts has nothing to populate.  You even get the added bonus
> of specifying a different action so you don't have to figure it out in
(what
> would have been) the original action class.
>
> This issue is really specific to someone's application, not really about
> struts.
>
> Good Luck
> JM
>
> (I never did like that project manager anyway)
>
>
> > -Original Message-
> > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, April 10, 2002 10:31 PM
> > To: Struts Developers List
> > Subject: Re: The Semantic of 'Cancel' Button
> >
> >
> >
> >
> > On Wed, 10 Apr 2002, Jing Zhou wrote:
> >
> > > Date: Wed, 10 Apr 2002 16:42:13 -0500
> > > From: Jing Zhou <[EMAIL PROTECTED]>
> > > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > > To: Struts Developers List <[EMAIL PROTECTED]>
> > > Subject: The Semantic of 'Cancel' Button
> > >
> > > In STRUTS, the 'Cancel' button (the html tag) will populate
> > > the form beans, if there is one, and skip over the validation.
> > > The question is why STRUTS need to populate the form beans
> > > When a 'Cancel' button signal is received.
> > >
> >
> > The original thinking for this design is that "cancellation is in the
eyes
> > of the beholder" -- it's the action that decides whether the user really
> > cancelled or not.  In addition, you couldn't do an "are you sure" page
> > that redisplayed the partially filled out form unless the form bean was
> > populated.
> >
> > I can see your reasoning for the opposite behavior as well -- but
changing
> > it now would also be a backwards compatibility issue.  At best, we could
> > make it a configurable behavior.  (Or, you can subclass ActionServlet in
> > 1.0 or RequestProcessor in 1.1 and achieve that behavior for yourself by
> > overriding a single method.)
> >
> > Craig
> >
> >
> > > >From my past experiences on UI development, if the 'Cancel' button
> > > is clicked in a dialog, it will close the dialog and do NOT apply
> > > any changes to the underlying data buffer, in STRUTS contexts,
> > > the data buffer is the form beans. If the 'Cancel' button
> > > is shown 

Re: Is FormBean mandatory???

[Jing Zhou]

- Original Message -
From: "Bob Lee" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, April 10, 2002 9:37 AM
Subject: Re: Is FormBean mandatory???


> ----- Original Message -
> From: "Jing Zhou" <[EMAIL PROTECTED]>
> To: "Struts Developers List" <[EMAIL PROTECTED]>
> Sent: Wednesday, April 10, 2002 4:28 AM
> Subject: Re: Is FormBean mandatory???
>
>
> > Form beans can be shared by multiple views in a wizard like
applications.
> > In particular, we want users to be able to use 'Previous', 'Next',
> 'Finish',
> > and 'Cancel' buttons to move between screens. Using form beans will save
> > a lot of coding work and these requirements are mandatory regardless
> > how large or small the applications are.
>
> Is it ever necessary to retain erred inputs past the request context? I
> still don't understand why you need getters and setters for every form
field
> when the data is readily available in the request object. Some argue
better
> type checking, but the fact is half this benefit is lost when you start
> depending on reflection. Also, Struts tools would be a lot easier to
develop
> if you could just work against a field map rather than having to
dynamically
> generate Java interfaces; from what I gather, this is what the DynaBean
> accomplishes.
>
> Thanks,
> Bob
>
>
The current Form Bean implementation (ActionForm + DynaBean) is to provide
a base for possible sophysisticated implemenations. The *advanced* versions
of
Form Bean should accomplish the following goals (in my personal opinions)

* The internal data structure or model for the Form Bean could be regular
   Java Bean or XML DOM or HashMap. But from outside point of view,
   These internal models are interchangable, nestable, with uniform and
   consistent access methods and developers should not worry about
   getter/setter any more.
* Initialization could happen when STRUTS initialize itself or on demand.
   Consider the system has 5000 form bean models in database, it can't
   initialize all of them at startup. STRUTS tool may help here.
* Form Bean should know how to reset/validate its internal properties given
a
   view model. It should reset those properties with respect to a view, not
   reset all properties. The same is true for validation.
* Form Bean should also know how to persist itself into strings and reload
   from strings as well as provide some callbacks for custom actions. Again
   not all fields are to be persisted. This is needed when replaying
   the submission processes is necessary in certain business requirements,
   like address corrections when you moved. Can any validator validate
   your address? :-)

Our internal system basically accomplish the above goals therefore a visual
tool is developed for it. The system also manage the security of the Form
Bean
as well as multi-user access to the same From Bean. The EJB security and
concurrent services are not enough. The presentation layer needs those
concepts too before the data reaching EJB server. So, if stay with the
Form Bean, the benifits are a lot than just type checking.
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
>


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

The Semantic of 'Cancel' Button

[Jing Zhou]

In STRUTS, the 'Cancel' button (the html tag) will populate
the form beans, if there is one, and skip over the validation.
The question is why STRUTS need to populate the form beans
When a 'Cancel' button signal is received.

>From my past experiences on UI development, if the 'Cancel' button
is clicked in a dialog, it will close the dialog and do NOT apply
any changes to the underlying data buffer, in STRUTS contexts,
the data buffer is the form beans. If the 'Cancel' button
is shown on a html page, when it is clicked, it will take the users
to a different page, which is the first page of a wizard like app,
or some index page. So in either cases, STRUTS do not need
to populate the form beans.

More important is that when user click the 'Cancel' button, she
means to discard whatever data on the screen. But STRUTS
populate the discarded data into the working form beans, so
it creates possibility that developers may use wrong data
in the form beans and make further logic decisions. Actually,
all the developers need to know is the Action.isCancelled(),
that is enough, in my opinion.

It gets another problem if the application would like to 
re-produce the screen before the 'Cancel' button is clicked.
The re-produced screen will show up with the data which
she means to discard in the previous clicking of the 'Cancel'
button in the current STRUTS implementation.

In all scenarios I think STRUTS should skip over the population
of the form beans  when the 'Cancel' button is clicked.
Could anyone clarify this issue? It is possible I am missing
some other scenarios where populating form beans are
necessary when clicking the 'Cancel' button.

Thanks,

Jing

Re: Is FormBean mandatory???

[Jing Zhou]

- Original Message -
From: "Paul Smith" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, April 09, 2002 8:48 PM
Subject: Re: Is FormBean mandatory???


> This logic is essentially correct in that the framework needs to process
> front end stuff prior to mapping to a view object. However, there are good
> reasons to not want to have a form bean and a view object and an entity
> bean.
>
> Memory usage -- while frivolous object creation is ok in small to medium
> sized apps, larger apps can have thousands of view, form combinations and
> object trees. you really dont want to be instantiating a view from the
bean
> and then a form from the view (even though that may be the purest way to
do
> it currently)
Form beans can be shared by multiple views in a wizard like applications.
In particular, we want users to be able to use 'Previous', 'Next', 'Finish',
and 'Cancel' buttons to move between screens. Using form beans will save
a lot of coding work and these requirements are mandatory regardless
how large or small the applications are.
>
> Ease of development -- dynaForms make for easy form beans but they dont
make
> for easy mapping from form->validate->view->entity. Also, having to glue
all
> of that together creates as much confusion as the original type 1
> infrastructures.
DynaForm provides a very good starting point for ease of development. People
will see an environment soon in which knowledge workers can visually
compose Mapping, Model, View, and Controller and then publish the composed
mapping. There are visual bindings for properties between the Model
(form bean model) and the View (JSP page), also visual bindings for forwards
between the Mapping and the Controller. The validations are even simpler:
knowledge workers just write the rules right below the property name
for which they want to validate on the View. How about the famous
reset() function remembering the fact that the knowledge workers do not
write
single line of the codes? The system will automatically reset unposted
properties related to check boxes and select options.
These are minor features in our internal systems. Making a tool for the mass
is possible on STRUTS infrastructure.
>
> Maintainability -- the current mechanism is somewhat clugey at best and
> results in significant conversion code that has nothing to do with
business
> logic.
Struts as a framework can not overdo its conversion code, but custom
conversion code should be able to embed some validation logic inside the
converters.
However, the current b1 release provides only a runtime exception,
ConversionException. I hope STRUTS team could consider a way to have
the RequestUtils or RequestProcessor to catch up the business logic
conversion
exceptions and put them into ActionErrors or forward to
an exception handler declared somewhere in the future.
>
> Design Clarity -- I have spent numerous hours with junior programmers in
> code reviews dealing with inconsistent transformation strategies, in
> appropriate amounts of object creation, etc. on relatively simple apps.
>
> Interestingly enough it does create something of an opportunity. Using
> proxies and some basic mapping/templating patterns the form bean could be
> 'split' to represent a combination of the VIEW and MODEL while maintaining
> there relationship and consistency using mapping/validation language in
the
> config file. Wouldnt that just be cool. Automate the view->form bean up to
a
> certain point of complexity, and then provide programming hooks for more
> robust functionality. Basically there is an opportunity to take struts one
> step further by providing apis for app server integration.
>
> Paul
>
There are indeed an open space between STRUTS and EJB server. That's
the cool part of STRUTS where it keeps itself from touching the EJB at all!
There should be a sperate framework or plugable framework that connects
the Form Bean and EJB using some kind of mapping technique. Form Beans
are very complicated animals: In our system, we allow nested models for
the Form Beans, which means the property name a.b[1].c could have
'a' refer to a form bean model property, 'b[1]' refer to a regular bean
property, and 'c' refer to another form bean model property again. In the
visual
presentation of the form bean model, we have check boxes for persistent,
populatable, constant. We also make distinct concepts between populating
a property and assigning a property to a form bean. We even have a
concept (anolog to EJB) for container managed form bean persistency for
benifits of knowledge workers. As a result, another feature is that we allow
knowledge workers to replay the wizard like applications exactly the
same sequence they did two months ago. Form beans are at the center stage
for such the business logics here. I think STRUTS team should have a
very deep understanding of this animal before connecting STRUTS to EJB.
My prediction to Form Bean is that it will share equal or more popular