date:20050802

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Struts Wiki" for change 
notification.

The following page has been changed by WendySmoak:
http://wiki.apache.org/struts/StrutsMaintenanceMaven

The comment on the change is:
Added link to possible fix for tests running twice in core

--
  
  === 5.4 @TODO for /core  ===
   * svn mv src/share src/java
-  * the junit tests get run 2 times (known issue for maven, I think)
+  * the junit tests get run 2 times (known issue for maven, I think) (Possible 
fix: http://jroller.com/page/carlossg?entry=maven_tips_and_tricks_avoid )
  
  === 5.5 @TODO for /el  ===
   * dist of el is copying twice

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

Re: Maven build issues

2005-08-02 Thread Wendy Smoak


From: "Frank W. Zammetti" <[EMAIL PROTECTED]>

I finally got around to getting Struts 1.3 to build for me, and I'm seeing 
some exceptions during the build (although it completes successfully).  It 
actually looks like the following snippet runs twice, which I think I saw 
somewhere is a known issue with JUnit tests and Maven?  Here's the 
snippet, if anyone can tell me whether this is expected and can be ignored 
or I need to do something to resolve it, that'd be great...


Compare yours to...
http://svn.apache.org/builds/struts/maven/trunk/nightly/logs/maven-build-20050802.log

(That's the log file from the nightly builds that run on James' machine.) 
It looks like you're seeing the same thing we all are.


The issue with tests running twice is listed under 5.4 on 
http://wiki.apache.org/struts/StrutsMaintenanceMaven , and I just added a 
link to a possible fix.  If you have time to investigate this, (or any of 
the things listed at the bottom of the page,) patches are welcome. :)


--
Wendy Smoak 




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

Re: DO NOT REPLY [Bug 35933] - [apps] Source code missing from example apps

2005-08-02 Thread Wendy Smoak


--- Additional Comments From [EMAIL PROTECTED]  2005-08-02
03:57 ---
Added source code to struts-mailreader, struts-examples, and struts-blank
webapps.

Fixed in 20050802 nightly build.


James, does the nightly build process include updating from svn?  I don't
see the source code in the .war files under 'struts-apps' in the nightlies
that you ran yesterday evening, or the ones this morning.

Thanks,
Wendy Smoak



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

Re: [STRUTS 2X]: Ideas

2005-08-02 Thread Ted Husted

Moving this to the dev@ .

On 8/2/05, Pilgrim, Peter <[EMAIL PROTECTED]> wrote:
> > But any proposals for a new Struts subproject or revolution have to be
> > based on an existing codebase. Discussions and debates will never be
> > enough. Someone has to show us the code, and more importantly, the
> > community behind the code.
> 
> Yes I tend to agree that just discussions is not equal to code, but
> one must have "the vision", and for a vision you must eventually
> come up with a design.

True. If we really want to start a revolution, I'd say the first
question is why?

(1) Why do we need a web application framework?
(2) Why isn't Struts Classic good enough?
(3) Why can't we fix (2) through evolution?

Another valid question would be: 

(4) Why isn't another ASL-compatible framework, like Spring MVC, Web
Works, or Wicket, good enough?

But, realistically, a great number of corporate teams use Struts and
getting another framework approved would be a challenge. For many
people, it might be easier to rebuild Struts than go through the
product-approval process again.

> > Every major codebases we've ever accepted, Validator, Tiles, Nesting,
> > EL, Scripting, Flow, and Shale, were all written and attracting
> > communities before we considered them for subprojects. And, had we
> > passed, each one of these would have gone on to live indepedant lives
> > with their own communities..
> 
> So what you saying one can take the existing codebase and build
> a next generation derivative. Publish it around, wait for the
> community to build up, and then you will get a chance to be
> considered among equals.

Yes. We don't have an alpha-geek here. People need to buy in, and most
volunteers won't buy-in until there is code on the table.

Back in the day, Bill Gates was able to walk around the Microsoft
campus and tell everyone "OK, it's all about .NET now." And everyone
there hunkered down and made it so. No one here can do something like
that. We need to see volunteers stepping up and maintaining the
codebase of their own free will.

But *not* because the codebase is labeled "Struts" -- but because the
volunteers want it and need it for their own work. People who work on
Struts because it's Struts are seeds in shallow ground. For a codebase
to succeed, we need to see that it has deep roots and committed
volunteers, who will do whatever it takes by any means necessary.

Now, if it were me, which right now it is not, I'd start by recoding
Struts for Java 5, test by test, example by example. I wouldn't worry
about backward compatiblity too much at first, and I'd drop anything
that's just there to maintain backward compatibility, including
pre-module stuff to support direct links to server pages.

I might skip over conventional ActionForms, and only implement the
dynamic or lazy versions, along with Hubert's POJO extension. I would
certainly integrate the Struts-Config, Tiles, and Validator schemas,
so that you can have one config, if you like, or slice and dice them.
I'd clean up some of the inconsistencies in the XML schema, and then
think about making some other changes (as delibrated in Jericho).
Ideally, we should be able to inject any object from the config, ala
Spring and HiveMind. I'd then jump ahead and add the things on the
Struts Roadmap.

In other words, revolution by mutation. Instead of waiting years for
Struts 1.x to evolve into 2.x, mutate Struts in a year of hard coding.

For a new UI layer, I'd start by looking at BeeHive 
[http://incubator.apache.org/projects/beehive.html], and then consider
adopting Struts Menu, Struts Layout, and DisplayTag, porting them all
to Java 5 of course. [The Apache License works both ways, you know :)]

Then, I'd see about adding a 1.x compatability layer, as other
frameworks have done.

Since I would expect that there might be several non-committers
interested in helping, I would probably start the whiteboard at Struts
SourceForge, to make it easier to add people. It would mean incubating
the code later, but that would be worth it. I'd probably get a SVN
account at WUSH.NET, though, since I don't want to go back to CVS :)

But, as it stands, I'm working in ASP.NET through the end of the year
at least, and I don't know if I'm quite ready to C# by day and J5 by
night :)

HTH, Ted.

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

Re: Maven build issues


Ok, at least it isn't just me :)

I've never actually used Maven before, but I don't mind doing some 
research to try and deal with that issue.  I'll see what I can do.


My other goal is to deal with all those javadoc errors.  I don't know 
about anyone else, but I hate seeing things like that during a build... 
anything less than a perfect, clean build is unacceptable to me, even 
when it's only relatively minor things like javadoc errors.


Frank

Wendy Smoak wrote:

From: "Frank W. Zammetti" <[EMAIL PROTECTED]>

I finally got around to getting Struts 1.3 to build for me, and I'm 
seeing some exceptions during the build (although it completes 
successfully).  It actually looks like the following snippet runs 
twice, which I think I saw somewhere is a known issue with JUnit tests 
and Maven?  Here's the snippet, if anyone can tell me whether this is 
expected and can be ignored or I need to do something to resolve it, 
that'd be great...



Compare yours to...
http://svn.apache.org/builds/struts/maven/trunk/nightly/logs/maven-build-20050802.log 



(That's the log file from the nightly builds that run on James' 
machine.) It looks like you're seeing the same thing we all are.


The issue with tests running twice is listed under 5.4 on 
http://wiki.apache.org/struts/StrutsMaintenanceMaven , and I just added 
a link to a possible fix.  If you have time to investigate this, (or any 
of the things listed at the bottom of the page,) patches are welcome. :)




--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com


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

RE: [moved] HTML labels and Struts

Moved to the dev list, I think it's more appropriate there now...

Hmm... interesting... seems like there might be more than one related
issue here.

