"javascript:void()" Problem

[ojay78]

 

HI, 

What is with my a href wrong`? I tried several other
solutions like _javascript_:void(0) or javscript:; but I get always a syntax
error in the _javascript_ console. I tried it with firefox, IE and avant browser
always the same failure

 

td class="button">

 

Thanks

 

 

Re: Hibernate 3 versioning/concurrency

[Adam Hardy]

Lee Harrington on 09/09/05 14:59, wrote:
Would love to get some "best practices" for setting up hibernate with 
struts. I'm gettin "staleobject" exceptions when I'm the only one editing. I 
had this problem with Hibernate 2 and eventually solved it, but never really 
understood.


Now the problem is back, and I'm stuck again.

Not sure what to put in the hbm.xml when it comes to version.
Not sure that to put in my action, my tableService class, when to begin the 
transaction, how to end it (applicaiton filter?)


Anybody got the 411 on how to properly set things up?


What Hibernate pattern are you using for session management? Check out 
the Hibernate docs here:


http://www.hibernate.org/37.html

HTH
Adam

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

Re: ot: struts obsesed

[Adam Hardy]

Vic Cekvenich on 09/09/05 21:52, wrote:

http://jroller.com/page/RickHigh?entry=is_struts_dead_is_struts

Is he going to get over it?
I wonder who the #2 framework is?


As someone who has never really contributed much to struts except a few 
bug reports, I feel slightly out-of-place saying this, but to a certain 
extent he is correct, although really it is a matter of semantics, since 
struts is not dead, it's just been fairly dormant.


Struts would have avoided the whole "struts is dead" thing by bringing 
out more elegant solutions to certain problematic areas such as dropdown 
boxes:


* dropdown box data setup & display
* dropdown box data request parameter handling (I'm thinking of 
Hibernate when the DTOs don't have primary keys)

* i18n of dropdowns
* reference data cache

There are some great things happening in struts though and when they go 
live, I'm sure it will shut a few people up. It'll be a case of "struts 
is dead, long live struts!"



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

Re: Who decides?

[Ted Husted]

On 9/9/05, Murray Collingwood <[EMAIL PROTECTED]> wrote:
> I'm just a humble Struts user (and relatively new), and I don't claim to 
> speak for the
> group as a whole.
> 
> I have read through Donald Brown's presentation (Struts 1.3 and beyond) and I 
> get the
> feeling that the goal posts just don't stop moving.
> 
> The time I have spent learning and creating a Struts application should be an
> investment in my future development, not a stepping stone to a whole new set 
> of
> technologies that will continue to slow my productivity (through on-going 
> training).
> 
> Who, and this is my question, who makes the decision whether a technology is 
> going to
> be good for the greater community?  Who asks the questions "Do we need it?",  
> "Will
> the technology provide significantly greater returns than training costs?", 
> "Will the
> technology last long enough to deliver those returns?"

Open source projects like Apache Struts are *not* designed to be
"steering committees" that make these type of decisions for the
"greater good".  We are simply a group of engineers, just like you,
who are trying to ship our own products. But, instead of keeping our
work behind closed doors, we try to share what we do with other
engineers.

Believe it or not, we're not trying to sell anyone anything. If people
want to use an Apache Struts product, and contribute to the project by
helping out on the list and with the coding, that's great. But, we're
not here to garner market share. We're here to foster a community of
volunteer developers that can collaborate on creating the software
they themselves want to use in their own projects. We're not trying to
save the world, we're trying to ship our own next release.


> Who is it that has decided we need to keep extending the Struts framework 
> without
> considering the developers' need for better problem identification and 
> documentation of
> the existing Struts system.  This list gets so many emails of people 
> struggling with
> existing technology: Dynaforms, Validation, Iteration, Cookies, Flow control, 
> and the
> number of different versions of everything "out there" that we need to know 
> about in
> order to work with this system.
> 
> Who answers the question, "Why aren't we getting better error checking / 
> debugging
> facilities for Struts?"

Unpaid volunteers answer that question, and every other question, by
donating their own time and energy to the project. Sometimes,
individual businesses help answer those questions by letting
employeers work on the project during company time.

Tthe "Struts PMC" does *not* answer that question, because nobody
works for the PMC. We are all unpaid volunteers, each answering that
question in our own way, in what little time we have available. The
PMC does decide if a contribution becomes part of a Apache Struts
distribution, but, first, an unpaid volunteer has to create a
contribution for the PMC to review.

To answer the explicit question, Struts does not have better error
checking because no one has volunteered the time and energy to make
that happen.


> It would be amiss of me to say Struts alone is responsible here, we should 
> include
> Tomcat, MySQL, Connector/J, JSP, Java.  And I'm not saying everybody is doing 
> a
> terrible job, just asking whether we need to refocus our development efforts.
> 
> I'm not a fan of Microsoft but at least they have somebody that makes those 
> decisions
> and they appear to be developing their technology for productivity.  They have
> documentation.  They have tutorials.  They have backward compatibility.  And, 
> have

Microsoft has these things because Microsoft pays for them. And, as to
J2EE, Sun also has these things, because Sun pays for them.

The Apache Software Foundation, like most open source organizations,
has no paid staff. The ASF can't "decide" how unpaid volunteers spend
their free time.

Of course, Struts Classic does provide backward compatibility because
we want our own applications to enjoy backward compatability between
releases. Like most Apache projects, we are very careful to put
features through a strict deprecate/release/remove cycle. Not because
it makes for a nice bullet on marketing collateral, but because
evolutionary compatability is a feature we want for ourselves.


> you noticed how many websites are using .NET technology!  The number seems to
> growing much faster than J2EE or JEE.

Well, let's do Struts for .NET, then. Or PHP. Or Ruby (if Rails is not
to your liking).

As an engineer, I don't much care what technology my clients or
employers choose. The engineering skills that matter transfer.
Platform specifics are ephemeral details that we will always have to
relearn, it's just a matter of when.

Struts is an ASF project. It is not our mission to support a
particular technology. We are here to foster communities that build
software using whatever technologies the volunteers choose.


> 
> When I was looking for an ISP to host my Struts applicat

Re: Who decides?

[Adam Hardy]

Dakota Jack on 10/09/05 07:09, wrote:

I sympathize entirely with what you are saying, Murray, and believe
that there is no good reason for the present difficulties you face. 
The situation is NOT inevitable or even desirable.


I would strongly suggest you consider the Spring alternative which is
highly unlikely to change in fundamentals for a very long time.

There is no vision here that is not willy nilly and merely fulfilling
some philosophical opinions about community which come down to
servicing the older committers' daytime jobs and reputatoins, in my
opinion.  They say that too, but I will guess that they don't want
anyone else saying it.

Struts is a very unstable community producing inferior code at this
point with political infighting on a "nice" level to steal the name
for the latest and greatest old idea trying to claim to be very, very,
very new.


Dakota, can't you control your trollish instincts? There are far less 
contentious ways of saying what you said.


Since you are recommending Spring, can you answer a couple of questions 
about it? For instance, is there any outstanding improvement over struts 
in the patterns that it offers for say:


* tiles
* breadcrumb menu
* taglibs
* nested beans
* l12n and i18n (prob: dropdowns)
* reference data cache
* dropdown data collections (Id & Label)
* DTOs to view mapping
* validator
* multiple commands on form submit
* cancel button
* post-redirect-get
* exception handling
* displaying messages
* security - Spring is based on Acegi right?
* transaction token


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

Re: ot: struts obsesed

[Vic Cekvenich]

Looking at CVS and developer comments on the dev list I would say that 
by far, Struts development has never been more active by order of 
magnitude. 1.3 classic release is iminent (in "Struts" time).


.V

Adam Hardy wrote:
it's just been fairly dormant.





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

Re: Who decides?

[Vic Cekvenich]

Dakota Jack on 10/09/05 07:09, wrote:




I would strongly suggest you consider the Spring alternative which is
highly unlikely to change in fundamentals for a very long time.



I would argue that technology is shifting to RiA (Ajax, Laszlo, JDNC), 
so a static framework (if Spring is statick, I would not know, I know 
they have a Swing project) is not futuristic.


But to the topic... :
In some organizations managers decide what the tech. stack is for them. 
My theory is that they read PC Week and pick some story like IBM EJB or 
MS Access, usualy they use logic like: We paid a lot of money for this, 
this will be good + we paid a lot of money for support, so we know we 
won't make a mistake. Lets use some inovative design... like push. Use 
Notes for mail client, and lots of virus scanners and sofware change 
managment on each PC to improve productivity. Then they direct people to 
support "company decission" and find ways to use the tech. Of course, 
sinc tech is expensive, their people are not best paid. Lets call this 
tech 1st orgnaization. Ex: "We are an IBM shop".


Other organizations let exerienced developers pick an effiective tech 
stack, based on the business requirments and the business problem. Ex: 
"We are a business shop".


Of course, mostly there are shades of gray.
I hope to mostly work in the 2nd type of orgnization and  I spend 
some time monitoring good tech stacks: Faclets, JDNC, CoR, iBatis, 
Groovy, Fedora, large MonitorS 
(And sometimes in my mind I put things in a bad tech stack: EJB, 
Spring(too heavy), ORM, Beans (used to be in good stach untill I used 
collections more), Notes, DHTML, etc. Your list could be different.


I think Ted is one of people that articulated that in different 
organizations in different situations one picks an eviroment friendly 
tech stack, or words to that effect. In order for developers to belive 
in their tools for one.



.V


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

Re: Who decides?

[Larry Meadors]

On 9/9/05, Murray Collingwood <[EMAIL PROTECTED]> wrote:
> I'm just a humble Struts user (and relatively new), and I don't claim to 
> speak for the
> group as a whole.
> 
> I have read through Donald Brown's presentation (Struts 1.3 and beyond) and I 
> get the
> feeling that the goal posts just don't stop moving.

Welcome to the world of technology.

I hate to be the one to break it to you, but the simple fact is that
it changes.

Frequently and massively, and often times in a manner more like
fashion than science (in contrast to Craig's response). Developers
have ADD, and chase after every shiny object they see.

On the bright side, it is somewhat cyclical. When I finished school in
the early 90's client-server VB apps were king. Next came the web. Now
we are looking at fatter RiA (Vic's favorite flavor du juor!) and next
we'll trim them down to make them run nicer on cell phones, then the
phones will get beefier and we'll get back to fatter clients, then
we'll trim them down to run on watches or chips embedded in our
sunglasses or toenails.

Get used to it, try to predict it to some extent, and you'll do fine.
If you are looking for a job that doesn't change...bad news: This is
not it.

Larry

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

Re: ot: struts obsesed

[Adam Hardy]

i was using past tense

Vic Cekvenich on 10/09/05 13:00, wrote:
Looking at CVS and developer comments on the dev list I would say that 
by far, Struts development has never been more active by order of 
magnitude. 1.3 classic release is iminent (in "Struts" time).


.V

Adam Hardy wrote:
it's just been fairly dormant.



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

Re: [OT] Who decides?

[Adam Hardy]

Adam Hardy on 10/09/05 11:11, wrote:
Since you are recommending Spring, can you answer a couple of questions 
about it? For instance, is there any outstanding improvement over struts 
in the patterns that it offers for say:



[snip]

* security - Spring is based on Acegi right?



while i'm on the subject, how should Acegi be pronounced?

ace G.I.
akeggi
A.C.E.G.I
A.C.G.I.

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

RE: "javascript:void()" Problem

[Martin Gainty]

The a href is an anchor tag referring to a URI or URL

feel free to check out

http://www.w3schools.com/html/html_links.asp

Viel Gluck,

Martin Gainty

(mobile) 001- 617-852-7822
(http)www.laconiadatasystems.com






From: "ojay78" <[EMAIL PROTECTED]>
Reply-To: "Struts Users Mailing List" 
To: 
Subject: "javascript:void()" Problem
Date: Sat, 10 Sep 2005 10:16:14 +0200
MIME-Version: 1.0
Received: from mail.apache.org ([209.237.227.199]) by mc3-f14.hotmail.com 
with Microsoft SMTPSVC(6.0.3790.211); Sat, 10 Sep 2005 01:16:16 -0700

Received: (qmail 9638 invoked by uid 500); 10 Sep 2005 08:16:05 -
Received: (qmail 9625 invoked by uid 99); 10 Sep 2005 08:16:05 -
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)by 
apache.org (qpsmtpd/0.29) with ESMTP; Sat, 10 Sep 2005 01:16:05 -0700
Received: pass (asf.osuosl.org: domain of [EMAIL PROTECTED] designates 
213.165.64.20 as permitted sender)
Received: from [213.165.64.20] (HELO mail.gmx.net) (213.165.64.20)by 
apache.org (qpsmtpd/0.29) with SMTP; Sat, 10 Sep 2005 01:16:16 -0700

Received: (qmail invoked by alias); 10 Sep 2005 08:15:58 -
Received: from p54A78FDE.dip0.t-ipconnect.de (EHLO ojaypc) [84.167.143.222] 
 by mail.gmx.net (mp008) with SMTP; 10 Sep 2005 10:15:58 +0200

X-Message-Info: 6sSXyD95QpX9Sv974aef0ym1b2bq8a6qQit6dXEa5EU=
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Precedence: bulk
List-Unsubscribe: 
List-Help: 
List-Post: 
List-Id: "Struts Users Mailing List" 
Delivered-To: mailing list user@struts.apache.org
X-ASF-Spam-Status: No, hits=0.5 
required=10.0tests=FROM_ENDS_IN_NUMS,HTML_MESSAGE,SPF_HELO_PASS,SPF_PASS

X-Spam-Check-By: apache.org
X-Authenticated: #8423223
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
Thread-Index: AcW13+jalsGeyE8lR2K9C2/DUhRUqg==
X-Y-GMX-Trusted: 0
X-Virus-Checked: Checked by ClamAV on apache.org
Return-Path: [EMAIL PROTECTED]
X-OriginalArrivalTime: 10 Sep 2005 08:16:16.0369 (UTC) 
FILETIME=[EA54D610:01C5B5DF]




HI,

What is with my a href wrong`? I tried several other solutions like
javascript:void(0) or javscript:; but I get always a syntax error in the
Javascript console. I tried it with firefox, IE and avant browser always 
the

