from:"Ted Husted"

Re: Multiple form-beans and Action class

2003-10-19 Thread Ted Husted

The controller will only populate a single ActionForm for each
ActionMapping. At least automatically. The HttpServerRequest is passed
to your Action, so you could always populate some others if you like.
See the code in the RequestProcessor to see how the controller does it.

Depending on your circumstances, another approach is to use a
coarse-grained ActionForm class that uses all the properties your
application (or module) uses at one time. You can then setup different
form-bean names to specify different validations for various pageflows.

HTH, Ted.

[EMAIL PROTECTED] wrote:

Hi,

Is it possible to point multiple form beans to the same action within struts-config file? Kindly let me know using an example.

Cheers,
Nitin
Visit our website at http://www.ubs.com

This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.

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

--
Ted Husted,
Junit in Action - <http://www.manning.com/massol/>,
Struts in Action - <http://husted.com/struts/book.html>,
JSP Site Design - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
"Get Ready, We're Moving Out!!" - <http://www.clark04.com>

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

Re: Struts-chain Behavior Discussion

2003-10-17 Thread Ted Husted

> Here is why I believe that the code is
> of interest to the Struts community:
There are many extensions of interest to the Struts community, and we
maintain a resource page to help people find them.

In practice, when an extension becomes very popular within the
community, and it's obvious that there will be people around to maintain
the extension, then someone has added it to the core. The Validator,
Tiles, and Nested, all came about this way.

So, the people to lobby aren't so much the Committers, but the Users. If
a good number of people in the community, which includes the Committers,
start using an extension like this, then it will probably find its way
into the distribution. Darwin decides.

Personally, I believe in keeping the core distribution as light as
possible. That's one reason I still haven't made my own Scaffold package
part of the core. It's also the reason we started places like Struts
SourceForge.

-Ted.

john sessler wrote:
Hello,

I get the distinct feeling that the committers point of view on the controller component of Struts is quite similar to Henry Fords point of view on the color of his cars. ...The controller component can be based on any arqitecture at all as long as its Command Chains...

I realize that at some point a path must be choosen and code written. Ideas and conjecture about how many design patterns could be applied to the problem are insufficient. Craig has written code and Ted likes it so a path has been choosen, code written. No problem. Life is good.
I don't doubt the proof of concept or the reasoning behind it. I am concerned about the acceptance of other ideas and other code (I have already said ideas are not enough).

Prior to this extensive thread I have submitted code which fits squarely inside the
controller component of the Struts MVC arquitecture. I requested comments on the code
and received none.
I might have expected constructive criticism, obsevations or even recognition of
merit... but needed. But indifference was quite surprising. In light of the discussion
within this thread I see the problem. My code contribution doesn't fit the expected
pattern. Yes, that's a play on words.
Indulge me for just a few more minutes. I formally request that a committer look at the code/doc I have contributed. Yes, I understand that you are volunteers and that you have no obligation to do so. If someone should decide to respond I thank you in advance. This is also my last request for comments. Here is why I believe that the code is of interest to the Struts community:

* The approach requires an absolute minimum amount of integration with existing Struts code. The approach requires an essentially trivial refactoring of the RequestProcessor. I repeat, REFACTORING, not a new or modified behavior RequestProcessor. Since even refactoring would not "be doing the right thing". In lieu of that, a Coomand adapter can probably be used.

* Much has been said about coupling between actions. I claim that there is no coupling between actions using the approach. Comments are welcome.

* Much has been said about mixing business logic with actions. I claim that the approach does not mix business logic with actions nor does it encourage it. Comments are welcome.

* The approach does not require a developer to choose this approach over other, differing approaches. Mixing and matching is fine.

* The approach is aimed toward reusable Struts controller components. Here, I'm refering to the MVC controller in the general sense not to the Struts servlet controller. Comments are welcome.

Here is the link to the code and documentation.
https://www.sistemas-jasper.com/indexStrutsActionWrappers.htm.

John A. Sessler

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

Re: Struts-chain Behavior Discussion

2003-10-16 Thread Ted Husted

PILGRIM, Peter, FM wrote:
Suppose team T1 invents a generic web search engine component.
Let say another team T2 wanted to use that component, say
embed it is in own JSP views using say Tiles.
How does the search component forward or transfer control to 
the external component that T2.

One way could be to use an action chain. First, one writes a Struts
Action in such way that it puts a known public bean or put the bean
in the form bean. Whatever. This Output Bean contains contains
your search result or selected object. Second, one can 
generate a dynamic ActionForward that names the second Action
to forward.

But I am thinkgin Craig has given us an alternative option, of maybe
using a Command to do this. But if and only if an Action is refactored
as a Command.
Personally, I wouldn't bother dragging an Action into it. Just do the 
whole thing as a Command/Chain. The Action collect the parameters, puts 
them into the Context, and passes the Context down to Chain. Chain 
executes the search and passes the Context back. The Action's one and 
only job is as an adapter that transfers attributes between the HTTP 
Context and the Chain Context.

I think when we start pursuing this strategy, servlets/actions as 
adapters, we start moving from Model 2 to Model 3.

What's Model 3? Here's something I wrote up this morning:

Model 1 uses a server page to conduct the business operations and render 
the dynamic data generated by the business operation.

Model 2 uses a servlet to conduct the business case processing and a 
server page to render the dynamic data generated by the servlet.

Model 3 uses an independent set of classes ("POJOs") to conduct the 
business operations and a server page to render the dynamic data; a 
servlet (or filter) acts as a thin adapter between the business classes 
and server pages.

-Ted.



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

Re: Nested-EL

2003-10-16 Thread Ted Husted

[EMAIL PROTECTED] wrote:
Understood.  I have all of the classes written. The TLD is looking a little
daunting.  From my studies it appears that the tld is generated from an xml
file that is run through an xsl stylesheet.  If you want the classes, I can
send them to you.
Yes, that's true. But it may not be as difficult to work with the XML 
you might imagine. Try copying a likely suspect for a template, and then 
run the Ant compile.website target .. Instant TLD.

-Ted.



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

Re: Struts-chain Behavior Discussion

2003-10-16 Thread Ted Husted

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.

-Ted.



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

Re: Struts-chain Behavior Discussion

2003-10-16 Thread Ted Husted

Joe Germuska wrote:
> 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.
PILGRIM, Peter, FM wrote:
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.
Ted Husted wrote:
I think the Chain package will make it easier for people to do the Right 
Thing. The ActionForm properties, and so forth, can be commuted to a 
Context, and the Context passed up to a Chain which can do whatever it 
is they want to do.
Just to check in ...

I've been refactoring an application that started out using the "page 
controller" type actions into an architecture that uses "view commands" 
instead, and it seems to be working well.

In cases where I want to forward directly to the page, I can use a 
single Command:

In cases where I need to do something else first, like look up a seed 
record or process an update, I can set up a Chain that executes the 
business operations first, and then runs the view command. For one 
"interesting" page, I have two chains running back to it, depending on 
which control is used:

So, in places where I had "business" actions forward to "presentation" 
actions, I'm now back to having "command" actions forward straight to 
the server pages again. Life is good.

Ladies and gentlemen, I believe we've found the "missing link" =:)

-Ted.

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

Re: Struts-chain Behavior Discussion

2003-10-13 Thread Ted Husted

PILGRIM, Peter, FM wrote:
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.
I think the Chain package will make it easier for people to do the Right 
Thing. The ActionForm properties, and so forth, can be commuted to a 
Context, and the Context passed up to a Chain which can do whatever it 
is they want to do.

This isn't anything new. Many of us have been using this type of 
strategy for years. But without a concrete package like Chain, it has 
been too easy for people to misuse Actions.

I personally wouldn't recommend try to Chain Actions per se. The less 
work done in a Struts Action the better. But, Actions can make a very 
nice adapter between a Struts application and a Business Layer based on 
Chain.

What I'm doing in my own work is to correlate the Chain name with the 
validation attribute (aka ActionForm name/attribute). The idea being the 
validation determines whether the correct attributes have been collected 
for a given Command. So, for Command XYZ, I need to use Validation XYZ. 
This strategy makes it easy to use a standard adapter class that 
converts the HTTP parameters to context attributes, and call the 
corresponding Command. Depending on the outcome of the Command, the 
Action puts the Context, or attributes from the Context, into whatever 
HTTP scopes are expected (like the Scaffold ProcessAction).

The final "link", so to speak, is the Commons Message Resources. The 
Business Layer can use this package to return whatever messages are 
needed, which the standard adapter class can then expose as Struts 
messages.

-Ted.



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

Re: Self Describing Business Objects :

2003-10-07 Thread Ted Husted

The closest thing I know about might be dbForms 
<http://jdbforms.sourceforge.net/>, but it doesn't generate the entire 
JSP. Just makes it easier to write.

There's also MiddleGen <http://boss.bekk.no/boss/middlegen/>, but I 
don't think that addresses the presentation page at all, just the 
configuration files.

This looks like a likely scenario for JavaServer Faces 
<http://java.sun.com/j2ee/javaserverfaces/>, but that isn't available 
for use in a production application yet.

If you're doing things with XLS, two likely suspects are stxx 
<http://stxx.sourceforge.net/> and Maverick <http://mav.sourceforge.net/>.

There's a Cocoon Plugin for Struts available 
<http://struts.sourceforge.net/>, and an example Hibernate plugin for 
Struts is on their site <http://hibernate.org/105.html>.

If you bring over the editor and so forth, you might consider using 
Velocity for the screens <http://jakarta.apache.org/velocity/>. It's 
very amenable to this sort of thing.

But, Rob's right. This is really a USER list question.

-Ted.

[EMAIL PROTECTED] wrote:
I will be working on porting a company framework (and hopefully open source
it) from ASP/VB (yack!) to Java. The idea of the framework is quite simple.
It is a framework for buiding administration screens like update/search
edit user but it has some interesting features :
The Business objects a described in xml ie :


user
usr

firstname


First Name

.



Label

firstname
surname



Edit

firstname
surname



etc..

The Business Object xml descriptor has enough information for display it as
well as updating it. AttributesGroups allow for list views and edit views
of the object.
Another component of the framework is the PageFlows that are made up of
Actions that use these Business Objects to get the info for these views
like "Edit User". Most of the time you do not need to write code at all, we
have also written a editor for the Business Objects and the Pages Flows.
So at the end of the day the html of genernated by the framework from the
xml descriptor and the persistence is also done from there. So doing
administration screens are very quick. ie : days instead of weeks. The some
code can be used for web front ends as well as guis.
I was wondering it there is anything else out there like this or are there
ways on doing some intergration of this with Struta and Hibernate and
Cocoon?
Mike




The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee; access to this
email by anyone else is unauthorised.
If you are not the intended recipient: (1) you are kindly requested
to return a copy of this message to the sender indicating that you
have received it in error, and to destroy the received copy; and (2)
any disclosure or distribution of this message, as well as any action
taken or omitted to be taken in reliance on its content, is prohibited
and may be unlawful.

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

--
Ted Husted,
  Junit in Action  - <http://www.manning.com/massol/>,
  Struts in Action - <http://husted.com/struts/book.html>,
  JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
"Get Ready, We're Moving Out!!" - <http://www.clark04.com>



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

Re: Struts-chain Behavior Discussion

2003-10-07 Thread Ted Husted

Craig R. McClanahan wrote (10/4/2003 2:02 PM):
So, implementing this as a single chain would require ValidateActionForm 
to the success/failure state of the validation into the Context -- easy 
to do -- and three commands must now (inside their implementation -- the 
Chain does not know anything about this) surround their current behavior 
in an "if" statement, which means that they have to know the location of 
the state information that was saved (slight increase in coupling), and 
they get processed by the Chain even if they are not relevant (very 
minor performance impact; almost never enough of a concern to worry 
about).  But it would definitely work.
Yes, the current implementation trades coupling the Commands to the 
Context with coupling this Command to the Catalog, which I agree is a 
fair trade under the circumstances. But, TANSTAFL, coupling does 
increase somewhere, it's just a matter of choosing your battles. :)

Based on using the Command strategy in other implementations, I would 
guess that people retrofitting code streams (as we are doing here) may 
often find it simplest to nest Commands. Meanwhlie, people building the 
business logic from scratch may tend to make more use of the Context so 
that is easier for Commands to skip themselves.

-Ted.



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

Re: Struts-chain Behavior Discussion

2003-10-07 Thread Ted Husted

Craig R. McClanahan wrote:
* The way it's currently implemented -- ValidateActionForm
 conditionally branches to a separate chain on validation
 failure ("servlet-validation-failure" in the current config file),
 and [returns true to] abandon the remainder of the original chain.
The phrase "conditionally *nests* a separate chain" might be more 
accurate. Branch implies the Command loses control, which is not the case.

dictionary.com / Computer Science

branch - To relinquish control to another set of instructions or another 
routine as a result of the presence of a branch.

nest - A set of data contained sequentially within another.

-Ted.



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

Re: Struts-chain Behavior Discussion

2003-10-04 Thread Ted Husted

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.


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


* 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.
This is not a case of Command looking for flags, but a case of the 
Command examining the state of the Context and deciding whether the 
current Context applies to them or not. It is perfectly  normal and 
expected for many Command to be called but to do nothing (and return 
false). Jumping is not something you need to do externally.

In fact, I would say that avoiding jumps is why we have the Chain of 
Responsibility in the first place. We don't want to work that hard. We 
want to hand the Context to the Command (or Chain of Commands), and let 
the Commands do what they will.

For more on the intent of the CoR, see the Design Patterns book.

It's possible that you are not imagining the Chains to finely enough 
grained. An application can use as many Chains (or Catalogs) as needed. 
A service method (like a Struts Action) can determine which Chain to 
call from which Catalog under which circumstances. The need for a "jump 
behavior" might imply that the Chain is too coarsely grained and needs 
to be refactored.

If this thread were based on an actual use-case with a real Chain and 
real Commands, then we could look at alternative ways to implement the 
Chain. But since it isn't, we can't.


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



* There are more issues. But I get to stop here for a clear view
   of my thinking. Again, this is der

Re: Struts-chain Behavior Discussion

2003-10-04 Thread Ted Husted

Craig R. McClanahan wrote:
In terms of the chain implementation of the request processing 
lifecycle, this is just an unconditional command in the chain (it's 
implemented in o.a.s.c.servlet.PerformForward).  No skipping or stepping 
is requried.  See

 contrib/struts-chain/src/conf/chain-config.xml

for the entire definition.  You'll note that it requires no skipping -- 
just the conditional behavior on validation failures, which is modelled 
as a branch to a separately named command.
I wonder if even these conditionals could be made part of the chain. As
an alternative to branching, the Command could update the state of the
Context and return false. What is now a conditional Command could be the
next link the Chain. The "conditional" would check to see if the state
calls for it to execute, and if so, do its business and return true.
-Ted.



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

Re: Struts-chain Behavior Discussion

2003-10-03 Thread Ted Husted

Jing Zhou wrote:
> * 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.
I believe Chain is suppose to be an implementation of the classic Chain 
of Responsibility pattern. Chain is something that a workflow engine 
might use, but I don't believe it is meant to a workflow engine itself.

> 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.
Using a Context to assist with a workflow process seems reasonable. The 
Command should be able to examine the state of the Context and decide 
whether they should proceed or not.

In this case, renderResponse could be the postprocess on a Filter. A 
Command returns True, the Chain ends, and the Filters begin.

For the original use-case, where you just wanted to fast-forward to the 
end, again a Filter may be the solution. Once a Command returns True, 
the Filters start firing.

> 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?
Why not build another Chain? It's not a "there can only be only one" 
pattern. As many Chains can reuse as many Commands as needed.

-Ted.

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

--
Ted Husted,
  Junit in Action  - <http://www.manning.com/massol/>,
  Struts in Action - <http://husted.com/struts/book.html>,
  JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.

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

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

2003-10-03 Thread Ted Husted

Jing Zhou wrote:
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?
As a general concept, "jumping" smells wrong to me. The commands should 
handle or not handle whatever is passed to them, as each individual 
Command sees fit. When context dictates, the commands should be able to 
"skip themselves". The chain shouldn't be cast as a controller.

I suppose you could use the Context as a psuedo-controller. For example, 
it could have an attribute that told these Commands that they should be 
skip themselves. (If ([whatever]) return false;)

Though, for skipping to a final Command, would a Filter work for you? I 
haven't started using them yet (though I may today), but I understand 
the idea is that once a Command returns true, it skips to a postprocess 
method (even if an exception is thrown). The Javadoc mentions reclaiming 
resources, but it could be to do anything that might need to be done 
when a Chain completes. Even call itself to trigger some behavior now 
that the Context has reached a certain state.

Either the Command that would trigger the "jump" could be a Filter, or 
the Filter Command could be executed early in the chain (and just return 
false).

-Ted.



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

Re: [Vote] Choosing a build/doc gen tool(s) [was: Re: The Forrest Option]

2003-10-02 Thread Ted Husted

Steve Raeburn wrote:
> I'd like to add Maven now, learn from the experience on 1.x and then
> use that to optimize the project organization and build process for
> version 2.
If the people voting +1 are ready to roll up their collective sleeves 
and give Maven a try, then that would be fine with me. The missing piece 
has been someone saying "I'm ready to do Maven *now*".

My only concern is that Maven has not had a stable release. After ten 
betas, it has just published a RC1, but that's still shy of 1.0.

During the 1.1 incubation period, we withheld making a final release 
until all our dependent JARs were also in a final release state. But, 
since Maven is a production environment, and not a JAR teams would need 
to include in their own releases, this consideration might not apply.

So, if we would be able to ship a GA of Struts with a Maven Release 
Candidate, then I'm fine with whatever anyone wants to do.

But, if anyone is going to vote against a Struts GA on the grounds that 
Maven is prerelease, then we should wait until Maven hits 1.0.

I don't mind waiting on the Commons Validator, but I wouldn't want to 
wait on Maven.

-Ted.

Don Brown wrote:
> I'm assuming a move to Maven is inevitable?
"You will be assimilated."

James Mitchell wrote:
> Mavenization:
> [ ] +1 - I am in favor of using Maven for build/dist/test/etc.
> [X] +0 - I agree, but cannot help at this time.
> [ ] -0 - I don't agree, but not enough to give a -1.
> [ ] -1 - I am not in favor of using Maven for build/dist/test/etc.
>
> Forrestization:
> [ ] +1 - I am in favor of using Forrest for site generation.
> [X] +0 - I agree, but cannot help at this time.
> [ ] -0 - I don't agree, but not enough to give a -1.
> [ ] -1 - I am not in favor of using Forrest for site generation.
>
> Other:
> [X] - I would like to pursue the Maven-with-Forrest-as-a-plugin idea.

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