Trying to tackle just the issue of being able to do in an Action:

mapping.findForward("myForward#myAnchor");

I can't seem to check out from SVN from my current location, so I can't
test any of this... here's what I *think* could be done to allow this
though...

(1) In ActionMapping, change the findForward() method to this:

  public ActionForward findForward(String name) {
String anchor = "";
int hashLoc = name.indexOf("#");
if (name != null && hashLoc != -1) {
  anchor = name.substring(hashLoc, name.length());
  name = name.substring(0, hashLoc);
}
ForwardConfig config = findForwardConfig(name);
if (config == null) {
  config = getModuleConfig().findForwardConfig(name);
}
if (config == null) {
  if (log.isWarnEnabled()) {
log.warn("Unable to find '" + name + "' forward.");
  }
}
ActionForward af = null;
if (config != null) {
  ActionForward af = new ActionForward((ActionForward)config);
  if (name != null}{
af.setAnchor(anchor);
  }
}
return af;
  }

(2) In RequestProcessor, right before the line:

  if (forward.getRedirect()) {

... in the processForwardConfig() method, add:

  uri += ((ActionForward)forward).getAnchor();

(3) In ActionForward, add the following:

  private String anchor;
  public void setAnchor(String anchor) {
this.anchor = anchor;
  }
  public String getAnchor() {
return this.anchor;
  }

Quick explanation:

In ActionMapping.findForward(), we check if there is a hash mark in the
requested forward name.  If there is we grab everything to the right of
it, which is the named anchor, and we set the name to everything to the
left of it, which is the forward name.  The forward should then be found
correctly.

Then, we essentially make a clone of the ForwardConfig we found so that we
can call setAnchor() on it without affecting anything outside the current
request (ForwardConfigs are shared and generally immutable after
creation).

Lastly, in RequestProcessor, we tack the anchor on to the URI before
forwarding or redirecting.  If there was no anchor, no harm is done.

Can anyone check me on this?  Does it look reasonable?  If anyone could
even test-compile, that'd be fantastic, otherwise I'll do it when I get
home and have access.  I'll submit the patch tonight unless anyone sees an
insurmountable problem that I've missed.

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

On Tue, August 2, 2005 8:58 am, Daniel Perry said:
> I don't think it's a bug, as anchors should never be sent to the server,
> (I
> believe the should never be sent in a redirect either).  I remember doing
> some experiments with this.
>
> If you request a page: blah.do#someLabel, #someLabel is never sent in the
> request.
>
> If you forward on the server, then it will still use the anchor from the
> original request (obvious as the browser knows nothing about the forward).
>
> If you redirect on the server, then the browser *may* loose it.
>
> I tried adding an anchor on the server in the middle of a redirect:
>
> Browser requests blah.do, server redirected to other.do#anchor.  I cant
> remember which way round it was, but I think:
> IE makes a subsequent request for other.do#anchor and obviously struts
> grumbles as this isn't a valid url.
> Firefox makes a subsequent request for other.do and uses the anchor as
> expected.
>
> Daniel.
>
>> -Original Message-
>> From: Frank W. Zammetti [mailto:[EMAIL PROTECTED]
>> Sent: 02 August 2005 13:41
>> To: Struts Users Mailing List
>> Subject: Re: HTML labels and Struts
>>
>>
>> Not sure :)  I personally would consider it a bug :)
>>
>> I made a Wiki entry for this yesterday by the way, so at least there is
>> documentation of it now.  I agree though that it shouldn't be a big
>> change and would be nice to "fix" it (or, alter the feature, depending
>> on what it is!).
>>
>> Want to throw a patch up Laurie?  If not, I think I could squeeze in
>> time to write the 3-5 lines of code it'd likely be :)
>>
>> Frank
>>
>> Laurie Harper wrote:
>> > Ouch, is that considered a feature or a bug? :-) It probably
>> wouldn't be
>> > hard to change Struts to ignore the anchor if such a change were
>> > acceptable.
>> >
>> > L.
>> >
>> > Frank W. Zammetti wrote:
>> >
>> >> This is probably ripe for a Wiki entry :)
>> >>
>> >> As you found out, Struts can't find an Action mapping with an anchor
>> >> added
>> >> to it... it's trying to find, literally, an ActionMapping named
>> >> "someAction.do#someLabel".  You might, I suppose, be able to make
>> that
>> >> literally your mapping path, I've never tried that, but I don't think
>> >> that's what you'd want to do even if it works.
>> >>
>> >> The "typical" solution to this is a little bit of scripting on
>> your page
>> >> like s

[Proposal] Struts Ti

I'd been waiting to announce/propose this until I could write up a 
decent proposal and have the code in a better state, but with all the 
talk about Struts 2.0, "good" now is better than "better" tomorrow I 
suppose.  The following is a proposal for Struts Ti, a possible 
successor to Struts classic:


Struts Ti is a simplified Model 2 framework for developing webapps which 
allows the developer better access to the underlying servlet/portlet 
environment. It serves a niche of web applications that don’t want the 
additional complexity of server-side components and verbose 
configuration, yet want the structure and controller features of a 
modern web framework. Struts Ti builds on the directions of Struts 1.x, 
yet re-implements the framework to provide a clean slate for the next 
generation of Struts Ti. It aims to combine the simplicity of Ruby on 
Rails and NanoWeb, the refinement of WebWork 2, the tool-friendly 
authoring and Page Flow of Beehive, and the lessons learned from Struts 1.x.


The key word for Struts Ti is simplicity. Ideally, Struts Ti should 
approach Ruby on Rails levels of easy of use, yet scale up to large 
applications providing a smooth transition to JSF/Shale if desired.


Key Features

* POJO-based action that combines an Action and ActionForm in a 
similar manner to JSF backing beans and WebWork 2 Commands
* Intelligent defaults utilizing naming and placement conventions 
to require minimal, if any, configuration per page, however it will be 
possible to override everything on a global and per-action basis
* Configuration can be “assumed” or declared through annotations, 
xml or properties files, or any other pluggable mechanism
* Pluggable EL for data binding defaulting to JSP 2.0 EL but 
allowing OGNL or even BeanUtils
* Integration of a dialog or page flow capability drawing from 
Beehive, Spring’s web flow, and Shale’s Dialogs.

* Per-Action optional interceptor chain ala WebWork 2
* Built-in dependency injection support

Design Goals

* No servlet dependency in core framework, portlet and JSF support 
out of the box

* Spring-based dependency injection in core to allow for pluggability
* No bias to any view technology
* Ability to layer Struts 1.x compatibility on top
* Highly toolable
* Smooth integration into a portal/portlet environment
* AJAX-friendly

Implementation

* Built on the backbone of commons-chain
* No restriction on multiple Servlets and/or Servlet Filter 
implementations
* Key decision points (action selection for example) use CoR chain 
for maximum flexiblity
* Configuration specified using XDoclet (Java 1.4) or Annotations 
(Java 5+), both supported out of the box


Dependencies

* Servlets 2.4
* Java 1.4 runtime, Java 1.5 to build
* JSP 2.0 if taglibs used

Existing project collaboration

* XWork/WebWork using their XWork and possibly parts/all of their 
tag libraries

* Beehive using the Page Flow and annotations

Status

I've setup a project site for myself and have a working, if feature 
sparce, framework in place.  In feeling out the scope of the project, 
I've been working with the two projects above as I want to avoid 
reimplementing anything I don't have to, and think there is a lot of 
synergy to be had.


At this point, the project site, code, and more detailed design 
discussions are on my personal server:


https://www.twdata.org/projects/struts-ti