same failure



td class="button">')">show Form Value Key Names



Thanks











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

access session attribute with taglib

[Tony Smith]

I have an attribute saved in session. In servlet, I
can access it by 
request.getSession().getAttribute("my");

In jsp, how can I access it without write java code? I
am thinking about , but do not know how to
use it.

Thanks,







__
Click here to donate to the Hurricane Katrina relief effort.
http://store.yahoo.com/redcross-donate3/

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

Re: Who decides?

[Frank W. Zammetti]

Ted Husted wrote:

Sometimes, we hear about people "voting with their feet".  Here, we
invite people to vote with their hands, by collaborating on code and
documentation. It's not up to anyone else. It's up to everyone who
volunteers. Here, the only decisions that matter are patches and
commits,  because without commits, nothing can change.


Interesting...  It's not really up to those that "vote", it is always in 
the end up to those that "commit".  Every time a contribution is turned 
away, that is in essence saying "your vote doesn't count, at least this 
time", isn't it?


Discussion is good. Stepping up to the plate and making a difference is better. 


But how many times have people stepped up and been stopped from making a 
difference?  In the end, isn't it the committers that have the power to 
direct where things go, regardless of what the community "votes"?  As 
Craig said, a good community-driven project will listen to the community.


--
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: Who decides?

[Frank W. Zammetti]

Craig McClanahan wrote:
I hope you'll find my comments useful in furthering this kind of discussion. 
But I'm starting from a different place than you ... I personally think it 
is a waste of time to improve the tools and documentation support for a five 
year old architecture that is definitely showing its age. 


Craig, I've heard you make this statement a couple of times... can you 
go into some detail on where and how Struts is "showing its age"?  More 
precisely, in those areas, what are the alternatives and what makes them 
better?


--
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: Who decides?