Re: Build improvements (was Re: The Forrest Option)

2003-10-01 Thread Ted Husted

Don Brown wrote:
Yes, this won't help our build at all.  Until we get Maven running, there
are some options to bring some Maven features over to Ant.  For example,
if we wanted to get rid of jars in our CVS, we could use something like
http://www.krysalis.org/ruper/ or
http://blogs.codehaus.org/people/kevin/archives/2003/09/21/index.shtml#000168.
Ant 1.6 has the ability to import build files which could help to spread
the load.
Ah, well, you see we don't have JARs in our CVS. That's one of the 
reasons people have trouble building Struts at first. They have to go 
off and snag all the JARs themselves. Though, it seems like ruper might 
help in that regard.

-Ted.



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

Re: The Forrest Option

2003-10-01 Thread Ted Husted

Robert Leland wrote:
> The whole Maven idea came because we felt the build
> process of ant struts-legacy was broken or needed some
> serious work. If Don wants to put energy into redoing our site's look
> and feel that then here is my +1. Just know we are still
> left with the original problem.
Struts-Legacy is a very special case. By rights, it should have gone to 
the Commons. It should be treated as if it were an external product. So, 
just like the Commons JARs, if you were doing everything from scratch, 
you would build struts-legacy first, and then the Struts core.

It's possible that the underlying problem is that we didn't release a 
struts-lib distribution with Struts 1.1 (as we did with some of the 
milestones).

-Ted.



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

Re: The Forrest Option

2003-10-01 Thread Ted Husted

David Graham wrote:
Rob mentioned something about Struts being setup for Maven already and I
asked for clarification.  If that's true then I see no point in
complicating things with another build tool.  Also, it seems that Maven in
some ways is a superset of Forrest functionality.  It handles the website
plus the jar builds.
The more tools involved means it's harder to understand the build process
which limits the number of people willing to put up with it and work on
Struts.  My personal goal (and I hope the group's as well) is to have
*one* easy to use tool that builds all of Struts.  I don't care if this is
Ant, Maven, or Forrest as long as it's only one of them.
David
Yes, but the goals around here are achieved by people willing to do the 
work.

If Rob wants to do the work of migrating to Maven, for whatever reason, 
that's fine with me. A lot of people I respect use Maven, it can't suck 
that badly. If Don wants to do the work of migrating to Forrest, that's 
fine too. A lot of people I respect use Forrest, so it can't suck that 
badly either.

But, if we're just looking for a "one-tool solution that builds all of 
Struts", we already have one. To change a page in the docs, you edit the 
corresponding XML page. To add to the menu, edit the project.xml for 
that directory. Run the Ant target. Done.

If we want Struts to be even easier to build for newbies, then we should 
bring back the struts-lib distribution. Download that with the source, 
and you were ready to rock.

-Ted.



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

Re: The Forrest Option

2003-10-01 Thread Ted Husted

Chris Gastin wrote:
I have to agree with David. Lets find one way to do it and make it simple,
if a build process can be. I have worked a little with Maven, and it seems
tobe simple. I am not knocking Forrest. I have not had a chance to look into
it. If that is more simple than Maven then I am all for it. Lets not make
the build process this awful process. I think everyone would agree with
that.
We're not talking about the build process as a whole. The Forrest Option 
refers only to website maintenance and documentation.

Since Don's ready to sign-up for Forrest, we should start by trusting 
his judgment and be ready to give this a try. That's what it means to be 
a Committer. Make the decision, do the work.

At this point, no one is raising their hand and offering to migrate us 
to Maven. Until someone does, Maven does not seem like a valid objection.

Though, a valid, technical objection would be that the website and the 
build (except for the current Cactus snafu) ain't broke, so we don't 
need to fix it. Steve's got everything running as valid XHTML. We're 
still using the original Apache look, but then so is the vast majority 
of other Apache projects. If we dusted off the struts-lib distribution 
(which appeared and disappeared during the last beta cycle), the 
quick-start concerns would be answered.

Certainly, it would make sense to start new development on Forrest 
and/or Maven. If we spun off taglibs or rolled up our sleeves on 2.0, 
then we'd definitely want to make a decision there. (Based primarily on 
who was willing to do the work.)

And, we do have Forrest running on the SourceForge site, so things like 
RSS feeds and WikiDocs could be tried there first to see how helpful 
they really are. (I must admit, I'm intrigued.)

-Ted.



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

Re: The Forrest Option

2003-10-01 Thread Ted Husted

Don Brown wrote:
For example, currently, we have quite a few Struts extensions, example
applications, and related frameworks that I feel Struts could do a better
job of encouraging.  Instead of requiring an extension developer to submit
a patch to bugzilla to change a description or add their project to the
page, why not have a page that aggregates extension project's RSS
announcing new releases into a news-type page.  Giving extension projects
more exposure will generate more interest in finding ways to make Struts
better.  Look what it did for Maven :)
How about if we give a wider trial Forrest on the Community section 
first? This would be mainly News and Status, Resources, and could also 
include a Wiki compilation.

If it doesn't work out, the Community section would be easy enough to 
roll back.

-Ted.



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

Re: Raising feature requests and fix suggestions - What's the accepted way.

2003-10-01 Thread Ted Husted

To discuss whether a feature might be a good idea, you can post here.
Though, it can take several days before everyone weighs in. We're all
volunteers with real jobs. Many of us can only work on Struts on the
weekends.

To raise and fix issues, you can post tickets to Bugzilla. This is where
patches should go, so they don't get lost. If you have an alternate
patch, you can append that to the same ticket.

If you strongly believe in an issue, you might have to lobby for it.
This is often the case in open source. On another project, I had to make
several followups over a two-week period before getting a three line
patch committed. It's just the way things work on volunteer projects.

Bugzilla, the DEV list, and CVS are the only media that the committers
use to develop Struts. Both Bugzilla and CVS are programmed to post
changes to the DEV list, so everything that happens is reflected here.

Re: The Forrest Option

2003-10-01 Thread Ted Husted

Don Brown wrote:
Further, deciding between Forrest and Maven isn't an either/or situation.
There exists a Forrest plugin for Maven and it would be easy to integrate
Maven's reports into a Forrest site build.
<.../>

If we did decide to go with Forrest, I'm willing to convert the old site
over and help handle any integration.  I'm most definately not an expert
at Forrest, but am familiar with Cocoon and thankfully, Forrest is pretty
easy.
+1

This sounds like a nice stepping stone. We can try Forrest now and 
migrate the build to Maven as soon as someone is ready to volunteer for 
that.

Outside of the Jakarta Commons Sandbox, Forrest and Maven are equally 
popular among other Apache products. Using both might be the best of 
both worlds.

-Ted.



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

Re: Reviving PageController (ViewController?) discussion?

2003-09-30 Thread Ted Husted

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.

In practice, many developers, including myself, have found that they 
need to interject a second Action to prepare the request for the page. 
We need two extension points, because there are two decisions being 
made. The first is "who" will handle the response. The second is "what" 
 material they need to handle it.

I believe we all like the idea of separation of concerns, but most of 
also do not like splitting responsibilities. Currently, Actions are 
responsible for doing all the same things we want a page controller to 
do. So, my current suggestion is to add an extension point to 
ForwardConfig, so that the RequestProcess can call an Action here as well.

This approach lets developers continue using the Actions we all know and 
love, but saves the trouble of forwarding the request through container, 
just to complete the response.


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

For Struts 2, I would suggest starting with the premise that multiple 
Struts controllers can be available in the application, and that an 
action can be specified anywhere that a page or forward can be specified 
now. If the configuration and server pages never need to know what 
server pattern is being used, since they can refer only to actions, then 
we can accomplish modules (and I imagine portlets) by registering each 
player under a different URI pattern.

If we add metadata inheritence, multiple configuration files, and 
wildcard mappings to the mix, I believe teams would be able to define 
and use both hierarchical modules or switched modules in the same 
application.

One element of the front controller pattern is consistency in how 
incoming requests are handled, which helped to justify the "there can 
only be one" strategy. Happily, the excellent work that's been done on 
the RequestProcessor now makes it possible for multiple controllers to 
share the same customized class. So, we could have our cake and eat it 
too :)

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 working with no codes or
very little custom codes.
To an extent, we already have this functionality. A user can drop a WAR 
file into a container's directory, and presto-bango, they have a web 
application.

The portlet spec tries to do the same sort of thing one layer down, so 
that you can drop a PAR file in an application with the sort of result 
you describe.

The state-of-the-art in for portlets is our own Jetspeed project here at 
Jarkara (which in fact bred the proposed portlet specification).

-Ted.



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

Re: Reviving PageController (ViewController?) discussion?

2003-09-30 Thread Ted Husted

Joe Germuska wrote:
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.

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.
Personally, I like returning the ForwardConfig instead of a String since 
it's extensible. You can always call a method to get whichever String 
you want, the logical name or the system path.

In terms of what a framework based on Commons Chain might be like, I've 
made some notes here:

http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/chain/WHITEBOARD.html

But the cool thing about Chain is that it plays well with others. You 
can start using a Chain solution in your Actions at any time. The Action 
path could be a command name keyed to the business logic. Likewise, the 
ActionForward name could be another command keyed to the presentation 
side of the business logic. (What raw materials will be needed by the 
controls client specified for the target page.)

But, there's also another aspect to the view controller use case -- 
better support for i18n. The message bundles are a great start, but many 
applications need to branch to different paths for different locales, or 
even different clients. So, aside from preparing the request, we could 
also use a View Action to munge the path (in a new instance of 
ForwardConfig). Of course, the nuts-and-bolts of this process could be 
encapsulated in a Chain.

But once you take these two related cases together, I do believe an 
Action extension point for the ForwardConfig would be useful and 
justified. We've been taking about making the forward smarter for years. 
Now that we have a more flexible request processor, perhaps it's time to 
make it smarter in the usual way, by giving it an Action class.

I agree that you could collapse the "business" Action and the 
"presentation" Action into a single Chain. But, as much as I like Chain, 
I don't know if I want to present it as the final solution to this 
problem. Even with Chain, I might want to separate the concern of 
calling the "business" command from the concern of calling the 
"presentation" command.

I might even want to put them in different catalogs. One set of Actions 
could be calling a standard set of DAO commands. Another might be 
calling a set of commands geared for the presentation layer. One might 
be in a JAR handed down from another team. The second might be in my 
WEB-INF directory. Of course, you could combine these into the same 
runtime catalog, but then you have to micro-manage the namespaces and 
all that. TANSTAFL.

-Ted.



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

Re: Dependancies a wonderful thing

2003-09-30 Thread Ted Husted

I'm not sure that it matters. We're pragmatic when it comes to Bugzilla, 
so whichever is less work for you, should work for the rest of us. 
Volunteer time is our most precious resource.

The dependency feature is relatively new, and we haven't come to 
"depend" on it ourselves yet :)

-Ted.

Chris Gastin wrote:
I want to fix Bug #14183 (html:img does not support forward attribute), but I want to use the enhancements I made to the TagUtils class (Bug# 23462) to do it. 

I could do one of the following:
Option 1 - Make Bug #14183 depend on Bug #23462
Option 2 - Roll Bug #23462 Patch in with the enhancement with Bug #14183, and resolve 
Bug #23462 as INVALID
Does it matter, which option I pick, and what do you guys prefer as a good practice for this type of mistake in the future. I apologize for any confusion. Please advise.

Thanks,

Chris Gastin


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

Re: Where are tld files in CVS tree

2003-09-30 Thread Ted Husted

Chris Gastin wrote:
> Where in the CVS tree is the struts-html.tld file that needs to be
> modified when adding attributes to a tag.
What we do is maintain the TLDs as XML documents and then use a style 
sheet to generate the TLD and the HTML documentation. So, they are 
hidden in the documentation portion of CVS.

/doc/userGuide/struts-*.xml (bean, html, logic, nested tiles)

The build will take care of generating the TLDs for you, as well as 
updating the Developers Guide documentation.

-Ted.



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

Re: XHTML Web site updates

2003-09-29 Thread Ted Husted

Steve Raeburn wrote:
> Done.
The ASF thanks you for your help and support =:)

Hey anybody going? I won't make it this year, but I'm starting to think 
about 2004.

Regarding the archived 1.02 docs - there doesn't seem to be a link to them
anywhere. Shall I add one?
We should probably remove those now.

Also, we don't have the current release (1.1) docs on the site which might
be confusing for some users. Do we want to maintain docs for the current
version as well, and add appropriate links?
That approach was mainly an artifact of the "extended 1.1 incubation 
period". =:) We might now want to fall back to the original approach of 
just featuring the nightly build on the website.

Hopefully, we can get the Cactus tests sorted out soon and start the 1.2 
march, to help support the new Validator release.

-Ted.



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

Re: XHTML Web site updates

2003-09-29 Thread Ted Husted

Steve Raeburn wrote:
Contributors List
-
One side effect of merging the XSL stylesheets is that the contributors list
is currently not written at the start of each chapter. (Some stylesheets had
it, some didn't so I opted to remove it from the chapter section.)
I wondered what the feeling was regarding whether it is neccessary to have
that list at the top of each page.
+1 as to the new "sidebar" approach. I'm quite pleased with the way all 
this turned out.


Let me know what you think or if you find anything I missed.
I should just do this myself, but if you had a moment, could you slip in 
a link to ApacheCon at the top of our sidebar, like the one at the 
Jakarta site. They've asked all the Apache projects to do this. 
Technically, we're not the project, Jakarta is, but since we kinda get 
our share of hits ...

-Ted.



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

Re: cvs commit: jakarta-struts/src/share/org/apache/struts/util ActionMappingMatcher.java

2003-09-29 Thread Ted Husted

Just a heads-up: The discussions about the short "2.0" license are 
heating up again. A good time to catch the 1.0 licenses would when 2.0 
goes through. In the meantime, as Rob says, new development should use 
the 1.1 license

http://www.apache.org/licenses

with #4 modified to read:

 * 4. The names "The Jakarta Project", "Struts", and "Apache Software
 *Foundation" must not be used to endorse or promote products
 *derived from this software without prior written permission. For
 *written permission, please contact [EMAIL PROTECTED]
There's a reference copy of this at

http://cvs.apache.org/viewcvs/jakarta-struts/LICENSE.txt

-Ted.

Robert Leland wrote:
[EMAIL PROTECTED] wrote:

mrdon   2003/09/28 20:23:30

 Modified:src/share/org/apache/struts/action RequestProcessor.java
 Added:   src/share/org/apache/struts/action 
ActionMappingMatcher.java
 Removed: src/share/org/apache/struts/util ActionMappingMatcher.java
 

I forgot to mention, most of the Struts source code uses the OLD Apache 
1.0 license, even though
it is labeled version 1.1.
Take a look at the License.txt in the top level of Struts, this is the 
correct wording al code should be using.


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

Re: New feature process

2003-09-28 Thread Ted Husted

Once upon a time, I made a point of updating the changelog, but during 
that death march affectionately known as the Struts 1.1. release =:), I 
fell out of the habit, and haven't picked it up again. Back in the day, 
some thoughtful people also tried to update the changelog as they made 
the commits.

CVS and the CVS emails should be the primary reference for the 
changelog, since these are kept automatically. Not everything goes 
through Bugzilla. Erik Hatcher mentioned that Ant can generate a summary 
changelog from CVS, but I haven't tried it yet.

As far as tests and documentation go, there is a general consensus that 
new features should breed new tests. When possible, bugfixes should 
generate new tests too. Although, since Struts was not designed for 
testability, creating such tests can be a challenge. We should at least 
be running the tests we have around any change or commit.

However, at this point, I believe the Cactus tests are broken and that 
James Mitchell may try to fix them soon.

Since we are in an evolutionary mode right now, it not strictly 
necessary to obtain a vote on new features. But, it can save the trouble 
of backing the change out if it turns out to be something another 
Committer would veto. The hardcore Apache projects rarely vote on 
anything except releases. The decision-making is consensus-based through 
general discussion on the development lists. People use terms like +1 
and -1 in the discussions, but its not so much a vote as an indication 
of how they would vote, should a vote occur.

So, if you used tests as part of developing the feature, then please 
commit those too. Or, if you see a test suite that could be extended to 
include the new feature, please add the test.

Unless we are going to try automating the changelog with Ant, then it 
would be helpful to update the changelog as well (creating a new one if 
needed).

Under heading "observe the style of the original", please make sure that 
any submission is fully Javadoc'd. If possible, please also update the 
user guide as to the existence of your feature, relying on the Javadoc 
for base material.

If the feature was covered by a Bugzilla ticket, then please resolve the 
ticket. It's been suggested that if a feature was not registered in 
Bugzilla, then we should create one for it, but I'm not sure that we've 
developed a behavioral consensus on that. =:)

-Ted.

Don Brown wrote:
I'm familiar with the process of bringing up new features to the group as
it is documented on jakarta's site:
http://jakarta.apache.org/site/decisions.html
Rather, I was interesting in what the Struts process once the feature is
committed.  I would assume the following areas would be affected:
 - tests
 - changelog
 - documentation
 - bugzilla
Don

On Sun, 28 Sep 2003, Robert Leland wrote:


Don Brown wrote:


What is the process when adding a new feature (in this case, wildcards for
action mappings)?
Create a Subject: [Proposal] wild cards for action mappings.

Use lazy Consensus.
At least 3 +1 votes, no -1 votes.
There is a doc somewhere that says when to use each type of vote.
Also I thought we already discussed this and it's addition was approved ?

Do we wait until a release is ready to update the
documentation or update it when the feature goes in?
I would say nightly Docs should always match the nightly source


Also, I couldn't
really find a changelog.
If you have maven you can now build the top level struts documentation
which includes a
generated change log.

Do we just use bugzilla to track new features?
If so, should an enhancement request be made before a feature gets added?

No.


If this information is already on a webpage somewhere, I apologize in
advance :)

I would like to know that answer also.



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

Re: Reviving PageController (ViewController?) discussion?

2003-09-28 Thread Ted Husted

Here's a third idea:

Instead of creating a new class, we could just associate an Action class 
with the ActionForward. This is what people do now anyway. It seems to 
work, but wastes an ActionMapping and trip through the container.