However, I plan to move everything over to the sandbox to start the 
incubation process and await acceptance by the Struts PMC and developer 
community.  I've stated before and I'm sure I'll be stating again, and 
again, Struts Ti does NOT compete with Struts Shale, as I see them, if 
accepted, as two sibiling projects serving different niches.


I've been watching the Struts 2.0 threads with interest and hope this 
proposal meets the needs of the Struts community for a successor to 
Struts Classic.


Don

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

Re: [Proposal] Struts Ti

2005-08-02 Thread netsql


Don Brown wrote:

* No servlet dependency in core framework, portlet and JSF support 
out of the box




1.  + Ajax, Jax-WS, Axis/DocLit... JDNC, XUL,  for us lunies doing 
UI layer rendering on the client. There has to be a "process request" 
signature that lets us do all.

Ex: List process(Context)

2. I would also say... a big benfit would be a DAO interface. The famous 
populate() or populate(Map) or my fave ArrayList populate(Map)

For the people that want to have a way to swap a Dao impl.

3. And to make it C# possible... all user exposed classes should be an 
interface (so that same interface could be reimplemented).

Ex: BeanActionApi x = new BeanActionImpl()
and put all Api into one package
org.struts.api
So one could have
org.struts.csharpimpl
(an issue on ibatis is that 2 api are different).

4. JMX. To track requests, users, dao, etc.

I think it could help put all on same page.
How about this:
All "layers" should do
List execute(Context)
Ex:
Contex ctx= {populate, selectCient, client=GM}
List populate(ctx) to dao, to get rows
or
List process(ctx) for "RPC", to return to rendering layer all known / 
needed info.


(Note how collections are a not too strongly typed)

that's all ;-)

.V


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

Re: [Proposal] Struts Ti

2005-08-02 Thread Michael Rasmussen

netsql wrote:
>3. And to make it C# possible... all user exposed classes should be an
>interface (so that same interface could be reimplemented).

I don't get this.  maybe I missed something here, (entirely possible)
but how are you going to write an underlying implementation in C# that
can be called by Java?  Or vice versa?  I totally agree that all the
API should be interfaces, but I'm not sure that the reason should be
that you can reimplement it in C#.  Please explain.

Thanks,
Michael

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

Re: [Proposal] Struts Ti


netsql wrote:

Don Brown wrote:

* No servlet dependency in core framework, portlet and JSF support 
out of the box


1.  + Ajax, Jax-WS, Axis/DocLit... JDNC, XUL,  for us lunies doing 
UI layer rendering on the client. There has to be a "process request" 
signature that lets us do all.

Ex: List process(Context)


I agree it is important to keep it platform-independent.  Since Struts 
Ti is built on OpenSymphony's XWork and Apache's commons-chain, the core 
can be kept clean and should allow more adventurous developers like 
yourself to adapt it to new environments.  One interesting feature of 
WebWork2 I've been discussing with those guys is their view-independent 
taglib.  Not only is it not tied to HTML, but not tied to JSP.  We are 
looking at ways to collaborate so both projects can benefit.


Which reminds me, I want to reiterate the purpose of Struts Ti - 
simplicity, but if I picked a second purpose, it'd be collaboration. 
There are a lot of great ideas and code out there, yet few instances of 
open source projects working together.  Struts Ti started out from 
discussions with WebWork/XWork and Beehive and it is my goal to continue 
to collaborate rather than compete.




2. I would also say... a big benfit would be a DAO interface. The famous 
populate() or populate(Map) or my fave ArrayList populate(Map)

For the people that want to have a way to swap a Dao impl.

3. And to make it C# possible... all user exposed classes should be an 
interface (so that same interface could be reimplemented).

Ex: BeanActionApi x = new BeanActionImpl()
and put all Api into one package
org.struts.api
So one could have
org.struts.csharpimpl
(an issue on ibatis is that 2 api are different).


Very interesting point; I hadn't thought of that.  Currently, the core 
is interface-driven, almost to a fault, which would hopefully facilitate 
multi-language use.  Thanks for pointing this out.


Take a look at what we have so far and let me know what you think. 
While I do want to keep it on the view tier, let me know if it is in 
line with what you are thinking.


Don


4. JMX. To track requests, users, dao, etc.

I think it could help put all on same page.
How about this:
All "layers" should do
List execute(Context)
Ex:
Contex ctx= {populate, selectCient, client=GM}
List populate(ctx) to dao, to get rows
or
List process(ctx) for "RPC", to return to rendering layer all known / 
needed info.


(Note how collections are a not too strongly typed)

that's all ;-)

.V


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




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

Re: [shale] JSF/Shale Usecase

2005-08-02 Thread Sean Schofield

Craig,

Thanks for the feedback.  There is a slight twist to my usecase that I
don't think I mentioned.  We have created a LookupDialog which takes a
'start' and 'stop' attribute.  It allows you to use a portion of
another dialog.  I know there is  but that is to cumbersome
when you have a dialog of 10 steps but then want to allow the user to
go back and change just one piece of information from one step.

We also have a common set of buttons that we resuse through tiles.  If
its a single step dialog we just have an OK and CANCEL button.  If
there are multiples steps we have PREV NEXT and CANCEL.  Whether or
not we show the NEXT button depends on if there is a "next" transition
available.  To use your solution, there would be a next transition (it
would be an ActionState which checks for matches) but its not a
visible transition.

Any thoughts on this wrinkle?  Also, if you're interested I can show
you the code I added for LookupDialog.  Even if you don't use it, you
might be interested to see how people are using Shale.

Regards,

sean



On 7/29/05, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> On 7/28/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
> > I have an interesting usecase that I'd like some feedback on.  I'm
> > working with Shale dialogs and I have a special situation with a multi
> > step dialog.
> >
> > Say there are two steps 1 + 2.  Step 1, user enters an applicant name.
> >  Before moving to step 2, we'd like to check and see if that name
> > already exists or if there are similar names.  So there is an optional
> > dialog screen in between steps 1 + 2 where we say that a similar name
> > has been found and would you like to: a.) pick from the list of
> > similar names b.) continue with the name you chose or c.) return back
> > to step 1 and try a new one.
> >
> > What I've done so far is to combine step 1 and the "optional" screen
> > onto the same JSP and conditionally render one or the other based on a
> > value from a backing bean.  So hitting next button on step 1 navigates
> > you to an action state where a method on the same backing bean is
> > called and a check is performed.  If the check fails, I throw an
> > AbortProcessingException, etc.
> >
> > Initially I wanted to just use a custom validator but there was one
> > problem.  The validation requires values that are being mapped to
> > #{dialog.data} and those values aren't updated yet at this point in
> > the JSF lifecycle.  Its important that the bean be populated before
> > the check because even after an error, the user might want to go on to
> > the next step (which is permissable.)
> >
> > Any ideas on this?  It seems like I am looking for a second validation
> > phase after the Update Model phase.
> 
> Regardless of the technology you use, this still sounds more like a
> three-screen dialog rather than a two-plus-a-validation-error dialog.
> In terms of Shale's dialogs, I'd model it like this:
> 
> * View State "Get Application Name", which accepts the name to search for.
>   The action that processes the submit does the lookup, and then returns
>   one of the following outcomes, which you'd map to different next states:
>   - "No Matches" -- Redisplay the same state (perhaps this one is
> actually a validator)
>   - "One Match" -- Transition to the "Exact Match" state
>   - "Multiple Matches" -- Transition to the "Multiple Matches" state
> 
> * View State "Multiple Matches" displays the set of close matches, and lets
>   the user pick one of them.  The outcome when they do would be "One Match",
>   which transitions to the "Exact Match" state.
> 
> * View State "One Match" displays the one-and-only match, and
> continues from there.
> 
> If you generalize this slightly, the same design pattern works just
> fine for a dialog to process pretty much any sort of a search widget
> -- if there's only one match, go display it directly; if there's more
> than one, offer the choices; and if there are no matches redisplay the
> search screen (perhaps with an error message suggesting that the user
> broaden their search).
> >
> > TIA,
> >
> > sean
> >
> 
> Craig
>

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