[Craig McClanahan]

On 9/10/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> 
> Craig McClanahan wrote:
> > I hope you'll find my comments useful in furthering this kind of 
> discussion.
> > But I'm starting from a different place than you ... I personally think 
> it
> > is a waste of time to improve the tools and documentation support for a 
> five
> > year old architecture that is definitely showing its age.
> 
> Craig, I've heard you make this statement a couple of times... can you
> go into some detail on where and how Struts is "showing its age"?


Here's a couple of things that (had we known then what we know now) would 
very likely be different -- and areas where I think improvements would be 
helpful:

* Actions as stateless singletons, instead of per-request instances

* Form beans (should have done it the way WebWork does)

* Extensibility of request processor (getting fixed in 1.3)

* Action chaining is messed up.

* Decorating actions (a la Spring MVC or WebWork or Tapestry) is missing

* Expression language syntax (based on BeanUtils) is way too limited

* Totally dependent on Servlet API objects, making (a) unit tests hard,
and (b) implementations on portlet difficult

* Key functional areas (such as Tiles and Validator) can be
pretty obtuse to configure

* No model of user interface components -- just hard coded HTML rendering

None of these things are totally unusable -- but they all need improvement.

Craig

RE: Who decides?

[David Thielen]

I was talking to my daughters about this the other day. In the last 25 years
I have had to learn a whole new environment/API/everything:

* DOS - Pascal and then C

* Windows - C and then C++

oApplications

oSystem level code (wrote part of Win95)

oGames

* Java - EJB 1.0 & EJB 2.0

* .NET/C#

 

You don't get to stick with a single technology anymore. Like it or not, the
world requires constant learning and constant movement to new tools and
technology. Struts will be replaced by JSP/Shale and in 5 years (or sooner)
that will be replaced by something else.

 

It's evolution at hyperspeed.

 

- dave

 

 

David Thielen

303-499-2544

www.windwardreports.com

 

 

-Original Message-
From: Craig McClanahan [mailto:[EMAIL PROTECTED] 
Sent: Friday, September 09, 2005 11:11 PM
To: Struts Users Mailing List
Subject: Re: Who decides?

 

...

I'm afraid that this is the nature of the software developer landscape. 

You've heard the term "Internet time"? That is the environment in which we 

(as application architects) need to decide which technoogies to become 

dependent upon. The gamble, of course, is that the lifetime of the 

technology will correspond with the lifetime of the application you build on


top of it. Sometimes you win, sometimes you lose.

...

Re: access session attribute with taglib

[Tamas Szabo]

Hi,

On 9/10/05, Tony Smith <[EMAIL PROTECTED]> wrote:
> 
> I have an attribute saved in session. In servlet, I
> can access it by
> request.getSession().getAttribute("my");
> 
> In jsp, how can I access it without write java code? I
> am thinking about , but do not know how to
> use it.
> 
> Thanks,


I presume you want to display a property of the bean:
Using JSTL:


or if you are sure that an attribue with the same name (my) is not set in 
page and request scope:


JSP standard tags:




Struts tags:




Tamas

Re: Who decides?

[Frank W. Zammetti]

Cool, thanks Craig.  It might amaze you to hear that not a single one of 
those items I really disagree with :)


I was in the middle of composing a big, grandious new message, but I 
think I can ask a single question here that really sums up all that I 
was writing there...


Of this list, I don't see a single thing that can't be done in current 
Struts.  Admittedly some are not as easy as others, but none of it, as 
far as I can tell, is undoable.  So, the question is, why don't we?  Not 
you specifically Craig, I know your off on your own crusade :)  Just a 
general question for everyone else.


Over the past few months there have been a number of people who have 
attempted to evolve Struts to "catch up" in some ways with what other 
frameworks are doing.  They have been turned away, sometimes for 
obviously legitimate reasons, sometimes for more debatable ones. 
Everyone seems to want to go off and create something entirely new when 
I haven't seen a single good, concrete reason why Struts as it exists 
today can't be evolved.  Why?


Many of the things that people claim to want in a modern framework I 
have either myself done or seen done with the current Struts codebase. 
Things like components that remember and render their own state ala JSF, 
a simple managed bean facility (IoC), built-in AJAX support, something 
akin to a prerender facility, the work of Michael Jouravlev, all of 
these things have been done in Struts, so clearly it is not a case of 
Struts not being expandable or "fixable".  Why is there so much seeming 
resistance to doing this I wonder?


Frank

Craig McClanahan wrote:

On 9/10/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:


Craig McClanahan wrote:

I hope you'll find my comments useful in furthering this kind of 


discussion.

But I'm starting from a different place than you ... I personally think 


it

is a waste of time to improve the tools and documentation support for a 


five


year old architecture that is definitely showing its age.


Craig, I've heard you make this statement a couple of times... can you
go into some detail on where and how Struts is "showing its age"?




Here's a couple of things that (had we known then what we know now) would 
very likely be different -- and areas where I think improvements would be 
helpful:


* Actions as stateless singletons, instead of per-request instances

* Form beans (should have done it the way WebWork does)

* Extensibility of request processor (getting fixed in 1.3)

* Action chaining is messed up.

* Decorating actions (a la Spring MVC or WebWork or Tapestry) is missing

* Expression language syntax (based on BeanUtils) is way too limited

* Totally dependent on Servlet API objects, making (a) unit tests hard,
and (b) implementations on portlet difficult

* Key functional areas (such as Tiles and Validator) can be
pretty obtuse to configure

* No model of user interface components -- just hard coded HTML rendering

None of these things are totally unusable -- but they all need improvement.

Craig



--
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: Who (really) decides?

[Leon Rosenberg]

 

> -Ursprüngliche Nachricht-
> Von: Frank W. Zammetti [mailto:[EMAIL PROTECTED] 
> Gesendet: Samstag, 10. September 2005 17:12
> An: Struts Users Mailing List
> Betreff: Re: Who decides?
> 
> Ted Husted wrote:
> > Sometimes, we hear about people "voting with their feet".  Here, we 
> > invite people to vote with their hands, by collaborating on 
> code and 
> > documentation. It's not up to anyone else. It's up to everyone who 
> > volunteers. Here, the only decisions that matter are patches and 
> > commits,  because without commits, nothing can change.
> 
> Interesting...  It's not really up to those that "vote", it 
> is always in the end up to those that "commit".  Every time a 
> contribution is turned away, that is in essence saying "your 
> vote doesn't count, at least this time", isn't it?

I agree with Frank that, what Ted says, is nice and right and everything,
but it's the theory. The real life shows it's cold shoulder.

I don't know whether my example fits your question, but at least it fits the
topic of the thread, so it came in handy.
As you might know, or not know, there is an issue with tomcat 5. To make it
short: 
You can not use struts (or probably most other jakarta projects) with tomcat
5. The issue has been submitted. There is a patch available. The bug became
16 votes (btw. some struts commiters voted too), which is by far most votes
on open tomcat 5 bugs right now. 
So far to the community part. The tomcat developers or probably the tomcat
developer in lead, Remy Maucherat, refuses to fix it.
So who really decides? Anyone, but not the community and not the users. (And
please don't think that struts is safe from that)

> 
> > Discussion is good. Stepping up to the plate and making a 
> difference is better. 
> 
> But how many times have people stepped up and been stopped 
> from making a difference?  In the end, isn't it the 
> committers that have the power to direct where things go, 
> regardless of what the community "votes"?  As Craig said, a 
> good community-driven project will listen to the community.

Yes, and it seems that "community-driven projects" are not to be found at
apache.


Regards
Leon

P.S. In case you didn't know it yet, here is the link to the tomcat issue: 
http://issues.apache.org/bugzilla/show_bug.cgi?id=36541

 
P.P.S. By the way, when goes struts warn their users, that struts 1.1, 1.2.x
and 1.3 aren't compliant with tomcat 5?



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

AW: Who decides?

[Leon Rosenberg]

 

> -Ursprüngliche Nachricht-
> Von: Craig McClanahan [mailto:[EMAIL PROTECTED] 
> Gesendet: Samstag, 10. September 2005 18:06
> An: Struts Users Mailing List; [EMAIL PROTECTED]
> Betreff: Re: Who decides?
> 
> Here's a couple of things that (had we known then what we 
> know now) would very likely be different -- and areas where I 
> think improvements would be
> helpful:
> 
> * Actions as stateless singletons, instead of per-request instances

I think they 'de facto' are stateless singletons? I mean the controller only
creates one instance, and you shouldn't create another :-)

> * Expression language syntax (based on BeanUtils) is way too limited

For those who need it :-)

> 
> * Totally dependent on Servlet API objects, making (a) unit 
> tests hard, and (b) implementations on portlet difficult

I think it's the nature of a http framework?

...

Regards
Leon



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

Re: AW: Who decides?

[Frank W. Zammetti]

Leon Rosenberg wrote:

I think they 'de facto' are stateless singletons? I mean the controller only
creates one instance, and you shouldn't create another :-)


That is how it currently works, and Craig has in the past explained the 
decision.  It made perfect sense 4+ years ago when he first wrote 
Struts, on the basis of performance.  Modern JVMs make those concerns no 
longer true though.


If an Action was created per request, you could do some things that you 
can't do now, like non-static class members.  This would not be a huge 
change to the Struts codebase (at least, that was my conclusion when I 
thought about it some months ago and looked at the code), but would open 
up a lot of nice possibilities.


One could go even further and quite easily add the ability to specify 
scope for an Action, so you could put them in session if you wanted. 
Then, combining your ActionForms and your Actions would be trivially 
easy... and hey, that starts to look a lot more like JSF/Shale, doesn't 
it?!? ;)