So, we just add a "type" property to ActionForward, and a step to the 
RequestProcessor to handle it when available. If it's there, it gets 
called, and the RequestProcess forward to the path. If it's not there, 
the RP forwards to the path given by the original forward. Everything 
else remains the same.

I'm sure some people will misuse the feature, but some people will 
always misuse any feature. At least this way, we recognize what most 
people (including me) already do most of the time, put an Action in 
front of page. The advantage being that we don't have to waste an 
ActionMapping or a trip through the container just to forward to the  page.

-Ted.

Joe Germuska wrote:
I've been thinking about this a bit; as I see it now, some 
implementation choices might be a little contentious, so I feel like the 
right approach is discuss first, code later.

Below is my interpretation of the interface based on earlier discussion 
and such.  Note that I suggest we change the name from "PageController" 
to "ViewController", although I don't feel very strongly about it.  It's 
just one method (plus some javadoc to flesh out the idea.)

package org.apache.struts.action;

public interface ViewController {

/**
 * Perform any view-level preparations after an [EMAIL PROTECTED] Action} 
has executed
 * and before the display is rendered.  Return a [EMAIL PROTECTED] ForwardConfig}
 * instance describing where and how control should be forwarded, or
 * null if the response has already been completed.
 *
 * In the simplest case, where an implementation only modifies the
 * request context, the return value may be the same as the 
ForwardConfig
 * provided as an argument.  However, note that implementations 
should not
 * directly modify the given ForwardConfig if it is not the appropriate
 * return value; they must instead return a new instance
 * (or an implementation-level cached instance).
 *
 * @param forward The ForwardConfig in whose context this controller is
 * being invoked.
 * @param request The HTTP request we are processing
 * @param response The HTTP response we are creating
 * @return a ForwardConfig which will be used for final view dispatch,
 * or null if the response has already been completed
 * @exception Exception if the view preparation process throws
 *  an exception
 */
public ForwardConfig prepareView(
ForwardConfig forward,
HttpServletRequest request,
HttpServletResponse response)
throws Exception;

I think it's important (as noted in the JavaDoc) to help people 
understand that they can't change a "frozen" ForwardConfig.  (I kind of 
feel like this belongs more in something like o.a.s.view, but if it's 
going to be the only class there...)

At 10:31 -0400 9/15/03, Ted Husted wrote:

I'll post more on this later, but to avoid the "gotcha", I'm now 
thinking we should try this using a modified ActionMapping.findForward 
method. In that way, all the navigational control stays within the 
Action.


The part that seems like it might raise some discussion is about who 
manages the ViewControllers.  It seems wasteful to instantiate one each 
time a view is dispatched.  So then does the base ActionMapping cache 
ViewControllers?  If that's the case, then what about Module-level 
"global forwards"?  You could make a simple support class that wrapped 
up the instantiation and caching and have it available to ActionMapping 
and implementations of ModuleConfig -- and just to note, the fact that 
ModuleConfig is an interface leaves open the risk that existing 
implementations wouldn't implement the new, more complex contract of 
"findForwardConfig".

I guess I'm waiting to hear more on Ted's teaser; I'm not sure I see the 
gotcha that makes hiding this behavior in ActionMapping better than 
making it the responsibility of the RequestProcessor, which seems like a 
clearer place to put a single cache of ViewController classes -- which 
seems to be how Tiles works.

If people want to weigh in on this, I'll distill the discussion into 
draft code once we think the path is clear.

Joe

--
Ted Husted,
  Junit in Action  - <http://www.manning.com/massol/>,
  Struts in Action - <http://husted.com/struts/book.html>,
  JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
"Get Ready, We're Moving Out!!" - <http://www.clark04.com>



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

Re: [Short Term Plan] Struts to depend on Validator 1.1.0

2003-09-28 Thread Ted Husted

Robert Leland wrote:
> Over 99% of commons-validator usage is through struts. In fact it may
> be 100%. I feel the only way to really promote commons-validator to
> Beta status is to make the nightly build of struts depend on the 1.1.0
> version which has released in Augustand been designated an Alpha.
This being the case, we might also roll a Struts 1.2.0 release after the 
dependency changes, so as to expose the updated validator to the widest 
possible audience. I don't believe the nightly build is up to GA 
standards yet. I expect that we will need to better document migrating 
from 1.0/1.1 with deprecrations to 1.2 without deprecations. But the 
best way to do that might be to run a milestone and see what people ask 
about.

Of course, we can always do a 1.2.1 once the Commons-Validator 1.1.x is 
GA. So, we wouldn't have to make any heroic efforts on the 1.2.0 
release. Just a milestone of Struts with this dependency change.

-Ted.



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

Re: Standard HTML Tags (was Extending Standard Tags ...)

2003-09-28 Thread Ted Husted

Steve Raeburn wrote:
I wasn't saying that the existing tags can't or shouldn't be extended. Just
that IMO the core Struts tags shouldn't be moved to somewhere like Jakarta
Taglibs, because they are dependent on Struts.
Jakarta Taglibs maintains a Dreamweaver extension, why could they not 
maintain a Struts extension?

Likewise, Jakarta Velocity maintains a Struts extension. Should we ask 
Nathan Bubna et al. to bring that here because it is dependent on Struts?

The new Commons Chain package supports extensions for Servlets, 
Portlets, and JavaServer Faces, which are technologies not maintained by 
the Chain team.

IMHO, it's not a question of technology. It's a question of community 
support. If the people who actively maintain these tags wanted to 
maintain them at Jakarta Taglibs, there's no technical reason to keep 
them here. Conversely, there's no technical reason to move them either. 
It's just a matter of where the people doing the work want to do the work.

All things remaining equal, I'd suggest that the Struts taglibs are more 
about taglibs then they are about Struts. They know how to find 
resources provided by the Struts framework, but after that, virtually 
all of the coding issues are related to the taglib and HTML 
specifications, not to the Struts Controller.

When Geir and I bootstrapped the Velocity Tools for Struts initiative, 
we did discuss whether it should be maintained here or there. In the 
end, we decided that by maintaining the Tools at Velocity, they would be 
exposed to the true Velocity experts, and that was a Good Thing. If 
Struts were doing it's job, hooking up that end of it should be the easy 
part. And it was.

By the time version 1.0 of Tools launched, there were multiple tools 
sets: a generic set that could be used by most any web framework or 
application, and a smaller set on top of that specialized to Struts. As 
a result, the Tools are not only useful to Struts people, but now make 
Velocity easier to use within other frameworks as well. [Now, *that's* 
sharing the wealth :)]

From a community standpoint, most of the taglib support issues are not 
about Struts, but about using taglibs generally. When JSTL and JSF 
catches on, this is going to be more and more the case. Not only will we 
have to support Struts, but we have to support JSTL and JSF as well.

And what do these tag libraries really do anyway? They look up resources 
from predetermined locations, use them as parameters, and emit HTML. 
Right now, many of the resource locations are hardwired to use the 
Struts defaults. But, if they were exposed to a broader community, and 
configurable factory methods were used, that could change. There could a 
generic html library that didn't care about Struts, and then a 
specialized one that utilized the Struts defaults. This strategy works 
well for the Velocity Tools and should work just as well for taglibs.

We keep saying that JSTL has no corollary to the html taglibs. Well, 
maybe then it needs one. :) We moved BeanUtils and friends to Commons, 
and I can't even count how many projects use these utilities now. Maybe 
we should do the same with the html tags. The problems we are trying to 
solve are the same problems everyone else is trying to solve. We shared 
the wealth with Commons, maybe its time to do the same with Taglibs.

But, hey, I'm not a taglib guy, and I'm not going to be doing the work, 
so it's not my decision. =:) I just want to be sure that them that does 
the work and make the decisions are aware of their options.

We scuttled Generic Datasource to get out of the Model business, and, 
volunteers willing, maybe it's time to get out of the View business too.

-Ted.



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

Re: Extending Standard Tags was Editable Fields V/S Static Text

2003-09-27 Thread Ted Husted

Steve Raeburn wrote:
> While I'd probably be in favour of Struts becoming a top level
> project, I must confess I don't quite understand the criteria for
> becoming one.
It's mainly a question of whether the community surrounding the product 
is mature enough to stand on its own and stay true to the Apache 
principles of meritocracy and collaborative development. And also 
whether that community wishes to be a top level project or not.

So, its *not* about the software product itself: it's about the 
community that surrounds and supports the product.

In practice, we could stay at Jakarta and do all this. But, it's my 
feeling that once you start talking about running subproducts that could 
sustain a community of their own, then it's time to bite the bullet and 
graduate to top-level.

> p.s. Jakarta Faces (or would it be Struts Faces?) would be an
> interesting subproject for a top level Struts. Then we'd be covering
> the V and the C.
If the people developing that product felt that way, then that would be 
one way to go. But, IMHO, a JSF implementation has a broad enough scope 
that it can easily justify a top-level project of its own.

Also, I believe that being under the Struts umbrella might stunt the 
growth and acceptance of a product like this. There are frameworks other 
than Struts that could use JSF, but if it's under our brand, many will 
write it off as a "Struts thing". Sad, but true. Better, I think, to run 
it under the Jakarta or Apache banner. But, as always, them that does 
the work, make the decisions.

-Ted.

Steve Raeburn wrote:
Many of the tags (basically those that have been implemented in struts-el)
are closely bound to Struts so I don't see that they belong anywhere else.
(Separate jar, yes. Separate cvs dir, probably). The remaining tags have a
limited shelf life, having been superseded by JSTL.
I'd also like to see a separate cvs & distribution of optional packages.

While I'd probably be in favour of Struts becoming a top level project, I
must confess I don't quite understand the criteria for becoming one. Having
Jakarta, XML, DB makes sense to me, but I don't get why Ant and Maven
warrant top level projects (build tools?) or Cocoon (surely that fits in
Jakarta?). If anyone has a clue, please let me know!
Having said that, if it's a question of visibility, Struts certainly
deserves to be recognized as a top level project and it would give us an
opportunity to reorganize the code base and get more people and related
projects on board.
Steve

p.s. Jakarta Faces (or would it be Struts Faces?) would be an interesting
subproject for a top level Struts. Then we'd be covering the V and the C.

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

Re: Html tags and "indexed" property - how does it work?

2003-09-27 Thread Ted Husted

This is really a USER list question, but you may be looking for the 
indexed properties how-to:

http://jakarta.apache.org/struts/faqs/indexedprops.html

Graham Leggett wrote:

Hi all,

I am having some conceptual problems with the "indexed" property of the 
HTML tags, I have tried to find docs on this property, but apart from a 
brief one line description I can find none.

I have some JSP that looks roughly like this:




  
  



The form property "policycovers" contains the list of options in the 
dropdown, and this works fine.

The form property "policycoverId" is a String[], containing the default 
value for the dropdown in each iteration.

The option indexed="true" means output variables with a sequence 
embedded in them - but - the default value of policycoverId is always 
interpreted to mean the last value of the array, and not each iteration 
in the array, as is the logical behaviour.

Is this a bug with the indexed="true" attribute? Am I reading the docs 
wrong? What is the "right" way to do this?

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

--
Ted Husted,
  Junit in Action  - <http://www.manning.com/massol/>,
  Struts in Action - <http://husted.com/struts/book.html>,
  JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
"Get Ready, We're Moving Out!!" - <http://www.clark04.com>



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

Re: Extending Standard Tags was Editable Fields V/S Static Text

2003-09-27 Thread Ted Husted

Vic Cekvenich wrote:
(also IMO Struts HTML and tiles tag could/should migrate to taglibs)
Yes, it would be nice if the taglibs were maintained by Jakarta Taglibs, 
in the same way that the Struts View Tools are maintained by Velocity. 
Struts should make it as easy as possible for presentation technologies 
to hook up to the controller, so that the experts in that technology can 
provide the appropriate adapters for their platform.

But Apache projects are not dumping grounds. To make it happen, a set of 
individuals deeply active in both Jakarta Taglibs and Jakarta Struts 
would have to step up and make the proposal to both communities.

(Personally, I'd also like to see someone with an itch start the ball 
rolling on a Jakarta Faces product. The Sun distribution is apparently 
going to be closed source, and the SourceForge MyFaces project is using 
a restrictive license. Then the Struts-Faces taglib would also have a 
home among experts in that technology.)

Alternatively, we should talk about setting up a series of "optional" 
Struts packages. So, rather than have things like Struts-Faces and 
Struts-el live in the nebulous contrib folder, they could live under 
org.apache.struts.opt.faces and *.opt.el. Likewise, there could be an 
*.opt.taglib. And at some point an opt.xls and maybe an opt.wml.

If we followed the "optional" strategy, I'd also suggest we apply for 
status as a top-level Apache project, so that each of the opt packages 
could be a proper subproject, with its own CVS, set of Committers, and 
so forth.

Though, personally, I'd prefer the idea of letting other Jakarta 
products do what they do best, so that Struts can focus on what it does 
best: provide the C in MVC.

-Ted.



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

Re: Bugzilla Item #14183

2003-09-27 Thread Ted Husted

Late in 1.1, we added an action property to html:link, so that the 
generated href could refer to a page, forward, or action. I believe that 
anywhere we offer one of these options (as with page on img and image), 
we should offer all three.

The page property cando double-duty as an action reference, but that 
means embedding the prefix or suffix into the reference (/action.do 
versus /action), which, IMHO, is something we should avoid.

-Ted.

Chris Gastin wrote:
In Bugzilla item #14183 (
http://issues.apache.org/bugzilla/show_bug.cgi?id=14183 ) I have already
coded it up for a forward attribute and it corresponding test.
Ted has the following comment attached to this bugzilla item - "Tagged for
1.2 (might as well add action while we're at it)."
I don't quite understand the implementation of the action attribute. Could
some explain to me the expectation, so I can code up action as well.
Thanks,
Chris Gastin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--
Ted Husted,
  Junit in Action  - <http://www.manning.com/massol/>,
  Struts in Action - <http://husted.com/struts/book.html>,
  JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
"Get Ready, We're Moving Out!!" - <http://www.clark04.com>



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

Re: Action Chaining

2003-09-26 Thread Ted Husted

Personally, I would tend to use a coarse-grained bean that contained the 
properties for both pages.

But, AFAIK, calling RequestUtils.createActionForm directly is 
sanctioned, especially as a way of obtaining a DynaActionForm.

-Ted.

James Turner wrote:
I haven't seen anyone mention the most common use of Action
chaining, which is to process the form values from a submit,
and use them to prepopulate a second page.  Currently, this
requires two Actions because there is no officially
sanctioned method of instantiating a new form from an Action
to be used on a subsequent JSP page.  I think if we
addressed this, the need for chained Actions would be
greatly reduced.
James 


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

Re: Action Chaining

2003-09-26 Thread Ted Husted

It is becoming commonplace to use an Action as a "front" for a server 
page. This is not what people mean when they talk about Action chaining.

Some people start to use the Actions as finely-grained business actions. 
 For example, they want to accomplish a "move" by forwarding to a 
"copy" Action and then have the copy Action forward to a "delete" 
Action. So the point of forwarding to the next Action not to complete 
the response, as contemplated by the architecture, but to continue the 
business transaction. In essence, they try to use Actions to create a 
Chain of Responsibility. IMHO, that's out of scope for an Action class.

It is true that we ask too much of the Action class. In fact, we have 
been discussing the idea of adding another "View" handler class, or a
"page controller", to the ActionForward. The idea being that the Action 
might nest a call to this class (when specified) as part of the 
FindForward sequence. The View class could then prepare the request for 
whatever page it is designed to service.

Tying it to the FindForward sequence keeps the calls to the business 
layer within the Action lifecycle, but allows for a separation of 
concerns. The Action class can focus on the core business transaction, 
and the View class can focus on preparing the request for its server 
page -- once the core transaction is completed and the ActionForward is 
ready to be selected.

http://www.mail-archive.com/[EMAIL PROTECTED]/msg18629.html

It's just a matter of some interested party coming up with an 
implementation for other people to try.

For the other usage, where people have trouble creating a finely-grained 
business API, there's a new Chain package in the Commons sandbox that 
can help. This package makes it easy to chain together arbitrary units 
of work, so that you can do things like create a "move" command by 
chaining a "copy" command to a "delete" command -- and still use "copy" 
or "delete" on their own.

-Ted.

Derek Richardson wrote:
I was trying to avoid rehashing old arguments about action chaining. I have heard two arguments: one, it is not supported and can cause strange results and, two, it is indicative of bad design (the argument made below).

I disagree that action chaining is always indicative of bad design. See my email on the users list (that got no discussion, which I never understood) http://marc.theaimsgroup.com/?l=struts-user&m=104370639426791&w=2. I believe I made an original argument for action chaining being almost required in a particular situation.

In any case, I am not trying to force the committers to make action chaining easier in the vanilla struts distribution. I was merely hoping to get feedback if there is an obvious problem with my approach.

Perhaps I should have posted to the users list - I thought that, since this deals with modifying the framework instead of just implementing within it, that I'd get better feedback here.

Thanks,

Derek Richardson


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

Re: Editable Fields V/S Static Text

2003-09-26 Thread Ted Husted

In the beginning, there was no Jakarta Taglibs, or inkling of something 
like JSTL. So, Craig bravely put together a useful implementation of 
some custom tags that did two things. First, they exposed the internals 
of the Struts Controller framework. Second, they provided some basic 
functionality so that people could get along without restoring to 
scriplets for everything.

Since that time, the need for Struts to provide basic tag functionality 
has withered away. The Jakarta Taglibs project thrives, JSTL has long 
since shipped, and JSF is late early release (to coin an oxymoron). 
Struts doesn't have to showcase taglibs as a proof of concept anymore.

Personally, I favor the idea that the original html taglib, and friends, 
should be continue to be maintain and improved. A lot of people just 
don't have access to the JSTL yet. But, we don't want to be in the 
datasource business anymore, and we don't want to be in the *generic* 
taglib  business anymore either. There are other places where such 
things can be done better than we can do them here.

Some good examples of people doing this already are Struts Layout 

and Struts Menu
.

If someone is not up to starting their own project, I'm sure the Struts 
SourceForge crew would also be open to Struts-related taglibs being 
hosted there.

What baffles us is the feeling that absolutely everything has to be part 
of the core framework. If people have tag implementations they want to 
share, there are many places where this can be done.

-Ted.

Edgar P Dollin wrote:
For the first time in many months, there was some visible progress in the
area of acceptance of submissions on tags.  Thank you David and Robert.
I do have some points that I am sure will draw fire, but I have been an
idiot on this forum for so long...
1) It is fine that the basic tags in struts don't emit non-standard html,
but why do struts tags have to 'police' the emission of non-html.  For many
intranet style projects, non standard html is important to achieve specific
required functionality.  To deny the need for such code seems strange.
2) It baffles my mind why struts insists the tags be so minimalistic and
non-creative.  I am aware of the difficulties in writing tags with the weird
life span and semi random instantiation patterns and the bugs that are
almost endemic with custom tags.  But simple tags like java-script assisted
date entry are so basic that simple implementations should be part of
struts.  Many of us have implementations of this (i.e. Matt Kruse's date
functions) but there would be no hope of a submission passing muster.
3) Lastly, there are certain class of business information that the view
needs, i.e. readonly, size.  The tags should have to ability to easily pass
this information from the business tier to the view.  Again, the hope of a
submission relating to this type of extension being accepted seems iffy,
especially since generalizing a specific implementation is a bit of effort.
Edgar


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