[shale] Possible Shale Enhancement

2005-08-02 Thread Sean Schofield

We're having some difficulties writing complex validators in JSF.  In
many cases we have a field whose validation depends on the value of
another field.  JSF doesn't really handle this situation very well in
the processValidations phase because you don't have access to the
other values.

I've run into this problem with dialogs where I'd really like to be
able to access #{dialog.data} inside my validator but its not updated
yet.  It seems like Shale might be able to provide a lifecycle
"add-on" here that would help developers deal with this shortcoming.

sean

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

DO NOT REPLY [Bug 35956] - Updated CheckStyle rules file

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35956





--- Additional Comments From [EMAIL PROTECTED]  2005-08-02 18:53 ---
CheckStyle.xml was removed from SVN some time ago, since Checkstyle itself is
now run via Maven using struts_checks.xml. This file is largely the same as
Maven's sun_checks.xml, since Struts uses the Sun coding guidelines.

If you'd like to propose changes to the Struts coding guidelines, I'd recommend
providing a diff for struts_checks.xml, along with an explanation of which rules
you are proposing to add / remove / change, so that we can see what we'd be 
getting.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: [shale] JSF/Shale Usecase

2005-08-02 Thread Craig McClanahan

On 8/2/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
> Craig,
> 
> Thanks for the feedback.  There is a slight twist to my usecase that I
> don't think I mentioned.  We have created a LookupDialog which takes a
> 'start' and 'stop' attribute.  It allows you to use a portion of
> another dialog.  I know there is  but that is to cumbersome
> when you have a dialog of 10 steps but then want to allow the user to
> go back and change just one piece of information from one step.
> 
> We also have a common set of buttons that we resuse through tiles.  If
> its a single step dialog we just have an OK and CANCEL button.  If
> there are multiples steps we have PREV NEXT and CANCEL.  Whether or
> not we show the NEXT button depends on if there is a "next" transition
> available.  To use your solution, there would be a next transition (it
> would be an ActionState which checks for matches) but its not a
> visible transition.
> 
> Any thoughts on this wrinkle?  Also, if you're interested I can show
> you the code I added for LookupDialog.  Even if you don't use it, you
> might be interested to see how people are using Shale.
> 

Hmm ... it's definitely hard to picture what your after without the
details, so it would be helpful to see the code.  But there *is* a
subtlety to Shale's dialog support that might or might not help ...
you can reuse the same JSP page (and its backing bean) in more than
one  if you want -- you do not *have* to resort to subdialogs
for reuse.  Does that help?

> Regards,
> 
> sean
> 

Craig

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

Re: [Proposal] Struts Ti

2005-08-02 Thread Michael Jouravlev

On 8/2/05, Don Brown <[EMAIL PROTECTED]> wrote:
> Struts Ti is a simplified Model 2 framework for developing webapps which
> allows the developer better access to the underlying servlet/portlet
> environment.

This is I agree with.

> It serves a niche of web applications that don't want the
> additional complexity of server-side components and verbose
> configuration, yet want the structure and controller features of a
> modern web framework.

This I don't get.

> Key Features
> 
>  * POJO-based action that combines an Action and ActionForm in a
> similar manner to JSF backing beans and WebWork 2 Commands

I am all in for this, but preserving compatibility with current
Action/ActionForm

>  * Pluggable EL for data binding defaulting to JSP 2.0 EL but
> allowing OGNL or even BeanUtils

Nice

>  * Integration of a dialog or page flow capability drawing from
> Beehive, Spring's web flow, and Shale's Dialogs.

How about Struts Dialogs? They are fully compatible with current
codebase and provide dialog and wizard support. Beehive seem to be too
heavy for me.

> Design Goals
> 
>  * No servlet dependency in core framework,

I don't like that. This is a *web* framework, I want to have easy
access to plumbing. I can see how WebWork guys are tired of answering
questions "how I can get my request".

> portlet and JSF support
> out of the box

Does not Shale support JSF out of the box? What is the point for Ti
then? I would say, than new Struts version should work with current
technologies like JSP and not force using new markup.

>  * No bias to any view technology

Well, using scope objects like request or session, every Java
framework is biased towards JSP. Is it not true?

Couple of words about flow. I think about flow for the third year, I
had several iterations, and now I came to thinking that flow is not
needed. I mean, the global application flow is not needed. It only
ties up actions/pages to each other, and is hard to maintain.

What I think of istead of flow, is "web islands", autonomous actions
which can have built-in  mini-flow in them if needed. That is, one
action has set of states and can render different pages according to
state.

Moving from action to action, from web island to web island should be
flow-less. Either an action accept input in its current state, or is
not. Either it can render itself in its state, or its not. How does a
user get to this action, should not be hardcoded.

Why would not you take a look at the simple wizard that can be created
using current Struts codebase:
http://struts.sourceforge.net/strutsdialogs/wizardaction.html There is
a live demo available which you can try.

I want to donate my project to Struts and I am open to suggestions. 

I rewrote MailReader using Struts Dialogs, I wanted to clean it up and
to write decent docs, but I guess no time for that, so I will upload
it to my demo server in couple of days.

Michael.

---
Struts Dialogs: build components, controls and wizards easier.
http://struts.sourceforge.net/strutsdialogs

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

DO NOT REPLY [Bug 35956] - Updated CheckStyle rules file

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35956





--- Additional Comments From [EMAIL PROTECTED]  2005-08-02 19:20 ---
Thanks Martin... I will do as you suggest when I get home tonight (can't 
access SVN repo right now).

However, I should note that I did get CheckStyle.xml out of SVN TRUNK just a 
day or two ago... I actually realized that struts_checks.xml is what's used 
when I finally got the build working, but I didn't know that when I submitted 
this.  A little bit of repo cleanup to be done perhaps?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: [Proposal] Struts Ti

Michael Jouravlev wrote:

* POJO-based action that combines an Action and ActionForm in a
similar manner to JSF backing beans and WebWork 2 Commands

I am all in for this, but preserving compatibility with current
Action/ActionForm

Struts Ti and particularly its underlying workhorse XWork, allows you to implement Actions however you'd like. The
default implementation will be a JSF/Ruby on Rails style POJO controller with annotations. We will provide a Struts
compatibility layer which will support regular Struts actions and forms.

* Integration of a dialog or page flow capability drawing from
Beehive, Spring's web flow, and Shale's Dialogs.

How about Struts Dialogs? They are fully compatible with current
codebase and provide dialog and wizard support. Beehive seem to be too
heavy for me.

The Beehive folks are re-implementing their Page Flow on top of Struts Ti and XWork. They bring experience with
toolability and Java 5 annotations which I personally don't have. My main complaint of Beehive is their verbose
annotations, however, they are working on that and for those that like it as simple as possible, Ti supports
XDoclet-style annotations simultaneously.

Design Goals

* No servlet dependency in core framework,

I don't like that. This is a *web* framework, I want to have easy
access to plumbing. I can see how WebWork guys are tired of answering
questions "how I can get my request".