* Totally dependent on Servlet API objects, making (a) unit 
tests hard, and (b) implementations on portlet difficult



I think it's the nature of a http framework?


Not to speak for Craig, but if I understood this point correctly, the 
idea is that right now there are a number of places where 
request/response/session are passed around directly and accessed 
directly.  A layer of abstraction between those places and those 
underlying objects would make unit testing easier.  I can't speak on the 
portlet point, but I take his word for it.


In 1.3, at least as far as the request processor chain commands go, you 
get a single Context object (ActionContext I think?)  If your Actions 
also recieved that object only, and there were methods that you called 
instead of directly accessing request/response/session, you'd have that 
abstraction.


As per my previous post, you could do all of this with the current 
Struts code base... well, the single Context thing would be a little 
more difficult because you couldn't replace what an Action looks like 
now without breaking backwards compatibility, but probably it can be 
done *in adddition* to how it is now.



Regards
Leon


Frank


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

Re: how to write cookie from a Struts jsp file

[Laurie Harper]

Legolas Woodland wrote:

Hi
Thank you for reading my post.
How i can write a cookie from a Struts jsp file into client system ?
I mean when user pressed sub,it button i write the cookie 
in a way that i can use it within

logic:present
and logic:notPresents 
tags .


There are probably dozens of answers to this... One simple, brute-force 
approach would be to use a scriptlet:


<%
response.addCookie(new Cookie("xxx","yyy"));
%>

I'm sure there are any number of JSP custom tags out there that let you 
achieve the same result. Google is your friend :-)


L.


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

Re: Template Depository, but how?

[Laurie Harper]

Danny Lee wrote:

Hi guys,

Let's imagine that I'm building a web store and have a lot of different 
product groups.


For every product group I have a template describing how to peresent the 
products in this group.


My web store have to be cool, so there is an admin interface, where the 
admin can create new product groups. So he can also define custom 
templates for presentation of these groups.


The question is how to put custom DB-stored templates with some data?
The only way I could think in the moment is creating some crazy bean,
which mixes the stuff together and generates some output, but I have a 
feeling this may be quite difficult and also quite slow solution, as 
long this mechanism have to be started for each product/product list 
presentation.


Well, I supose I'm not the first poor guy having this problem, so any 
tips and suggestions are welcome :)


cheers

Danny


So essentially what you want to do is take template text from a database 
and implement some component capable of rendering that template against 
data from your application.


There are an awfully large number of technologies out there that you 
could use to achieve this. It's difficult to recommend any one 
technology without knowing more about your needs and requirements. For 
example, since templates should be created/editted by administrators you 
presumably care about what the template language/syntax looks like. You 
may need to pass simple sets of data into your templates or you may need 
them to be able to accept and address arbitrarily complex data 
structures. You may need templates to be highly efficient to render or 
you may be prepared to accept some compromises here in favour of making 
them easier to work with. Etc.


Without knowing more about your needs, I'd suggest looking at something 
like Velocity or WebMacro, frameworks that provide a simple but powerful 
template language that's easy to integrate / call into; or BSF which 
would allow you to support templates written in any of a number of 
programming languages (Java, Python, Java, etc.) if you need more 
powerful templates.


L.


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

Re: ActionForm Problem

[Laurie Harper]

You're not seeing any data in your action because your JSP doesn't 
contain anything that would submit data. You have a form in your JSP, 
but no input elements: all your data is just written to the page as 
static text.


If you want a form to submit data, that form needs to include HTML input 
elements that allow the data to be entered. If you don't actually need 
the user to be able to edit or enter data, you can use 'hidden' form 
fields to specify what should be submitted with the form.


See Struts' HTML tag library [1] for a set of tags that help you build 
forms and bind them to server-side data. See the Struts User Guide [2] 
for more detail, particularly the sections on bulding view components [3].


L.

[1] http://struts.apache.org/userGuide/building_view.html
[2] http://struts.apache.org/userGuide/index.html
[3] http://struts.apache.org/userGuide/building_view.html

[EMAIL PROTECTED] wrote:

[EMAIL PROTECTED]

I have a problem with my Form Bean:

On my jsp I have have a List of values and put them on my jsp with this code






<%=lineNo.intValue()+1%>

size="15"/>


size="3"/>








I get those values I want on my JSP. I tried to get those values into my
ActionForm with indexed properties but it wont work, I dont now whyhere
is my code from my action form, I have a few log.debug() in it so that I can
see if it works but none of my log.debug() shows up.