Re: Editable Fields V/S Static Text

2003-09-26 Thread Ted Husted

Sgarlata Matt wrote:
Of course if I really want that I should probably just use
Velocity, huh? ;)
+1. I do =:)

-Ted.



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

Re: Editable Fields V/S Static Text

2003-09-26 Thread Ted Husted

David Graham wrote:
There are 3 things that earn my -1 on tag enhancements:
1.  Functionality already provided by the JSTL.
Just as an aside, I believe by -1 David means that he won't volunteer 
his own time to the issue. As a volunteer, this is his absolute right. 
But, since the Struts minimum platform doesn't support JSTL, this point 
alone would not be a justification for a "product change" veto.

2.  Functionality that supports non-standard HTML generation.
3.  Tags that don't tie into the Struts core functionality.  These are
better suited for the Jakarta Taglibs project.
However, IMHO, these would be technical justifications for a -1 veto =:)

-Ted.



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

Re: Editable Fields V/S Static Text

2003-09-26 Thread Ted Husted

Chris Gastin wrote:
> As I can tell from the list I have opened topic that is pretty well
> beaten. Let me first apologize.  I did not realize this was such a
> political topic in the Struts community.
There was a time when we were encouraging people to use the JSTL, and 
there was a political bent to some of the encouragement. We were 
concerned that the popularity of the Struts tags would cause a schism 
and slow the adoption of a new JCP standard. The Apache Software 
Foundation and Struts have always been ardent supporters of standards, 
and so we did not want to further the Struts tags at the expense of the 
JSTL.

However, at this time, we have a Struts-el taglib in circulation. We 
even have a Struts-faces taglib in the wings. We've definately reached 
the point where the JSTL has to sink or swim on its own. If the 
Community wants to use the tags, then we are bound to facilitate that 
any way we can. Standards are essential, but community-building is the 
Apache prime directive, and a large segment of our community is still 
locked out of the JCP JSTL standard.

Problem is, none of the active Committers seem to be using the old tags 
anymore, and so we are reaching out for new blood

http://nagoya.apache.org/wiki/apachewiki.cgi?StrutsJobJar

-Ted.

Chris Gastin wrote:
As I can tell from the list I have opened topic that is pretty well beaten.
Let me first apologize.  I did not realize this was such a political topic
in the Struts community.
I am starting to think that there should be some sort of Struts Tag Lib
Extensions, which would address some of these issues while being totally
separate from the Struts project. I am starting to agree with David I don't
want to polute Struts with non standard HTML, but it would be nice to have
an add on module which is dependant on Struts that could give users the
functionality which it seems that other are requesting. I am willing
contribute to this effort.
I did not realize there were so many bugs for the taglibs, which some of you
pointed out. I will see if I can help out. I will check out bugzilla, and
try to contribute in that area.
Chris Gastin

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

Re: struts-chain, wildcards, web services

2003-09-26 Thread Ted Husted

Don Brown wrote:
> Regarding wildcards
> (http://issues.apache.org/bugzilla/show_bug.cgi?id=21813), I decided
> to hold of on putting them as it seemed a 1.1.1(2?) was around the
> corner. However, as it looks like it is not, I'd like to put it in
> this weekend.
It sounded to me like this code was quite stable, so you might was well 
put it in. It would also close a few open tickets (which I am still 
meandering through).

Unless there are any objections, I'd like to join the struts-chain effort,
and hope to put in some time this weekend.  I've been experimenting with
ways to develop struts forms/actions that can simultaneously be exposed as
SOAP web services in stxx (http://stxx.sf.net), but feel the struts-chain
is key to building a robust implementation.
Can't see why any sane person would object to that. =:) Hey, feel free 
to join the Commons-Chain effort too -- that's where the *real* action 
is =:)

-Ted.

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

Re: creating beans.

2003-09-26 Thread Ted Husted

These types of questions are best asked on the Struts USER list.

http://jakarta.apache.org/struts/using.html#Lists

khabot zakaria wrote:
Hi,
How to create a bean corresponding to a tagLib, and how to generate an Action like 
"/logon".
Thanks..
________
--
Ted Husted,
  Junit in Action  - <http://www.manning.com/massol/>,
  Struts in Action - <http://husted.com/struts/book.html>,
  JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
"Get Ready, We're Moving Out!!" - <http://www.clark04.com>



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

Re: Struts vs JSP : Validators

2003-09-26 Thread Ted Husted

In the context of "new development" You might be thinking of the JSTL 
tags (struts-el). Since JavaServer Faces is still in the Early Access 
stage, I don't believe any of us would be recommending JSF for new 
development that you planned on shipping yourself. The Early Access 
license says that "Licensee shall have no right to use the Software for 
productive or commercial use."

-Ted.

Guido García Bernardo wrote:

What do you think about "Struts validators" vs "JSF validators" ? 
(advantages, etc)

I think you encourage the user to migrate to jsf html tags instead of 
using the struts ones (at least for new projects), but what about 
validators?

Regards.

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

--
Ted Husted,
  Junit in Action  - <http://www.manning.com/massol/>,
  Struts in Action - <http://husted.com/struts/book.html>,
  JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
"Get Ready, We're Moving Out!!" - <http://www.clark04.com>



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

Re: [Short Term Plan] Struts to depend on Validator 1.1.0

2003-09-26 Thread Ted Husted

Maybe we can wait until it's time to add a form of validate that will 
just take a mutable ActionContext and return void, and deprecate it all 
at once.

Robert Leland wrote:

David Graham wrote:

Only ActionError was deprecated, not ActionErrors.  We still need to use
ActionErrors because the ActionForm.validate() method returns an instance
of that class.  ActionMessage should be used instead of ActionError
though.
Eventually we'll need to add a method that will allow us to deprecate 
ActionForm.validate(), just as
Action.execute() deprecated Action.perform(). The only reason I haven't 
done that is I couldn't think of a good name
maybe
valid(),
validateForm(),
doValidate(),
checkFields(),
checkForm()
... ???


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

Re: Where is Struts 2 going?

2003-09-21 Thread Ted Husted

Sorry to confuse you, Peter. Apparently, I'm not being clear.

FormProc is a SourceForge project . 
It's a mature library that is used by the JPublish Framework and 
distributed under the Apache License. It is designed to capture a list 
of parameters, validate those parameters, and if valid, transfer the 
parameter to a target object. The target can be an arbitrary JavaBean or 
a Map. The list can be any List or extracted from a HttpServletRequest.

XML is only used as a deployment descriptor. I'm not talking about using 
a XML DOM in the workflow, only to use XML to define a more complete 
Form object than we see today in FormProc or the Validator.

I'm using FormProc in my current project now, along with Commons Chain 
and Maverick, and everything is lining up quite nicely. Soon, I'll port 
the work into a Struts context where it will be easier to see what I'm 
talking about.

Right now, I'm using FormProc to validate the input parameters and 
convert them directly into a target object (a Commons Chain context). If 
the validation fails, my Velocity markup is displaying the original 
input from a list maintained by FormProc. If the validation succeeds, 
the target object is passed down to the business layer, validated, 
converted, and ready to use.

In many ways, this approach is similar to where JavaServer Faces is 
going. The components have their own String cache, so you don't have to 
define one. Likewise, FormProc has its own input cache.

The missing piece right now is that I need to make the Converters 
bi-directional. When a target object comes back from the business layer, 
I'd like to hand it to the form object to convert back to a list of 
Strings. So if I have "12/31/2003" being converted to a Date, I can get 
a Date converted back to "12/31/2003", without writing any additional code.

The only place XML comes in is in defining the form object (a POJO). 
Right now, FormProc has the same sort of internal object that Validator 
would use, with the addition of a Converter property. I believe it would 
be useful to extend that object to include all the other properties we 
like to use in forms, like a label, a usage hint, an initial value, a 
default control type, and, in the case of a HTML control, the script 
triggers and so forth.

The goal being that we could hand the form object to a JSP tag, 
Velocimacro, or whatever, and have it render the markup for a default 
input form. Of course, in many case, a custom form might be needed 
instead, but it would at least be nice to have the option =:0) And, of 
course, you could define as few or as many of these properties as needed.

This is the same general direction JavaServer Faces is going with the 
DataGrid, but I'd like to generalize it for use with any type of input 
form.

-Ted.



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

Re: Where is Struts 2 going?

2003-09-21 Thread Ted Husted

The browsers universally accept HTML documents as output over HTTP, but 
they do not input HTML or XML, but a simple list of parameters. We've 
been experimenting with transforming that list into JavaBeans, and I'm 
not sure that the experiment has succeeded. It made writing tags more 
convenient but maintaining the JavaBeans has been costly. Especially 
when, for a lot of teams, the formbeans correspond 1:1 with their model 
beans, except for a few native parameters.

Following the Struts perspective, the Command Validator is designed to 
validate a JavaBean. But, when the input is coming in from HTTP, I don't 
really want a  JavaBean. I want to validate the parameters and, if they 
pass, then I might want to put them on a JavaBean or a Map, or whatever 
my business layer expects. If validation fails, I don't really want to 
display the object I'm validating (following the Validator perspective), 
I want to redisplay the original input.

What I really want to do is take a list of parameters, validate the 
parameters, and if they pass, set them to an arbitrary target object. I 
also don't want to catch every matching parameter, I just want the ones 
I need for this workflow (or "form"). And, if validation fails, I want 
to redisplay the original input.

Which is what FormProc does. =:0)

I had to patch the original input list so that it could be exposed. Next 
I want to make the stock converters bi-directional. So, if it's supposed 
to take a String like "12/31/2003" and turn it into a Date, I can also 
hand it a Date and get back a String like "12/31/2003". This way I can 
pass my Model object to the form and get a list of String parameters to 
expose to the server page.

When I mentioned XML, I mean define a object deployment descriptor in 
XML, same as the struts-config.xml, web.xml, and validator.xml. But, 
neither Validator or FormProc goes far enough. I want a form object that 
describes everything about the form, so that I could actually hand that 
object to a tag or Velocimacro or something and have it render a default 
HTML input form for me, just as we hand it the output from that form so 
that it can tender a default validation.

-Ted.

Peter A. Pilgrim wrote:
Ted Husted wrote:

I working on something similar right now too, but using the FormProc 
package. I believe that we should represent entire input form in XML, 
including things like the default control type and field labels, and 
so  forth, along with prompts, error messages, validations, and type 
conversions. Ideally, we should be able to write a default form just 
by reference to an XML element.

What I like about FormProc is that is not focussed on JavaBeans, but 
on the process of validating a list of parameters against a form 
definition and then transferring the validated properties to some 
target object. The object can also be a Map, which makes for a very 
nifty hand-off to something like a Context. =:)

In fact, expanding on the DynaForm idea, it might also be possible to 
create a type-safe Context backed by a XML-configured form object. We 
could then use the same XML document on both layers. On the 
presentation layer, it can generate and/or validate the data-entry 
form. On the business layer, it can define the properties expected by 
a Context.

Of course, this is much like what we've been talking about doing for 
the Validator, but right now the emphasis there seems to be on the 
JavaBean and moving away from the form, where I believe we should be 
emphasizing the form and moving away from (pure) JavaBeans.

Ted

You lost me over the architecture.
What I dont understand is that the current browsers are communicating
HTML on HTTP. So how in the first do you get XML in the front end?
Are proposing that there are new types of browsers that communicate
exclusively XML over HTTP?
If so then it makes for interesting future, where the HTTP request 
representing
a HMTL Form for example, a POST method, is a XML document and the output
is XML.


--
Ted Husted,
  Junit in Action  - <http://www.manning.com/massol/>,
  Struts in Action - <http://husted.com/struts/book.html>,
  JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
"Get Ready, We're Moving Out!!" - <http://www.clark04.com>



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

Re: Conceptual question about populating/validating values

2003-09-17 Thread Ted Husted

I'd agree with Edgar. Since ActionForms are a class rather than an 
interface, as it stands, you either have to live with the duplicate 
objects, or least two sets of properties, or go to other extremes. You 
can do things like use the ActionForms as an adaptor or facade for your 
business objects, or nest your business objects on the ActionForm, but 
that's no less work, and causes its own set of problems.

The other leading Java frameworks are WebWork, Maverick, JPublish, and 
Barracuda, if you care to have a look. After choosing Java itself, 
selecting an application framework and persistence layer are the most 
important decisions you will make. So, it's worth shopping around.

For harvesting form values, I've been playing with FormProc recently. It 
has a different approach than the Validator, in that it doesn't validate 
JavaBeans, it validated a list of input entries against a collection of 
field elements that comprise the form. Once the input for a field is 
validated, then it is converted and transferred to a target object (an 
arbitrary JavaBean or Map implementation).

One thing to note is that FormProc doesn't do a wholesale transfer. If a 
parameter does not correspond to a field element, it is not harvested. 
So, you don't have to worry about inappropriate properties being 
populated by a hostile client. Also, the target property (or entry) is 
only populated *after* it has been validated, so bad data is never 
tendered to good objects =:0)

Meanwhile, the original input is maintained on a separate List. So, when 
you go back to the page, you can redisplay the original (buffered) 
input, whether it was valid or not. (Well, I had to submit a patch for 
that one, to give the list a public accessor.)

I'm working on a FormProc extension for Maverick now and may try one for 
Struts next (by hooking into the reset method). This would let you 
define your form without subclassing a base ActionForm, much like the 
DynaActionForm.

-Ted.

[EMAIL PROTECTED] wrote:

Hi there,

I have a conceptual question about the population process for properties
inside Struts.
First of all a description:

I have a JSP which includes a text input field like this:



"currentPerson" is a Person-Object which has a birthDate-Attribute of type
java.util.Date (!).
This object is part of the myForm-Bean. 

I know about the alternative to have string values in my FormBean and set
the property of my object "by hand", but I don't like this !!
The Request-Processing now does the following:

1. RequestProcessor.processPopulate(...)
   2. RequestUtils.populate(...request)
  3. BeanUtils.populate(bean, properties)
  ...
  4. BeanUtils.setProperty(...)
 5. ConvertUtils.convert(...)
6. PropertyUtils.setProperty(...)

6. RequestProcessor.processValidate(...)
..

In my example the string representing a date is converted into a
Date-Object in step 5 (ConvertUtils.convert())
I could use the sessions locale here for LOCALE-specific conversions and
set a default value in case the conversion failes.
I know about this !
Lets asume the following:
-> A user enters an invalid date 
-> conversion failes and the default value will be set as birthDate
-> the user gets the page back including an error message about an invalid
date
-> the date input field holds the default date now

BUT: What I would like the user to see is it's original text, not the
default value or anything else.
ANY IDEA, how to do this ? (Without having string variables to store the
form-values !)
Since I also would also like to specify a regexp-mask in the
validation.xml it looks to me, that the processValidate() is a bit too
late.
Thanks in advance,
Dirk








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

--
Ted Husted,
  Junit in Action  - <http://www.manning.com/massol/>,
  Struts in Action - <http://husted.com/struts/book.html>,
  JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.


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

Re: Where is Struts 2 going?

2003-09-16 Thread Ted Husted

I working on something similar right now too, but using the FormProc 
package. I believe that we should represent entire input form in XML, 
including things like the default control type and field labels, and so 
 forth, along with prompts, error messages, validations, and type 
conversions. Ideally, we should be able to write a default form just by 
reference to an XML element.

What I like about FormProc is that is not focussed on JavaBeans, but on 
the process of validating a list of parameters against a form definition 
and then transferring the validated properties to some target object. 
The object can also be a Map, which makes for a very nifty hand-off to 
something like a Context. =:)

In fact, expanding on the DynaForm idea, it might also be possible to 
create a type-safe Context backed by a XML-configured form object. We 
could then use the same XML document on both layers. On the presentation 
layer, it can generate and/or validate the data-entry form. On the 
business layer, it can define the properties expected by a Context.

Of course, this is much like what we've been talking about doing for the 
Validator, but right now the emphasis there seems to be on the JavaBean 
and moving away from the form, where I believe we should be emphasizing 
the form and moving away from (pure) JavaBeans.

-Ted.