As I said, Ti will have a Struts classic compatibility layer which will let you use Actions and ActionForms, if you are
more comfortable with them.

portlet and JSF support
out of the box

Does not Shale support JSF out of the box? What is the point for Ti
then? I would say, than new Struts version should work with current
technologies like JSP and not force using new markup.

If you are happy with JSF and/or Shale, feel free to use it. Struts Ti is aiming for a simple, clean framework that
requires no configuration, is Action-first rather than Page-first, can run in multiple environments, and use any
presentation technology, JSF and JSP included.

Regarding flow, have a closer look at Beehive. Their page flow is intuitive and tested, not to mention toolable. In
fact, they just had their first open source release and I believe are now a top level Apache project.

Don

* No bias to any view technology

Well, using scope objects like request or session, every Java
framework is biased towards JSP. Is it not true?

Couple of words about flow. I think about flow for the third year, I
had several iterations, and now I came to thinking that flow is not
needed. I mean, the global application flow is not needed. It only
ties up actions/pages to each other, and is hard to maintain.

What I think of istead of flow, is "web islands", autonomous actions
which can have built-in mini-flow in them if needed. That is, one
action has set of states and can render different pages according to
state.

Moving from action to action, from web island to web island should be
flow-less. Either an action accept input in its current state, or is
not. Either it can render itself in its state, or its not. How does a
user get to this action, should not be hardcoded.

Why would not you take a look at the simple wizard that can be created
using current Struts codebase:
http://struts.sourceforge.net/strutsdialogs/wizardaction.html There is
a live demo available which you can try.

I want to donate my project to Struts and I am open to suggestions.

I rewrote MailReader using Struts Dialogs, I wanted to clean it up and
to write decent docs, but I guess no time for that, so I will upload
it to my demo server in couple of days.

Michael.

---
Struts Dialogs: build components, controls and wizards easier.
http://struts.sourceforge.net/strutsdialogs

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

Re: [shale] Possible Shale Enhancement

2005-08-02 Thread Craig McClanahan

On 8/2/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
> We're having some difficulties writing complex validators in JSF.  In
> many cases we have a field whose validation depends on the value of
> another field.  JSF doesn't really handle this situation very well in
> the processValidations phase because you don't have access to the
> other values.
> 

With a bit of effort, you can gain access to the *submitted* values of
other components (because the validator receives a reference to the
component being validated and the FacesContext, so you can navigate
around the tree) ... but, your fundamental issue is that Process
Validations happens before Update Model Values, right?

> I've run into this problem with dialogs where I'd really like to be
> able to access #{dialog.data} inside my validator but its not updated
> yet.  It seems like Shale might be able to provide a lifecycle
> "add-on" here that would help developers deal with this shortcoming.
> 

Interesting thought ... it sounds like you want a "business rules
validation" phase in between Update Model Values and Invoke
Application, which coud examine the converted and *updated* state of
all the components.  That is definitely achieveable using phase
listeners.  Maybe something along the lines of this in ViewController?

/**
 * Callback that is invoked during a postback, in between the Update
 * Model Values phase and the Invoke Application phase of the
 * request processing lifecycle.  Use this callback to examine the
 * overall state of the updated component values, applying business
 * rules that should be enforced no matter which action was submitted
 * by the user.  If business rule validations are found, throw a
 * ValidationException containing a FacesMessage
 * that describes the failure.
 */
public void validate() throws ValidatorException;

One fly in the ointment, though, is the fact that the values each
component is bound to *have* been updated, even though the business
rules are going to flag a failure.  If those updates have side
effects, your application will need to undo them.

Of course, you can accomplish the same thing by calling a validate
method like this yourself at the beginning of each action handler
(which also lets you apply different business rules, say, to a
"Cancel" versus a "Save"); but you're going to suffer the same problem
of having to undo the updates that occurred.  It would seem safer to
deal with the submitted values during Process Validations instead.

> sean

Craig

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

DO NOT REPLY [Bug 35956] - Updated CheckStyle rules file

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35956





--- Additional Comments From [EMAIL PROTECTED]  2005-08-02 19:56 ---
You may have found that file in the trunk, but it would have to have been in
some subproject such as EL, since it was removed from core and build on May
13th. And yes, we need to clean up those other subprojects as well, but I was
focussing on core at the time.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: [Proposal] Struts Ti

2005-08-02 Thread netsql

Michael, in esence, one could just cut and paste the code from 
"org.struts.api" to C#, fixing syntax as needed.


Then in esence people that use it in one or the other have the same 
signature. Some users may never know how it's implemented. The issue is 
more interesting on iBatis, where they have "smilar" usage, but not same.


.V


Michael Rasmussen wrote:

netsql wrote:


3. And to make it C# possible... all user exposed classes should be an
interface (so that same interface could be reimplemented).



I don't get this.  maybe I missed something here, (entirely possible)
but how are you going to write an underlying implementation in C# that
can be called by Java?  Or vice versa?  I totally agree that all the
API should be interfaces, but I'm not sure that the reason should be
that you can reimplement it in C#.  Please explain.

Thanks,
Michael



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

Re: [shale] Possible Shale Enhancement

2005-08-02 Thread Sean Schofield

> With a bit of effort, you can gain access to the *submitted* values of
> other components (because the validator receives a reference to the
> component being validated and the FacesContext, so you can navigate
> around the tree) ... but, your fundamental issue is that Process
> Validations happens before Update Model Values, right?

Right.

> Interesting thought ... it sounds like you want a "business rules
> validation" phase in between Update Model Values and Invoke
> Application, which coud examine the converted and *updated* state of
> all the components.  That is definitely achieveable using phase
> listeners.  Maybe something along the lines of this in ViewController?
> 
> /**
>  * Callback that is invoked during a postback, in between the Update
>  * Model Values phase and the Invoke Application phase of the
>  * request processing lifecycle.  Use this callback to examine the
>  * overall state of the updated component values, applying business
>  * rules that should be enforced no matter which action was submitted
>  * by the user.  If business rule validations are found, throw a
>  * ValidationException containing a FacesMessage
>  * that describes the failure.
>  */
> public void validate() throws ValidatorException;

Exactly what I was thinking.

> One fly in the ointment, though, is the fact that the values each
> component is bound to *have* been updated, even though the business
> rules are going to flag a failure.  If those updates have side
> effects, your application will need to undo them.

In my current situation that is not an issue.  The dialogs are run in
a popup and are used to update the underlying page.  So the database
isn't updated, just the #{dialog.data} which eventually gets dumped
into a javascript return object.

I think I see your point though.  The value in the bean will
potentially be changed to an unacceptable value since you are already
done with UpdateModel phase.  I guess the previous value is lost by
this point?

> Of course, you can accomplish the same thing by calling a validate
> method like this yourself at the beginning of each action handler
> (which also lets you apply different business rules, say, to a
> "Cancel" versus a "Save"); but you're going to suffer the same problem
> of having to undo the updates that occurred.  It would seem safer to
> deal with the submitted values during Process Validations instead.

I'm doing something like this now.  On my dialog I have a page with a
next button like this:





Here is the relevant method in the wizard bean ...

public void processAction(ActionEvent event)
{
Status status = (Status) getSessionMap().get(Globals.STATUS);
String viewName = status.getStateName();
Object obj = getBean("jsp$wizard$"+viewName);

if (obj == null)
{
return;
}

String outcome = ((WizardController)obj).check();
HashMap wizardState = (HashMap)getValue("#{dialog.data}");

if(outcome.equals(WizardConstants.SUCCESS))
{
wizardState.put("Valid",WizardConstants.TRUE);
}
else
{
throw new AbortProcessingException();
}
}