public class SaveFVKNForm extends ActionForm {

private Logger log = Logger.getLogger(LoginAction.class);

private List fvknListIndexed;


/** 
 * Method validate

 * @param mapping
 * @param request
 * @return ActionErrors
 */
public ActionErrors validate(
ActionMapping mapping,
HttpServletRequest request) {

return new ActionErrors();
}

/** 
 * Method reset

 * @param mapping
 * @param request
 */
public void reset(ActionMapping mapping, HttpServletRequest request) {
   log.debug("FORM RESET");
fvknListIndexed = new ArrayList();
}

/**
 * @return Returns the formFieldIndexed.
 */
public FormValueKeyName getFvknList(int idx) {
log.debug("FORM getFVKN");
	if( fvknListIndexed == null ) 
fvknListIndexed = new ArrayList();

resizeList(idx);

if( fvknListIndexed.size() > idx )

return (FormValueKeyName) fvknListIndexed.get(idx);
else 
return new FormValueKeyName();

}
/**
 * @param formFieldIndexed The formFieldIndexed to set.
 */
public void setFvknList(int idx, FormValueKeyName field) {
log.debug("FORM set FVKNFIELD");
	if( fvknListIndexed == null ) 
fvknListIndexed = new ArrayList();

resizeList(idx);

if( fvknListIndexed.size() > idx )

this.fvknListIndexed.set(idx, field);
else
throw new RuntimeException("Index out of bounds!");
}

/**
 * @param fieldList
 */
public void setFvknList(List fieldList) {
log.debug("FORM SET FIELDLIEST");
this.fvknListIndexed = fieldList;
}
/**
 * @param fieldList
 */
public List getFieldList() {
log.debug("FORM getFieldlist");
	if( fvknListIndexed == null ) 
fvknListIndexed = new ArrayList();

return this.fvknListIndexed;

}


In my Action I want to get those values into my logfile but the List is
empty

here is my action

SaveFVKNForm saveFVKNForm =  new SaveFVKNForm();
Integer size = new Integer(saveFVKNForm.getFieldList().size());

log.info(size.toString());

for (int i=0; iDoes anyone see my mistake(s) 


Thanks for your help





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

Re: Fwd: Re: Fwd: Re: Re: RE: how to represent nested bean properties in a jsp form

[Laurie Harper]

temp temp wrote:

I  solved the problem by creating an instance of
AddressVO in the formbean.

Here  is my code  after modifications.


  public class ServiceSelectionForm extends ActionForm
{

private AddressVO  addressVO  = new  AddressVO();   
public AddressVO getAddressVO() {
return addressVO;
}
public void setAddressVO(AddressVO addressVO) {
this.addressVO = addressVO;
}   
  } 
I am wondering is this the right approach or is there 
a better way to deal with   nestedbean in a  formbean 
or how to create  an instance of   nestedbean in a

formbean.

Note: forwarded message attached.


The normal way to setup your form beans is to have an action that is 
called before the page which displays the form -- in other words, your 
HTTP request is mapped to a Struts action; the action creates and 
populates the form bean, then forwards to the JSP to display it.


If you only ever need to have an empty AddressVO instance (i.e. you 
don't need to pre-load / pre-populate data in that AddressVO object) 
then what you've done is fine, though note that you should probably also 
have a reset() method that re-initialises the addressVO member field so 
you don't get unexpected results if a form bean instance is reused.


See the Struts User Guide [1] for more information, particularly 
sections on building form beans [2] and using them [3].


L.

[1] http://struts.apache.org/userGuide/index.html
[2] http://struts.apache.org/userGuide/building_model.html#actionform
[3] http://struts.apache.org/userGuide/building_view.html#form_beans


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

RE: AW: Who decides?

[Martin Gainty]

Leon et al

addressing the last item

Unit tests easily handled by Artur Hecfyz's tool testsgen (independent of 
implementation protocol)

http://wttools.sourceforge.net/unittestsgen/package.html

Struts Portlets can be easily implemented with Oracle JDeveloper via 
http://portalstudio.oracle.com/pls/ops/docs/FOLDER/COMMUNITY/PDK/articles/pdkstruts/portletize-your-app.html

(also independent of implementation protocol)

Martin-










> -Ursprüngliche Nachricht-
> Von: Craig McClanahan [mailto:[EMAIL PROTECTED]
> Gesendet: Samstag, 10. September 2005 18:06
> An: Struts Users Mailing List; [EMAIL PROTECTED]
> Betreff: Re: Who decides?
>
> Here's a couple of things that (had we known then what we
> know now) would very likely be different -- and areas where I
> think improvements would be
> helpful:
>
> * Actions as stateless singletons, instead of per-request instances

I think they 'de facto' are stateless singletons? I mean the controller 
only

creates one instance, and you shouldn't create another :-)

> * Expression language syntax (based on BeanUtils) is way too limited

For those who need it :-)

>
> * Totally dependent on Servlet API objects, making (a) unit
> tests hard, and (b) implementations on portlet difficult

I think it's the nature of a http framework?

...

Regards
Leon



-
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: Who decides?

[Ted Husted]

On 9/10/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> Over the past few months there have been a number of people who have
> attempted to evolve Struts to "catch up" in some ways with what other
> frameworks are doing.  They have been turned away, sometimes for
> obviously legitimate reasons, sometimes for more debatable ones.

Usually, the problem has been retaining backward compatibility. When a
suggestion breaks backward compatibility, we tend to pass, at least
until we can setup a deprecate/ remove/ release cycle. Since this
cycle can take a year or more, some people drift away before we can
implement a suggestion.

Some suggestions have been out of scope, mainly for the taglibs. Along
the way we decided that the original taglibs should stick to the HTML
4.1 specification. Some taglib suggestions are non-starters because of
the product's scope.

The big fix for both of these problems, and several others, is to
subdivide the one-size-must-fit-all Struts distribution into
subprojects. If a suggestion is not backwardly compatible, then
perhaps we can make it an optional component in the Extras subproject.
If a taglib is not HTML 4.1 compliant, then maybe we can start another
taglib subproject.

But, until last month, we simply didn't have the infrastructure to
even consider such things.

Another problem is being sure that there be someone around to maintain
the code. We like to see broad enough support for any suggestion to
ensure that there will be at least three people around who will
support the code. It doesn't matter if comes from a developer or a
committer. A lot of suggestions from committers die on the vine
because too few people seem interested.

Many folks don't realize that extensions we now take for granted, like
Validator and Tiles, were being used in production applications for
*years* before we added them to the distribution. (I used both myself
in April 2001, before Struts 1.0 final.)

In the same light, I expect we will see an Ajax subproject for Apache
Struts one day. But before that happens, we'd like to see broad
support for Ajax among Struts users. Then, we can be sure there will
be committers around to support the subproject later.

As it stands, we are just now completing tasks we planned *18 months*
ago. But, we are completing them, slow and steady.

In fact, I remember Don Brown making the first "subproject
reorganization" commits at ApacheCon 2004 last November. Martin and I
were sitting at a table with him at the Hackathon, jovially giving Don
verbal +1s. :)

Ten months later, we're finally at the point where we can build and
distribute the original Struts subprojects, along with the new kids on
the block, Flow, Scripting, and Shale.

> Everyone seems to want to go off and create something entirely new when
> I haven't seen a single good, concrete reason why Struts as it exists
> today can't be evolved.  Why?

It *is* being evolved. It's just that evolution takes time.
Personally, I still fully intend to walk down the Struts Classic
Roadmap that we posted over a year ago. We're just now hitting the
first milestone: subprojects. We hit this one, and we'll hit the
others too.

* http://struts.apache.org/roadmap.html

Meanwhile, exploring alternatives like Ti can be good for Struts
Classic too. Like as not, there will be techniques used in Ti that we
can retrofit to Struts Classic. And, perhaps, one day, they might even
evolve into the same product. Or not. At this point, Ti is still
hypotethical.

> 
> Many of the things that people claim to want in a modern framework I
> have either myself done or seen done with the current Struts codebase.
> Things like components that remember and render their own state ala JSF,
> a simple managed bean facility (IoC), built-in AJAX support, something
> akin to a prerender facility, the work of Michael Jouravlev, all of
> these things have been done in Struts, so clearly it is not a case of
> Struts not being expandable or "fixable".  Why is there so much seeming
> resistance to doing this I wonder?

It's not resistance, it's as you say: If we want to, we can already do
all of this now in our own applications. I expect that many of us are.
But, going the extra yard and making what we do for ourselves
available to everyone is a lot of work. We're doing the work, but it's
on a time available basis, and most of us have very little time
available. Unlike some open source projects, we don't have any
committers who are paid to work on Struts during company time.

Because committers tend to have busy professional lives, we try to
bring on new committers whenever we can. Last month, we brought on
Wendy Smoak, who has been a godsend. With help from James, She's
propelled the Mavenized web sites forward, and we can see the light at
the end of the tunnel.

Meanwhlile, after adding the "extends" feature, our other new hand,
Hubert, cleaned up the stale deprecations, so we can continue to
steadily evolve the codebase. Now, it's left to me to finish
refa

AW: AW: Who decides?

[Leon Rosenberg]

 

> -Ursprüngliche Nachricht-
> Von: Frank W. Zammetti [mailto:[EMAIL PROTECTED] 
> Gesendet: Samstag, 10. September 2005 18:47
> An: Struts Users Mailing List
> Betreff: Re: AW: Who decides?
> 
> Leon Rosenberg wrote:
> > I think they 'de facto' are stateless singletons? I mean the 
> > controller only creates one instance, and you shouldn't 
> create another 
> > :-)
> 
> That is how it currently works, and Craig has in the past 
> explained the decision.  It made perfect sense 4+ years ago 
> when he first wrote Struts, on the basis of performance.  
> Modern JVMs make those concerns no longer true though.
> 
> If an Action was created per request, you could do some 
> things that you can't do now, like non-static class members.  
> This would not be a huge change to the Struts codebase (at 
> least, that was my conclusion when I thought about it some 
> months ago and looked at the code), but would open up a lot 
> of nice possibilities.