Don Brown wrote:
In the aforementioned stxx (http://stxx.sf.net) project, I've been working
on combining Struts with xmlforms (http://www.xmlform.org) to create
Struts ActionForms that use plain XML as the model.  Using pure XML as the
model has several advantages over javabeans I believe:
- Quicker development
- Use of XPath for powerful data access
- Many different validation options (schematron, xsd, relax-ng, etc)
- Ability to simultaneously expose forms as document-based SOAP web
services
While xml mapping toolkits have gotten better, I found keeping the model
in XML saves development time, and with xpath and JDOM, the data can be
accessed much quicker (in development time, not runtime of course).
Don



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

Re: Reviving PageController discussion?

2003-09-15 Thread Ted Husted

I'll post more on this later, but to avoid the "gotcha", I'm now 
thinking we should try this using a modified ActionMapping.findForward 
method. In that way, all the navigational control stays within the Action.

-Ted.

Joe Germuska wrote:

About a month ago, Ted put forth a description of a new Struts extension 
point which he called a "Page Controller"

http://marc.theaimsgroup.com/?l=struts-dev&m=106060806828676&w=2

It seemed to get some interest from other developers, and then subside a 
bit.  As we've just been "wishing" for such a thing on our latest 
project, I thought I'd see about kicking the discussion back up.

This came up in the context of Craig's chaining mechanism and contexts, 
and also with the question of whether Struts should define some 
ActionContext interface that would unify the interface to calls to 
various steps in the processing cycle.

I have been thinking about it a little, but nothing radical, so I think 
I'll sit back and see if people see this as Struts 1.3-ish material, or 
whether it needs to ferment longer...

Joe

--
Ted Husted,
  Junit in Action  - <http://www.manning.com/massol/>,
  Struts in Action - <http://husted.com/struts/book.html>,
  JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.


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

Re: JavaDocs on the website

2003-09-14 Thread Ted Husted

Yes, it's suppose to be the JavaDocs for the nightly build, but the 
update process is not automated, and I've been neglecting the api when 
doing the website update. I'm posting current JavaDocs now. They don't 
actually say 1.2.x because we haven't actually released 1.2.x yet.

Yann ? wrote:
Hi,

the link on the Struts Homepage under "Nightly Build" -> "JavaDoc" links to
the 1.1 final JavaDocs http://jakarta.apache.org/struts/api/index.html.
Shouldn't it link to the 1.2 JavaDocs (which I couldn't find online) ?

Yann



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

--
Ted Husted,
  Junit in Action  - <http://www.manning.com/massol/>,
  Struts in Action - <http://husted.com/struts/book.html>,
  JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.


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

Re: Multiple struts configs, modules, and resource bundling

2003-09-14 Thread Ted Husted

The course you are now following is probably the best one. Set the 
application up as a single module, and just given each team a prefix for 
their actions and page directories, and have them use it as part of 
their everyday work, rather than let the module code do it. Since 
multiple configuration files are supported, they can also have their own 
struts-config file, which is the major source of contention. This way 
you have full access to the entire Struts feature-set, including path 
mapping.

The way modules are implemented now makes them very useful when you are 
deploying two completely independent modules, but less useful when you 
have teams that are cooperating on the application and also need to 
share some resources.

We would like to support path mapping for the modules, but no one has 
figured out how to do that yet.

To answer your question about the JSP paths, you can use the forwardPath 
for this:

http://jakarta.apache.org/struts/userGuide/configuration.html#controller_config

A link to this setting has been added to the "module" section of the 
user guide, so that it easier to find.

For multiple message resources, I believe you have to give each bundle 
its own name and then specify that bundle whenever it is to be used. 
But, the name space trick works here too. It's a simple file and not 
updated as often as the configs, so CVS can usually sort out any conflicts.

-Ted.

Jeffrey Bonevich wrote:
I have some questions regarding difficulties we have been having using 
multiple struts config files and modules at work.  Here is the scenario:

We developed our first application in struts after having set some 
coding standards that seemed (at the time) pretty reasonable.  Chief 
among them for purposes of this discussion is securing access to JSP 
pages by putting them under WEB-INF.  We are in the process of 
integrating a second struts-based app into the main application, and 
originally planned to do so as two separate modules.  However, I am 
running afoul of several limitations in the struts module support.

Firstly, we had originally gone with path-mapping for our actions. I 
figured out from the mailing lists pretty quick that using modules for 
path-mapped actions is not supported.  Is there any plan to build such 
support into the next or some future release?  When?

So I converted the apps to extension-mapped actions and proceeeded. 
However, I am hitting the "struts prepends module context to every path" 
wall: I can no longer create forwards to JSP pages in WEB-INF, but 
instead have to put them in module-specific subdirectories of the 
document root.  Is there any reasonable way around this via the configs? 
 Or do I have to create a custom "JSP page forward" action to handle 
this particular (but not peculiar) need?

Lastly, since going the module route was proving exceeding difficult, we 
decided to treat both apps as a single module, but with separate config 
files for each (as specified in web.xml).  However, there appears to be 
a bug (feature?) in struts with message resource loading - the last set 
of resources loaded are the only ones that will be present.  This 
appears to be because ModuleConfigImpl holds a hashmap of resource 
bundles with only a single possible key.  As each set is added to the 
map, it displaces the previously added set.  To get around this, I had 
to merge all properties from both apps into a single properties file - 
not desireable but it works.  All the other parts of the configs (forms, 
actions, forwards, etc.) all seem to be additively accumulated.  Is this 
exclusive loading of message resources truly a bug?  Can't struts handle 
multiple sets of properties per module?

Answers, suggestions and workarounds would be most welcomed!

Thanx!

jeff


--
Ted Husted,
  Junit in Action  - <http://www.manning.com/massol/>,
  Struts in Action - <http://husted.com/struts/book.html>,
  JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.


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

Re: Where is Struts 2 going?

2003-09-13 Thread Ted Husted

Craig R. McClanahan wrote:
> * As a completely new and separate project, commissioned through
>   the Apache incubator process, with an ultimate destination of
>   either Jakarta (as a subproject parallel to Struts) or as a
>   completely separate "Apache Faces" project with its own PMC (like
>   Ant, Avalon, and James).
Yes, this is what I actually had in mind. But, it's a chicken-and-egg 
scenario. To be incubated, you need something to incubate. IMHO, a good 
place to do that, when you are starting from scratch, is the Commons 
sandbox. Once there's some code on the table, and some Committers 
maintaining it, the code's community can decide where to go next.

Struts has always been an integrator of enabling technologies. Along the 
way we've had to create a technology or three, like BeanUtils, 
Collections, and the Digester, to name a few. And, being good citizens, 
we've been busily moving these to the Commons for other people to share. 
This approach has been quite successful. The number of projects using 
these technologies is stunning. Absolutely stunning.

But, that's why we invented the Commons: so that projects wouldn't have 
to start sub-projects to create enabling technologies. We built them, we 
shared them, and people are using them. (And in saying this, I'm using 
the royal we. I helped charter the Commons, but others, especially 
Craig, have made it so.)

It's my feeling that developing a JSF implementation is out of scope for 
a framework, whether it lives at Jakarta or at struts.apache.org. 
Frameworks should integrate technologies, rather than invent them. IMHO, 
it would *not* be a good idea to link an Apache JSF implementation to 
the Struts brand. As mentioned, the JSF scope is quite broad and can 
easily support a project on its own. It doesn't need another product to 
support it.

A JSF implementation is *not* something that only Struts would use. It's 
something any framework would want to use. It would be *much* easier for 
other communities to accept a JSF implementation if it wore the Apache 
or Jakarta brand. I think the Commons has proved that technologies are 
very easy to share when placed on neutral ground. I truly don't believe 
a Struts-Digester and Struts-BeanUtils would have gained as much 
acceptance as the Commons versions. I realize this is marketing stuff, 
but, sometimes, that's part of community building =:0)

If someone has an itch to create a top-level frameworks/tools Commons 
for web applications, IMHO, it should not wear the Struts brand, for all 
the same reasons we created the Commons in the first place. I'd 
certainly agree that there are technologies that Struts, Tapestry, and 
Turbine can share, but we would need to share them under a new brand.

Meanwhile, if for some reason, an Apache Java ServerFaces implementation 
were to cause Struts to whither away, then so be it. Personally, I don't 
believe JSF will have that affect. Standard technologies are never that 
good or that complete. Though, this will be one of the first standards 
with Craig in the thick of things, so maybe it will be different this 
time. =:0)

But it's not Struts that matters. What matters is that the community 
that uses Struts. Worst case, we have all the same heartbeats working on 
Apache Faces rather than Struts, and our community is served. Best case, 
we have a vibrant community around Apache Faces *and* another vibrant 
community around Apache Struts. Either way, our open source community 
wins =:)

-Ted.

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

Re: Where is Struts 2 going?

2003-09-13 Thread Ted Husted

Ted Husted wrote:
Personally, I would suggest that if people were interested in an Apache 
implementation of JavaServer Faces
Neglected to mention that there is, of course, the MyFaces project at 
SourceForge

<http://sourceforge.net/projects/myfaces>

but current work is under the LGPL.

<http://www.gnu.org/copyleft/lesser.html>

I would suggest that any open source developers interested in MyFaces 
lobby them to consider a more liberal license, like the ASL.

<http://apache.org/LICENSE>

-Ted.



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

Re: Where is Struts 2 going?

2003-09-13 Thread Ted Husted

On Sat, 13 Sep 2003, Niall Pemberton wrote:
I may have got the wrong end of the stick, but doesn't Struts overlap to
some degree with JavaServer Faces and wasn't there talk of perhaps Struts
evolving to be a implementation of JavaServer Faces?
Craig R. McClanahan wrote:
That's certainly a possibile evolution (or perhaps even a subproject), if
enough developers are interested.  Thanks in large part to Apache's
advocacy and influence, the JCP process has been modified so that we
(Apache) can even qualify for the certification scholarship (for
nonprofits) and access to the TCKs and certify that our application is
compliant.
If we were to do that, it wouldn't be the *reference* implementation, of
course, but it would certainly be an Apache-licensed open source
implementation.
Personally, I would suggest that if people were interested in an Apache 
implementation of JavaServer Faces, that it begin in the Jakarta 
Commons. Many Java frameworks now support JSP and will certainly want to 
support JSF in the future. [Of course, for Struts, the future is now, 
since we already have a JSF taglib ready to rock. =:0)]

By exposing "Jakarta Faces" at the highest possible level, the greatest 
number of projects and teams will consider using the product and joining 
its community.

In this way "Jakarta Faces" could focus on being a "by the book" 
implementation of JSF. Meanwhile frameworks like Struts could offer 
(yet to be determined) "value add" features that go beyond the formal 
specification. "Jakarta Faces" might not be the reference 
implementation, but that doesn't mean we can't treat it like one =:0)

IMHO, the true value of Struts has been the way it helps people "put the 
pieces together" by leveraging existing technologies like JavaBeans, 
JavaServer Pages, JDBC, Localization, and so forth. So moving forward, I 
see JSF as one more link in the chain. Once people start rolling out 
applications based on JSF, I'm sure there will be plenty of "missing 
links" for frameworks like Struts to provide.

-Ted.



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

Re: Where is Struts 2 going?

2003-09-12 Thread Ted Husted

Craig set it up in the Sandbox last month.

CVS:

http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/chain/

Build:

http://cvs.apache.org/builds/jakarta-commons/nightly/commons-chain/

I'm starting to use it in a production application now, as the basis of 
the business integration layer. There is also some very sweet code in 
Struts Contrib that prototypes how you would use it to create a 
RequestProcessor.

http://cvs.apache.org/viewcvs/jakarta-struts/contrib/struts-chain/

-Ted.

Mike Jasnowski wrote:
I think it?s in the sandbox area

-Original Message-
From: Norm Deane [mailto:[EMAIL PROTECTED]
Sent: Friday, September 12, 2003 2:36 PM
To: 'Struts Developers List'
Subject: RE: Where is Struts 2 going?
Where the heck is this new Commons-Chain?  I don't see it in CVS or on the
website.  Sounds like the next big thing from Jakarta.
--
Ted Husted,
  Junit in Action  - <http://www.manning.com/massol/>,
  Struts in Action - <http://husted.com/struts/book.html>,
  JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.


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

Re: Where is Struts 2 going?

2003-09-12 Thread Ted Husted

, 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


--
Ted Husted,
  Junit in Action  - <http://www.manning.com/massol/>,
  Struts in Action - <http://husted.com/struts/book.html>,
  JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.


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

Re: Link to Struts Nightlies

2003-09-12 Thread Ted Husted

Thanks, Tetsuya. I updated some of the others as well.

Tetsuya Kitahata wrote:
Fixed .. (I guess)

If there're anything to be done, please let me know.

Thanks,

__ Tetsuya <[EMAIL PROTECTED]> __

On 12 Sep 2003 08:13:09 +0200
(Subject: Re: Link to Struts Nightlies)
Stefan Bodewig <[EMAIL PROTECTED]> wrote:

On Thu, 11 Sep 2003, Ted Husted <[EMAIL PROTECTED]> wrote:


As it turns out, we just have a wrapper page on j.a.o that calls a
script on the main apache site, to which I do not have karma =:(
But the script uses the page in jakarta-site as a template.  You will
want to modify xdocs/site/binindex.xml and regenerate the site.
Stefan


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

--
Ted Husted,
  Junit in Action  - <http://www.manning.com/massol/>,
  Struts in Action - <http://husted.com/struts/book.html>,
  JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.


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

Re: Link to Struts Nightlies

2003-09-11 Thread Ted Husted

As it turns out, we just have a wrapper page on j.a.o that calls a 
script on the main apache site, to which I do not have karma =:(

Unless someone chirps up, I'll post a note on General.

-Ted.

David Graham wrote:

The Jakarta download page uses this link to point to Struts nightly
builds:
http://jakarta.apache.org/builds/jakarta-struts/nightly/
That link redirects you back to the downloads page.  I believe the correct
link is http://cvs.apache.org/builds/jakarta-struts/nightly/
I'm confused by the Jakarta site build process so I'm not sure how to fix
this.  Is the site generated from jakarta-site or jakarta-site2 from cvs?
David

__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--
Ted Husted,
  Junit in Action  - <http://www.manning.com/massol/>,
  Struts in Action - <http://husted.com/struts/book.html>,
  JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.


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

Re: What happened to the taglib attribute listings?

2003-09-11 Thread Ted Husted

Right now, we use scp to either send up the files or a WAR to burst. 
This requires karma to jakarta.apache.org, which root no longer hands 
out as a matter of course, but should be available for the asking.

The Jakarta site2 project uses a system where you can checkout the HTML 
pages from CVS, but that still requires access to j.a.o.

-Ted.

Robert Leland wrote:
Steve Raeburn wrote:

I've posted a patch to the struts.xsml stylesheet. Ted could you do the
honours?
BTW, I'm not sure what needs to be done to update the live site and if 
it's
something I could or should be doing. I'd be happy to make the updates if
someone lets me know how.
 

The site docs talk about using CVS to update. And most of the apache 
sites, www.apache.org, xml.apache.org, ...
do look like they use CVS, since there are CVS directories under those 
directories. However, very few of the jakarta.apache.org web sites look 
like they use use CVS, no CVS directories, except for, struts-el

So I would say just use 'scp' to send the war file over, an unzip. For 
the longest time I was e-mailing my self stuff, cause I
hadn't read all the docs :-} !

-Rob


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

Re: What happened to the taglib attribute listings?

2003-09-11 Thread Ted Husted

If it's not something we can fix right away, I'll post a copy from an 
earlier build.

David Graham wrote:

That's a definite bug in the build.  Those pages are worthless without the
attribute descriptions.
David

--- Kris Schneider <[EMAIL PROTECTED]> wrote:

The tag doco pages, for example:

http://jakarta.apache.org/struts/userGuide/struts-html.html

used to include tables listing each of the tags' attributes. Was there a
conscious decision made to remove that information or is there just some
bug in
the build?
--
Kris Schneider <mailto:[EMAIL PROTECTED]>
D.O.Tech   <http://www.dotech.com/>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--
Ted Husted,
  Junit in Action  - <http://www.manning.com/massol/>,
  Struts in Action - <http://husted.com/struts/book.html>,
  JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.


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

Re: XHTML Web site updates

2003-09-11 Thread Ted Husted

With an update to Ant 1.5.4, it now WORKSFORME with both 1.4.1_03 and 
1.4.2_01. The validation step takes a few seconds, but I'm OK with that.

I'm posting the new version now. Thanks Steve! It looks great!

-Ted.

Steve Raeburn wrote:
Thanks James, I'm about to commit an updated build-webbaps.xml file. It
seems to solve my problem on 1.4.1_02.
According to the Ant manual:
reloadstylesheet - Controls whether the stylesheet transformer is created
anew for every transform operation. If you set this to true, performance may
suffer, but you may work around a bug in certain Xalan-J versions. Default
is false. Since Ant 1.5.2.
http://ant.apache.org/manual/CoreTasks/style.html

Setting this to true, appears to work and it's not much slower. Give it a
whirl.
Steve


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

Re: XHTML Web site updates

2003-09-10 Thread Ted Husted

I've installed Sun 1.4.2_01 but I'm still having trouble getting the 
site to render.

I am in favor of rendering the site in valid XHTML, but we need it to 
work with what people will commonly have installed. If the site can't be 
rendered using the standard "Java 1.2 or later" advice, then I'll have 
to ask that the stylesheet changes be withdrawn.

Also, I don't know if my pages are rendering correctly, but the ones I 
am seeing have a "Lynx" look and feel. I don't mind this personally, but 
I do feel that we need to either retain the original layout or migrate 
to Forrest or Maven. Something different is not what we are gong for 
right now. =:0)

-Ted.

Steve Raeburn wrote:
Sorry, I'm getting my versions in a muddle. Here's the correct state:

Sun 1.4.2_01 - No problem
Sun 1.4.1_05 - Intermittent failures
Sun 1.4.1_02 - Intermittent failures
Sun 1.3.1- No problem
2 many twos and ones :-)

Steve


-Original Message-
From: Steve Raeburn [mailto:[EMAIL PROTECTED]
Sent: December 10, 2003 8:12 AM
To: Struts Developers List
Subject: RE: XHTML Web site updates
What JDK are you running on? I did experience a similar
intermittent problem
with Sun 1.4.2_01 (on W2K) but _02 runs with no problems.
Steve

-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]
Sent: September 10, 2003 3:58 AM
To: Struts Developers List
Subject: Re: XHTML Web site updates
I'm fine with all this generally, and was going to post the update, but
I'm having trouble getting it to transform. Several arbitrary files are
coming back
: Fatal Error! java.lang.NullPointerException Cause:
java.lang.NullPointerException
Failed to process
C:\projects\Apache\jakarta\jakarta-struts\doc\resources\projects.xml
I'll try it again tonight with a clean checkout, but wanted to bring
this up in case anyone experienced similar problems.
-Ted.

Steve Raeburn wrote:

We now have an XHTML 1.0 Strict compliant, CSS based tableless
layout web

site with only one XSL stylesheet to worry about (plus the
taglib) and no

need for a separate "printer friendly" version of the User Guide.

I've added a validation task to the build file to ensure that the
generated

documents stay valid over time ;-) and to save having to validate each
page

manually.

Anchors
---
One thing to watch out for when you're updating documents - I've begun
replacing anchors with element ids. So this:
 Some text

becomes
 Some text
It's still linked in exactly the same way -- myPage.html#test -- but you
need to make sure that you use a valid element id. Anchors in the news
pages

were being specified using the date, but element names cannot
start with a

digit so I've just added the letter 'S' (for Struts) as a prefix.

Contributors List
-
One side effect of merging the XSL stylesheets is that the contributors
list