I've also extended ViewController interface (WizardController) and
added this new check method to it.  There is an abstract
implementation which always returns SUCCESS.  So each view controller
that needs check logic can implement its own check logic.

I'm not entirely comfortable with this method but it works.  I'm just
wondering if we couldn't standardize it somehow through Shale.  It
seems like this would be an issue for more than just me.

> Craig

sean

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

DO NOT REPLY [Bug 35956] - Updated CheckStyle rules file

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35956





--- Additional Comments From [EMAIL PROTECTED]  2005-08-02 20:53 ---
Yes, you are correct it seems...

I just was able to check out from
http://svn.apache.org/repos/asf/struts/core/trunk (I have not yet dealt with any
of the sub-projects, like you I'm just focusing on the core)... in it I found
CheckStyle.xml in the path /build-legacy/el/conf/qa/CheckStyle.xml.

I was confused because I checked out /core, so I didn't expect it to be there
since I didn't check out a sub-project.  Just getting used to the directory
structure :)

Not that any of this matters a great deal, it's just a minor cleanup point
either way you look at it.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

[Struts Wiki] Update of "StrutsRelease130" by HubertRabago

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Struts Wiki" for change 
notification.

The following page has been changed by HubertRabago:
http://wiki.apache.org/struts/StrutsRelease130

The comment on the change is:
Changed Bug 35604 to enhancement