Hmm, ok, than I must have misunderstood him. Nevertheless, aren't we talking
about a virutal three-liner here, which works with existing code as well?

Interface ActionCommand{
 public ActionMapping execute(...);
}

Interface ActionCommandFactory(){
  public ActionCommand createCommand();
}

And then a basic action:
CommandEnabledAction extends Action{
  execute(...){
 ActionCommandFactory factory = lookupFactory(...);
return factory.createCommand().execute();
  }
}

Now implement an extension to the config to specify a factory, and you are
done, aren't you?


Regards
Leon

> 
> One could go even further and quite easily add the ability to 
> specify scope for an Action, so you could put them in session 
> if you wanted. 
> Then, combining your ActionForms and your Actions would be 
> trivially easy... and hey, that starts to look a lot more 
> like JSF/Shale, doesn't it?!? ;)
> 
> >>* Totally dependent on Servlet API objects, making (a) unit tests 
> >>hard, and (b) implementations on portlet difficult
> > 
> > 
> > I think it's the nature of a http framework?
> 
> Not to speak for Craig, but if I understood this point 
> correctly, the idea is that right now there are a number of 
> places where request/response/session are passed around 
> directly and accessed directly.  A layer of abstraction 
> between those places and those underlying objects would make 
> unit testing easier.  I can't speak on the portlet point, but 
> I take his word for it.
> 
> In 1.3, at least as far as the request processor chain 
> commands go, you get a single Context object (ActionContext I 
> think?)  If your Actions also recieved that object only, and 
> there were methods that you called instead of directly 
> accessing request/response/session, you'd have that abstraction.
> 
> As per my previous post, you could do all of this with the 
> current Struts code base... well, the single Context thing 
> would be a little more difficult because you couldn't replace 
> what an Action looks like now without breaking backwards 
> compatibility, but probably it can be done *in adddition* to 
> how it is now.
> 
> > Regards
> > Leon
> 
> Frank
> 
> 
> -
> 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: Who decides?

[Dakota Jack]

The main issue, Adam, was stability.  I believe that my statements
were useful for the person asking the question.  I am not interested
in being "non-contensious" or otherwise satisfying your personal
needs.  I was trying to answer the question in a helpful way, even if
you might do otherwise.  If you would like to do otherwise, do so.  I
don't care.  I think that a honest answer to the questioner requires
stating what is relevant.  That seems okay to me.  LIke I said, do
what you like.  If you don't like what I say, I recommend you take
evasive action.  I am not trying to impress you but assist someone
else.

Regarding the list you tossed out, much of that is portable and almost
all could be easily made portable.  Some of the "features", e.g. the
way Struts code does multiple commands on a form submit, I personally
consider to be more a bug that a feature.

What you like is not my concern.  I was talking to someone else.  I
don't find your list to be fair, however.  A large part of your list
is stuff that is quite portable and not Struts specific and others are
simply not covered by Strust.  Anyway, I have always liked Struts
classic and still do.  What I was saying is that the community is
unstable and that a person starting an application would be taking a
risk at this point starting with Struts.



On 9/10/05, Adam Hardy <[EMAIL PROTECTED]> wrote:
> Dakota Jack on 10/09/05 07:09, wrote:
> > I sympathize entirely with what you are saying, Murray, and believe
> > that there is no good reason for the present difficulties you face.
> > The situation is NOT inevitable or even desirable.
> >
> > I would strongly suggest you consider the Spring alternative which is
> > highly unlikely to change in fundamentals for a very long time.
> >
> > There is no vision here that is not willy nilly and merely fulfilling
> > some philosophical opinions about community which come down to
> > servicing the older committers' daytime jobs and reputatoins, in my
> > opinion.  They say that too, but I will guess that they don't want
> > anyone else saying it.
> >
> > Struts is a very unstable community producing inferior code at this
> > point with political infighting on a "nice" level to steal the name
> > for the latest and greatest old idea trying to claim to be very, very,
> > very new.
> 
> Dakota, can't you control your trollish instincts? There are far less
> contentious ways of saying what you said.
> 
> Since you are recommending Spring, can you answer a couple of questions
> about it? For instance, is there any outstanding improvement over struts
> in the patterns that it offers for say:
> 
>  * tiles
>  * breadcrumb menu
>  * taglibs
>  * nested beans
>  * l12n and i18n (prob: dropdowns)
>  * reference data cache
>  * dropdown data collections (Id & Label)
>  * DTOs to view mapping
>  * validator
>  * multiple commands on form submit
>  * cancel button
>  * post-redirect-get
>  * exception handling
>  * displaying messages
>  * security - Spring is based on Acegi right?
>  * transaction token
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-- 
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

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

Re: Who decides?

[Dakota Jack]

I really doubt that this writer is so lacking in insight as these
sorts of answers reflect.  Quite the opposite, assuming that the
writer knows this rather obvious sort of thing, the writer seems to be
pointing up a problem which this sort of answer seems to miss
altogether.