is currently not written at the start of each chapter. (Some stylesheets
had

it, some didn't so I opted to remove it from the chapter section.)

I wondered what the feeling was regarding whether it is
neccessary to have

that list at the top of each page.

Personally, I think it gets in the way of reading the
documentation but it

wouldn't be too difficult to add back if that's what's wanted.

Let me know what you think or if you find anything I missed.

Steve



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

--
Ted Husted,
  Junit in Action  - <http://www.manning.com/massol/>,
  Struts in Action - <http://husted.com/struts/book.html>,
  JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.


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




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






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

--
Ted Husted,
  Junit in Action  - <http://www.manning.com/massol/>,
  Struts in Action - <http://husted.com/struts/book.html>,
  JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.


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

Re: XHTML Web site updates

2003-09-10 Thread Ted Husted

I'm fine with all this generally, and was going to post the update, but 
I'm having trouble getting it to transform. Several arbitrary files are 
coming back

: Fatal Error! java.lang.NullPointerException Cause: 
java.lang.NullPointerException
Failed to process 
C:\projects\Apache\jakarta\jakarta-struts\doc\resources\projects.xml

I'll try it again tonight with a clean checkout, but wanted to bring 
this up in case anyone experienced similar problems.

-Ted.

Steve Raeburn wrote:
We now have an XHTML 1.0 Strict compliant, CSS based tableless layout web
site with only one XSL stylesheet to worry about (plus the taglib) and no
need for a separate "printer friendly" version of the User Guide.
I've added a validation task to the build file to ensure that the generated
documents stay valid over time ;-) and to save having to validate each page
manually.
Anchors
---
One thing to watch out for when you're updating documents - I've begun
replacing anchors with element ids. So this:
  Some text

becomes
  Some text
It's still linked in exactly the same way -- myPage.html#test -- but you
need to make sure that you use a valid element id. Anchors in the news pages
were being specified using the date, but element names cannot start with a
digit so I've just added the letter 'S' (for Struts) as a prefix.
Contributors List
-
One side effect of merging the XSL stylesheets is that the contributors list
is currently not written at the start of each chapter. (Some stylesheets had
it, some didn't so I opted to remove it from the chapter section.)
I wondered what the feeling was regarding whether it is neccessary to have
that list at the top of each page.
Personally, I think it gets in the way of reading the documentation but it
wouldn't be too difficult to add back if that's what's wanted.
Let me know what you think or if you find anything I missed.

Steve



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

--
Ted Husted,
  Junit in Action  - <http://www.manning.com/massol/>,
  Struts in Action - <http://husted.com/struts/book.html>,
  JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.


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

Re: Saving messages in the session

2003-09-10 Thread Ted Husted

It does come up, especially when people are using frames. I usually 
recommend that people use an Action to cache the messages in the session 
during the redirect and then have another Action to move it back again 
afterwards. It might be possible to engineer a standard Action to 
automate this sort of thing.

It seems to me to be a workflow issue. People want to put the attribute 
into the session so that it survives a redirect, but we all want to see 
some assurance that it will be disposed afterward.

The big fix might be to consider adopting Matthias Bauer's Workflow 
plugin, which could be used to enforce these types of contracts. But, it 
would be better to do that in the 1.4.x timeframe, when the new 
RequestProcessor might be on board.

-Ted.

Robert Leland wrote:
Use Cases:  I am not familar with the particular use cases where the 
ActionMessage needs
to hang around in the session. So these suggestions might not fit.
Questions:
Would managing the life cycle through the struts-config.xml, like the 
ActionForm work ?
or
How about a PlugIn that has the ability to schedule a cleanup of a 
session variable after
a configurable amount of time ?  The method that reads the message from 
the session
would need to be syncronized. This doesn't have to be a plugin.

-Rob



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

--
Ted Husted,
  Junit in Action  - <http://www.manning.com/massol/>,
  Struts in Action - <http://husted.com/struts/book.html>,
  JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.


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

Re: signature [was: Struts web site [was: Re: Conversion of web site docs to XHTML]]

2003-09-08 Thread Ted Husted

Consider it under the ASL =:0)

http://apache.org/LICENSE

My favorite motto is by Devo: "Duty now for the future."

Mainguy, Mike wrote:
Ted, I may adopt the last line of this email to be my signature as it
accurately reflects my experience with IT.
<>

Please let me know how much you intend to charge in royalties, or, if you
are not the proper copyright holder, please lend me his/her name...


--
Ted Husted,
  Junit in Action  - <http://www.manning.com/massol/>,
  Struts in Action - <http://husted.com/struts/book.html>,
  JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.


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

Re: Struts web site [was: Re: Conversion of web site docs to XHTML]

2003-09-07 Thread Ted Husted

Robert Leland wrote:
I am strongly in favor of moving to maven now, and will help where I 
can. 
My only concern is that we continue to view Struts 1.x as being 
evolutionary mode. If we have a consensus on this point, then we should 
all be careful that we do nothing that will break the build or prevent 
us from shipping a release on a moment's notice. I don't actually care 
what system we use (including the existing one), so long as it works and 
continues to work.

For myself, at this time, I'm devoting my volunteer hours to finishing 
things that we already started, beginning with the legacy 1.1 bugzilla 
tickets, and try to put together something resembling a roadmap. I'll 
then be converting my own stuff over to the nightly build (1.2.x) to 
help document any issues others may encounter.


The effort involved is much less
than adding many of the features listed for Struts 2.0
AFAIK, Struts 2.x is a revolution which implies an new code base. We're 
not adding features for Struts 2.x, we're using lessons learned from 
Struts 1.x to build Struts 2.x from the ground up.

Of course, I'm sure that there will be code that we can port, but, 
AFAIK, Struts 2.x is a clean slate. Which, IMHO, makes it a good place 
to give Maven a try.

Joe says he's using Maven in production and seems to like it. I trust 
Joe and value his opinion. It would be nice to hear from some other 
people who are using Maven in larger projects that rival the complexity 
of Struts.

-Ted.



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

Re: Struts web site [was: Re: Conversion of web site docs to XHTML]

2003-09-07 Thread Ted Husted

David Graham wrote:
I was under the impression that the blue/grey l&f was the new Jakarta
standard that sites would be moving to.  Maybe it's just the default Maven
l&f that no one ever bothered to customize.  Both the Maven and Forrest
l&f are fine with me; I'm just a big fan of consistency so if there is a
Jakarta standard we should follow it.
My guess is that few bother to customize (and may not even know how). 
AFAIK, there is no direction coming from the PMC or ASF to standardize 
on either Maven or Forrest.

As Craig says, there's no telling how long we will remain a Jakarta 
subproject. Even so, of 22 top-level Jakarta products only three seem to 
be using Maven:

jakarta.apache.org/bcel
jakarta.apache.org/poi
jakarta.apache.org/turbine
Within the Commons, Maven is more popular. There are also 22 packages 
there, and 13 seem to be using Maven:

Betwixt
CLI
Codec
Daemon
DBCP
FileUpload
HttpClient
Jelly
JxPath
Latka
Net
Pool
Validator
Maven is quite popular in the Sandbox, where all the listed products 
that have setup Welcome pages seem to be using Maven.

As you might note, there is a pattern here of Maven being adopted for 
new development, but there has been almost no transition of mature 
products to Maven.

Of the 16 top-level Apache level (where we should be anyway), three 
projects are using Maven, counting Maven itself

avalon.apache.org
db.apache.org
maven.apache.org
and four are using Forrest

ant.apache.org
cocoon.apache.org
incubator.apache.org
xml.apache.org
Unsurprisingly, Forrest is relatively popular among the 13 products of 
xml.apache.org, where it being used by six products (including Forrest 
itself):

xml.apache.org/fop
xml.apache.org/forrest
xml.apache.org/commons
xml.apache.org/security
xml.apache.org/xindice
xml.apache.org/xmlbeans
But even in XML land, one hold out, xmlrpc, is using Maven. [Bless their 
souls :)]

As to there ever being an Apache or Jakarta standard, I would venture to 
say that such a thing would be unlikely. These are the types of 
decisions that the ASF prefers to leave to the Committers that actually 
manage the project.

If a standard emerges, it will be a defacto standard that evolves from 
the decisions each team makes about whether the package works for them. 
("Let Darwin decide".) My own personal guess is that if such a standard 
does emerge one day, it will look more like Forrest and less like Maven.

But, honestly, I don't really care what we use, so long as the work gets 
done =:0) No matter what we use today, sooner or later I'm sure we'll be 
using something else =:0)

-Ted.



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

Re: Struts web site [was: Re: Conversion of web site docs to XHTML]

2003-09-07 Thread Ted Husted

Joe Germuska wrote:
It will be some mildly tedious work to move the current doc to xdocs, 
but nothing too bad, and if they are valid xhtml, it will be much easier.
The documentation is all XML now. Steve was just tweaking the XLS. 
There's a bit of HTML/XHTML in the sample applications, but that's 
trivial and probably wouldn't be a Maven issue anyway.


I'm no expert, but I'll be happy to help where I can.  It can be a 
little frustrating to push an existing CVS structure into Maven 
conventions (I tried to do it for SnipSnap and really got stuck, but 
their build is pretty funky.)  It's a breeze when you start fresh (like 
maybe Struts 2.0...)
So it sounds like that since Maven is also a build tool, we not only 
have to address the web site/documentation content but bring CVS in line.

Unless someone is of the opinion that moving the Struts CVS to Maven 
conventions is a no-brainer, perhaps the consensus should be to consider 
Maven for any *new* Struts product installations (CVS/website 
combinations). This could include

+ A new CVS/website for the taglibs
+ A new CVS/website for Struts 2.x (which is now just a roadmap)
So, given either or both of these, the Struts home page could become a 
simple portal that links to our products (1.x core, taglibs, 2.x roadmap).

Once we got started on Maven using "fresh meat", we could then make a 
informed decision about whether to migrate the Struts 1.x core.

Meanwhile (assuming the 1.x CVS is an issue), if someone were interested 
in moving the 1.x documentation to Forrest, I wouldn't be opposed.

-Ted.

(Just a random thought, would either Maven or Forrest care that how we 
generate the taglib API documentation from the TLDs?)



--
Ted Husted,
  Junit in Action  - <http://www.manning.com/massol/>,
  Struts in Action - <http://husted.com/struts/book.html>,
  JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.


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

Re: Struts web site [was: Re: Conversion of web site docs to XHTML]

2003-09-07 Thread Ted Husted

Robert Leland wrote:
Joe:
Thanks, I was hoping you would chime in ! It looks like you used maven 
for your site, and I prefer your color scheme over the standard...
Which is here, if anyone was wondering:

http://demo.jgsullivan.com/struts/

-T.



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

Re: Struts web site [was: Re: Conversion of web site docs to XHTML]

2003-09-06 Thread Ted Husted

Craig R. McClanahan wrote:
> Or, to put it another way, using Maven as a
build system will give us a website/docs publishing system for free.
Well, last I knew, TANSTAAFL. =:)

It's nice that Maven has a build system, so long as it's a build system 
that fits our needs. Likewise, it's nice that Maven has reports, so long 
as are they are reports our team will actually use. =:)

I haven't tried it, so I'm not stating an opinion here, except TANSTAAFL.

I have noticed that a lot of the Maven deployments do not seem to be 
using all the default features, giving the site an "unfinished" feel. 
This seems like a hint that Maven may be easier to deploy than to 
configure. Meanwhile, Maven itself is in perpetual beta, which hints 
that build and comprehension tools don't necessarily speed shipping 
times =:) (OK, like we should talk about long incubations.)

I don't actually care, and, lacking a basis of comparison, I don't even 
know if what we have now is broken. Will Maven or Forrest be less work? 
If so, great. Personally, I don't care about the "look and feel" issues. 
It looks the way it looks. I just want to know if it will make better 
use of our volunteer time.

The one thing I wouldn't want is people falling into FUD mode because at 
some point something might change. If someone wants to sign-up for 
migrating the site to Maven or Forrest, that would be great. But, a 
consensus without a working group starts to devolve into a roadblock.

-Ted.



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

Re: Struts web site [was: Re: Conversion of web site docs to XHTML]

2003-09-06 Thread Ted Husted

Robert Leland wrote:
> Do we want to hold a formal vote/lazy consensus on what doc
> system we are moving to ?
Don already put the Struts SourceForge site on Forrest, so I would lean 
in that direction.

http://struts.sourceforge.net/

http://xml.apache.org/forrest/

-Ted.



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

Short terms plans

2003-08-31 Thread Ted Husted

Craig R. McClanahan wrote:
Sorry for the late response on this ... it seems like weekends are the
only time I get to play with open source code any more :-(.
I hear that, brother! =:0) The catch-as-catch-can thing isn't working 
for me anymore either, so I think I'll take my own advice

http://jakarta.apache.org/struts/faqs/helping.html#corp

and block out a regular time for open source development and call it 
part of the work week. I really want to Bugzilla sorted-out and fill in 
some of the remaining gaps in the documentation.

Since we have a wiki now, I thought it might be helpful to setup a short 
term plans page. I took the liberty (surprise!) of adding some notes 
people have made on the list or in Bugzilla recently.

http://nagoya.apache.org/wiki/apachewiki.cgi?action=edit&id=StrutsShortTermPlans

Also, I setup a Job Jar page on the Wiki

http://nagoya.apache.org/wiki/apachewiki.cgi?StrutsJobJar

I'd like to add this item as well:

* A maintainer for the conventional Struts taglibs package is 
needed. If you are motivated, self-starting developer who is 
actively using these tags, groks the Apache Way, and can spare the time, 
please take a look at the outstanding reports for the taglibs 
components, and start submitting patches for our consideration.

But thought I should see if we have consensus on this first.

At one time, we were not pursuing the conventional tags because we did 
not want to steer people away from JSTL. But now that we have an 
actively-supported JSTL tag library, it may be time to fish around for 
someone to actively maintain this package on behalf of the segment of 
our Community who need, or choose, to use these tags.

Usually, I would suggest we let nature take its course and see if a 
taglib developer appears spontaneously. But, I think we may have given 
the community the impression that we are antagonistic towards these 
tags, and it may be prudent to take affirmative action to correct that 
impression.

-Ted.

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

Re: Support for non-JSTL tags (was RE: DO NOT REPLY [Bug 21465] - Enhancement of the html:link tag)

2003-08-30 Thread Ted Husted

David Graham wrote:
IMO, Struts 2.x should attempt to get out of the taglib business
altogether.  Until then, we should just let the tags be and maintain
Struts 1.x as Servlet 2.2 minimum requirement.
+1

And along the way, we can start distancing the core distribution from 
the taglib distribution. The action/config packages and the taglib 
packages live on two different layers. One is controller and the other 
is view.

IMHO, the underlying architecture of Struts will be much more apparent 
once we make each of the tablibs (original, EL, and Faces) separate 
deliverables with their own release cycles.

Many Jakarta products have subproducts with their own CVS. Perhaps there 
should be a Struts taglib CVS where all three packages could live.

-Ted.

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

Re: Support for non-JSTL tags (was RE: DO NOT REPLY [Bug 21465] -Enhancement: link tag)

2003-08-30 Thread Ted Husted

It's my feeling that Struts 1.x has to support 2.2/1.1, because that's
where a significant number of users still live.

But, it's also my feeling that the refactoring of the Request Processor
could open the door to being able to offer more than one front
controller for Struts 1.x.

The default servlet/request processor configuration should be targeted
for Servlet 2.2/1.1, but there might be enough flexibility there for
another configuration that supported Servlet 2.3/1.2 and shared most of
the code that mattered most. Such alternate configurations might be made
available here, or as a third-party extension, or on Struts SourceForge,
but I can see them existing. It's just a matter of whether anyone cares
enough to make it so.

IMHO, the real point of Struts 2.x is to give us a chance to put
backward compatibility aside and do things they way they should have
been done in the first place. But that doesn't mean that we can't
continue to let Struts 1.x evolve closer and closer to what we envision
for Struts 2.x.

So, IMHO, 2.x is not about versioning or platforms. It's about starting
a new codebase and using all the lessons we have learned (and are still
learning) from Struts 1.x, to building a better framework, test by test.

To put it in Jakarta terms, Struts 2.x is a revolution.

-Ted.

Kent Sølvsten Rasmussen wrote:
Regarding the required environment for using Struts: The servlet 2.3 spec is now 2 years old. There seem to be agreement, that it is still too early to switch to that platform.

There also seem to be agreement, that the required platform for Struts 1.x should be servlet 2.2/JSP1.1.

If the Servlet 2.4/JSP2.0 is not yet finalized, when will it be possible to use this as a minimum requirement for trus? 3 years from now?

The corollary of this will be, that if JSP2.0 /JSF should be the required platform for
Struts 2.x, then
it will be necessary to stick with Struts 1.x/Servlet2.2/JSP1.1 for another
approximately 3 years.
IMO this would be a very bad idea. Wouldn't it be better to switch the versioning to 2.x, maybe next summer, and then switch to Servlet2.3/JSP1.2? This should leave space for a couple af "cleanup" releases in between.

Kent

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

Re: Struts 2 planning and discussions

2003-08-30 Thread Ted Husted

All development discussions do happen on this list. If anyone following 
the thread wants to reduce the discussions to another format, including 
a  Wiki page, they can. But I think most people are used to using the 
DEV list.

I do try to get the broad stokes up onto the Roadmap page, whenever I 
can carve out some free time.

http://jakarta.apache.org/struts/status.html

Of course, as it stands, we're talking about using Servlet 2.4/Portlet 
1.0 (or whatever) for 2.x, but these specifications have not been 
finalized.

In practice, discussions don't move progress along much. They just serve 
to give some one an itch to punch out some code, as happened with month 
with the Commons Chain proposal.

I think there are a lot of ways we can move Struts 1.x along, especially 
if you look at the sweeping internal changes between Struts 1.0 and 1.1.

-Ted.

Chris Gerrard wrote:
Hi all,

Are there any plans to have organized discussions about the thinking 
towards Struts 2? WIll it happen on this list, or will there be a Wiki 
or something else?

I've been an avid follower of the discussions here, admit that many of 
them are beyond me, but would like to help out however I can as the 
opportunities arise, even if it's something as mundane as trying to 
distill out the various ideas people have had regarding how Struts 
should be in the future.

Chris



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

--
Ted Husted,
  Junit in Action  - <http://www.manning.com/massol/>,
  Struts in Action - <http://husted.com/struts/book.html>,
  JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.x series

2003-08-30 Thread Ted Husted

> Should Struts 2.x aim to be a portlet framework as well?