--
  || [http://issues.apache.org/bugzilla/show_bug.cgi?id=35389 35389] || 
[taglib] equal tag doesn't work with huge numbers  || Custom Tags  || 
Enhancement ||
  || [http://issues.apache.org/bugzilla/show_bug.cgi?id=35477 35477] || 
TagUtils.getActionMappingURL() does not consider "/*.do" ...  || Custom Tags  
|| _ ||
  || [http://issues.apache.org/bugzilla/show_bug.cgi?id=35513 35513] || 
multiform validation  || Validator || Confirm  issue ||
- || [http://issues.apache.org/bugzilla/show_bug.cgi?id=35604 35604] || 
[FEATURE] Allow use of native languages in resource bundle  || Utilities  || _ 
||
+ || [http://issues.apache.org/bugzilla/show_bug.cgi?id=35604 35604] || 
[FEATURE] Allow use of native languages in resource bundle  || Utilities  || 
Enhancement ||
  || [http://issues.apache.org/bugzilla/show_bug.cgi?id=35806 35806] || 
[taglib/validator] quotes not properly escaped in dynamic...  || Validator || 
Need patch ||
  || [http://issues.apache.org/bugzilla/show_bug.cgi?id=35895 35895] || 
Attributes with false in TLD p...  || Custom Tags  
|| _ ||
  || [http://issues.apache.org/bugzilla/show_bug.cgi?id=35931 35931] || [el] 
Example webapp missing || EL || _ ||

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

Re: [Proposal] Struts Ti

2005-08-02 Thread Michael Rasmussen

On 8/2/05, Don Brown <[EMAIL PROTECTED]> wrote:

> Key Features

>  * Pluggable EL for data binding defaulting to JSP 2.0 EL but
> allowing OGNL or even BeanUtils
> 
> Design Goals
> 

> Implementation
> 
>  * Built on the backbone of commons-chain

Don,
  I wrote a patch for Chain a couple weeks ago that created support
for an EL.  It uses JSTL-EL by default and was designed with the idea
that it would be pluggable.  The patch is just sitting there, I don't
know what you are using for Struts-Ti, but it seems like if you are
going to add pluggable EL support and use chain it should be
consistent across the projects.  THe patch is not committed yet.  Joe
Germuska was going to look at it when he got back from vacation, but
he seems to have taken a LONG vacation.

The bugzilla ticket is here if you are interested.  

http://issues.apache.org/bugzilla/show_bug.cgi?id=35326

The patch is for CVS and not SVN, which I need to change, but haven't
gotten around to.

Excuse my "patch plugging", I just thought it might be useful to your work.

Michael

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

Re: [moved] HTML labels and Struts

2005-08-02 Thread Laurie Harper

The only thing that occurs to me is: are anchors guaranteed to be at the 
end of the URL? I.e. is this valid: http://.../myAction.do#anchor?query=...


Come to think of it, it may not make any difference; is the 'name' argument 
to findForward pre-processed to strip request parameters?


L.

Frank W. Zammetti wrote:


Moved to the dev list, I think it's more appropriate there now...

Hmm... interesting... seems like there might be more than one related
issue here.

Trying to tackle just the issue of being able to do in an Action:

mapping.findForward("myForward#myAnchor");

I can't seem to check out from SVN from my current location, so I can't
test any of this... here's what I *think* could be done to allow this
though...

(1) In ActionMapping, change the findForward() method to this:

  public ActionForward findForward(String name) {
String anchor = "";
int hashLoc = name.indexOf("#");
if (name != null && hashLoc != -1) {
  anchor = name.substring(hashLoc, name.length());
  name = name.substring(0, hashLoc);
}
ForwardConfig config = findForwardConfig(name);
if (config == null) {
  config = getModuleConfig().findForwardConfig(name);
}
if (config == null) {
  if (log.isWarnEnabled()) {
log.warn("Unable to find '" + name + "' forward.");
  }
}
ActionForward af = null;
if (config != null) {
  ActionForward af = new ActionForward((ActionForward)config);
  if (name != null}{
af.setAnchor(anchor);
  }
}
return af;
  }

(2) In RequestProcessor, right before the line:

  if (forward.getRedirect()) {

... in the processForwardConfig() method, add:

  uri += ((ActionForward)forward).getAnchor();

(3) In ActionForward, add the following:

  private String anchor;
  public void setAnchor(String anchor) {
this.anchor = anchor;
  }
  public String getAnchor() {
return this.anchor;
  }

Quick explanation:

In ActionMapping.findForward(), we check if there is a hash mark in the
requested forward name.  If there is we grab everything to the right of
it, which is the named anchor, and we set the name to everything to the
left of it, which is the forward name.  The forward should then be found
correctly.

Then, we essentially make a clone of the ForwardConfig we found so that we
can call setAnchor() on it without affecting anything outside the current
request (ForwardConfigs are shared and generally immutable after
creation).

Lastly, in RequestProcessor, we tack the anchor on to the URI before
forwarding or redirecting.  If there was no anchor, no harm is done.

Can anyone check me on this?  Does it look reasonable?  If anyone could
even test-compile, that'd be fantastic, otherwise I'll do it when I get
home and have access.  I'll submit the patch tonight unless anyone sees an
insurmountable problem that I've missed.




--
Laurie, Open Source advocate, Java geek and novice blogger:
http://www.holoweb.net/laurie


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

Re: Documenting wildcard action mapping behaviour

2005-08-02 Thread Laurie Harper


Excellent, thanks :)

Don Brown wrote:


I added the patch to Struts core.  Thanks again for the patch!

Don

Laurie Harper wrote:


I got bitten once too many times by unexpected behaviour using wildcard
action paths so I dug out my debugger and figured out what was going on.
Attached is some extra documentation to save others from confusion.

Note, I added a debug log in ActionConfigMatcher (it would have helped me
figure out what was going on a lot sooner) but it's probably redundant 
with

the added documentation. Your call, committers ;-)

The patch is against CVS HEAD.

L.

-- 8< -- 8< -- 8< --

Index: src/share/org/apache/struts/config/ActionConfigMatcher.java
===
RCS file: 
/home/cvspublic/jakarta-struts/src/share/org/apache/struts/config/ActionConfigMatcher.java,v 


retrieving revision 1.11
diff -u -w -B -r1.11 ActionConfigMatcher.java
--- src/share/org/apache/struts/config/ActionConfigMatcher.java 1 Apr 
2004 17:56:47 -   1.11
+++ src/share/org/apache/struts/config/ActionConfigMatcher.java 19 Jul 
2005 20:59:24 -

@@ -38,7 +38,9 @@
 /**
  * Matches paths against pre-compiled wildcard expressions pulled from
  * action configs. It uses the wildcard matcher from the Apache
- * Cocoon project.
+ * Cocoon project. Patterns will be matched in the order they exist
+ * in the Struts config file. The last match wins, so more specific
+ * patterns should be defined after less specific patterns.
  *
  * @since Struts 1.2
  */
@@ -110,6 +112,10 @@
 for (Iterator i = compiledPaths.iterator(); i.hasNext();) {
 m = (Mapping) i.next();
 if (wildcard.match(vars, path, m.getPattern())) {
+if (log.isDebugEnabled()) {
+log.debug("Path matches pattern '"
++ m.getActionConfig().getPath() + "'");
+}
 config = convertActionConfig(
 path,
 (ActionConfig) m.getActionConfig(),
Index: xdocs/userGuide/building_controller.xml
===
RCS file: 
/home/cvspublic/jakarta-struts/xdocs/userGuide/building_controller.xml,v

retrieving revision 1.2
diff -u -w -B -r1.2 building_controller.xml
--- xdocs/userGuide/building_controller.xml 27 Apr 2004 22:34:01 
- 1.2
+++ xdocs/userGuide/building_controller.xml 19 Jul 2005 20:59:31 
-

@@ -1405,6 +1405,15 @@
 

 
+Mappings are matched against the request in the order they appear in
+the Struts configuration file. If more than one pattern matches the
+last one wins, so less specific patterns must appear before more
+specific ones. However, if the request URL can be matched against
+a path without any wildcards in it, no wildcard matching is 
performed

+and order in not important.
+
+
+
 Wildcard patterns can contain one or more of the following 
special tokens:

 

-- 8< -- 8< -- 8< --




--
Laurie, Open Source advocate, Java geek and novice blogger:
http://www.holoweb.net/laurie


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

Re: [Proposal] Struts Ti

2005-08-02 Thread Laurie Harper

I've also seen at least one JVM stack for .Net, allowing you to 
mix-and-match Java and C# in the same application.


L.

netsql wrote:

Michael, in esence, one could just cut and paste the code from 
"org.struts.api" to C#, fixing syntax as needed.


Then in esence people that use it in one or the other have the same 
signature. Some users may never know how it's implemented. The issue is 
more interesting on iBatis, where they have "smilar" usage, but not same.


.V


Michael Rasmussen wrote:


netsql wrote:


3. And to make it C# possible... all user exposed classes should be an
interface (so that same interface could be reimplemented).




I don't get this.  maybe I missed something here, (entirely possible)
but how are you going to write an underlying implementation in C# that
can be called by Java?  Or vice versa?  I totally agree that all the
API should be interfaces, but I'm not sure that the reason should be
that you can reimplement it in C#.  Please explain.

Thanks,
Michael



--
Laurie, Open Source advocate, Java geek and novice blogger:
http://www.holoweb.net/laurie


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

Re: [moved] HTML labels and Struts


Laurie Harper wrote:
The only thing that occurs to me is: are anchors guaranteed to be at the 
end of the URL? I.e. is this valid: http://.../myAction.do#anchor?query=...


That's a good point, I don't know the answer off the top of my head... 
have to do some looking around...


Come to think of it, it may not make any difference; is the 'name' 
argument to findForward pre-processed to strip request parameters?


Nope, wouldn't appear to be... findForward() in ActionMapping calls 
findForwardConfig() in ActionConfig, and that simply does a get() on the 
forwards collection (a HashMap).  So, at least that part of it isn't a 
problem.


The first question is interesting though... I'd be willing to bet you 
can have parameters after an anchor (or maybe the other way around, not 
sure)... lemme see what I can dig up, unless anyone reading this knows 
for sure?


Wouldn't be a big hassle to deal with it if it is possible.

Frank


L.

Frank W. Zammetti wrote:


Moved to the dev list, I think it's more appropriate there now...

Hmm... interesting... seems like there might be more than one related
issue here.

Trying to tackle just the issue of being able to do in an Action:

mapping.findForward("myForward#myAnchor");

I can't seem to check out from SVN from my current location, so I can't
test any of this... here's what I *think* could be done to allow this
though...

(1) In ActionMapping, change the findForward() method to this:

  public ActionForward findForward(String name) {
String anchor = "";
int hashLoc = name.indexOf("#");
if (name != null && hashLoc != -1) {
  anchor = name.substring(hashLoc, name.length());
  name = name.substring(0, hashLoc);
}
ForwardConfig config = findForwardConfig(name);
if (config == null) {
  config = getModuleConfig().findForwardConfig(name);
}
if (config == null) {
  if (log.isWarnEnabled()) {
log.warn("Unable to find '" + name + "' forward.");
  }
}
ActionForward af = null;
if (config != null) {
  ActionForward af = new ActionForward((ActionForward)config);
  if (name != null}{
af.setAnchor(anchor);
  }
}
return af;
  }

(2) In RequestProcessor, right before the line:

  if (forward.getRedirect()) {

... in the processForwardConfig() method, add:

  uri += ((ActionForward)forward).getAnchor();

(3) In ActionForward, add the following:

  private String anchor;
  public void setAnchor(String anchor) {
this.anchor = anchor;
  }
  public String getAnchor() {
return this.anchor;
  }

Quick explanation:

In ActionMapping.findForward(), we check if there is a hash mark in the
requested forward name.  If there is we grab everything to the right of
it, which is the named anchor, and we set the name to everything to the
left of it, which is the forward name.  The forward should then be found
correctly.

Then, we essentially make a clone of the ForwardConfig we found so 
that we

can call setAnchor() on it without affecting anything outside the current
request (ForwardConfigs are shared and generally immutable after
creation).

Lastly, in RequestProcessor, we tack the anchor on to the URI before
forwarding or redirecting.  If there was no anchor, no harm is done.

Can anyone check me on this?  Does it look reasonable?  If anyone could
even test-compile, that'd be fantastic, otherwise I'll do it when I get
home and have access.  I'll submit the patch tonight unless anyone 
sees an

insurmountable problem that I've missed.






--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com


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

[Struts Wiki] Update of "StrutsShale" by WendySmoak

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Struts Wiki" for change 
notification.

The following page has been changed by WendySmoak:
http://wiki.apache.org/struts/StrutsShale

The comment on the change is:
Fixed link to Validation article & typo

--
   * Server side infrastructure to respond to background XML requests from JSF 
components (or other code) that has client side JavaScript behavior
   * Add some JSF components to provide easy developer access to these sorts of 
facilities, plus examples of how they can be used
  
- == Recipies and Articles About Shale ==
+ == Recipes and Articles About Shale ==
  
   * [http://www.jroller.com/page/dgeary/20050321#shale_cometh Shale Cometh]
  
@@ -57, +57 @@

  
   * ShaleAndSpring Using Spring Dependency Injection With Shale
  
- * [http://www.jroller.com/page/dgeary#added_commons_validator_support_to 
Shale Adds Validation Support]
+  * 
[http://www.jroller.com/page/dgeary/20050419#added_commons_validator_support_to 
Shale Adds Validation Support]
  

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

Re: DO NOT REPLY [Bug 35933] - [apps] Source code missing from example apps

2005-08-02 Thread James Mitchell


If it didn't I'd be pretty worried ;)

I'm changing a few things around so that I can have some better visibility. 
I'll post back (no pun intended) when I have news.


Thanks.


--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM:   jmitchtx
MSN:   [EMAIL PROTECTED]
Skype: jmitchtx

- Original Message - 
From: "Wendy Smoak" <[EMAIL PROTECTED]>

To: "Struts Developers List" 
Sent: Tuesday, August 02, 2005 7:25 AM
Subject: Re: DO NOT REPLY [Bug 35933] - [apps] Source code missing from 
example apps




--- Additional Comments From [EMAIL PROTECTED]  2005-08-02
03:57 ---
Added source code to struts-mailreader, struts-examples, and struts-blank
webapps.

Fixed in 20050802 nightly build.


James, does the nightly build process include updating from svn?  I don't
see the source code in the .war files under 'struts-apps' in the nightlies
that you ran yesterday evening, or the ones this morning.

Thanks,
Wendy Smoak



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






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

Re: [Proposal] Struts Ti

2005-08-02 Thread Joe Germuska


At 3:41 PM -0500 8/2/05, Michael Rasmussen wrote:

 I wrote a patch for Chain a couple weeks ago that created support
for an EL.  It uses JSTL-EL by default and was designed with the idea
that it would be pluggable.  The patch is just sitting there, I don't
know what you are using for Struts-Ti, but it seems like if you are
going to add pluggable EL support and use chain it should be
consistent across the projects.  THe patch is not committed yet.  Joe
Germuska was going to look at it when he got back from vacation, but
he seems to have taken a LONG vacation.


I wish!  I just haven't had much spare time to devote to open source 
projects since I've been back.


I agree that the EL support, especially if designed to be pluggable, 
should be as consistent as possible between projects. I'd like to see 
how Don has set up the configurability in Struts-Ti  (btw, how is 
that pronounced anyway?  Is it like "Titantium"? or like "tie"? or 
like "tea"?  Am I really the first one to ask?)


Joe

--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction"  -The Ex


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

Re: [Proposal] Struts Ti


Joe Germuska wrote:
I agree that the EL support, especially if designed to be pluggable, 
should be as consistent as possible between projects. I'd like to see 
how Don has set up the configurability in Struts-Ti  (btw, how is that 
pronounced anyway?  Is it like "Titantium"? or like "tie"? or like 
"tea"?  Am I really the first one to ask?)


I'm going with Titanium.  I'm an ultralight backpacker so Titanium is near and dear to my heart - very light, yet 
surprisingly strong.


Regarding configurability, that is where Spring and interface-driven development comes in.  Commons-chain helps with key 
decision points to allow someone to plug in their own behavior.  Concerning EL support, XWork, the action framework for 
Ti, relies on OGNL.  I'm working with the WebWork guys on abstracting that out so it will be pluggable.  OGNL has a lot 
of power, however, if you are using JSP 2.0, you might want to keep the EL consistent.


Don



Joe




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

[Struts Wiki] Update of "StrutsUpgradeNotes12to13" by FrankZammetti

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Struts Wiki" for change 
notification.

The following page has been changed by FrankZammetti:
http://wiki.apache.org/struts/StrutsUpgradeNotes12to13

--
  
||http://jakarta.apache.org/struts/tags-tiles||http://struts.apache.org/tags-tiles||
  
  
+ 
+ Remember to add commons-chain.jar to your WEB-INF/lib directory (or to your 
app-accessible classpath otherwise)!  I was able to drop 1.3 into a simple 
Struts app that wasn't using any taglibs, EL or Tiles, and the only problem I 
had was in forgetting to add commons-chain.jar.  Open question: is this still 
required if you DON'T use the ComposableRequestProcessor?
+ 
+ 
+ 
  (please add notes here as you gain experience with this migration) 
   
  

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

Re: [moved] HTML labels and Struts


The situation is actually even a little more complicated...

I would have sworn before that you could include a query string when you 
called ActionMapping.findForward(), but you cannot... after the fact I 
remembered that you have to play some games with adding it to the path 
on the returned forward.


So, the code needs to be altered to even allow that in the first place. 
   I haven't yet verified whether you can have an anchor and a query 
string, although I suspect you can.  I'm toying with this stuff right now...


Frank

Frank W. Zammetti wrote:

Laurie Harper wrote:

The only thing that occurs to me is: are anchors guaranteed to be at 
the end of the URL? I.e. is this valid: 
http://.../myAction.do#anchor?query=...



That's a good point, I don't know the answer off the top of my head... 
have to do some looking around...


Come to think of it, it may not make any difference; is the 'name' 
argument to findForward pre-processed to strip request parameters?



Nope, wouldn't appear to be... findForward() in ActionMapping calls 
findForwardConfig() in ActionConfig, and that simply does a get() on the 
forwards collection (a HashMap).  So, at least that part of it isn't a 
problem.


The first question is interesting though... I'd be willing to bet you 
can have parameters after an anchor (or maybe the other way around, not 
sure)... lemme see what I can dig up, unless anyone reading this knows 
for sure?


Wouldn't be a big hassle to deal with it if it is possible.

Frank


L.

Frank W. Zammetti wrote:


Moved to the dev list, I think it's more appropriate there now...

Hmm... interesting... seems like there might be more than one related
issue here.

Trying to tackle just the issue of being able to do in an Action:

mapping.findForward("myForward#myAnchor");

I can't seem to check out from SVN from my current location, so I can't
test any of this... here's what I *think* could be done to allow this
though...

(1) In ActionMapping, change the findForward() method to this:

  public ActionForward findForward(String name) {
String anchor = "";
int hashLoc = name.indexOf("#");
if (name != null && hashLoc != -1) {
  anchor = name.substring(hashLoc, name.length());
  name = name.substring(0, hashLoc);
}
ForwardConfig config = findForwardConfig(name);
if (config == null) {
  config = getModuleConfig().findForwardConfig(name);
}
if (config == null) {
  if (log.isWarnEnabled()) {
log.warn("Unable to find '" + name + "' forward.");
  }
}
ActionForward af = null;
if (config != null) {
  ActionForward af = new ActionForward((ActionForward)config);
  if (name != null}{
af.setAnchor(anchor);
  }
}
return af;
  }

(2) In RequestProcessor, right before the line:

  if (forward.getRedirect()) {

... in the processForwardConfig() method, add:

  uri += ((ActionForward)forward).getAnchor();

(3) In ActionForward, add the following:

  private String anchor;
  public void setAnchor(String anchor) {
this.anchor = anchor;
  }
  public String getAnchor() {
return this.anchor;
  }

Quick explanation:

In ActionMapping.findForward(), we check if there is a hash mark in the
requested forward name.  If there is we grab everything to the right of
it, which is the named anchor, and we set the name to everything to the
left of it, which is the forward name.  The forward should then be found
correctly.

Then, we essentially make a clone of the ForwardConfig we found so 
that we
can call setAnchor() on it without affecting anything outside the 
current

request (ForwardConfigs are shared and generally immutable after
creation).

Lastly, in RequestProcessor, we tack the anchor on to the URI before
forwarding or redirecting.  If there was no anchor, no harm is done.

Can anyone check me on this?  Does it look reasonable?  If anyone could
even test-compile, that'd be fantastic, otherwise I'll do it when I get
home and have access.  I'll submit the patch tonight unless anyone 
sees an

insurmountable problem that I've missed.








--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com


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

DO NOT REPLY [Bug 35988] New: - Problem with validation in MailReader example app