On 9/10/05, Larry Meadors <[EMAIL PROTECTED]> wrote:
> On 9/9/05, Murray Collingwood <[EMAIL PROTECTED]> wrote:
> > I'm just a humble Struts user (and relatively new), and I don't claim to 
> > speak for the
> > group as a whole.
> >
> > I have read through Donald Brown's presentation (Struts 1.3 and beyond) and 
> > I get the
> > feeling that the goal posts just don't stop moving.
> 
> Welcome to the world of technology.
> 
> I hate to be the one to break it to you, but the simple fact is that
> it changes.
> 
> Frequently and massively, and often times in a manner more like
> fashion than science (in contrast to Craig's response). Developers
> have ADD, and chase after every shiny object they see.
> 
> On the bright side, it is somewhat cyclical. When I finished school in
> the early 90's client-server VB apps were king. Next came the web. Now
> we are looking at fatter RiA (Vic's favorite flavor du juor!) and next
> we'll trim them down to make them run nicer on cell phones, then the
> phones will get beefier and we'll get back to fatter clients, then
> we'll trim them down to run on watches or chips embedded in our
> sunglasses or toenails.
> 
> Get used to it, try to predict it to some extent, and you'll do fine.
> If you are looking for a job that doesn't change...bad news: This is
> not it.
> 
> Larry
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-- 
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

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

Re: Who decides?

[Dakota Jack]

Again, there is no reason to think that the writer did not see this. 
This is a response that fails to address the problem by assuming (as a
"straw man" or a "red herring") with no evidence at all that the
writer was not aware of this rather obvious fact that people not even
involved in the IT community are well-aware of on a daily basis.  The
question was about the Struts community and not the writer.  The
writer should be aware from answers like this that something is amiss.

On 9/10/05, David Thielen <[EMAIL PROTECTED]> wrote:
> I was talking to my daughters about this the other day. In the last 25 years
> I have had to learn a whole new environment/API/everything:
> 
> * DOS - Pascal and then C
> 
> * Windows - C and then C++
> 
> oApplications
> 
> oSystem level code (wrote part of Win95)
> 
> oGames
> 
> * Java - EJB 1.0 & EJB 2.0
> 
> * .NET/C#
> 
> 
> 
> You don't get to stick with a single technology anymore. Like it or not, the
> world requires constant learning and constant movement to new tools and
> technology. Struts will be replaced by JSP/Shale and in 5 years (or sooner)
> that will be replaced by something else.
> 
> 
> 
> It's evolution at hyperspeed.
> 
> 
> 
> - dave
> 
> 
> 
> 
> 
> David Thielen
> 
> 303-499-2544
> 
> www.windwardreports.com
> 
> 
> 
> 
> 
> -Original Message-
> From: Craig McClanahan [mailto:[EMAIL PROTECTED]
> Sent: Friday, September 09, 2005 11:11 PM
> To: Struts Users Mailing List
> Subject: Re: Who decides?
> 
> 
> 
> ...
> 
> I'm afraid that this is the nature of the software developer landscape.
> 
> You've heard the term "Internet time"? That is the environment in which we
> 
> (as application architects) need to decide which technoogies to become
> 
> dependent upon. The gamble, of course, is that the lifetime of the
> 
> technology will correspond with the lifetime of the application you build on
> 
> 
> top of it. Sometimes you win, sometimes you lose.
> 
> ...
> 
> 
> 


-- 
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

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

Re: "javascript:void()" Problem

[Murray Collingwood]

You have too many nested quotes.  Take out the inner nested double quotes. Try:
show Form Value Key Names
I don't know if Struts will complain about this, I know it's not XML compliant 
but it might 
be the best you can do unless you write the url manually.

Also, you can prove the problem is not the href entry by changing it to 
href=#top or 
some other url string.  The javascript should then correctly identify the 
problem as being 
in the submitForm() function.

Kind regards
mc

On 10 Sep 2005 at 10:16, ojay78 wrote:

> 
> 
> HI, 
> What is with my a href wrong`? I tried several other solutions like 
> javascript:void(0) or 
javscript:; 
> but I get always a syntax error in the Javascript console. I tried it with 
> firefox, IE and 
avant 
> browser always the same failure
> 
> td class="button"> href="javascript:void()"onclick="submitForm('searchform', 
' action="showFVKNAdminView"/>')">show Form Value Key Names
> 
> Thanks
> 
> 
> 
> 



FOCUS Computing
Mob: 0415 24 26 24
[EMAIL PROTECTED]
http://www.focus-computing.com.au



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.10.20/95 - Release Date: 9/09/2005


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

Wrapping Struts tags in tag files

[Laurie Harper]

This isn't really Struts specific, but I'm trying to wrap some of the 
Struts HTML tags with tag files (in order to compose them into more 
complex 'controls') and I'm running into a slight problem... Some 
attributes are mutually exclusive (e.g. 'alt' vs. 'altKey'). I can't see 
a way to pass attributes through from the tag file to the Struts tag 
that works with this constraint. For example, if I write a tag file like 
this:


<[EMAIL PROTECTED] name="property" required="true" rtexprvalue="true"%>
<[EMAIL PROTECTED] name="alt" required="false" rtexprvalue="true"%>
<[EMAIL PROTECTED] name="altKey" required="false" rtexprvalue="true"%>
...


then, regardless of whether I set alt and/or altKey in the call to the 
tag file, the html:text tag complains that I can't specify both 
attributes. I've tried passing in the values using "${empty alt ? null : 
alt}" but get the same result.


Does anyone know a way to work around this (i.e. a 'correct' way to 
pass-through attributes from tag files to custom tags)?


Failing that, how big a deal would it be to change the Struts tags to 
treat the empty string equivalently to 'null' when performing these 
checks? [I'll happy put together a patch to do that]


L.


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

Re: Who decides?

[Murray Collingwood]

Hi folks

Firstly, please feel free to call me Murray (or Muz if you like to be 
informal).  Being 
referred to as the author makes me feel like I don't belongand I do.

I guessed that there would be a volley of responses to my email but I want to 
make 
Craig feel special because he didn't get all defensive in his answer - I 
appreciated that 
Craig.  I also want to thank Dakota who assumed (correctly) that I did know 
what I was 
talking about.

I've been in IT for 25 years and been through the mill of Pascal, Basic, C, 
Assembler 
(IBM/370), Easytrieve Plus, dBase, Java, Smalltalk, Javascript/DHTML and a 
myriad of 
proprietary programming languages (I'm sure you understand what I mean).  In 
1998 I 
wrote my own HTML pre-processor - at that time there was little knowledge of 
anything 
called JSP or ASP.  I have been using this technology for nearly 7 years. 

Interestingly my HTML preprocessor included simple functions like 
if-else-endif, nested 
includes, substitution tokens and a simple syntax that was consistent across 
the 
products - stuff I miss in Struts.  I also wrote the reference manual for using 
the 
preprocessor.  It was however proprietary and not feasable as an open source 
product.  
I have since sold this technology to a company and decided rather than writing 
another 
one I would hook up with a open source community project, and along came Struts.

I do understand the need to change technology every few years.  I have been 
using 
Struts 1.2.7 for just 3 months and am concerned that I should be now looking to 
learn 
JSF/Shale.   I know you will agree that changing technology after 3 months is 
not ideal, 
however when I started I wasn't aware that Struts had been around for 5 years 
already.  
I'm also picking up indications that these sub-projects (Shale, JSF, Ti, Tiles, 
etc) may 
become part of the Struts package one day - this is a good thing.

I am very happy to contribute towards the development of Struts (since Craig 
invited 
me) however I'm still kinda new so I might not be much use for a while.  So, 
here I am 
sticking up my virtual hand and asking "what would you like me to do?" as a 
volunteer 
does.

Some of the responses we have had indicate that 'committers' are making 
direction 
decisions rather than the PMC.  The role of the PMC is to control the project.  
It sounds 
from some responses that our 'committers' (some not all) have their own agendas 
and 
this is being accepted by the PMC.  As a volunteer (contributor) I should be 
doing what 
the PMC ask me to, otherwise they aren't "in control" and I'm not really a 
volunteer.  

SUMMARY
--
Maybe my view is a little altruistic or idealistic. I would like to see the PMC 
take control 
of the project and assign those tasks identified below (by Craig) to the 
volunteer 
developers that work on this project.

Craig, if there is anything from your list you feel I could have a go at, 
please send it my 
way.

Kind regards
mc

PS "Voting feet stuck perfectly where mouth is!" - attrib: me, just now



On 10 Sep 2005 at 9:05, Craig McClanahan wrote:

> On 9/10/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> > 
> > Craig McClanahan wrote:
> > > I hope you'll find my comments useful in furthering this kind of 
> > discussion.
> > > But I'm starting from a different place than you ... I personally think 
> > it
> > > is a waste of time to improve the tools and documentation support for a 
> > five
> > > year old architecture that is definitely showing its age.
> > 
> > Craig, I've heard you make this statement a couple of times... can you
> > go into some detail on where and how Struts is "showing its age"?
> 
> 
> Here's a couple of things that (had we known then what we know now) would 
> very likely be different -- and areas where I think improvements would be 
> helpful:
> 
> * Actions as stateless singletons, instead of per-request instances
> 
> * Form beans (should have done it the way WebWork does)
> 
> * Extensibility of request processor (getting fixed in 1.3)
> 
> * Action chaining is messed up.
> 
> * Decorating actions (a la Spring MVC or WebWork or Tapestry) is missing
> 
> * Expression language syntax (based on BeanUtils) is way too limited
> 
> * Totally dependent on Servlet API objects, making (a) unit tests hard,
> and (b) implementations on portlet difficult
> 
> * Key functional areas (such as Tiles and Validator) can be
> pretty obtuse to configure
> 
> * No model of user interface components -- just hard coded HTML rendering
> 
> None of these things are totally unusable -- but they all need improvement.
> 
> Craig
> 



FOCUS Computing
Mob: 0415 24 26 24
[EMAIL PROTECTED]
http://www.focus-computing.com.au



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.10.20/95 - Release Date: 9/09/2005


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

Re: AW: AW: Who decides?

[Frank W. Zammetti]

Assuming I too did not misunderstand, which certainly is possible, that 
sounds about right based on the last time I looked at doing it (this has 
been something that has been discussed for as long as I can remember). 
Although, I don't remember it being even *that* complex :)  But, it's 
been a while since I looked, and the underlying point is what's 
important: instantiating an Action on a per-request basis no longer 
carries the performance penalty it used to (from what I have heard... 
can't say I've verified this myself), has some benefits that people 
would probably appreciate, and changing the current codebase to do it is 
pretty close to trivial, regardless of how one decides to actually 
implement it.


Frank

Leon Rosenberg wrote:
 




-Ursprüngliche Nachricht-
Von: Frank W. Zammetti [mailto:[EMAIL PROTECTED] 
Gesendet: Samstag, 10. September 2005 18:47

An: Struts Users Mailing List
Betreff: Re: AW: Who decides?

Leon Rosenberg wrote:

I think they 'de facto' are stateless singletons? I mean the 
controller only creates one instance, and you shouldn't 


create another 


:-)


That is how it currently works, and Craig has in the past 
explained the decision.  It made perfect sense 4+ years ago 
when he first wrote Struts, on the basis of performance.  
Modern JVMs make those concerns no longer true though.


If an Action was created per request, you could do some 
things that you can't do now, like non-static class members.  
This would not be a huge change to the Struts codebase (at 
least, that was my conclusion when I thought about it some 
months ago and looked at the code), but would open up a lot 
of nice possibilities.




Hmm, ok, than I must have misunderstood him. Nevertheless, aren't we talking
about a virutal three-liner here, which works with existing code as well?

Interface ActionCommand{
 public ActionMapping execute(...);
}

Interface ActionCommandFactory(){
  public ActionCommand createCommand();
}

And then a basic action:
CommandEnabledAction extends Action{
  execute(...){
 ActionCommandFactory factory = lookupFactory(...);
return factory.createCommand().execute();
  }
}

Now implement an extension to the config to specify a factory, and you are
done, aren't you?


Regards
Leon


One could go even further and quite easily add the ability to 
specify scope for an Action, so you could put them in session 
if you wanted. 
Then, combining your ActionForms and your Actions would be 
trivially easy... and hey, that starts to look a lot more 
like JSF/Shale, doesn't it?!? ;)



* Totally dependent on Servlet API objects, making (a) unit tests 
hard, and (b) implementations on portlet difficult



I think it's the nature of a http framework?


Not to speak for Craig, but if I understood this point 
correctly, the idea is that right now there are a number of 
places where request/response/session are passed around 
directly and accessed directly.  A layer of abstraction 
between those places and those underlying objects would make 
unit testing easier.  I can't speak on the portlet point, but 
I take his word for it.


In 1.3, at least as far as the request processor chain 
commands go, you get a single Context object (ActionContext I 
think?)  If your Actions also recieved that object only, and 
there were methods that you called instead of directly 
accessing request/response/session, you'd have that abstraction.


As per my previous post, you could do all of this with the 
current Struts code base... well, the single Context thing 
would be a little more difficult because you couldn't replace 
what an Action looks like now without breaking backwards 
compatibility, but probably it can be done *in adddition* to 
how it is now.




Regards
Leon


Frank


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







--
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: Who decides?

[Frank W. Zammetti]

Ted, I read what you wrote here with interest.  I consider myself a 
champion of backwards compatibility... in fact, within the past month I 
recall being involved in a discussion thread here where I seemed to be 
the only one saying backwards compatibility should not be broken, within 
the context of that discussion (which, to be honest, I do not recall :) 
).  I completely agree that it is an important consideration always.


What I infer from what you wrote, and please correct me if the inference 
is not accurate, is that the milestone of breaking things out into 
subprojects could in essence serve to open the floodgates a bit... 
meaning, maybe the committers will be more willing to entertain some 
ideas that they may have previously passed on once that reorganization 
is complete and "in the wild" because it will theoretically be easier to 
do them then.  Is that a fair assessment?


If so, I for one look forward to the 1.3 release even more than I did 
before :)


Frank

Ted Husted wrote:

On 9/10/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:


Over the past few months there have been a number of people who have
attempted to evolve Struts to "catch up" in some ways with what other
frameworks are doing.  They have been turned away, sometimes for
obviously legitimate reasons, sometimes for more debatable ones.



Usually, the problem has been retaining backward compatibility. When a
suggestion breaks backward compatibility, we tend to pass, at least
until we can setup a deprecate/ remove/ release cycle. Since this
cycle can take a year or more, some people drift away before we can
implement a suggestion.

Some suggestions have been out of scope, mainly for the taglibs. Along
the way we decided that the original taglibs should stick to the HTML
4.1 specification. Some taglib suggestions are non-starters because of
the product's scope.

The big fix for both of these problems, and several others, is to
subdivide the one-size-must-fit-all Struts distribution into
subprojects. If a suggestion is not backwardly compatible, then
perhaps we can make it an optional component in the Extras subproject.
If a taglib is not HTML 4.1 compliant, then maybe we can start another
taglib subproject.

But, until last month, we simply didn't have the infrastructure to
even consider such things.

Another problem is being sure that there be someone around to maintain
the code. We like to see broad enough support for any suggestion to
ensure that there will be at least three people around who will
support the code. It doesn't matter if comes from a developer or a
committer. A lot of suggestions from committers die on the vine
because too few people seem interested.

Many folks don't realize that extensions we now take for granted, like
Validator and Tiles, were being used in production applications for
*years* before we added them to the distribution. (I used both myself
in April 2001, before Struts 1.0 final.)

In the same light, I expect we will see an Ajax subproject for Apache
Struts one day. But before that happens, we'd like to see broad
support for Ajax among Struts users. Then, we can be sure there will
be committers around to support the subproject later.

As it stands, we are just now completing tasks we planned *18 months*
ago. But, we are completing them, slow and steady.

In fact, I remember Don Brown making the first "subproject
reorganization" commits at ApacheCon 2004 last November. Martin and I
were sitting at a table with him at the Hackathon, jovially giving Don
verbal +1s. :)

Ten months later, we're finally at the point where we can build and
distribute the original Struts subprojects, along with the new kids on
the block, Flow, Scripting, and Shale.



Everyone seems to want to go off and create something entirely new when
I haven't seen a single good, concrete reason why Struts as it exists
today can't be evolved.  Why?



It *is* being evolved. It's just that evolution takes time.
Personally, I still fully intend to walk down the Struts Classic
Roadmap that we posted over a year ago. We're just now hitting the
first milestone: subprojects. We hit this one, and we'll hit the
others too.

* http://struts.apache.org/roadmap.html

Meanwhile, exploring alternatives like Ti can be good for Struts
Classic too. Like as not, there will be techniques used in Ti that we
can retrofit to Struts Classic. And, perhaps, one day, they might even
evolve into the same product. Or not. At this point, Ti is still
hypotethical.



Many of the things that people claim to want in a modern framework I
have either myself done or seen done with the current Struts codebase.
Things like components that remember and render their own state ala JSF,
a simple managed bean facility (IoC), built-in AJAX support, something
akin to a prerender facility, the work of Michael Jouravlev, all of
these things have been done in Struts, so clearly it is not a case of
Struts not being expandable or "fixable".  Why is there so much seeming
resist

Problem with Validation of Struts DynaValidatorForm

[Weng Kong Lee]

Hi all,
I've just started exploring the use of Struts DynaValidatorForms. I've
tried to set-up a very simple login form with a username and password
fields, where both are required. Here's the relevant details:

1. struts-config.xml
The application message resource bundle has been configured with the
required validation messages for the validation framework, and the
validator plugin is also declared.
I declared a form bean as follows:
form-bean
name="loginForm" type="org.apache.struts.validator.DynaValidatorForm">




Then I declared a action tied to the form bean as follows:

  
  


2. login.jsp
This is the JSP with the form. It uses both client and server-side
validation.The code is as follows:



  

  Login:
  


  Password:
  


  

  




3. validation.xml
I declared both the "userName" and the "password" fields to be
"required", as follows:











4. Action class, LoginAction.java
Here's the execute mehod implementation. Basically, it rejects the
login when the userName and password are not both "test".
public ActionForward execute(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse 
response) {
DynaValidatorForm loginForm = (DynaValidatorForm) form;
String userName = loginForm.getString("userName");
String password = loginForm.getString("password");
if ((userName == null) || (!userName.equals("test"))) {
return mapping.findForward("failure");
} else if ((password == null) || (!password.equals("test"))) {
return mapping.findForward("failure");
} else {
return mapping.findForward("success");
}
}

I then tried to test the above by deploying the application, hitting
login.jsp and attempting to login with invalid userName and password.
The Javascript validation works fine, and the messages display
correctly => The message resource is configured correctly.

However when I turned off Javascript on my bowser to test the
server-side validation. The validation did not take place at all! If I
supplied a blank userName and/or password, it simply performs the
logic in LoginAction and sends me back to login.jsp, without any error
messages!

Anyone has any ideas what I might have missed out here?

Thanks in advance for any suggestions!

Weng Kong Lee

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