I think the goal is that Struts should be both a servlet and portlet
framework. So, yes, it would be a servlet/portlet framework. I'm not
interested in portlets myself, but I do support the goal, for different
reasons. I would like Struts to be a servlet/portlet/generic framework.

I would like Struts to become a controller framework with servlet,
portlet, or whatever adaptors to process the incoming request. The
processor could translate the request into a generic Context (a la
Commons Chain), and pass that down to the rest of the framework.

Most of the Actions that most of us write now do not use a lot of web
semantics. We pull properties out of form beans and pass them down to
business classes. There are occasions when people do have to chase after
cookies and whatnot, so we need to keep that door open. But what we do
in these cases could often be built into the request processor and
placed into the Context before calling the the Action. (Especially if
the processor were more extensible, as proposed by the Commons Chain
whiteboard code).

Ideally, there should be a form of the execute() signature without any
reference to *Servlet* or Portlet* at all, along with other forms with
those semantics if we need them. For example, the processor could call
the signature with the web semantics, and that could turn around and
call the generic one. (Just as we did with the process to execute forms.)

To choose whether to use a Servlet or Portlet Action (or even just a
generic Action without any web semantics), the processor could use the
factory pattern (as is done with the other config classes). To do it
right, we'd have to migrate Action to an interface, with some default
implementations. Of course, the default for 1.x would be the
Servlet/HttpServlet Actions we use now. But it should plug right in.

I think the key is to pursue the new Request Processor implementation
that Craig has suggested. Once that is in place, it would become very
easy to plug in entirely different ways of processing the request. The
use of the Context pattern opens many doors. And the way-cool way the
default Chain Context supports JavaBean semantics can solve a number of
documentation/type safety issues that the Context pattern can raise.

We've been steadily separating the Request Processor from the rest of
the Controller. Given the Chain Processor, and David's ongoing
refactorings, I think we'll be in a place where we can separate the
deployment of the Struts configuration from the processing of the request.

This road ~could~ lead to alternate Struts front-ends that receive
requests in different ways and just hand them off to the Request
Processor. The Request Processor then becomes the actual Front
Controller, and the servlet (or what have you) becomes a web adaptor
sitting between the Controller and the Container.

The key is being able to "level the playing field" for the Request
Processor, so that it can live outside a Servlet, Portlet, or whatever,
environment, and rely on a Context to do the mainstay of its job. (As
suggested by Craig's whiteboard code.)

I'm actually quite excited by the Commons Chain proposal. The paradigm
is very close to what I'm using in my applications now. I'm about to
start work on a new module on a paying project and hope to base the
business layer on Commons Chain.

Brilliant stuff, really, and well worth a look see:

http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/chain/

The whiteboard code in the Contrib folder is a real eye-opener:

http://cvs.apache.org/viewcvs/jakarta-struts/contrib/struts-chain/

-Ted.

Mete Kural wrote:
Struts 2.x series would be based on
Servlet 2.4 / JSP 2.0, but that's it

Also for the Struts 2.x series, is there any inclination among the rest of the Struts developers to realize this goal statement that Craig mentioned:

"I believe that we should aim for the following ideal state -- a Struts application
shoud be usable either as a webapp or as a portlet, with little (ideally no) changes.
Therefore, I believe that we'd build
whatever it takes to support this into the standard Struts distribution, which would then
be used in both environments."
Should Struts 2.x aim to be a portlet framework as well?

Mete
--
Ted Husted,
Junit in Action - <http://www.manning.com/massol/>,
Struts in Action - <http://husted.com/struts/book.html>,
JSP Site Design - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Support for non-JSTL tags (was RE: DO NOT REPLY [Bug 21465] - Enhancement of the html:link tag)

2003-08-30 Thread Ted Husted

Each of us can only offer support from our own experience. If a person 
is not using the html taglib, then they might not know the html taglib 
solution. But if they are using JSTL, they might know a JSTL solution.

There's no limit on the number of responses we can post to a question. 
If someone else knows the html taglib solution, then they can post that 
solution too.

In my experience, all it takes is a few secondary posts that start out 
with "If you aren't using Servlet 2.3 and/or can't use JSTL, then try 
this instead ...", and others in the community will soon follow your lead.

I do agree that it is important to keep in mind that not everyone can 
use JSTL, or Servlet 2.3. This is especially in larger companies where 
server upgrades are a major budget item.

But what's most important is getting the community to support itself. 
Fielding these questions on the list is wonderful thing for Committers 
to do, but, strictly speaking, it is not our primary responsibility. We 
need Committers to keep the codebase and documentation up to date, but 
anyone in the community can provide support on the user list. If there's 
no one left to provide support, then that we would mean that we've lost 
our community =:(

The User list is a place where users can help other users, and when we 
post to the user list, it's really just because we're users too. =;0)

-Ted.

(Hey, maybe I should start answering the html taglib questions with the 
Velocity Tools solution!)

Steve Raeburn wrote:
My original point really was that if the standard for Struts continues to be
2.2/1.1 that we should be careful not to reply to the "How do I do this with
" questions with the stock answer of "use JSTL".
If we're supporting Struts tags then I believe we should first answer the
question that was asked and *then* offer the advice that JSTL offers an
alternative *if* their environment supports it.
I feel it's become a bit too easy to give the JSTL answer and not deal with
the issue as presented. And I do feel that if there are gaps in the
functionality provided by the current supported environment we should at
least consider additions, particularly if someone has gone to the trouble of
providing a patch.
If someone doesn't want to deal with Struts taglib issues than that's fine,
but if there's no one left who's prepared to provide support then at that
point (and I'm not suggesting that we're anywhere near yet) I would urge
that we reconsider the required platform.
Please read this as a gentle reminder/prompt for discussion, rather than a
stern lecture. It's not my intention to cause any offence and it's something
I need to be aware of as much as anyone.
        O
   _   /|\
soapbox-> |x|  / \  <- me, no longer on it :-)
Steve



-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]
Sent: August 29, 2003 1:44 PM
To: Struts Developers List
Subject: Re: Support for non-JSTL tags (was RE: DO NOT REPLY [Bug 21465]
- Enhancement of the html:link tag)
Craig R. McClanahan wrote:

I'm -1 on making Struts 1.2.x dependent on Servlet 2.3 / JSP 1.2.
Ditto. Contrary to popular brief, a great number of organizations have
*not* migrated to 2.3/1.2, including some of the largest companies in
the world.
-Ted.



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






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

--
Ted Husted,
  Junit in Action  - <http://www.manning.com/massol/>,
  Struts in Action - <http://husted.com/struts/book.html>,
  JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: When is the next release?

2003-08-30 Thread Ted Husted

Robert Leland wrote:
> Shall we move to Validator 1.1.0, for 1.2.0 ?
If it makes it from Alpha to GA in time, and it's a drop-in replacement, 
then it would be OK with me =:0)

Though, I'd like to get out at least one 1.2.x point release before 
doing anything drastic, like migrating to Commons Resources (once it 
comes up and out).

I'm updating the News/Resource area (which is several months out of date 
now). Once that's done, I'll be taking a look at the stale tickets.

(And, Vic, thanks for getting started on these!)

-Ted.



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

Re: Support for non-JSTL tags (was RE: DO NOT REPLY [Bug 21465] - Enhancement of the html:link tag)

2003-08-29 Thread Ted Husted

Craig R. McClanahan wrote:
I'm -1 on making Struts 1.2.x dependent on Servlet 2.3 / JSP 1.2.  
Ditto. Contrary to popular brief, a great number of organizations have 
*not* migrated to 2.3/1.2, including some of the largest companies in 
the world.

-Ted.



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

Re: When is the next release?

2003-08-29 Thread Ted Husted

So, I'm getting back to work on this now.

I'm reviewing the documentation now, to be sure there aren't any 
dangling issues there before getting on with the usual Bugzilla / 
Changes gauntlet.

Following up on the post to the User list, I'm adding links to the 
Struts Wiki where people can post comments regarding any of the 
documentation pages.

I'm also updating the roadmap with some of the posts we've made here 
regarding Portlets, the Composable RequestProcessor, a Struts Context, 
and Struts 2. Please watch for the CVS updates to see if I've got our 
intentions right =:0)

-Ted.



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

Re: When is the next release?

2003-08-25 Thread Ted Husted

Vic Cekvenich wrote:
Any updates on 1.2.x?
Another matter required my undivided attention last week, and so I 
haven't been able to work on this since my last post.

IMHO, before we start on the 1.2.x series, we do need to audit the 
outstanding LATER and REMIND tickets. A good number of these were 
created during the 1.0 -> 1.1 era, saying that we would revisit them 
post 1.1. So, if it's post 1.1, we should honor our obligation, and 
revisit these tickets. I'm sure that nearly all of them are obsolete, 
but, IMHO, we do need to practice due diligence and dispose of them.

Reviewing these tickets is not something that has to be done by a 
Committer. Any knowledgeable member of the Community can review these 
tickets and dispose of any that are obsolete. All changes are sent to 
the list, and so we have all have an opportunity to override any change.

A Committer does need to apply any patches to CVS, but, again, any 
member of the community can review a ticket with a patch to see if its 
obsolete or whether the patch "works for me".

I will be working through these myself, but if anyone one is willing to 
make it a joint effort, please feel free to jump in.

Also, a release is a majority vote. While I feel that this needs to be 
done, other Committers may disagree. If someone else wants to do the 
work of making a 1.2.x release without the Bugzilla audit, you won't 
hurt my feelings. =:0) --- It's not about what any one of us think, it's 
about consensus and community. I feel that resolving these tickets is an 
important part of community-building, but that's just me =:0)

-Ted.



Ted Husted wrote:

AFAIK, the consensus is that our releases should follow the same 
general process used by the Jakarta Commons and the Apache HTTP Server 
project.

So, for reference, I'm following

http://httpd.apache.org/dev/release.html

and

http://jakarta.apache.org/commons/releases/

but observing the HTTPD numbering system.

Right now, I intend to post a Release Plan for majority approval, 
either late tonight or early tomorrow. This Plan would include when we 
plan to roll the initial Alpha release. (I may even decided just to 
roll a release and post that along with the Plan.) We'd then vote 
whether to upgrade 1.2.1 from Alpha to Beta or General Availability (GA).

Since there are any burning reasons to ship this instantly, I'm taking 
it as a foregone conclusion that this first roll will be at least a 
Beta. I'm confident that there are not any "serious problems that 
prohibits its use", so I don't believe it will not remain an Alpha. 
But, I do suspect that there may be "problems with this release that 
prohibit its widespread adoption" -- even if it simply documenting 
"what to do now that X is deprecated". So, I was calling it a Beta 
release.

Once we have cleaned up the 1.2.1 roll (which I wager will only be a 
Beta), we can roll 1.2.2. Hopefully, the 1.2.2 release will merit the 
General Availability stamp. Of course, nobody knows until the vote.

Heretofore, we have rolled several version of the same "release" and 
then suffixed them B1, B2, and so forth. Moving forward (as I 
understand it), we of these releases get their own integer. If the 
release does not make it to GA, it dies on the vine, we and go onto 
the next number.

In practice, you often get a odd/even pattern, where the odd was the 
"beta" or "development" version and even is the stable release. Some 
communities, like Linux, Perl, and Emacs, codify this pattern. When 
the odd-beta is sufficiently patched to make it release-worthy, they 
roll it over to the next even number and release that for general 
availability

AFAIK, we're not enforcing the odd/even pattern or a formal "patch 
level". So, if we roll 1.2.2 and it fails to get the votes for a GA, 
we'd go on to 1.2.3, and if that passes, it becomes the next "stable" 
release, odd or not.

Of course, it would even be possible for 1.2.1 to pass a GA vote, if 
someone called for one. Personally, I think that unlikely, if only for 
documentation issues. But, others could out-vote me if the consensus 
feels differently.

The core idea is that when any of us feel brave enough to roll a 
release, we can tag CVS with the next integer, and have at it. The 
instant we tag and roll it, it's automatically an Alpha. To upgrade 
the status from Alpha to Beta, or from Alpha to GA, we need a Majority 
Vote of the Committers (At least three committers have voted 
positively for a status and that there were more positive than 
negative votes (three is our working quorum for a binding vote)).

To prevent any confusion with the CVS tags and so forth, the releases 
are immutable. Once it's rolled, it's rolled. If there's an issue that 
keeps a release from being upgraded, you either patch it, or tag and 
roll another release.

T

Re: Flexible form support (was Re: Simplifying DynaActionForms)

2003-08-16 Thread Ted Husted

Steve Raeburn wrote:
The problem with adding a 'parameter' is that you then find a need for
another parameter, etc etc. Is  not suitable here? Or, even
better, nested configuration elements under form-bean.
Yes, set-property would work here, just like everywhere else. I'm just 
saying that if action has a general-purpose "parameter", then maybe 
form-bean and forward should have one too. People would not then have to 
extend action-forward or form-bean every time they wanted to try 
something out.

IMHO, the "general purpose" parameter has been a useful feature of 
ActionConfig/ActionMapping and is worth applying elsewhere. We just have 
to be quick to remind people that if they outgrow the general purpose 
parameter, then they should start extending the base object and using 
set-property. (As people often do now.)

-Ted.



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

Re: Flexible form support (was Re: Simplifying DynaActionForms)

2003-08-15 Thread Ted Husted

Don Brown wrote:
> 2. Explicitly handle form population.
I've never been quite sure whether it should be the RequestProcessor's 
job to populate an ActionForm, or whether a ActionForm should populate 
itself. The reset() method is essentially a pre-population extension 
point, and validate is essentially a post-population extension point, 
but there is no populate extension point ~:)

> 1. Pass parameters to a form in the configuration

You might want to extend form-bean and put your parameter there. You'd 
then look up the form-bean through the ActionMapping to retrieve it.

One suggestion might be to add a standard "parameter" properties to 
form-bean and action-forward, for the same reasons we have the parameter 
property on action-mapping. You could then just say

And if there were a ActionForm populate method (instead of a 
processPopulate method), you can have your DOMForm grab the parameter 
from the ActionMapping, and do whatever it needs to do to itself.

Likewise, the form-bean might give us a place to retrofit a populate 
method (assuming we decided that we wanted one). There could be a 
processPopulate property on the form-bean, and if set to false, the 
RequestProcessor could call form.populate(mapping,request) instead of 
performing its own behavior.

-Ted.

Don Brown wrote:
This reminds me, I think Struts should be more flexible supporting the
configuration of other types of forms or extensions to existing forms
(like the aforementioned modification to the dynaform).  While you can
specify any form class, you cannot pass properties to that instance making
it difficult to develop generic, powerful forms, like dynaforms, outside
the Struts framework.
For example, I've been working with an extension of ActionForm that uses
XML as its model, allowing the XML to be modified directly through Struts
saving heaps of mapping code.  In addition to naming my class, I'd like to
specify the XML file it should use as a model.  Currently, I do this
although it is admittedly a hack:

In addition, in order to have control over the form population, I have to
extend RequestProcessor and override processPopulate().
Therefore, I think there should be a way to:

1. Pass parameters to a form in the configuration
2. Explicitly handle form population.
Perhaps there are strong reasons why this wouldn't be a good idea, but I'd
like to hear them.  I apologize if this topic has already been dealt with.
Don

On Fri, 15 Aug 2003, Ted Husted wrote:

In terms of simplifying the maintenance of DynaActionForms, I was
wondering if we had tried anything like this yet?

where the proxy class would be introspected, and String or boolean
dynaproperties generated for each public property? (Rather than specify
them ourselves as XML.)
-Ted.

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

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

--
Ted Husted,
  Junit in Action  - <http://www.manning.com/massol/>,
  Struts in Action - <http://husted.com/struts/book.html>,
  JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.

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

Re: Simplifying DynaActionForms

2003-08-15 Thread Ted Husted

In terms of simplifying the maintenance of DynaActionForms, I was 
wondering if we had tried anything like this yet?


where the proxy class would be introspected, and String or boolean 
dynaproperties generated for each public property? (Rather than specify 
them ourselves as XML.)

-Ted.



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

Re: Bye struts-dev

2003-08-15 Thread Ted Husted

Of course, there's no debating Erik's points. =:)

Though, AFAIK, we haven't been discussing Struts 2 at all. A while back, 
we came to a consensus that the Struts 2.x series would be based on 
Servlet 2.4 / JSP 2.0, but that's it.

The recent discussions are all things that we can do with the 1.x 
series. Craig thinks his new request processor will be able to snap in 
over the the 1.1 version, and I agree. The ActionContext signature could 
be brought in the same way we brought in the execute signature. The 
ActionForward page controller could also be an extension of what we 
have. If the ActionForward type property isn't used, the current 
behavior prevails.

Meanwhile, something I'd like to see would be a Struts extension that 
would allow us to use Tapestry UI components for view. We already have 
such for JSPs, JSTL, JSF, Velocity, XLST, and Coccoon, why not Tapestry 
as well? [Just putting a bug in your ear =:)]

-Ted.

Erik Hatcher wrote:
Normally I don't make a parting post to an e-mail list when 
unsubscribing, I just subtly disappear.  But Struts has been a big part 
of my past couple of years professionally.  I'll be signing off this 
e-mail list in a few days (to give time to see any juicy replies this 
might generate first :).  My day job development team has decided to use 
Tapestry for our next project.  It's always nice to get less e-mail than 
more, and the discussions of Struts2 are so far removed from my daily 
coding efforts that its best for me to sign off for now.

The app we just successfully deployed is completely in Struts, and the 
tricks we pulled with it have been the subject of my TheServerSide 
Symposium and No Fluff, Just Stuff symposium presentations, as well as 
the recent articles on Struts-XDoclet integration at the JavaPro 
website.  Struts gave us enough flexibility to plug in cool things like 
resources from a database, a label taglib that leveraged Validator and 
ActionErrors information, and more.

So, Struts has served me well.  Its far from perfect though, and in the 
spirit of *constructive* criticism here are some areas to consider.

Struts does not provide is true UI components that can be reused and 
encapsulate JavaScript, images, or other resources (i.e. there is a 
whole lot of cut-and-paste and trial and error).

Struts Actions are also hard to test, and things that are hard or no fun 
get neglected by developers (i.e. dependence on container API in Struts 
Actions is a real drawback for testing).  Sure, Cactus or Mock use of 
StrutsTestCase are better than nothing, but its tough to mock business 
methods in Struts actions such that a database and container are not 
needed.

While exploring web frameworks, I spent a bit of time with WebWork2.  I 
really like what I see going on there.  Its lightweight, 
straightforward, and powerful.  The interceptors add tons of 
flexibility.  The IoC aspect of it decouples actions from the container 
and even concrete business implementations (making testing a WW2 action 
a real joy).  The command-pattern is clean.  The discussions of Struts2 
seem to be aiming towards the same thing WebWork2 already is.  I'd 
highly recommend those that are hard-core Struts developers give 
WebWork2 a good look and either jump ship or start seriously 
incorporating these ideas into the Struts2 architecture.  Using 
interfaces is one immediate take-away from WW2 :)

I'm sure that our foray into Tapestry will not be without its share of 
hurdles, and probably reinventing some wheels we mastered with Struts, 
and judgment is still out on how tough testing will be with Tapestry.

I will continue to be a Struts developer for maintaining and enhancing 
the app we just deployed, so I'm not going to totally give it up - I 
just want to reduce my e-mail influx.  And I will still present my 
Advanced Struts presentation several more times this year at No Fluff, 
Just Stuff symposiums.

I look forward to checking out the Struts2 architecture and code as it 
evolves.

Erik

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

--
Ted Husted,
  Junit in Action  - <http://www.manning.com/massol/>,
  Struts in Action - <http://husted.com/struts/book.html>,
  JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.


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

Re: Struts Composable Request Process (was RE: ActionForwards, etal)

2003-08-15 Thread Ted Husted

>> (although for 1.1 we'd probably implement all this inside a new one
>> that simply replaces the process() method with the appropriate chain
>> lookup and execution.)
For clarity, we probably should be saying the 1.x processor, since we'd 
certainly be past 1.1.x before anything like this shipped. (Old habits 
die hard.)

-Ted.





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

Re: When is the next release?

2003-08-14 Thread Ted Husted

Craig R. McClanahan wrote:
Tomcat's 4.1 experience was that only every sixth release or so was voted
GA, at least for the first several. 
I think if you look at the various Betas and RCs most Jakarta products 
go through, six would be the mode. So, this seems pretty typical.


I think it's unlikely to pass a GA vote, simply because ripping out all
the deprecated stuff is a fairly major amount of surgery, and we might
have missed something.  But we'll see.
Which is the beauty of this system. If it turns out to be GA after-all, 
we just need to update the links. CVS remains the same.


Absolutely.  One missing detail in the plan, though, is whether we branch
on each 1.2.x release.  Tomcat doesn't and I don't see a reason to since
we would probably never go back and try a 1.2.5.1 release to fix something
in 1.2.5.
Agreed. The release scheme implies that you wouldn't reissue a release. 
At most, you'd issue a patch based on the CVS tag. But more likely, 
you'd fix 1.2.5 with 1.2.6, and demote 1.2.5 if there was a serious issue.


Another thing Remy does for Tomcat (which I *really* appreciate) is keeps
a running change log (summary, not detailed) in the release notes for each
version.  That way, everyone can get a quick summary of what's changed.
I'd like this kind of thing to be part of the release manager's
responsibilities.
Once upon a time, I did a lot of this when we were ramping up for a 
milestone, but burned out during the 1.1 campaign. I agree that this is 
important, and so will bring us current for 1.x -> 1.2.x.

I'm also thinking we should make a concerted effort to apply or discount 
any outstanding patches developers have submitted. There's at least 21 
of these now.

http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=VERIFIED&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&product=Struts&short_desc=&short_desc_type=allwordssubstr&long_desc=&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&keywords=PatchAvailable&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&order=Bug+Number

We may not have a fix for an outstanding issue yet, but we really should 
honor any outstanding contributions.

I'm a zero-relative guy at heart :-).  My only concern is that people will
assume 1.2.0 really means 1.2, but I'd be happy with either 1.2.0 or
1.2.1.
I think we should assume that people will make wrong assumptions no 
matter what we do, so let's just start with zero, as Cantor intended. =:0)

-Ted.



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

Re: ActionForwards, et al (was SuccessAction)

2003-08-14 Thread Ted Husted

My only concern would be using the term "context" to imply more than one 
object.

IMHO, there should be a functional non-httpd framework below Struts, 
that would provide things like a Context Object, which would be a 
generic version of the HttpRequest. At the Stuts level, you could then 
have available to you signatures that used a Context or a HttpContext.

In the future, we should be able to write pure business Actions that 
don't use http semantics, and only use the http version when we 
absolutely need to. In practice, most of us rarely use the http services 
of the HttpRequest, and the same Actions could be coded using a generic 
Context (that might be chained to the HttpRequest, as is done with the 
Velocity Tools).

[We started along this way with duel Action classes, but I've never even 
tried to use the non-http one.]

So, if we're talking about the ActionContext interface being an 
abstraction of the Action class, I'd like to search for another name. My 
suggestion for an Action class interface would be

Action <- HttpDispatcher.

As for the other core classes, I would suggest

ActionForward <- HttpResource

ActionMapping <- HttpCommand

or, if you prefer,

Action <- WebDispatcher

ActionForward <- WebResource

ActionMapping <- WebCommand

Since, I'm lead to understand Craig finds "http" hard to say when he 
gives talks =:)

-Ted.

David Graham wrote:

--- Joe Germuska <[EMAIL PROTECTED]> wrote:

Just a little "me-too" here, but I think both Ted and David have good 
points.  Ted's approach to adding a controller to the ActionForward 
is a relatively small change to the infrastructure that can offer a 
lot of gain.   And I've been interested in seeing some kind of 
ActionContext class for quite a while now.


I chose my words carefully when I said "ActionContext interface".  I
*think* we can all agree that if we added this it should be an interface
:-).
David


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

Re: When is the next release?

2003-08-14 Thread Ted Husted

Steve Raeburn wrote:
I'm for removing it. I can do this if no one else is on it already.
David said he thought I was going to do it, and I thought David was 
going to do it, so let's split the difference and let Steve do it =:)

-Ted.



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

Re: ActionForwards, et al (was SuccessAction)

2003-08-14 Thread Ted Husted

Craig R. McClanahan wrote:
One of the potential problems in a Context-based environment is knowing
which keys you are using to store and retrieve stuff -- obviously, the
producer and consumer of a piece of data need to agree.  It is also
important that people looking at a Command should be able to determine
what attributes will be used for what by this particular Command.
The convention of exposing the keys that you're using seems quite helpful
in this regard, for at least two reasons:
* It's automatically configurable in case you want to
  reuse the Command implementation in a different way.
* The fact that a "fooKey" property exists is automatically
  documentation that your Command is going to utilize
  a particular attribute for some purpose.
And a potential problem in any Strategy-based implementation is that you 
don't know which of the parameters are actually used by a particular 
instance. For example, every Action is passed the Response, but very few 
every actually use it.

In a framework like Struts, we can be passing some type of ActionContext 
that would have JavaBean properties corresponding to the 
"greatest-denominator" signature. So, given the properties, we'd have 
the same level of documentation as we do now.

In implementing a Strategy-based or Context-based business layer 
framework, something I'm starting to look at know is the idea of 
building validation into the Command processing. So just as we can 
validate ActionForms, you might also want to validate a Context for a 
particular Command, using the Command's Catalog name (to use the Chain 
classnames) as the key.

Of course, here, I'm talking about that fabled business layer framework 
that would live below Struts but use the same architectural patterns =:0)

-Ted.







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

Re: ActionForwards, et al (was SuccessAction)

2003-08-14 Thread Ted Husted

David Graham wrote:
No, I was thinking Actions would be passed an ActionContext in their
execute() method similar to how Servlets know about a ServletContext.  The
ActionContext would contain the HttpServletRequest, form bean, etc. and
would serve to keep the API stable while allowing flexibility in what the
ActionContext actually contained.
Perhaps it's time for a Commons Context foundation class. Tiles uses a 
Context, Velocity uses a Context, the Commons-Chain sandbox package uses 
a Context, Struts wants to use a Context, and I'm sure that there are 
others.

Ideally, we might want to be able to pass a Context between Struts and 
the business layer as well as other packages like Tiles and Velocity. So 
it might be helpful if they could be implementations of the same 
underlying interface.

Perhaps we could squeeze it into Resources, since, in practice, messages 
are definitely something you would be attaching to a Context.

=:0) I just don't want Geir coming along in a few months and pointing 
out how many Context implementations we have in Jakarta now =:0)

-Ted.



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

ActionForwards, et al (was SuccessAction)

2003-08-14 Thread Ted Husted

David Graham wrote:
What I think we're seeing here
is that we've outgrown our ActionForward declarations and need some new
ones.  I'm fine with adding a SuccessAction but would really like to see
us discuss future possibilities in this area.
This may not be what you meant, but I've been thinking that 
ActionForward could use a class extension point, same as ActionMapping.

The idea would be to give ActionForward a type property for a Java 
class. If the property is specified, instead of just taking the path as 
it stands, the Controller would call a "prepare" method on the class, 
passing it the ActionForward, ActionForm, HttpRequest, and HttpResponse. 
The prepare method would return a String that the Controller would use 
for the path.

This allows the ActionForward to act as a Page Controller for the path. 
If the particular page referenced by the path needs any special "chrome" 
the Page Controller can set that up. Or, if the path needs to be 
adjusted for Locale or device (PDA, browser, et al), then the Page 
Controller could adjust the path before returning it.

If it were a virtual page, like an dynamic image, merge file, or PDF, 
the Page class could also render the Response, rather than have the 
Action do it.

Right now, the Action is doing double duty. It first acts as a 
Dispatcher that acquires business resources and selects the logical 
view. But, in real life, many pages often need special runtime resources 
of their own. So, the Action also serves as a Page Controller for the 
page it selects. Many of us consider that a mixing of concerns, and so 
we start to use some Actions as Dispatchers and others as Page 
Controllers. Tiles also fills this gap and is essentially a hybrid of a 
Compositive View and a Page Controller framework.

I'm thinking that, architecturally, the ActionForward represents some 
resource available to the application, of any type, that can be reached 
by the application's protocol. In an http environment, it's the job of a 
Resource object to provide a URI that the Controller can use the reach 
the actual resource. (And, in  another environment, perhaps the path 
would not be a URI.)

The Action, in its purest form, represents a Dispatcher. It's the job of 
a Dispatcher to select which (logical) Resource will handle the 
response. When we talk about selecting between "success", "failure", or 
"glockenspiel", we're talking about dispatching.

But, in real life, we often can't just dispatch to a page. The page 
needs certain resources to render, often to fill UI controls like select 
lists.

Ideally, I believe another class, specified by the ActionForward, should 
be responsible for setting up any "chrome" a particular page may need. 
It's the one that knows where the page is (via the path property), and 
so it's the one that should be privy to these details.

What would start to happen here, I think, is that people will put into
the new class the code that now encourages them to "chain"
some Actions. By providing a separation of concern between "choosing the
Resource" and "preparing the context for the Resource", it becomes
easier for people to Do The Right Thing.
The "gotcha" is that, to do its job, the ActionForward type may also 
need to interact with the business layer. It doesn't seem right that the 
Page Controller should try to branch to another page, like an Action 
might, if there's an error. But the declarative exception handling might 
be able to step in here.

-Ted.

--
Ted Husted,
  Junit in Action  - <http://www.manning.com/massol/>,
  Struts in Action - <http://husted.com/struts/book.html>,
  JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.


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

Re: ActionForwards, et al (was SuccessAction)

2003-08-14 Thread Ted Husted

Peter A. Pilgrim wrote:
> If the interface was supposed to be environment free what would
> this interface be?
Have a look at the abstract WebContext in the Craig's new Chain of 
Responsibility package.

http://jakarta.apache.org/builds/jakarta-commons/nightly/commons-chain/

So, the ActionContext interface *might* start with the WebContext 
members and then add some convenience methods for retrieving the 
ActionMapping and ActionForm.

MyActionForm form = (MyActionForm) context.getActionForm();

The idea being that at runtime Struts could be passing around a 
ServletActionContext or a PortletActionContext, or a generic 
ActionContext (implemented with HashMaps) that you populated yourself as 
part of an automatic test.

Another import idea is that, if we wanted, we could also add other other 
convenience methods to the context without breaking the signature.

-Ted.

--
Ted Husted,
  Junit in Action  - <http://www.manning.com/massol/>,
  Struts in Action - <http://husted.com/struts/book.html>,
  JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.

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

Re: Wildcard-matched actions (again)

2003-08-14 Thread Ted Husted

The one thing that the ticket doesn't say specifically is whether you
are already using the patch in a working application.
If so, and it's working well for you in practice, then I'd say commit it.

But, if its experimental, then I'd say let's roll a 1.2.x GA first
before playing with something this deep in the API.
The cutting point being whether you, as a Committer, have a high-degree
of confidence in the code.
We should probably mark the feature "experimental" in either case, just 
to see what shakes out when it's presented to the Community.

-Ted.

Don Brown wrote:
I'd like to put the wildcard-matched action code from Bug #21813
(http://issues.apache.org/bugzilla/show_bug.cgi?id=21813) into
Struts.  When I mentioned it last, the only concern I heard raised was
from Craig regarding performance penalties.  As I noted in the bug
description, the path isn't checked against compiled wildcards until an
exact match cannot be found.  Even then, it is only checked against action
mappings that actually contain at least one wildcard.
Let me know if anyone has any reason I shouldn't do this or concerns I can
hopefully alleviate.  Thanks.
Don



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

--
Ted Husted,
  Junit in Action  - <http://www.manning.com/massol/>,
  Struts in Action - <http://husted.com/struts/book.html>,
  JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.




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

Re: Addition of two new actions

2003-08-14 Thread Ted Husted

+1

Steve Raeburn wrote:
This is not a general purpose action. It is intended to do just one thing
and that's forward the request to one place.  There is deliberately no
flexibility in the action. The flexibility comes from being able to use an
ActionFoward definition.
We wouldn't be dictating anything because you always have the option of
creating a custom action. However, if you want to do this right now then
Struts *requires* that you create your own action.
To enable naming the foward via parameter would IMHO be generalising at the
expense of usability.
SuccessAction already seems to be a common idiom and I think this would just
reflect what many people are already doing and make it just a little bit
easier.
Steve




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

Re: When is the next release?

2003-08-14 Thread Ted Husted

David Graham wrote:
We already documented this in the 1.1 @deprecated tags.  I don't think we
need more documentation on the deprecations.
Then maybe the best thing is to post the Alpha and ask people to tender 
their vote as to whether it should remain an Alpha, go to Beta, or go to 
General Release.

 SAMPLE ONLY, NO VOTES PLEASE 

( ) +1 for ( )Alpha, ( )Beta, ( )General Release (select one status)
( ) -1 for Beta or General Release status


Also, as I understand it, these votes are revocable, so if a problem 
surfaced, we could also downgrade the status of a release and declare 
another to be the "best available version".

-Ted.



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

Re: ActionForwards, et al (was SuccessAction)

2003-08-14 Thread Ted Husted

PILGRIM, Peter, FM wrote:
Would this new ActionForward be created each time like it is now?
ActionForwards (or FowardConfigs) are instantiated when the Struts 
Config is digested and stored in a Map. FindForward then returns the 
instance directly from the Map. So they are already singleton instances 
(or at least shared instances), like ActionMappings.

   public ActionForward findForward(String name) {

ForwardConfig config = findForwardConfig(name);
if (config == null) {
config = getModuleConfig().findForwardConfig(name);
}
return ((ActionForward) config);
}

public ForwardConfig findForwardConfig(String name) {

return ((ForwardConfig) forwards.get(name));

}

protected HashMap forwards = new HashMap();

Or would it become a dynamic singleton? 
The core idea is to expand ForwardConfig so that it can host a "type" 
(or "handler") property, like the ActionMappings. If the type were 
specified, it would point to a "View" class. The View class would have 
an extension method that would return a String. If the View class were 
specified, the Controller would call that to obtain the path instead. 
So, if specified, the View class gives ForwardConfig another "bite at 
the apple" before passing back the String to use for the path.

A View class instance would be shared by all the ForwardConfigs, as an 
Action class instance is shared by all the ActionConfigs.

The problem is not necessarily
interacting with the business tier, but making any such interaction
to a minimum. The probably means delegation, or caching, or something
else to add decoration. Ideally the Struts Action such grab all the
business logic for you and then store this information for you. 
Ideally, yes, but then the Action needs to know every presentation 
requirement of the View, which implies it has a deep knowledge of the 
View's implementation. One View may need a select list, another View may 
not, but they may both serve the same Action in different page flows.

Alternatively, the Action needs to serve the highest-common denominator 
of all the decoration required by all the Views.

If we define a Context that can be passed around Struts, and perhaps the 
business layer too, it would be easier for people to implement facades 
and services that Actions and Views can share. (Though, it's not so hard 
now.)

> If an action forward requires special business requirements then
> I can see both advantages and disadvantages.
>
> The advantages is that such a new ActionForward could add
> special attributes to the response that are not concerned
> with the Action logic.
>
> The disadvantages is that it is open to abuse. Bad programming
> could introduce another layer of dispatching in the ActionForward
> code. You would get mini-MVC nested inside another MVC, which
> looks like Hierarchical MVC
This is why the extension method returns a String and not another 
ActionForward. The intent here is to render the path, not to dispatch to 
another component.

One viewpoint would be that the Action is not (or should not be) 
dispatching to a path. It's dispatching to a logical view. It's already 
the ForwardConfig's job to provide the path. Whether it is a static path 
or a dynamic path doesn't affect the status quo.

And speaking of the status quo, we already have Composite View tools 
like Tiles, which essential create a virtual path, and may have page 
controller actions of their own.

Meanwhile, people are doing things like creating dynamic ActionForwards 
in Actions (mainly to paste on request parameters) simply because they 
have no place else to do it. IMHO, the Action should have as little to 
do with web semantics as possible. An extension point on the 
ForwardConfig gives people a place to dynamically control the path and 
safely add web semantics without polluting the Action.

Also, as it stands, we have the Action rending a dynamic Response, if 
needed. IMHO, this is another place where lack of a View extension point 
pollutes the Action. To work around this, you can create an Action who's 
only job is to create a Response and then chain to it. But a better 
solution would be to have a View class render such a Response and leave 
the Action class out of it.

So, the best practice would be that the Action class should never touch 
the Response or the ActionForward path, that would be up to the View class.

-Ted.

--
Ted Husted,
  Junit in Action  - <http://www.manning.com/massol/>,
  Struts in Action - <http://husted.com/struts/book.html>,
  JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.

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

< 1 2 3 4 5 6 7 8 9 10 >

201 - 300 of 1272 matches

Mail list logo