Re: OT: Struts JSR?

[Vic Cekvenich]

Lets take the leads of Sun, JCP and Jakarta  at their word, for a 
second and then add my .02: If JSF is positioned as better than 
Struts (or Spring or WebWork etc.) then I personally would rather use 
other platforms entirely and I am on my way moving in that direction 
for a few months now, porting bP, etc.

.V

Nadeem Bitar wrote:
Since there is an overlap between struts and jsf, I highly doubt that
Struts would be accepted as a JSR. 

I already expressed similar concerns regarding struts being replaced by
JSF. I believe the open source community works faster than JCP and if
struts want to be remain competitive and still be considered the defacto
java web application framework, the struts developers need to address
the concerns raised with the current struts architecture and deliver the
next generation application framework that would silence struts
critiques and improve productivity of struts developers.
Struts 2.0 roadmap already have very good points but the timeframe of
the availability would be critical for the future of struts.
If for example JSF 2.0 is available, and Spring Framework is well
integrated with JSF before Struts 2.0 is available, I strongly believe
that struts won't have a place and would lose market shares. 

Spring 1.1 would offer amazing enhancement (JMX managed beans. JMS
support, Command framework, Swing support for rich clients..) and an
excellent architecture to build complex applications, combining that
with JSF component model would offer a very strong framework that's hard
to match. 

On Fri, 2004-03-19 at 21:14 -0500, Thomas L Roche wrote:


David Geary spoke on JSF at trijug.org M 15 Mar 04. My notes of 
his remarks include

- Is JSF a replacement for Struts? Yes!

- JSF is a standard. Struts will never be a standard.

which I believe to be pretty-nearly-direct quotes. I'm assuming he
really meant
+ JSF 1.0 can do pretty much everything Struts 1.1 can.

+ JSF is a JSR, and Struts will never be a JSR.

but I'm wondering about that last statement. What prevents Struts
from undergoing the JCP? Are there circumstances under which you
might consider this?
-
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]

OT: MVC in NYC- 4/3

[Vic Cekvenich]

If any open source luminary is in town for the MVC seminar in NYC on 4/3 
that I am posting, of course they would be free, just RSVP.

.V

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

1.2.0

[Vic Cekvenich]

Is there any news on 1.2?
.V
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Proposal] ActionFactory refactoring

[Vic Cekvenich]

Don Brown wrote:
 It would take probably a few hours
to code so little effort is "wasted" when the struts-chain move takes
place.
I think that is the key at the end of the day. I think it be more 
effective the few hours be spent on integrating IoC into 
struts-chain but I do not need to remind anyone I am not a commiter, 
and even then each comiter can commit what they please, but I would 
rather see a design of IoC in CoR. If CoR already does digester, it 
can't be to far away from some level of alpha. I think it easier to work 
with a clean sheet of paper, but your preference, thanks for contributions.
Maybe if there is a way to create a commons-IoC-api of interfaces that 
could be implemented as Nano, Hivemind, etc.  and  I duno.

.V



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

Re: [Proposal] ActionFactory refactoring

[Vic Cekvenich]

So here are comments:
- I like IoC idea!  I prefer Nano, Hivemind or something else Jakarta 
based. I have been using HiveMind on projects and it is very nice.
- I do not like any kind of factory. It's harder to teach and maintain 
then just new(). Factory and pool had it's place in JDK 1.3, but a new() 
is not bad in 1.4. Besides we know the type of object is comming, so no 
reason for factory, it would just add complexity.
- I like what Struts chain does, it's simple and clever and it shows 
people how to create their own custom action that extend base action 
with the user base. That should be the starting point and improvments 
should be based on it, IMO. For example, calls from there to IoC. An IoC 
DAO that populates a XMLFormBean Document. Digester could be called via 
IoC from CoR. I kind of think IoC is something users should do as calls 
from Strut's CoR. I do have a question if struts chain already reads 
digester or there is code someplace that does it or if I want to play 
with it I have to read mapping by myslef?

.V

ps: 2.0 wish: Call a use case implemnetation a "bundle", same as other 
light weight service implementation.

Don Brown wrote:
What if we extracted the creation of Actions and ActionForms (including
DynaActionForms) into an ActionFactory, overridable by the user?
Here's the problem as I see it: there is no simple way for a user to plug
in their own code to manage the creation of actions and action
forms.  The actual creation is handled by static methods in
RequestUtils, obviously not overridable, leaving the only option to
extend RequestProcessor and duplicate a lot of logic.
Why would you want to plug in your own ActionFactory?  My primary purpose
is to better integrate Inversion of Control (IoC), specifically Spring's
IoC, into Struts.  By letting Spring create Struts objects, Spring can
handle any dependencies and configuration they need.  Another use, as
stated in bug #23583
(http://issues.apache.org/bugzilla/show_bug.cgi?id=23583), could be a
factory that creates ActionForms using JavaAssist at runtime.  Finally,
this factory would be an easy way for the user to create their own
DynaActionForms, particularly useful for unit testing.
Impact: This would have no impact on current Struts applications as it is
an internal refactoring and default behavior would remain the same.
Extensions that include custom RequestProcessors or interfere with object
creation might be affected.
Configuration: I'd recommend another attribute in the 
element in struts-config, possibily named "actionFactoryClass", pointing
to the new ActionFactory implementation to use.  If none specified, a
default factory which mimics current behavior would be used.
This is my proposed interface:

public interface ActionFactory {

	public Action createAction(ActionServlet servlet);

public DynaActionForm createDynaActionForm(ActionServlet servlet,
   FormBeanConfig config,
   ActionConfig mapping);
public ActionForm createDefaultActionForm(ActionServlet,
  FormBeanConfig config);
public ActionForm createActionForm(ActionServlet servlet,
   FormBeanConfig config,
   ActionConfig mapping);
}

Note createActionForm() creates either a DynaActionForm or ActionForm
depending on the config.
Comments?  Obviously, I'd perform the refactorings if this feature was
agreed upon.  Future targets for factories could include config objects:
http://issues.apache.org/bugzilla/show_bug.cgi?id=13638
Don


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

Re: Struts 2 (Was PMC?)

[Vic Cekvenich]

Vic Cekvenich wrote:
I would like to recall this part of a message.
I am wondering if I was to develop a strawman of the 2.0 wish list w/ 
IoC, XMLFormBean, etc. if ANY committer would look at it with me, or if 
it be a waste of time for me.

.V
I just saw code in Struts chain
AbstractExecuteAction implements Command 
I like a lot how it can work w/Catalog and all.  I can't code that!
Only wish is... IoC (HiveMind or Nano).
.V

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

Re: Struts 2 (Was PMC?)

[Vic Cekvenich]

Craig R. McClanahan wrote:



So, do we invite the non-Java implementations of the same concept in, or do we
say "nah, we're a Java project?"  I'm not personally much interested in the non
Java solutions, but a cross-language framework would be somewhat unusual.
Craig

It may be interesting to keep an eye out when developing interfaces as 
to how C++, C#, PHP could reimplement the same "UML".

I am wondering if I was to develop a strawman of the 2.0 wish list w/ 
IoC, XMLFormBean, etc. if ANY committer would look at it with me, or if 
it be a waste of time for me.

.V

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

tests

[Vic Cekvenich]

As far as I can tell the test themselfs are borken, why not just junk 
them. I am all for testing as religion, but I wonder if the test are 
worth the trobule in this case?

.V



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

Re: [VOTE] 1.2.0 Release Plan

[Vic Cekvenich]

I am now testing nightly and sample wars for what it's worth.


All wars work (once over lightly).
Somone did a nice job on localizing validation war.
bP works (which uses jstl 1.1, struts menu 2.1, etc.)
-Validation example complains in console about 
-I wish most excetions were logged w/ e.getCuase() and not the entire 
trace to fill up the console.
-Also Tomcat complains about formbeans not implementing seriaizable 
marker for sesion scoped beans. (My baseBens does mark it as 
seriazable... it's not. To me, that is a Tomcat bug, it should just be a 
low level info log, becuase Resin does not care. Serializing beans for 
fail over in container is not a good idea imo, DAO's can do it nicer 
outside of the container's limitation)

So one minor error, 

.V

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

Re: [VOTE] 1.2.0 Release Plan

[Vic Cekvenich]

Robert Leland wrote:
Ted Husted wrote:

OK, here's what we have




I would say release, we are using a x.y.z numbering scheme.
Noteing in the limited release that this should be considered an Alpha
until further testing says otherwise. Also to ask others not to announce 
this on other lists
until it has been voted Beta/GA or better.


Side effect is that this is a great way to introduce 1.2.0 to users as 
... it's released like Tomcat releases, but not really designated, and 
not released like 1.1 was with beta, rc1

I am now testing nightly and sample wars for what it's worth.

.V







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

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

[Vic Cekvenich]

Don Brown wrote:
With Struts 2.0, we have a chance to
look at Struts best practices, other web frameworks, and current
technologies to design Struts to be the best and easiest framework for
web applications, and perhaps beyond. 
I hope it's more of a revolution than evolution, it be more fun, look at 
everything that is new and practical.

 My point is we should look at
whether to encourage through Struts design and documentation the
combination of forms and actions, or keep the current design. 
My view... is that it's not a good idea to have Action and FormBean 
combined. MVC should be seperate in "best" practice.
A similar is multiple form beans.. I think one nested bean that matches 
the form and can be unit tested is better.

.V



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

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

[Vic Cekvenich]

repost (it seems that Gmane loses some msgs)

I was going over samples in Oscar, and found a good paper (mentions 
Avalon) on a  futuristic framework called Gravity, maybe you like ideas:

http://www-adele.imag.fr/BEANOME/papers/CervantesHallCBSE2003.pdf

.V




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

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

[Vic Cekvenich]

Craig R. McClanahan wrote:


There's a couple of variations on the theme that are possible, but I can think
of at least three layers of something that might be called a "form bean" in the
conceptual sense:
(1) A set of typesafe field names and corersponding values
where the application doesn't have to worry about maintaining
values across requests.
- Variation:  dynamically add and remove fields as needed
- Variation:  allow non-typesafe fields
- Variation:  allow fields that can have multiple values (arrays)
- Variation:  represent data hierarchically instead of just
  a name-value map (bean properties, nested expressions,
  XML DOM, what have you)
(2) The above plus a mechanism to define validation rules (correctness
checks) on the field values that are independent of physical
presentation
- Variation:  hard coded logic for validations (i.e. the original
  validate() method in Struts ActionForms.
- Variation:  pointer to a configured set of validation rules
  that is abstracted from presentation considerations.  

(3) All of the above plus event handlers for UI events that change
the state of the field values -- perhaps in the same bean,
perhaps somewhere else.
A type (1) or type (2) form bean is really better thought of as an abstract way
to pass the input data for some sort of business transaction between tiers, or
within tiers.  A type (3) form bean would definitely live in the presentation
tier, and not be used between them.  For all three of the cases, though, we
probably want to invent a different term than "form bean" because that seems so
conceptually tied to presentation only.  Transaction Bean?  Input Bean?  Data
Transfer Object :-)?


Can't it be just one good old View layer "thing" that maps the 
properties and it's still called formBean? KISS

Don did not link XMLForms good, here are better links for a real fun read:

http://webservices.xml.com/lpt/a/ws/2003/01/29/cocoon-xforms.html

http://www.cocoonhive.org/xmlform/index.html

I like that Pico is lightest IoC and do not see a need for a Bean 
Factory, etc.. So there should be some talk of Spring vs Pico.

So far, if it's built on top of
-IoC
-with "XMLFormBean" (as option, since XML can be slow right now, so it 
needs to support backward compatible FormBean)
-an execute(context) Action iterface,
-chain request procesor filter interfaces
-HTML tag to support XML Submit (including multi row)
-JDK 1.4
-Clear testing interface to major user components.

That could be the broad stroke major center pieces. It is same design as 
Struts 0.6 with each component refactored, same diagram.

There are several smaller pieces, but if Struts can stay light without 
too many moving parts, better, people can put arms arround it.
XML config wishes:
- all xml files be able to extend like tiles, like in Validator
- move form beam declaration section to validator, no need to do it 2 times.
- move all tiles xml to struts config, and get rid of tiles.xml
- have a forward to a tile declaration allow you to name the "base" 
definition and tile to replace, even maybe have tile part of "* forward" 
or what ever Don's thing is called.

I still kind of think maybe DAO interface should be there, we learned a 
lot about DAO since.

(I still think one or 2 people should do it in 48 hours from start 
else... it's design by comittee)

.V









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

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

[Vic Cekvenich]

Ted Husted wrote:
The "dynamic field" use case comes up all the time, but I have trouble 
getting my head around it. What would be helpful would be a example 
application that people could play with.


And making it that dynamic defeats testing and layers.
I am not aware of even Client Server uses cases for dynamic fields.
Simple example: A report for Jasper and SQL.
If you have diferent sql fields, it's a diferent report.
Struts example: Clients give you a mock up of a view somehow, you then 
know the fileds on the view, you know the formbean properties. (and then 
implement a DAO to CRUD the formbean "contract")

So dyamic fields I think should be in the 20% not to be done by core 
Struts.

.V



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

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

[Vic Cekvenich]

Craig R. McClanahan wrote:

One of the things people have said they liked about using a chain to decompose
RequestProcessor is that you could easily compose your own chains, adding your
own custom processing stages and so on.  You can do exactly the same thing with
Filters by making each processXxx method its own filter, and using (say) the
request attributes to play the role of the Context object in commons-chain.
Filters have an additional capability if you're building a servlet-specific
framework -- they can wrap the actual request and response objects that are
passed on to the next filter in the chain, so you can implement some
interesting things not directly possible with a chain based implementation --
such as caching or on-the-fly compression of the response.


Craig
I do not get chains, but Hookom posted this link:
http://java.sun.com/blueprints/corej2eepatterns/Patterns/InterceptingFilter.html
which I sort of get (sort of) and it's my favoirte chain impl.

So if we can use filters or other chain, somone clever could write an 
"chainRequestProcessor" *interface*, that could be impledented for 
JSP2.0 filter... and then somone else could later write a JSP 1.2 
version, even non filter versions.

?

So I like chain as interface, and action as interface.

I am thinking of fliping sides on FormBean as interface, I am now 
leaning against formbeans being an interface. FormBean is a concept 
(properties that map to form elements), plus this idea of XML as a 
FormBean. It could be a List or String or anything. As long as it itself 
does not do DAO, and it maps to a form, good. (but do have way to unit 
test it w/o a container)
For starters so the JSTL x: tag can be used instead of c:out, plus some 
Stxx things.
(Then maybe a way to make HTML tag submit XML Doc, multi row and all).

.V





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

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

[Vic Cekvenich]

Martin Cooper wrote:



I think I need to elaborate on my thoughts some more, since I wasn't
really clear the first time around...
A great deal has happened in web application framework land since Struts
came along 3-1/2 years ago. 
new technologies:
bytecode manipulation
IoC
SOA
filters
xml (XML Beans?)
AOP (just to list all)
Oscar
Unit Testing
scripting (including client javascript)
XML-RPC (not really new, just I like )
JDK 1.4 (interesting quirk: should jericko use the poor JDK logger? 
Maybe, but it's poor.)

Some can be leveraged... others do not apply.


So, what makes Struts Struts? What characteristics do we need to preserve
in order to keep it Struts, and retain the greatness that has made it so
amazingly popular? 
My answer is:
-light weight. If "jericho" is bloated, then IMO it fails.
-formbeans. The concept that bean properties correspond to a (html data 
entry) form. (thinking outside the box: maybe a XML Document that maps 
to form properties can also be a form bean in Jericho).
-it had several clear extension points
And what it did not have:
- A DAO. Many popular frameworks of the day went down with their DAO.

It was a minimalist framework, that did 80% of what you need and it did 
not get in the way when you wanted it to do things it was not designed for.

Therefore, one person needs to write most of Jericho over a single 
weekend and not try to please a committee, just their own business 
application and do initial check in! :-)

Lets not forget validation, btw. it should not be an after taught. Keep 
same? yes.



.V

"perfection is achived when you have nothing left to remove"
by Saint something or other


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

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

[Vic Cekvenich]

Craig R. McClanahan wrote:
Regarding 2.x, an important consideration will be base technology platforms --
I'm in favor of using J2SE 1.4 and the relevant standards from J2EE 1.4 (i.e.
Servlet 2.4 for web applications, JSP 2.0 if you're using JSP as the
presentation technology, etc.).


JDK 1.4, yes.

One popular? goal mentioned was:
"Get away from reliance on Servlet API"
I like being on Tomcat 4.
What does it gain to be Tomcat 5 technically? What containers support 
2.4? How long for users to convert to the new 2.4 containers?
It'd be limiting.

If it ends up being interface, so it could be even used from Soap or 
applications (the discussed interface execute(Context ctx) ; ) it won't 
matter much.

.V

ps: I would like light IoC to be considered just a bit more as platform, 
Pico, Oscar. Not Spring or Avalon.



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

Re: Ideia

[Vic Cekvenich]

Martin Cooper wrote:
On Thu, 18 Dec 2003 [EMAIL PROTECTED] wrote:

Creating one definition of each target is hard work  (this is true when
using extension too), because most of pages of a module works on the same
page layout.


It's not "hard work" at all if you make use of 'extends'. ;-)

--
Martin Cooper


If there is a way to *not* have to create a definition just to change on 
tile...
and maybe combine it to Struts config so the * mapping can be used.



.V



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

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

[Vic Cekvenich]

public ActionForward someStateAction( 
 org.apache.commons.chain.Context  context,
 some.generic.request  request,
 some.generic.response response );




Why not just KISS and
 public ActionForward someStateAction(
   org.apache.commons.chain.Context  context );
It can *all* go into context(or a Map!!!), else we have the 
tilesAction 
execute signature.

I can allways do a
map.get("request")
This would work for SOAP or other protocols.

.V


Yes I agree KISS is better, Vic. It is better by the design.
Maybe you can be person to announce to the Struts 1.0
1.1 user base that all of their Actions are now invalid, they 
wont compile for Struts 2.0 because you need to upgrade ALL 
your state methods to get HttpServletRequest and 
HttpServletResponse and ActionForm and ActionMapping 
from the Chains context.

Both above method signatures above are not compatible!

But you could have a base class:

execute(context) {
execute(context.getReq(),context.getMapp(),...
}
You could go the other way too, not at the same time

execte(req,resp,mapping,the4ththing) {
context = new Context();
context.setReq(req);
context.setMapping(mappping);
execute(context);
}
This is sort of what I do now in bP
So it can be compatible.
Beside, we had perform and excute once, so users know.
Also, I imagine a long road to 2.0, people will be using nightly build 
for a while that only has the new stuff.

.V



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

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

[Vic Cekvenich]

 public ActionForward someStateAction(
   org.apache.commons.chain.Context  context );
It can *all* go into context(or a Map!!!), else we have the tilesAction 
execute signature.

I can allways do a
map.get("request")
This would work for SOAP or other protocols.



I was going to add:
This lets people "store" and pass additional info.
Else they start putting properties in action (not thread safe).
Maybe Struts 2.0 should have an action implemenation that gets 
instaciated every user session (it should not be used but... it exposes 
the issue).

.V



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

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

[Vic Cekvenich]

In terms of new functionality, the three biggest fish I'd like to fry 
are Workflow, SSL, and Unit Testing. Towards that end, I'd like to 
consider integrating LivingLogic's Workflow, ssl-ext, and Struts 
TestCase into the Struts 2.x development stream. We may also want to 
consider adding these as standard options to Struts 1.x, so 
as to blaze 
a trail.


I aqgree that DAO should be outside of Sturts.
I do not think Workflow should be inside. Becuase I do not think it is a 
good practice. It may be needed by some people... as a plug in.


Integrating StrutsTestCase would help with the Unit tests,
although it will have to be heavily modified in parallel
to keep up with changes in development. 

I also do not think testing should be insdide. There are many that look 
into JVM, into container's JSP, etc. and people should inovate.
I use OpenSTA, becuase I want to see what happens under load.

However... Monitoring and Managing the application while runing in 
production maybe should be included. Ex: Jamon.
I used it, and it's great.
I works similar to log4j.
Or at least it should be documented.
In days of ClientServer, 3 tier ment:
Data Layer, Presentation Layer and Managment Layer.

So you no longer going to pass in request and response objects
around, but instead have a context instead. Maybe it would
be a little inconvenient for every Action to call 
``context.getRequest()'' all the time. Perhaps we can keep them
please. I dont mind losing the form bean. I could live with
``context.getForm()'', because for some environments you dont
need to buffer a user's input. e.g. web services, or even 
a flat file.

public ActionForward someStateAction( 
  org.apache.commons.chain.Context  context,
  some.generic.request  request,
  some.generic.response response );




Why not just KISS and
 public ActionForward someStateAction(
   org.apache.commons.chain.Context  context );
It can *all* go into context(or a Map!!!), else we have the tilesAction 
execute signature.

I can allways do a
map.get("request")
This would work for SOAP or other protocols.

.V



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

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

[Vic Cekvenich]

The BeanWrapper and the BeanFactory are interesting ideas.
An example of configuring commons DBCP is given
http://www.springframework.org/docs/lightweight_container.html
I am not convince however of the requirement for BeanFactory.
I can understand if you need to have massive XML configuration
and need to dynamic generate Beans (objects) at run-time.
It is great but other than that I can really view to the
advantage inverse of control there that Struts or Commons BeanUtils
combine Digester could not do itself.
I like this for beans:
www.joda.org
Wow!
It would get rid of a lot of questions on the user list.
(This man wanted to go ASF)
Struts is great because it concentrates on doing one thing well MVC.
I wouldn't want it to branch out go into a generic framework space
e.g Avalon, Expresso, Keel, Spring, Pico etc.
But maybe  build Struts on top of Pico or similar 
(http://oscar-osgi.sourceforge.net) or hivemind or...

See if we pick high level light interfaces and use "generic" jars like 
now, it could be done quick like, and fund, since code would be done at 
a bit higher level.

(And maybe WebWork or Spring or  implement our MVC high level light 
interface.)

.V



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

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

[Vic Cekvenich]

David Graham wrote:
--- Vic Cekvenich <[EMAIL PROTECTED]> wrote:

And even a simple DAO interface, to be used optionaly be people, so 
they can go back and forth from iBatis to Hibreante or what ever.


I started the Mapper project in the commons for this exact reason.  It
doesn't belong in Struts.
http://jakarta.apache.org/commons/sandbox/mapper/

David


I like the goal.

Thanks for the link, I looked at it but my idea was more of a utra 
simple CRUD DAO interface, taking Collections or XML as arguments. .. 
following the Sun DAO patern (what most people do) but simpler.

ex:
public interface OptionalDAO {
Document retrieveAsXML(Map arg); // so people can implement a DAO that 
executes a retrieve any way they please.
List retrieveAsList(Map arg);
boolean saveXML(Document arg); // so people can implement a DAO that 
saves any way they please.
boolean saveList(List arg);
void beginTran() ;
void endTran();

along those lines.
.V


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

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

[Vic Cekvenich]

Martin Cooper wrote:

* Make the Struts core independent of the Servlets spec  
Above is my favorite wish!

I would like to be able to call an Action via XML-RPC for it to give me 
a FormBean and for me to give it a FormBean back. (or any other 
SOA). There was a few threads of SOAP Struts some time back.

And... maybe a FormBean is an XML DTD.
(Like .NET stuff, and iBatis 2.0 _sqlMap.getXMLResult())
This way a view can render it (such as core tags X: ) any way it wants. 
Ex: from javascript you call XML-RPC to get a XML (multirow bean)

And even a simple DAO interface, to be used optionaly be people, so 
they can go back and forth from iBatis to Hibreante or what ever.

And build Struts on top of HiveMind or similar. (IoC and Services... and 
XML).

If just the MVC interfaces are defined, then several implemenations can 
ship. One implemtation would be backwards compatible.
Once could be SOAPActionImpl.

Action's execute should take a Map as signature argument. This way we do 
not have Req/Resp tie in, but anything comes in.
Ex: execute(Map arg)  { .. }
A good 1st step is to have a TilesAction and Action have same signature 
for execute.

.V



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

Re: [VOTE] 1.2.0 Release Plan

[Vic Cekvenich]

Ted Husted wrote:
. If someone were up for sheparding the tests, especially the
example application testing, 
If testing example apps, means not much more than see if the war files 
work and browse it, I will do it. (of course some of them had problems 
before, like tiles example, but not sure what, like broken links, but I 
will test ). I would rather not learn Cactus, etc.
Tell me when to plan.
I might do it anyway, with a nightly build, and also test it in my bP, 
that nothing is broken, and will send a mail to the dev list.

Is the nighly build very similar to 1.2 so some can happen now?

.V



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

getDataSource deprecate

[Vic Cekvenich]

Consider if it be good idea to sometime in the future mark getDataSource 
as deprecated.

.V



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

Re: Should Struts ship with all of the commons jar files needed to get Struts datasources working?

[Vic Cekvenich]

Hello Rick,

They are deprecated; targeted for removal; and for a good reason, since 
it's a bad practice to have a data source served by the web app., a 
container provides a data source. In esence, maybe legacy jar should not 
be included any more, it has been a while since 1.1 released.
There is to much talk about data connection's as it is on user.

(I wish more be taged as deprected :logic/bean, since in the future... 
they will be and there was a comment on dev list that no one is keen to 
patch, so just give users a signal )

.V

Rick Hightower wrote:
Currently 1.1 does not ship with commons jar files needed to get Struts
datasources working.
 

You need booth commons-pooling and commons-dbcp to get Struts Datasources to
work, but they are *not* included with Struts 1.1. (In fact in Struts 1.1.,
you also need Struts Legacy jar file as well.)
 

I think this got through because if you are using Tomcat then both
commons-pooling and commons-dbcp ship in the shared folder. You do need to
download them if you are using another application server. You do need to
download them only if you are going to use Struts Datasources. My
understanding was that Struts would ship with the entire set of commons jar
files needed to utilize all of the features of Struts. Are Struts Datasource
EOL or something?
 

 

 

Rick Hightower

Chief Technology Officer

ArcMind

Know the Next!

http://www.arc-mind.com  

 




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

Re: cvs commit: veto

[Vic Cekvenich]

I promise to *try* not to comment on this issue on any public lists, it 
really is up to the members. I support Struts, Apache and Open Source!!

.V

Ted Husted wrote:

-1

The community can make up its own mind on issues regarding an 
individual's behavior.

I formally ask that any product changes made for the sole purpose of 
censoring an individual be reversed, with the exception of consultants 
and powered, which pages can be removed completely as they are obsolete.

-Ted.

[EMAIL PROTECTED] wrote:

craigmcc2003/11/11 13:23:32

  Modified:contrib/struts-faces build.xml
   doc  learning.xml using.xml
   doc/faqs kickstart.xml
   doc/news news_2001.xml news_2002_q2.xml news_2002_q3.xml
news_2002_q4.xml news_2003_q1.xml 
news_2003_q2.xml
news_2003_q3.xml
   doc/resources archives.xml consultants.xml powered.xml
sigs.xml
  Log:
  Vic Cekvenich of BaseBeans.com has made it clear in public postings 
that
  he is ashamed of using Struts, and has engaged in an attack on the 
proper
  behavior of the Apache Software Foundation's Board of Directors.  In 
these
  circumstances, it would be hypocritical for BaseBeans to benefit 
from the
  free advertising value of being visible on the Struts web site.  
Help them
  out of this conundrum by removing such references.
Revision  ChangesPath
  1.4   +131 -4jakarta-struts/contrib/struts-faces/build.xml
Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-struts/contrib/struts-faces/build.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- build.xml9 Aug 2003 19:29:30 -1.3
  +++ build.xml11 Nov 2003 21:23:32 -1.4
  @@ -88,6 +88,7 @@
 

  +  
   
  @@ -312,7 +313,7 @@
 
-  
  +  
  description="Install example webapp on Tomcat">
   
   path="${example.path}"
  @@ -320,24 +321,142 @@
 
-  
  +  
  description="Reload example webapp on Tomcat">
   
   path="${example.path}"/>
 
-  
  +  
  description="Remove example webapp from Tomcat">
   
   path="${example.path}"/>
 
+  
  +
  +
  +  
  +
  +
  +
  +
  +
  +  
  +
  +
  +  
  +
  +
  +
  +  
  +
  +
  +
  +
  +  
  +
  +
  +  
  +
  +
  +
  +
  +
  +  file="${build.home}/lib/struts-faces.jar"/>
  +
  +  file="${commons-beanutils.jar}"/>
  +
  +  file="${commons-collections.jar}"/>
  +
  +  file="${commons-digester.jar}"/>
  +
  +  file="${commons-fileupload.jar}"/>
  +
  +  file="${commons-lang.jar}"/>
  +
  +  file="${commons-logging.jar}"/>
  +
  +  file="${commons-validator.jar}"/>
  +
  +  file="${struts.jar}"/>
  +
  +  
  +
  +
  +  
  +if="build.standalone">
  +
  +
  +
  +  file="${commons-dbcp.jar}"/>
  +
  +  file="${commons-pool.jar}"/>
  +
  +  file="${jsf-api.jar}"/>
  +
  +  file="${jsf-ri.jar}"/>
  +
  +  file="${jstl.jar}"/>
  +
  +  file="${standard.jar}"/>
  +
  +  
  +
  +
  +  
  +
  +
  +
  +
  +   destdir="${build.home}/webapps/stf/WEB-INF/classes"
  + debug="${compile.debug}"
  +   deprecation="${compile.deprecation}"
  +  optimize="${compile.optimize}">
  +  
  +
  +
  +
  +
  +  
  +
  +  
  +
  +
  +  
  +
  +
  +  
  +
  +
  +  
  +   description="Install STF webapp on Tomcat">
  +
  +path="${stf.path}"
  + war="file://${build.home}/webapps/stf"/>
  +  
  +
  +
  +  
  +   description="Reload STF webapp on Tomcat">
  +
  +path="${stf.path}"/>
  +  
  +
  +
  +  
  +   description="Remove STF webapp from Tomcat">
  +
  +path="${stf.path}"/>
  +  
  +
  +
 
-  
  +  
  description="Create binary distribution">
  
  @@ -372,6 +491,14 @@
   
 
 
  +   
  +  
  +
  +
  +  
  +
  +  
  +  
  
 
   
1.16  +1 -6 

Re: cvs commit: jakarta-struts/doc/resources archives.xml consultants.xml powered.xml sigs.xml

[Vic Cekvenich]

So if we disagree, that means remove a link?

Steve Raeburn wrote:
you put your arguments in a way that seems
rambling and paranoid. 
Yeah, this makes me paranoid:
http://marc.theaimsgroup.com/?l=geronimo-dev&m=106873140521473&w=2
Above says, quote: "committed not his own IP but a "derivative work" of 
IP already owned by JBOSS commiters, and thus already covered by the 
LGPL, and that therefore this file should indeed be licensed under the 
LGPL " (end quote)

http://marc.theaimsgroup.com/?l=geronimo-dev&m=106875482022176&w=2
Above says, quote:
"I'm not sure, but I think even having it in the Attic is still not 
sufficient.
...
It also must be deleted from mail archives, if it was ever there."  (end 
quote)

Would you say that that is FUD?
I have a point and you know it. Community should keep open source safe 
and clean.

.V



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

Re: cvs commit: jakarta-struts/doc/resources archives.xml consultants.xml powered.xml sigs.xml

[Vic Cekvenich]

There are many people that criticized Struts, saying Barracuda is better 
that Struts; or JSF is better than Struts, etc.  What a PITA.

The issue I raised was not a Struts issue, but a Political issue on a 
different list. If you are Democrat, then Republicans are a PITA, it be 
easier if there were just no Republican sites (or the other way around, 
depending on you POV). So this has little to do with Struts!

But ... if you want to discuss or judge the merits of “my” politics on 
this on this list, there is a tangent you can draw. There is a change 
that Apache SF is copying a design,
( http://theserverside.com/home/thread.jsp?thread_id=22337#101419 )
 and according to the archive of “Elba.sf.net” the plans is to, quote:
"Think of Elba (jBoss code) as a latticework for Geronimo--and as a 
shield to buffer the Geronimo codebase and CVS repository from any LGPL 
code. As Geronimo is built, its code will replace the code from Elba" 
(end quote)
So my reading comprehension says: They will take jBoss design, and 
refractor it, and PMC went along with this, a mistake I think. What PITA!
So what is the tangent to Apache Open Source projects, developers and users?
This is: I spend 30% of my time “selling” Apache open source technology 
to business, that it is a safe platform to be on. If there is a 
precedent that Apache open source developers are capable or inclined to 
use a legal loophole, and that they could/would refractor a design of a 
client’s application, it would make it harder for ALL of us in the open 
source community to get gigs. What a PITA that would be!

But don’t go with the selfish Makaveli-an above, if one sees a bunch of 
kids beating up a girl, it be a PITA to help her, so much easier to 
cross the street. Well… for better or worse, I did not cross the street!

.V

ps: ah… support open source?

Steve Raeburn wrote:
The committers of the Struts project are entrusted by the Apache
Foundation to determine the content of the Struts portion of the
website.  None of us has objected to Craig's update, probably because
we've all grown tired of Vic being a PITA. (Incidentally he's always a
PITA about non-technical, POLITICAL issues.)
It's done. Hopefully, Vic will get the message that nobody here wants to
listen to his ramblings and we can all move on with the development of
Struts and leave the conspiracy theories behind.
Steve



-Original Message-
From: news [mailto:[EMAIL PROTECTED] Behalf Of Jonathan Revusky
Sent: November 13, 2003 10:45 AM
To: [EMAIL PROTECTED]
Subject: Re: cvs commit: jakarta-struts/doc/resources archives.xml
consultants.xml powered.xml sigs.xml
Craig R. McClanahan wrote:

Quoting Vic Cekvenich <[EMAIL PROTECTED]>:



Was that called for Craig?


Yep.



Maybe putting in the4 context of ... ASF was accused of stealing
designs, and Vic decided to presure ASF?
http://www.mail-archive.com/general%40jakarta.apache.org/msg
08432.html

Feel free to go make your case on someone else's website.


As an external observer (I keep one eye on various forums in this
application space) I cannot help but make certain comments.
First of all, as regards your statement above in which you refer to
"someone else's website", I parse this to mean that you consider the
jakarta.apache.org/struts website to be _yours_. As a matter
of fact, it
is not. It belongs to the Apache Software Foundation, a non-profit
entity set up with a certain charter and that has received
support from
various organizations.
If the website in question were your personal website (which
it is not)
then there would be no issue whatsoever in terms of removing
material on
the basis of arbitrary, personal considerations. In terms of
one's own
personal website, one can be as petty and arbitrary as one wishes.
However, if you are maintaining the Struts-related material on
apache.org, on behalf of ASF, I think one should be subject
to certain
constraints related to professional ethics, and one's behavior should
not be petty and arbitrary, subject to personal animosities and so on.
Let me develop this a bit further. Presumably the BaseBeans site was
linked in the first place because it was considered to be something
potentially of interest to the Struts community. It stands to reason.
What other reason would there be to link it?
Correct me if I'm wrong.

Now, as far as I can see, a legitimate reason to remove the
link would
be the determination that the BaseBeans site is no longer
potentially of
interest to the Struts community. However, BaseBeans, as far
as I know,
continues to offer the same products and/or services that it offered
when originally linked. If the site was potentially of interest to
Struts users when it was linked, it would seem that nothing
has occurred
to change that.
Any 3rd party observer would draw the conclusion from this that Mr.
Cekvenich made statements in a certain context that rubbed
you the wrong
way, so you are removing th

Re: cvs commit: jakarta-struts/doc/resources archives.xml consultants.xml powered.xml sigs.xml

[Vic Cekvenich]

Martin Cooper wrote:
 You've attacked 
 ... Craig.
Craig attacked me.

 All the
while, you've been told that appropriate measures are being taken by the
appropriate people
I was not told that! Do you have a link? You can send a private mail if 
you'd like, not to fan the falmes.

, but still you whine on with your "guilty until proven
innocent" attitude.
On general list, I linked the interface where TSS post in esence proved 
that the code that showed up... was not ASF license. It's on general, do 
you want a link? That was  proof as far as I am concrened.
Also the circstances of all this code showing up and the timing of it 
made it very suspicions to me.

If you feel "dirty" to be using Struts now, you are perfectly free to use
something else instead.
I have invested some 4 years into Struts.

  I
see absolutely no reason that you should expect free publicity
You mean the fact that I was hosting a few popular Jakrata newsgroups, 
commons, tags, and Struts and *paying for the bandwith*, not charging 
anyone to the benefit of Struts community? Free publicity? In the same 
way  UNC hosts Maven and provides bandith?
This was way long before there were alternatives (Gmane). Some people 
did not want to sign up to the mail list, they just wanted to browse the 
messages. Now, there is an alternative for newsgroups, so the fact that 
baseBeans supported it for year, counts for nothing. Real nice.

And this is for supporting OSS!
I would would companies hire Apache comitters if there is a precident of 
ASF taking code and refactoring it and "owning" it. I think it should be 
crystal clear the ethic in here.

I fully support Craig's action in updating the Struts site today.
You might also state which way you support the code alegations and what 
should be done about it.

.V







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

Re: cvs commit: jakarta-struts/doc/resources archives.xml consultants.xml powered.xml sigs.xml

[Vic Cekvenich]

This is what broke it:
http://theserverside.com/home/thread.jsp?thread_id=22337
It was aleged that code was takem from someplace that was not allowing 
it and placing it into Apache code base! ASF seems to be saying "we took 
the design and are re-implementing it.

Whatever.

Shame on you for ... aparently... supporting it.
I guess it's good for comercial vendors such as Sun, but it is bad for 
Open Source. I think ASF and Sun are a bit to close. I guess another brick.

.V

Craig R. McClanahan wrote:
Quoting Vic Cekvenich <[EMAIL PROTECTED]>:


Was that called for Craig?


Yep.




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

Re: cvs commit: jakarta-struts/doc/resources archives.xml consultants.xml powered.xml sigs.xml

[Vic Cekvenich]

Was that called for Craig?
Maybe putting in the4 context of ... ASF was accused of stealing 
designs, and Vic decided to presure ASF?

http://www.mail-archive.com/general%40jakarta.apache.org/msg08432.html


  Vic Cekvenich of BaseBeans.com has made it clear in public postings that
  he is ashamed of using Struts, and has engaged in an attack on the proper
  behavior of the Apache Software Foundation's Board of Directors.  In these
  circumstances, it would be hypocritical for BaseBeans to benefit from the
  free advertising value of being visible on the Struts web site.  Help them
  out of this conundrum by removing such references.
 
.V



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

Re: Conversion to ToStringBuilder

[Vic Cekvenich]

The less jars, the better.

I have like 2 dozen. I wish containers shipped with some commons-* jars 
and xml handling jars, like Tomcat does.

Really, servelt 2.5 spec should state something like jars needed by 80% 
of apps (collections, beans, log4j, xmltypes suggested) should be in the 
container common lib. No, not the silly j2ee.jar which has things that 
are used by 15% of people (yes, it's a scientific #, it says this, if I 
do not need it, no one needs it). I mean even rt.jar is 18 megs, why not 
containers have some stuff, we already have class loader issues anyway.
bP is only 90K, but needs a lot of jars to wake up.

I happen to use lang for other things so this one does not help me and 
it would detriment and active commiter.

.V



Craig R. McClanahan wrote:
Quoting David Graham <[EMAIL PROTECTED]>:


I think we inherit the dependency on commons lang from some other
component.  Our use of lang's features is very limited and my preference
is to keep it that way.  Regardless, toString() is easy to implement
without ToStringBuilder.


Last time I looked, ToStringBuilder was the only  dependency we have on
commons-lang.  I'd much rather do a little more work in our toString() methods
and dump the dependency if that's actually the case, unless there's some
compelling need for any of the other c-l methods.

David


Craig


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

Re: Struts Chain... seams similar to HiveMind ?

[Vic Cekvenich]

But... the chain has a set of steps that are "pre-progrmed", and there 
was some discusion as to what those steps should be idealy. Yes, it can 
do return codes but

If HiveMind (or an aproach like it) is used to do the chain, then I can 
easily add interceptors, and alterantice idea for consideration

I found this very educational:
http://jakarta.apache.org/~hlship/HiveMind.ppt
... and based on that I made a "leap", that, hey, we can intercept the 
flow. A bit of AOP.
(There are some other ideas in there, like code to the interface "contract")

.V



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

Struts Chain... seams similar to HiveMind ?

[Vic Cekvenich]

Struts Chain... seams similar to HiveMind ?
Am I wrong?
.V


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

Re: Looking for thoughts on html:errors with indexed properties

[Vic Cekvenich]

I  belive I had "reported" in bugzzila multi row validation problme 2 
years ago, as well as posts.
Here is the code I have been shiping for a long time with bP (writen by 
Jose/Ben):
package com.fX.base;

/*
 * MultiRowValidator.java
 * by Ben Tomasini - original by Jose Quiteriono ?
 * 12/10/2002
 *
 */
import java.io.Serializable;
import java.util.Collection;
import java.util.Iterator;
import javax.servlet.http.HttpServletRequest;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.commons.validator.Field;
import org.apache.commons.validator.ValidatorAction;
import org.apache.struts.action.ActionErrors;
/**
 * This class contains multi-row validations for a collection
 * *** validation.xml
 ex: use
 
 
 
 
 rowName
 row
 
 
 
 
 
 rowName
 row
 
 
 
 
 
 rowName
 row
 
 
 
 *
 */
public class MultiRowValidator extends 
org.apache.struts.validator.FieldChecks
implements Serializable {
//TODO: rename row to index

/**
 * Commons Logging instance.
 */
private static Log LOG = LogFactory.getLog(MultiRowValidator.class);
/**
 * Checks if the field isn't null and length of the field is 
greater than zero not
 * including whitespace.
 *
 * @param   beanThe bean - must implement Collection
 * @param   va  The ValidatorAction that is 
currently being performed.
 * @param   field   The Field object associated 
with the current field
 *  being validated.
 * @param   errors  The ActionErrors object to add 
errors to if any
 *  validation errors occur.
 * @param   request Current request object.
 */
public static boolean validateMultiRowRequired(Object bean,
   ValidatorAction va, 
Field field,
   ActionErrors errors,
   HttpServletRequest 
request) {

boolean valid = true;
// Need to iterate over a collection
Collection coll = (Collection) bean;
for (Iterator i = coll.iterator(); i.hasNext();) {

Object entry = (Object) i.next();
if (!validateRequired(entry, va, field, errors, request))
valid = false;
}

return valid;

}

/**
 * Checks if the field matches the regular expression in the 
field's mask attribute.
 *
 * @param   beanThe bean - must implement collection
 * @param   va  The ValidatorAction that is 
currently being performed.
 * @param   field   The Field object associated 
with the current field
 *  being validated.
 * @param   errors  The ActionErrors object to add 
errors to if any
 *  validation errors occur.
 * @param   request Current request object.
 */
public static boolean validateMultiRowMask(Object bean,
   ValidatorAction va, 
Field field,
   ActionErrors errors,
   HttpServletRequest 
request) {

boolean valid = true;
// Need to iterate over a collection
Collection coll = (Collection) bean;
for (Iterator i = coll.iterator(); i.hasNext();) {

Object entry = (Object) i.next();
if (!validateMask(entry, va, field, errors, request))
valid = false;
}

return valid;

}

/**
 * Checks if the field can safely be converted to an int 
primitive.
 *
 * @param   beanThe bean - must implement collection
 * @param   va  The ValidatorAction that is 
currently being performed.
 * @param   field   The Field object associated 
with the current field
 *  being validated.
 * @param   errors  The ActionErrors object to add 
errors to if any
 *  validation errors occur.
 * @param   request Current request object.
 */
public static boolean validateMultiRowInteger(Object bean,
  ValidatorAction va, 
Field field,
  ActionErrors errors,
  HttpServletRequest 
request) {

boolean valid = true;
// Need to iterate over a collection
Collection coll = (Collection) bean;
for (Iterator i = coll.iterator(); i.hasNext();) {

Object entry = (Object) i.next();
if (validateInteger(entry, va, field, errors, request) != null)
valid = false;
}

return valid;
}
/**
 * Checks if the field can safely be converted to a float 
primitive.
 *
 * @param   beanThe bean - must implement collection
 * @param   va  The Va

Re: The Forrest Option

[Vic Cekvenich]

Don Brown wrote:

If we did decide to go with Forrest, I'm willing to convert the old site
over and help handle any integration. 


AFAIK, that is 90%+ of O.S.

.V



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

Re: [VOTE] Accept patches to make html taglib more extensible

[Vic Cekvenich]

+0

David Graham wrote:
--- Sgarlata Matt <[EMAIL PROTECTED]> wrote:

I hope it's OK for a non-committer to start a vote.  I know this has
been a
contentious issue, so I would like to clearly outline my plan for making
the
html taglibs more extensible and I would like a vote before I go to all
the
trouble of coding, updating documentation, resolving bugfixes, answering
questions, etc.
DESIRED FUNCTIONALITY
The ability to cleanly extend the Struts tags.  The tags are so good
that
when an application-specific requirement arises, it's much more
desirable to
extend from the Struts tag and keep tie-ins with ActionForms and such
than
it is to go off on your own.
PROPOSED SOLUTION
The solution is two parts.  Please vote separately for each part of the
solution.
A) Instead of accessing instance variables directly, use getters.


+1.  I've done some checking on this in the past but another round is
probably needed.


if (accept != null) {
   results.append(" accept=\"");
   //old way
   //results.append(accept);
   //new way
   results.append(getAccept());
   results.append("\"");
}

If someone wanted to override the accept attribute so that it was always
equal to foo then they would be able to do so.  A better use case would
be
overriding the onclick method so that it does something special like
display
a calendar popup.  Getters are actually already used in some places
(e.g. -
prepareMouseEvents in BaseHandlerTag), so really this is just doing an
audit
on the code to ensure getters are used consistently throughout the
taglib.
Use case for Part A:
I built an implementation
of Matt Kruse's JavaScript calendar widget based on the Struts tags a
few
weeks before Matt made his own implementation, so I have some experience
doing this.  As some brief background, the widget is a text box and a
corresponding calendar icon.  When you click on the calendar icon a
popup
appears where you can choose the date.  When you click on the text box
(which is what overrides a Struts tag) you want onfocus to automatically
call this.blur() so that the user can't enter text into the textbox
(that's
the calendar popup's job).  So in my subclass it would be nice to
override
the getOnfocus() method instead of overriding the entire
renderIForgetWhatItIsCalled() method.  Of course in this particular
instance
getOnfocus() is already being used instead of onfocus being accessed
directly, but I think this behavior should be consistent for all
attributes.
B) Add a new renderExtraAttributes() method that gives people the chance
to
throw non-standard HTML into their tags that extend from Struts tags.


-1.  As I've stated previously, I don't think the Struts tags should
support emitting non-standard HTML.
David



results.append("\"");
results.append(this.prepareEventHandlers());
results.append(this.prepareStyles());
results.append(this.getElementClose());

results.append(renderExtraAttributes());

return results.toString();

Use Case for Part B:

Unfortunately I still can't think of a good HTML 4.01 compliant use case
for
renderExtraAttributes(), but here is a weak try at it.   If my other
suggestion of having the render() method call getters instead of
directly
accessing instance variables is used, then renderExtraAttributes()
becomes
more important.  If it is not provided and someone wants to stick in
some
non-HTML 4.01 compliant HTML, what they will do is override something
like
the getSize() method so that it correctly renders the size and then
sticks
in the understandard HTML.  This is a nasty hack but you know a
programmer
will choose that over duplicating an entire render() method.
If you made it this far, thanks for reading this long email ;)  I know
I've
posted much of this before in several different messages, but hopefully
this
consolidation is useful.
Matt

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


__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com


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

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

[Vic Cekvenich]

Steve Raeburn wrote:
Many of the tags (basically those that have been implemented in struts-el)
are closely bound to Struts so I don't see that they belong anywhere else.
(Separate jar, yes. Separate cvs dir, probably). The remaining tags have a
limited shelf life, having been superseded by JSTL.
If I can disagre !with above; ex:
http://www.mattkruse.com/javascript/javascripttoolbox.zip
This exentds the HTML tag with .js emit.
Variations are a frequent need.
.V


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

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

[Vic Cekvenich]

Sgarlata Matt wrote:
  If my other
suggestion of having the render() method call getters instead of directly
accessing instance variables is used, then renderExtraAttributes() becomes
more important.  If it is not provided and someone wants to stick in some
non-HTML 4.01 compliant HTML, what they will do is override something like
the getSize() method so that it correctly renders the size and then sticks
in the understandard HTML.  


David Graham wrote:

> I agree that the standard tags should be extendable to make 
customizations
> easy.  

If there is a way to make extending tags easier for rich tags 
displaytag, calendar tag, (tree tag is anyone knows one?)... it would be 
very nice if they come more easier from CORE or HTML.

Just like people extend Action and ValidatorForm... it should be 
encouraged that people extend tags to make them rich (and there is now 
rich UI browser standard)

So please look upon kindley on how it can be made easier to exeetnd 
"CORE" and HTML tags.

(also IMO Struts HTML and tiles tag could/should migrate to taglibs)

.V



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

Re: Where is Struts 2 going?

[Vic Cekvenich]

My wish list:

- Multi protocol support, with a "default" implementation/support for 
XML-RPC. HTTP/HTML is ... so 80's. Light Services will be big in 2K.

- Multi container support. Ex: PicoContainer. Servlet containers web.xml 
is so ... 90's. (Maybe make Pico or IoC the "default" container.)

- Built in Interface for app. monitoring / managment. (3 tiers used to 
mean Presentation, Data and Management back in the 80's). Right now I 
use  JaMon in action to monitor time/ip/parms and exec time, etc. Anyone 
could implement a monitor engine, but building in "monitoring" api, 
basically start(String s) and stop(String s), would be nice.

There are also few ideas that can be shared from Commons HiveMind I think.

But... basically I think Pico + XML-RPC is very powerful and I am 
beginning to use it. Imagine DAO (iBatis) on back end, XML-RPC as 
protocol (talk to ANYTHING) listening to requests, processing them in 
IoC, and "binding" to a "formBean".

btw: What is business layer relay? To me it is peopleware, or the "actor".

.V



Ted Husted wrote:
Personally, I'd like to start the work on 2.x by defining the use-cases 
or stories that we'd like the framework to realize. Ideally, we should 
be able to trace each feature back to its use-case. Then, I'd suggest we 
build the framework up, story by story, test by test.

Here's some early work along those lines:

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

Of all possible *features*, the one I would emphasize the most is 
testability.

The second, which is a corollary to the first, would be decoupling the 
core framework from http, while allowing direct access to the underlying 
protocol when needed.

Though, if we base the core around Commons Chain of Responsibility, both 
should follow naturally.

 > "If every controller function can be done in Faces or
 > other frameworks, what do we gain by using Struts 2?"
 >
 > "Using Struts 2, our applications can cruise across
 > modules built from different vendors or teams. And
 > we could also develop modules for others."
 >
 > Could we realize this dream? I know there are many
 > challenging problems there. Could we think about it
 > in terms of defining characteristics of Struts 2?
Personally, I'm uncomfortable defining an open source product in these 
terms. We're not a retail product looking for a market. We're a 
community of developers building the everyday tools we each need to use.

If the Java platform did ship with everything everyone needed, then it's 
true that we'd have nothing to do here, and we could all focus on our 
paying jobs. 

But it is unlikely that such a day will ever come . In all 
likelihood, there are always going to be vacuums for open source to fill.

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

IMHO, the role of the Struts Committers is to ensure that generally 
accepted best practices are followed, so that the codebase remains easy 
to maintain and improve. For new development, especially, that means 
using techniques like test-driven development and technologies like 
Maven and IDEs that help us write cleaner code. For frameworks, it also 
means using patterns like Context and Chain of Responsibility to loosen 
coupling. But as to where the specifics of development take us, IMHO, it 
should be "from each according to their need".

 > Now we have the Struts chain. I like the ideas of the chain.

Amen to that brother. =:0) But, it's not *Struts* chain -- it's the 
*Commons* Chain. The true power of this package is that it gives us 
common ground upon with to build *business layer* frameworks. Right now, 
many of us are abusing Actions because Strut is the only controller 
framework we got. :(

But Chain is opening the door to another framework -- one that lives 
below Struts and manages all that nasty business logic -- the way Struts 
(and friends) now helps us with all the nasty presentation logic. :)

-Ted.

Jing Zhou wrote:

I believe this topic has been discussed hundreds of times
in different subjects. One of important tasks for a new
version is to identify concept leaps. This is the place I
would like to entertain your brain - hope everyone to have
a brainstorm on what are really the innovative ideas to be
built in Struts 2.
To start, let's review what the innovative ideas are in
Struts 1.0. Struts is called a MVC framework. But that
is not enough, actually there are many other frameworks also
called MVC ones. What made Struts unique at its early
time is its defining characteristics between form beans and
web forms. They are symmetrical entities.
In Struts 1.1, another concept leap is introduced, we

Re: [OT] Re: DO NOT REPLY [Bug 22519] - Allow multiple MessageResourcesfiles to be loaded under one key

[Vic Cekvenich]

"fictitious" as is key word.

Main thing I want to say is that it is not my goal to antagonize this 
community, for many reasons (great product, donated time, I use it to 
make $ and pay bills, great learning, etc. ).

To your message:
Lets not take thing to serious, here. EJB's are OT for Struts, having a 
thread enumerating I do not see as fitting in Struts groups, nor do I 
think that it a good idea that a vendor implies that people should 
upgrade to a "better" version of Struts, JSF. I take it you think EJB's 
are nice. I have seen clients turn from Jave, once EJB goes to 
production. That is not good. iBatis (Hibernate, etc. I find better, 
maybe I can speak my mind?)

I can code some, you can see my code at bP on sf.net.  (Want the link? 
see, it does not have to be serious) Yes, DAO, Master detail, multi row, 
etc. some of these things I was the first to document and give Struts 
examples of, and I was also 1st to advertise Struts in JDJ and other 
magazines, and I believe I did trained more Struts people than all 
others trainers combined, etc.  (Maybe you have sample apps linked I 
missed someplace? A lot of my posts are links to CVS code: Ex: From Vic: 
"here is a link to working source code example showing multi row update" )
I am critical of JCP, so are others. I sincerity believe that Sun is 
hurting Java via complexity, I beleive it best to make sure they hear 
that, else you and I will have to learn and master another language. I 
have written a 16 page letter to JCP on JSF as soon as the 1st spec came 
out. While I did get an itemized response, the follow up API docs did 
little to change.
A long time ago, Craig send me a personal e-mail saying he would  "-1" 
if it ever came up for me to be a commiter, he said becasue I am 
crticial of EJB. (Yes, this was long time before JSF) OK, you think of 
that what you will.

Now they did! have an effort to simplify JSF, and EJB 3 (good, and it 
was no thanks to people that kept quiet)  but not enough!
Assuming I sincerely believe in these things, what do you suggest I do?

You can feel free to defend EJB any time I criticize it. Also, EJB's 
were  talked about long before me:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg03376.html

Now sometimes I do post a short message, just asking the person to look 
into it more, and they can make their own decision, no need to argue 
w/them, they can Google if they wish, I can't write a paper every time.

For my own personal improvement, if you (or somone) can PLEASE send me a 
personal message pointing out where I have called someone a name or was 
insulting?

The thing about democracy (and open source maybe) is that if people are 
not active ... it fails.

Perhaps you did not see the message here where Ted "implied" a non 
commiter can review tickets ( I took that to mean me)? I was just trying 
to help, perhpaps I did more harm.

Anyway, your post bellow was a bit funny (other than my name in it)

.V



James Mitchell wrote:

Vic, what's your problem?

I think I've heard enough of your ramblings as well.  I've tried to
sympathize with your views hoping that somewhere (in some unknown galaxy)
you actually knew what you were talking about.
If you don't know what I mean, tell me if this sounds familiar to you (or
anyone):
(fictitious, but you get the idea)


On 8/16, "Message Message <[EMAIL PROTECTED]>" wrote:

Dear Struts group,
What is the best practice for using Struts with EJB?
"Vic" replied:
Don't use EJB, it sucks.
"Message Message" replied:
How can you justify saying that?
"Vic" replied:
Because I know these words
Model View Controller / Master Detail and Multirow / DAO / XLM / XSL
"Message Message" replied:
Wow.  You must be right, cause I don't even know all them werds.



"Craig" wrote:
Vic, you misspelled XML.




--
James Mitchell
Software Engineer / Struts Evangelist
http://www.struts-atlanta.org
770-822-3359
AIM:jmitchtx
[EMAIL PROTECTED]


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

Re: DO NOT REPLY [Bug 22519] - Allow multiple MessageResources files to be loaded under one key

[Vic Cekvenich]

Craig R. McClanahan wrote:
 Now get your hands off of our bug tracking system or you're
going to be banned.

Craig McClanahan

OK... about the only part of the message that made sense
.V





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

Re: When is the next release?

[Vic Cekvenich]

OK, sorry.

David Graham wrote:
--- Vic Cekvenich <[EMAIL PROTECTED]> wrote:

I closed too many most likely. In advance I beg forgiveness, just
reopen.


Please don't mark any more enhancements as LATER.  It's a real pain to go
through that huge list and reopen them and it messes up saved bugzilla
queries.  Enhancements should just stay open until they become irrelevant,
are fixed or are determined to not belong in Struts.
David


15 open bugs in 1.2 left. (half could easily be made later for 1.2.2,
etc.)
.V

Ted Husted wrote:

Vic Cekvenich wrote:


Any updates on 1.2.x?


Another matter required my undivided attention last week, and so I 
haven't been able to work on this since my last post.

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

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

A Committer does need to apply any patches to CVS, but, again, any 
member of the community can review a ticket with a patch to see if its

obsolete or whether the patch "works for me".

I will be working through these myself, but if anyone one is willing
to 

make it a joint effort, please feel free to jump in.

Also, a release is a majority vote. While I feel that this needs to be

done, other Committers may disagree. If someone else wants to do the 
work of making a 1.2.x release without the Bugzilla audit, you won't 
hurt my feelings. =:0) --- It's not about what any one of us think,
it's 

about consensus and community. I feel that resolving these tickets is
an 

important part of community-building, but that's just me =:0)

-Ted.




Ted Husted wrote:


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

So, for reference, I'm following

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

and

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

but observing the HTTPD numbering system.

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

whether to upgrade 1.2.1 from Alpha to Beta or General Availability 
(GA).

Since there are any burning reasons to ship this instantly, I'm 
taking it as a foregone conclusion that this first roll will be at 
least a Beta. I'm confident that there are not any "serious problems

that prohibits its use", so I don't believe it will not remain an 
Alpha. But, I do suspect that there may be "problems with this 
release that prohibit its widespread adoption" -- even if it simply 
documenting "what to do now that X is deprecated". So, I was calling

it a Beta release.

Once we have cleaned up the 1.2.1 roll (which I wager will only be a

Beta), we can roll 1.2.2. Hopefully, the 1.2.2 release will merit
the 

General Availability stamp. Of course, nobody knows until the vote.

Heretofore, we have rolled several version of the same "release" and

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

In practice, you often get a odd/even pattern, where the odd was the

"beta" or "development" version and even is the stable release. Some

communities, like Linux, Perl, and Emacs, codify this pattern. When 
the odd-beta is sufficiently patched to make it release-worthy, they

roll it over to the next even number and release that for general 
availability

AFAIK, we're not enforcing the odd/even pattern or a formal "patch 
level". So, if we roll 1.2.2 and it fails to get the votes for a GA,

we'd go on to 1.2.3, and if that passes, it becomes the next
"stable" 

release, odd or not.

Of course, it would even be possible for 1.2.1 to pass a GA vote, if

someone called for one. Personally, I think that unlikely, if only 
for documentation issues. But, others could out-vote me if the 
consensus feels differently.

The core idea is that when any of us feel brave enough to roll a 
release, we can tag CVS with the next integer, and have at it. The 
instant we tag and rol

Re: When is the next release?

[Vic Cekvenich]

I closed too many most likely. In advance I beg forgiveness, just reopen.

15 open bugs in 1.2 left. (half could easily be made later for 1.2.2, etc.)

.V

Ted Husted wrote:
Vic Cekvenich wrote:

Any updates on 1.2.x?


Another matter required my undivided attention last week, and so I 
haven't been able to work on this since my last post.

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

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

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

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

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

-Ted.



Ted Husted wrote:

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

So, for reference, I'm following

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

and

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

but observing the HTTPD numbering system.

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

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

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

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

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

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

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

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

To prevent any confusion with the CVS tags and so forth, the releases 

Re: When is the next release?

[Vic Cekvenich]

Any updates on 1.2.x?

Ted Husted wrote:

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

So, for reference, I'm following

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

and

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

but observing the HTTPD numbering system.

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

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

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

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

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

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

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

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

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

To ensure that two us don't start rolling a release at once, it's 
prudent to announce your intentions first. Depending on how formal you 
want to be, that announcement might be dubbed a "Release Plan". But the 
only thing that matters is whether the release you roll passes a 
Majority Vote to move it from Alpha to Beta or GA.

At least that's how I understand it =:0)

Since this release is not backwardly compatible with 1.1.x, having 
removed all those deprecations, we are moving to the 1.2.x release 
series. Until something compels us to go on to the 1.3.x series, we can 
make be as many "General Available" releases in this series as we need.

The current GA for Tomcat 4.1, for example, is now 4.1.27. I'm not sure, 
but I believe the GA release before .27 was .24: .25 and .26 didn't make 
the GA cut.

One point I'm fuzzy on is whether we should do 1.2.0 or 1.2.1 first. I 
had thought it would be 1.2.0, but Martin and Craig seem to be saying we 
should start with 1.2.1. Being a geek, my natural inclination was to 
start with zero. =:0)

-Ted.

Steve Raeburn wrote:

-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]
Sent: August 9, 2003 8:57 PM
To: Struts Developers List
Subject: Re: When is the next release?
That was my understanding as well -- we agreed to switch to the x.y.z
style that Apache HTTPD and Tomcat are using, where you post the bits 
and
then call for a vote on stability (alpha/beta/general availability).  
It's
perfectly reasonable to have a series of "general availability" releases
with new features in the 1.2.x series, as long as we continue to 
maintain
backwards compatibility within it.

Therefore the first release would be 1.2.1 and we'd keep going from 
there.

Re: Simplifying DynaActionForms

[Vic Cekvenich]

It is such a small change, and you have done so much for the community, 
I imagine that you should do as you would like.
.V

David Graham wrote:
Here's a snippet from my typical Action.execute() that deals with
DynaActionForms:
DynaActionForm dynaForm = (DynaActionForm)form;
String userName = (String) dynaForm.get("userName");
// do something with userName...
Casting to String gets to be quite painful with many form properties. 
Unless I've forgotten/missed an easier way of dealing with
DynaActionForms, I propose we add a DynaActionForm.getAsString(String)
method that does this casting for us.

Thoughts?

David

__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


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

Re: [BeanUtils] Interesting Microbenchmarks

[Vic Cekvenich]

I think jPetStore is using DynaBeans and that is what they saw - 
Reflection time.
I myself do not use DynaBeans (or think they are a good idea for a few 
other reasons, like unit testing and reuse).

.V

Craig R. McClanahan wrote:
The most important factor in page rendering time (which is not the same as
the CPU consumption being discussed on the ServerSide thread) is the
quality of the JSP page compiler.  Tomcat 4.0.6 (your platform) uses the
original version of Jasper, whereas the current generation (4.1.27 and
5.0.6) uses a completely rewritten "Jasper2".  On some apps I'm familiar
with, just this change resulted in 6x-8x improvements in rendering
speed.  The difference is startling, even in a single user environment.
You're right ... reflection gets a bum rap when it gets blamed for long
render times unless your CPU is maxed out.  Even then, it's typically an
insignificantly small factor in the big scheme of things.
Craig


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

Re: Workflow for Struts

[Vic Cekvenich]

Ted Husted wrote:
The thing I keep coming back to is whether workflows are a Struts 
problem."
Agree! that Workflow, PageFlow are not a Struts... or a problem.

In greenscreens(Cobol), we had (work)flow, chose menu 1-12, then 1-6, 
etc. The programers is in control of next step.
Web is event oriented. The user is in control, programer has to code 
defensive. We just receive events and handle.
Ex: User start to fill out credit info, then browses to Amazon, Google, 
then comes back.

From business side, being process centric is bad. Info, or model, or 
data centric is better, since the business process changes and needs to 
be dynamic.



my 02 c.
.V


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

Re: Addition of two new actions

[Vic Cekvenich]

That could be a good compromise.
A base action, that has 20% of code that is used by 80% of actions that 
extend it.
(I am sure this suggestion is not needed: just writing a list of 
feaures, the figuring out what is in common to put in base vs specific. 
Ideally somehow tiles action could be extended from the "base" action.)

My original objection was based on teaching Struts? Ex: When should we 
use tiles action?
It is just easier to tell people, use this action, and pass in this type 
of arguments, and if it find nothing, it just defaults to "Success".

.V



Steve Raeburn wrote:
I would prefer going with simpler, specialised classes than a monolithic
DispatchAction but if there is a consensus to combine them then I accept
your point.
A combined action may perhaps offer more flexibility. A concrete subclass
might be able to resolve the method in different ways depending on what was
present at runtime. (request parameter, parameter, key).
However, I'm not sure that flexibility justifies the increased complexity of
the class or of understanding how to use it. Potential areas for user
confusion would be misunderstanding the order of preference for resolving
the method names or not recognizing conflicts that could arise between them.
Also, what happens if we need to resolve by other means? Add more weight to
the super class or add another specialized sub class?
To summarize:
  - I think we definitely need the functionality that
ParameterDispatchAction offers.
  - If the actions are combined, the result needs to be just as extensible
and easy to understand as keeping them separate.
  - I would rather not combine them, but I'm open to ideas that satisfy
the previous two points.
Steve



-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]
Sent: August 1, 2003 1:38 PM
To: Struts Developers List
Subject: RE: Addition of two new actions


I would prefer to add ParameterDispatchAction now and defer a decision
about
merging the three actions.
To me, that would be 'the simplest thing that could possibly work' :-)
The downside to doing that is if we decide to combine them we have to go
through the deprecation phase, document the changes, and explain it to
confused users.  I'd prefer it if we took a look at all 3 classes now and
decided on an implementation before committing anything new.
David


Steve



-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]
Sent: August 1, 2003 10:42 AM
To: Struts Developers List; [EMAIL PROTECTED]
Subject: RE: Addition of two new actions
So, what you really want is LookupDispatchAction without requiring the
developer to create the map-related methods?  I think you already get
the

abililty to combine CRUD related actions and things like that.  If so,
then implementing a default getKeyMethodMap() in LookupDispatchAction
might accomplish the same goal, without requiring another action.
Such a

default implementation could examine the current LookupDispatchAction
subclass and create the mapping information automatically.
Don't get me wrong ... I like the idea behind what you're proposing.
I

just think we might already have it (with the potential to improve
ease of

use by not forcing people to implement getKeyMethodMap() for a common
use

case).

Craig


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


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




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

Re: Addition of two new actions

[Vic Cekvenich]

I think less actions are needed, not more.
.V
Steve Raeburn wrote:
I'd like to add two new actions to org.apache.struts.actions that I find
particularly useful.
1. SuccessAction - A simple action that forwards control to an ActionFoward
named "success".
This is a very simple action, but I find it exceptionally useful,
particularly in the early stages of development when it can act as a
placeholder for as-yet undeveloped actions.
  public ActionForward execute(
ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception {
ActionForward forward = mapping.findForward("success");
  if (forward == null) {
String message =
  messages.getMessage("success.required", mapping.getPath());
log.error(message);
throw new ServletException(message);
  }
  return forward;
}
2. ParameterDispatchAction - A DispatchAction that selects a handler method
using the value of the ActionMapping parameter.
This is as per the suggestion by Anthony Kay via Bugzilla
, except I prefer
the name ParameterDispatchAction to his suggestion of ConfigDispatchAction
as I think it's more descriptive of what the class actually does. Other than
the name change, I've just tidied up the Javadoc and changed the
'unspecified' method to throw an Exception (as in DispatchAction) rather
than return an Http error code.
If no one has any problems with adding these two, I'll put them in tomorrow.

Steve


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

Reflection

[Vic Cekvenich]

http://www.theserverside.com/home/thread.jsp?thread_id=20655
A good paper on performance, but implies that Struts reflection is slow.
I disagree, but.. would not mind converting some of the Struts to CGLib, 
if there is a comiter who would review and integrate, should it come on 
agenda.

.V



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

Re FRIDAY: Powered By Struts Logos

[Vic Cekvenich]

+1

Can we just assume... that Struts logo will be a Monkey?  A Struting 
monkey named "Struts".

Drawings of Struts logo with no monkeys in it can be submited  but 
who would vote for them? :-)

With clear see trough 3D like Mac OSX Look and Feel. A monkey in 
water... with ripples.

(undocumented feature: of course holding right shift and holding S and 
clicking on the monkey will search C: drive for HTML files and rename to 
JSP, with validation mapps created , form beans generated, etc.)

.V

Brandon Goodin wrote:
Personally, I think we should have a Struts logo "revision" contest. No
offense to who designed the current one. But, it's kind of drab. Why not do
a "logo suite" contest and keep a unified look across the Struts branding
elements. I would hate to see a powered by logo that is dramatically
different than the Struts logo. Any thoughts?
Just as a disclaimer I don't think we need a logo that looks like a circus
tent to get attention. I'm just thinking we need something that is clean and
professional, yet doesn't look like someone rolled it out with 2 seconds of
thought, their favorite font and a drop shadow in gimp. Hopefully I don't
upset anyone. Just my thoughts.
Brandon Goodin

-Original Message-
From: Rick Reumann [mailto:[EMAIL PROTECTED]
Sent: Monday, July 07, 2003 6:27 AM
To: struts-dev
Subject: RE: Powered By Struts Logos
One my brother came up with...

http://www.reumann.net/reumann/struts/logos.html

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


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

Re: [PROPOSAL] Modular Struts Examples

[Vic Cekvenich]

For more general purpose use (such as in the business tier), doesn't
RowSet already do everything you need?  I've heard it argued that this can
be the standarized DAO interface you are talking about.
What if the Data Feed is MQ, or Soap? RowSet has all this other 
mechanisam that gets in the way. Also disconected rowset for Oracle 
works a bit dieferent than RowSet for pgSQL, etc. So porting from SQL to 
   SQL will depened on RowSet driver, ouch. DAO interface can be 
tabular like disconected rowset, but based on Collections.


JSF (as you know :-( ) I personaly consider propriatory. Once I see the
real production license in 1.0 release by Sun or others, I will
re-consider.


It's under exactly the same terms as the Servlet API, or JSP -- for
example, you cannot ship a Servlet 2.4 container today, because Servlet
2.4 is not yet final.  Yet, we all know that it *will* become final, so we
can plan ahead on how to leerage it when it's released.
TC5.02 has been release as has Resin 3.1.
bP today downloads with TC5 and Resin 3.0 integrated, both have a great 
license.


2nd, JSF makes some architectral mistakes that remind me of EJB. I could
write another long letter to the JCP, but too late, the comitte is
locked.  Short story is that Java Everywhere plan will *not* work for
GUI, UI must be browswer, not Java, and not by a Java Developer but by
graphic artist. (As proof, I could show you some sites I designed the
GUI for :-) ). Also, I sincerley, but maybe naivley, think that JSF push
by Sun will push Java Developers into .Net. Nothing in version 1.0 will
fly, look how Struts was allowd to grow in 0.6 in a shade. If my clients
balk at JSF, I have no choice. Diverting Apache Struts users to Sun JSF
is not a great idea.


Your argument is pretty ironic, given that even Microsoft provides
mechanisms to programmatically create and modify UI components (using VB
or C# or whatever), so obviously there are at least a few people in the
world who differ on "UI must be browser".  :-)

Rich UI should not be Java, even if miniroity think it. We can agree to 
disagree, but I think that is where JSF misses. Masses are fickle.




I think JSTL is a great direction, and JSP 2.0 is great (KISS). If a
data grid was based on JSTL more, would that suffice?


No.

JSP and JSTL exist only at rendering time (what JavaServer Faces
calls the "render response" phase of the request processing lifecycle).
That does not provide any opportunity to perform event processing and/or
server side validation, which any robust UI framework needs to support.
Further, page authors need to be able to think of a DataGrid as a single
"thing" they can manipulate, and concentrate on look-and-feel issues,
without worrying about things like the iteration and result set scrolling
that would have to be explicitly dealt with if you're doing it the JSTL
way.  Sure, you can create something like the Pager tag library that makes
this kind of thing possible today, but still exposes lots of the plumbing.



If in JSF the Java Developer in a JSP creates a bean, populates it and 
then uses DataGrid for UI  then they are worying about pluming more 
so than Model 2; but I do not want to be confused for someone who wants 
JSF to get better :-). HTML was not meant for the complex forms we do 
now, and it can't be fixed at the server, but up close.

This is what "we" Model 2 people used to do in Struts in the days of 
Java, before JSF came and paved the way for .NET: :-)
In action we create a bean a populate it and put it in request, then the 
display tag  in JSP access the collection and displays it using CSS 
styles. Any pageing is done at the Data Layer (DAO) where page down, 
page up data can be cached (data cached at data layer, not view layer).

If JSF is not at some DAO level, but at a RowSet level... one would have 
to cache data in the view or controller for pageinator.



JSF needs to be more open, scaleable, rich UI (right now not even
Javascript support).


I thought you said that Struts should *not* have a UI at all, and
concentrate on the controller tier?  Make up your mind :-).

I think Struts should stay View agnostic.
(Why not add EJB to Struts? same argument, it is contraversial, ex:
Bitter EJB) JSF could become an anti-patern.


No matter how much people like you like to diss EJB, it's been the basis
for more than a few successful application deployments in large scale,
high availabililty, production environments.  Whether you like it or not
doesn't matter much to me ... there's enough people that do to have built
an entire app server software industry around it.
It wouldn't bother me at all for JavaServer Faces to have the same kind of
effect, and it still won't matter much to me whether *you* like it or not
:-).  It's clear already that more than a few vendors are taking it
seriously enough to build product around.  It's clear already that lots of
users like the direction.  There's already a SourceForge project (MyFaces)
pretty far along at an o

Re: [PROPOSAL] Modular Struts Examples

[Vic Cekvenich]

Got it "we".

Vic Cekvenich wrote:



Ted Husted wrote:

Craig R. McClanahan wrote:

sbip.

While ee should keep the new Struts-Examples application tied to 
what's in our core distribution, I think there's room for a 
Struts-Extensions application that uses things like DisplayTag, Struts 
Menu, xDoclet, and so forth. But, that's something I would envision 
living on the Struts SourceForge site (assuming somone wants to build 
it).

Typo on ee?


-Ted.




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

Re: [PROPOSAL] Modular Struts Examples

[Vic Cekvenich]

Ted Husted wrote:

Craig R. McClanahan wrote:

sbip.
While ee should keep the new Struts-Examples application tied to what's 
in our core distribution, I think there's room for a Struts-Extensions 
application that uses things like DisplayTag, Struts Menu, xDoclet, and 
so forth. But, that's something I would envision living on the Struts 
SourceForge site (assuming somone wants to build it).

Typo on ee?


-Ted.




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

Re: [PROPOSAL] Modular Struts Examples

[Vic Cekvenich]

Craig R. McClanahan wrote:

On Thu, 3 Jul 2003, Vic Cekvenich wrote:


My point was a shade on the other side. Yes Struts can show integration
to do 100's of things out there.
But at its core, Struts is a controller framework.


Right now, it's in particular a "front controller" framework, in design
pattern terms.  That's one of the areas I would personally like to see us
do some innovation.

Action Event Object execute signature- instead of the execute signature
with 4 arguments, have a single object containing the 4 objects.
This reduces people new to Struts creating properties in action, and
allows same execute signature for TilesAction, etc. The code looks a lot
cleaner. bP does this (as I think does Expresso)


No matter how technically worthy such an idea might be, this isn't going
to happen in a 1.x train, due to backwards compatibility expectations.
This is part of the responsibility that goes with being a widely deployed
and utilized framework -- we have to protect the investment of people who
have built on top of the existing architecture.  If we only had a few
users, we would be more free to do stuff like this.  But according to the
Apache web site stats (unofficial, but seem like they're pretty accurate)
we get ~75,000 downloads per month, and that was BEFORE 1.1 went final.
If we're willing to look at changing the fundamental APIs (and I think we
are in a 2.x train), there is a lot more we can do to make Struts better
than just this kind of change -- I'd rather look at the overall
architecture more holistically, instead of incrementally, when making
decisions like this.  For example, I will shortly be done with a pretty
radical proposal for the "decomposing the request processor" conundrum
that has been discussed a lot lately on STRUTS-DEV.
Incremental change is great for improving implementations.  It's not so
great for modifying fundamental APIs.  To do the latter well, you need to
be prepared to think outside the box, and even re-invent yourself on
occasion.
It is a simple change, like perform and execute signatures.


protected List _list in FormBean. As Husted's book points out (and bP
implements), it is nice to store data in a protected _list. (I am sure I
took it out of context) People mostly work with a tabular recordset,
rows of columns, eg: List of Maps. There are many ways of getting DAO
data to FormBean, but a good idea is to store the rows as a _list.
People that extend the ValidatorFormBean can then write their own
getValue, setValue and beann getters/setter, it nuges people in right
direction to store data agnosticly. (Ex: MQ gets results, remaped via
magic to formBean, and stores in a list).  Things like indexed
properties become easier then ... and best view in JSP world is display
tag, works with collection. Note that I would not implement the methods,
just leave it like that, protected _list, a place to plug into.


As you well know :-), you and I don't totally share a vision of what a
form bean is for, and what it's not for :-).  However, the recent progress
on JavaServer Faces clearly indicates that Struts's form bean approach,
and total lack of any real UI component model, needs to be addressed.
Yes. But we do agree that FormBeans have nothing to do with how the data 
comes in. (And I have adjusted my designs a lot since)


I'd actually rather address it by focusing on the controller (as you
suggest), and let all the view-layer considerations be separated as well.
I think that form beans, by themselves, are too limiting as a long term
abstraction for server-side view state.
Just as an example of this, look at where JavaServer Faces is today, with
respect to the concepts behind form beans and actions:
* You can use one form bean per page, or more than one -- your choice.
This I think is a mistake on JSF part. A formBean should map a form 
(JSP). If JSP is nested, so formBean should nest beans.
The major benefit is that one can unit test the formBean outside of the 
JSP for CRUD, etc. Modular! Else you are integrating in the JSP and that 
is just no good, now we need Container debugging, since less of a unit test.

* You can combine the form bean data with your "action" class
  (the way that WebWorks does it) or keep them separate -- your choice.
* You can ask for ANY bean to be automatically instantiated on demand,
  not just form beans.
Hey, now that is a security problem potentialy. It should map to the 
form(JSP). And then what about bean.populate() and if there  is no data 
found or ...
Model 1!

The technology train is passing us by.  We're not going to be able to
catch up with simple incremental changes.

Maveric instead of Ant for build. My argument is this. CVS out
CommonsSQL and use Maverick to build it. Sexy!
It auto downloads all the other jars it needs. People can target any
thing very easily. The build process becomes simple and fun.
(I do not have this code, 

Re: [PROPOSAL] Modular Struts Examples

[Vic Cekvenich]

Craig R. McClanahan wrote:


David


Would David's argument be that JSF integration (requires 2.3) be
postponed till Struts 2.0?


For integration into the core of Struts, yes it does.  But we can provide
an optional add-on integration for Faces, just like struts-el does for EL
evaluation, as soon as Faces 1.0 goes final.  Use it if you want, but it's
not required by the core of Struts.

OK, just do one or the other, so everyone is playing on the level field.

So all I am saying, call v 1.2 2.0 if you want, but target 2.3.

.V



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

Re: [PROPOSAL] Modular Struts Examples

[Vic Cekvenich]

snip
Target servlet 2.3 snip - There are now dependencies on 2.3 and 
more comming. Almost no one uses Tomcat 3. TC 5 level JSP 2.0 looks like

more fun. People that want 2.2 or 1.3 could rebuild, or they can keep 
using solid 1.1. A small KISS step. By the time 1.2 comes out

snip



How many times do we need to explain this to you?  Struts 1.x is based on
Servlet 2.2 and JSP 1.1.  It would take a major release version upgrade to
change that dependency.
David


.V

Craig




Would David's argument be that JSF integration (requires 2.3) be 
postponed till Struts 2.0?
OK, just do one or the other, so everyone is playing on the level field.

And a great argument on Maverick vs Ant David.
Good thing I did not do the diff for all of this.
Here is "Struts" with JSP2.0:



 
   ${fb['title']}
 


 
 
  ${fb['content']}
 


The most importnat part is that the C tag, DOES NOT NEED TO BE DECLARED 
in the JSP 2.0, since C tag, and EL is part of the JSP 2.0 Spec. Nice.

.V



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

Re: [PROPOSAL] Modular Struts Examples

[Vic Cekvenich]

Craig R. McClanahan wrote:
SNIP> 

We definitely need examples of modules, and all of the other individual
features.  I am not a believer that "one big example app" is the right way
to approach that -- the sheer scale of such a thing would be a barrier to
entry.  It's better in some cases (say, illustrating the different ways
you can use some of the tags) to have single-page illustrations (like what
we do in struts-exercise-taglib, but focused on, and documented as, being
examples rather than pseudo-unit-tests).
Also, there's no way that one could ever hope to illustrate *all* possible
best practices in a single application anyway, because there are
legitimate application-specific needs to choose between various
alternatives at every design point.  The fact that you choose one
particular strategy for user authentication (say, to use SecurityFilter
instead of container managed authentication) does not automatically make
all other choices "bad" or even "not best" -- they are just "different".

Yes, no monolithic best practice. It also changes over time, what was 
best done with logic can now be done via C tag, etc. etc. So just keep 
adding more better examples ... and then when something is way to old, 
just stop carrying the war. Sites like struts.sf.net and others have 
more examples  plus what Craig said, many different approaches, 
Camino, Expresso. Else all would be using basicPortal :-)


I think struts-upload could be deprecated (along with bean and logic
tags). People can do file upload out of commons, or using Jason Hunter's
COS upload. etc. Upload is not a Struts core value and could go back to
commons.


Have you been paying attention, Vic?  The Struts file upload
implementation uses commons-fileupload already :-).
More seriously, though, file uploading functionality really has two parts:

* The generic part that can be (and is) used in any web application
  framework, and/or stand alone (as is the case with
  commons-fileupload, which is used by Turbine and Tapestry
  as well as by Struts).
* The part that integrates the generic library into your
  particular framework (for our purposes, that's things like the
   tag that is Struts-specific, and not appropriate
  for the generic library).  It's entirely reasonable to have
  adapters like this; every other framework will do the same.
We did the right thing by factoring out the common part of fileupload and
sharing it -- just like we did with validator. 
GREAT!

 But it is silly to suggest
that Struts should give up the custom integration part of that, simply
because the fundamental logic is generic.
I have no problem beeing silly. :-)
My point was a shade on the other side. Yes Struts can show integration 
to do 100's of things out there.
But at its core, Struts is a controller framework.
So the "value" of MVC upload is a bit of a gray area.
If we kind of agree (ahh agree) that Struts is model agnostic and view 
agnostic, I was just implying that upload is not a core value of Struts. 
People that want upload can upload, and Struts is agnostic. So if 
struts-dev decides to slolwy move tags to jsptaglib, one think that can 
be marked for moving out (and solidifying core) is upload integration.
I do not feel strongly about it at all, to say that Struts can redcue 
it's scope a bit. So no + or - 0.


I would like for 1.2 to ... (can someone set up a "wish list" wiki
please?) is repackage into 2 jars: Struts core, and other (taglibs), a
few patches and a quick release. Also maybe Mavenize Struts build.


As Ted says, the Wiki is available for everyone to make their own
proposals.  So is the STRUTS-DEV list :-).  In either case, though,
specific proposals (with specific action plans) are generally more likely
to have useful effects, rather than generic suggestions.
And, don't forget, patches often speak louder than words :-)
I have 18 months ago worked with a few people(clients) to post patches 
to Struts with diff in bugzila and ... nothing happened. And I have seen 
this with other things in bugzilla.
So the things I propose I can post code to (since I use/tested already 
on site), if a commiter is willing to work with me to put in CVS. So 
after I propose, if a dev says oh, thats sounds fun, I, Vic, will do 
the CVS diff. after there is at least tiny interest of a specific dev 
member.

Ex:

Action Event Object execute signature- instead of the execute signature 
with 4 arguments, have a single object containing the 4 objects.
This reduces people new to Struts creating properties in action, and 
allows same execute signature for TilesAction, etc. The code looks a lot 
cleaner. bP does this (as I think does Expresso)

protected List _list in FormBean. As Husted's book points out (and bP 
implements), it is nice to store data in a protected _list. (I am sure I 
took it out of context) People mostly work with a tabular recordset, 
rows of columns, eg: List of Maps. There are many ways of getting DAO 
data to FormBean, but a good idea is t

Re: [PROPOSAL] Modular Struts Examples

[Vic Cekvenich]

OK, just to enumerate:

struts-documentation.war ( html tag docs),
mail-reader.war,
TomcatLikeNewExampleByTheNewCommiter.war,
tiles.war
blank.war
validator.war
Is this the list?
.V
Ted Husted wrote:
Steve Raeburn wrote:

In the interests of ease of understanding, the first application would 
not
necessarily exhibit best practice all the time. For instance, in the
examples I put together I have made no effort to protect JSPs with a
security constraint or by placing them under WEB-INF. I felt this was not
necessary to demonstrate the tags in use and might confuse novice 
users. I
don't necessarily think this app should use modules as this could again
confuse new users. I'm prepared to be convinced on that, Ted :-)


I'm -1 on demonstrating anything but best practices all the time. We 
made that mistake with MailReader and it has haunted us ever since. 
Unfortunately, people expect everything we do to be an example they can 
emulate.

Though, I don't agree that using a security constraint or placing pages 
under WEB-INF is a best practice. It's a common *pattern*, but there's 
no tangible benefit. If I do do it, it's just to remind other team 
members to follow the "Link only to actions (never to server pages)" 
best practice. [See what I mean, just because I document the pattern, 
people think I advocate it as a best practice =:)]

Meanwhile, I would be +1 on using Tiles in the Struts Examples module, 
since there is so much repetitive markup, anything else would be a bad 
practice =:)


The second application should demonstrate current best practice in the
context of a working, realistic application. The purpose of this app 
would
not be to tutor novice users but to show how Struts features can be used
together to create real-world applications. Struts Pet Store springs 
to mind
as a possible example.


I think something like this might be a good candidate for the Struts 
Application site at SourceForge. IMHO, our scope here should be the core 
documentation, a simple starter application (MailReader is fine), and a 
library of examples, like the ones you started. I think much of the 
Tiles-Doc would work better in the example format as well.

To help with the understanding how it all comes together, I'd like to 
adopt the "example" format for the MailReader too. So instead of just 
having a plain text "tour", we would have an annotated walk-through, 
where people can call up the corresponding source code and JSPs along 
the way. (Wish I thought of that when I first wrote the tour -- we had 
the Tomcat Examples even then).


Struts-blank would continue as the basic starter application template.


+1, and I think this should be the only second application that we need, 
and only because it's intended use is to drag, drop, and develop.

The intended course would then be to walk through MailReader to get the 
big picture, start your own development with Struts Blank, picking and 
choosing whatever use cases you needed from the Examples. For additional 
background, the core documentation would be "right there" as well.

-Ted.


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

Re: Struts repackaging (was RE: [PROPOSAL] Modular Struts Examples)

[Vic Cekvenich]

Agree 99.5%! (other than JSF of course, but all commers are welcome)

Struts does not select a DAO! There are some good DAO's standard or not 
and some bad ones. How many use the standard JDO? What if Struts shiped 
with JDO by Castor(and Castor proved slow for example, as it did)?

Struts could get out of View (very slowly move tags to jakarta taglib) 
and be agnostic on view. Pick your poison. I think a lot of people (my 
clients all do) use display tag (and Struts menu), but it does not ship 
with Struts, no big deal.

And Struts could down the road then dish out XML, ala SOA, or Axis. XML 
could then be rendered by any view I can think of, like the X tag. Maybe 
require the request processor element in struts-config.dtd to nudge people.

Struts core is controller and with that focus maybe better release cycle.

.V

David Graham wrote:
--- Steve Raeburn <[EMAIL PROTECTED]> wrote:

What problems would be solved by repackaging into seperate jars?


There is a perception among some people that Struts only supports JSP in
the view layer because it provides JSP tags.  While this is not true, it
would be clearer if there was a separate taglib jar.  Velocity users
wouldn't have to lug around the JSP tags but, more importantly, the tags
could have their own release cycle.  A *large* percentage of bugs are
reported against the tags so it makes sense to decouple them from the
"core".
Also, as JSF becomes the standard view technology, there won't be a need
for the Struts specific html taglibs (JSTL has already largely replaced
the bean and logic taglibs).  So, it makes sense to separate the Struts
"core" from the view layer technology because there are many choices out
there besides the Struts JSP custom tags.
I don't see any benefit to separating out other parts of Struts besides
the custom tags.
David


Steve


-Original Message-
From: Etienne Labonté [mailto:[EMAIL PROTECTED]
Sent: July 2, 2003 7:46 AM
To: 'Struts Developers List'
Subject: RE: [PROPOSAL] Modular Struts Examples
I propose (quite informally) a new packaging:

 Struts.jar (core logic only)
 Struts-taglib-rt.jar
 Struts-taglib-el.jar (from current contrib/struts-el.jar)
 *Struts-tiles.jar
 *Struts-upload.jar
 *Struts-validator.jar
 Struts-jsf.jar
Jars preceded by * are optional. I see no problem with leaving
those closer
to the core.
Perhaps heavier on the backs of release managers, but more intuitive
in my

sense. Someone using Struts with velocity could use only the core
part.

Someone doing JSP will know the difference between EL and non-EL.
Does this
make sense to you?
Etienne


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


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com


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

Re: [BeanUtils & Struts]RE: Support for Date datatypes!!!

[Vic Cekvenich]

Nice. Where can an jar be downloaded for this?
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/wqdata/wqdata/src/java/shared/org_apache_commons/util/ 

tia,
.V
Ted Husted wrote:
Joe Germuska wrote:
 > I'm still not completely convinced that the best solution isn't to
 > write your own ActionForm class that has two properties, 'date' and
 > 'dateAsString' (or whatever you want to call them) and behind the
 > scenes, when one of the properties simply sets and returns a data
 > member, and the other parses and formats values.
+1

IMHO, this problem is outside both the scope of Struts and ConvertUtils.

There are myriad ways to handle expressions of date and time. Enough 
that they deserve their own UI class (or classes). The Java libraries 
provide all the functionality most of us need. The trick, as Joe pointed 
out, is to put that functionality behind a facade. Especially when you 
get to as many use-cases as have been enumerated here.

IMHO, the solution is not to push the work off onto the tags or onto the 
framework, but to centralize it in your own date handler object that can 
be extended to do what you need it to do.

After three years, we all have working solutions to this problem. Most, 
I would hazard to guess, are variations of Joe's approach. IMHO, work on 
this subject is best directed at a better date-handling object (or 
facade), that could be used by Struts or any other presentation 
application.

Right now, I'm using a DateDisplay object to handle displaying dates in 
drop-down boxes and converting it back and forth:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/wqdata/wqdata/src/java/shared/org_apache_commons/util/ 

There are also some date/time/calendaring handling utilities under 
development in Commons Lang:

http://cvs.apache.org/viewcvs/jakarta-commons/lang/src/java/org/apache/commons/lang/time/ 

The way I approach this problem is by defining a date handling class (or 
classes) that can talk to Struts and can also talk to the controller or 
your business classes. If a date need to be accepted in one format and 
presented in another, it should the job if this class to handle any 
conversions. Or, if you need to provide the Date in different binary 
flavors (util, sql), the class could do that tIn this way it can be used 
not only with the Struts tags but with JSLT tags and other presentation 
devices.

I think in the end, we will all be using UI components that make such 
objects easier to plug into frameworks like Struts, but such components 
will need objects like these to do the dirty work.

IMHO, this is the most Agile approach of all, since it is easy to 
implement and test, and can be reused time and again.

-Ted.


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

Re: [VOTE] Steve Raeburn as a Struts Committer

[Vic Cekvenich]

+0 to exand the team.
+0 for more examples
.V
Ted Husted wrote:
Steve Raeburn has been a regular contributor to the mailing list and has 
recently put together a Struts Examples application that he would like 
to donate.

http://www.ninsky.com/struts/

I think Steve would be of great help in refactoring our existing sample 
applications into a single modular application and adding this new module.

I believe that this would be a good time to bring Steve on board as a 
Struts Committer.

He has my +1

-Ted.


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

Re: [PROPOSAL] Modular Struts Examples

[Vic Cekvenich]

-0.

Module was... is optional and confusing. I think delay this a point 
after 1.2.

I think struts-upload could be deprecated (along with bean and logic 
tags). People can do file upload out of commons, or using Jason Hunter's 
COS upload. etc. Upload is not a Struts core value and could go back to 
commons.

I would like for 1.2 to ... (can someone set up a "wish list" wiki 
please?) is repackage into 2 jars: Struts core, and other (taglibs), a 
few patches and a quick release. Also maybe Mavenize Struts build.

(after 1.2 consolidate actions and beans classes).

.V

Rob Leland wrote:
Ted Husted wrote:

I'd like to propose that we gather together the

struts-documentation,
struts-example (MailReader),
struts-exercise-taglib,
struts-upload,
struts-validator, and
tiles-documentation 


I am curretly -0 on this.
I don't like smashing --all-- the examples into one example simply
because it would be too much of a bite for new users to swallow.
Tiles already uses modules as part of it's documentation.
Having the :
struts-example (MailReader),
struts-upload,
struts-validator as a single application seem reasonable.
Perhaps we can structure them so they are both standalond and modules ?

-Rob


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

Re: Struts can't "get its act together" - JavaPro

[Vic Cekvenich]

When will JSF have a tool: I think the answer is 2004, but this is the 
wrong list for this.

Is there something in .NET that can do this like there are dozens of 
tools for Struts:
http://www.scioworks.com/scioworks_camino.html

I also just started using an open source bean generator that writes 
Struts bean getters and DAO.

I would say that Java has little advantage over C#.
Business managers would prefer .NET.
J2EE has mislead application developers in the past, Ex: EJB, which lead 
lots of bus. users to .NET.

I would hope that people do not use JSF as best J2EE has to offer. I 
think the best J2EE has to offer is Open Source tools like Struts.
Ex:
http://news.netcraft.com
This shows how much more MS is popular than Sun.
But it also shows how much more popular OS is than MS.

So my argument has been that MS > Sun, but Open SSource > MS.

I say that Struts + JSTL + IBatis + OO Programer can code circles around 
best .NET combo. I am willing to prove it any day or night, even via the 
web.

Then lets talk cost to operate:
MS tends to be cheaper than Sun. But... OS is cheaper to operate than MS.
Same for support. I go seach struts mail list: "validate date" and it 
shows like 1200 times people asked this question.
So I say... past is the future. OS > MS > Sun

Please do not put forth JSF as "best" of J2EE, it might be best Sun has 
(like they have iPlannet, NetBeans, SlowLaris, should I go on?).

I "sell" consulting; and clients feel better when of the bat I say, yes, 
.NET is better than Sun.
Then I sell Open Source. They say you can save us money?
YES! I say.
How popular is this?
http://news.netcraft.com I say.
Oh. they say.

Now I have offense.
I say: let me show you how quick I can write an 2 screen master detail 
app., with  a nice UI.
Ren *.HTML to JSP.
Write actions to go to JSP!
Add tiles/menu.
Demo one. Est time. 5 minutes for 2 screens.
I say, can your graphic artis using Dream Weaver customize this? Yes, 
they say, they like their logo bigger, and they like colors!
(At this time, client thinks I am done - I did not do beans yet, they do 
not know what beans is or why we need it)
I say: How would you like not to have to get legal approval and no buget 
meetings! Maybe get a little raise instead.
Then I say, ok, lets make some reusable comonents (beans) that could get 
used by Soap, Flash, and elsewhere in the app and test in your app with 
data.
DAO, 5 minutes, they like stored procedures usualy. (Last time they saw 
a DAO, it was EJB and... they say, wow, Java got better.)
Beans (I have getter/setter macro) 5 minutes.
Show Unit test of beans talking DAO !
I explain Soap, Flash compoents, and their web app. and ask for a PO and 
sit there while they glance at each other!

Do they want to talk iReport.sf.net. Great, they have a wizzard. Stress 
test? Disel Test! Demo? no, they have seen enough.
What is your pain I ask?  How many screens can your developers do per 
day? Do you want me to teach them a few OO tricks?

So I never argue #C vs Java. I absorb the punch and allways agree with 
client and agree that they should use popular tools that save money 
for the org.

Good luck selling! But.. if you ask more Sun JSF questions, there is JSF 
mail list on the Sun site.

.V

Davidson, Glenn wrote:
Chris, 
Thanks for your response, I find many of your arguments and others
compelling. Please note that I am working with Struts when I had the
opportunity to work with .NET. (Just what does that say about me? :-) )I
agree with the majority of what you wrote and probably didn't fully
understand the parts I might have issue with. 

The issue here is the perception by the majority of the business world. I
will be using many of the issues raised here to try and to get more
acceptance for Struts/JSP If you need any proof of the business
acceptance of .NET just look at the job sites for web developers and see how
many listings are for .NET and how many are for Struts/JSP etc.
I have used the argument that 

"Real productivity lies in the ability to provide rich, complex
functionality that supports real people in getting real things done."
the .NET heads ( is there a term used to describe them? ) come back and say
that it is easier and faster to build in C# then Java. They say that the
tools to work with C# are better ( I don't agree ). In fairness, we should
not assume that .NET developers are going to skip design or write GUIs with
no functionality. We should look at the total cost of development.
I must take issue with your point that
 "It's this complexity that goes begging when UI construction is the sole
(or even majority) measure of productivity."
The fact is that as of right now you can build and maintain a GUI using .NET
faster and easier (read productivity). You can build rich and complex
functionality using C#. The building the business functionality is basically
on par between Java and C#. Is it not fair to say that the productivity
gained in the GUI construction is a clear win for .NET?

Re: Struts can't "get its act together" - JavaPro

[Vic Cekvenich]

It's due sometime in 2004. Its based on Netbeans. Lets you drag and drop 
... from RowSet. (similar to ScioWorks for Struts). Hyped at JavaOne. 
Includes JSF. Later (2005?) it would allow drag and drop from EJB and 
Soap. It's unclear if there will be licensing cost to vendors.
(but I am like a 3rd party so ... )

.V

Igor Shabalov wrote:
Do anybody have a bit more information about "Project Rave"?

On Thu, 12 Jun 2003 01:51:40 -0400, James Holmes <[EMAIL PROTECTED]> 
wrote:

Hi Glenn,

There's actually been some really exciting JavaServer Faces tools news
at JavaOne.  First, there's Project Rave from Sun which looks really
close to the Visual Studio stuff from Microsoft.  This looks very
promising.  Basically drag and drop type stuff.
I also had the fortune of getting to see some upcoming Oracle JDeveloper
builds which also incorporate very nice functionality for JavaServer
Faces.  The Oracle stuff looks very promising and I'm quite excited
about it.
I just added a link to my Java Server Faces page for Project Rave:

http://www.jamesholmes.com/JavaServerFaces/

-James
Struts Console
http://www.jamesholmes.com/struts/
-Original Message-
From: Davidson, Glenn [mailto:[EMAIL PROTECTED] Sent: 
Wednesday, June 11, 2003 2:34 PM
To: 'Struts Developers List'
Subject: RE: Struts can't "get its act together" - JavaPro

James,
Your site is most helpful, thanks. I was wondering if you had any
additional
details on potential JSF developer products and/or any idea when we
might be
able to start using JSF? Are there any tools planned for migrating
Struts
applications to JSF? JSF is clearly something we want to know more
about.
Glenn

-Original Message-
From: James Holmes [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 11, 2003 3:19 PM
To: 'Struts Developers List'
Subject: RE: Struts can't "get its act together" - JavaPro
I'd recommend you have a look at JavaServer Faces (JSF).  I'm at JavaOne
right now and Sun -- along with other vendors -- is putting some serious
resources into developer productivity by way of JSF.  I have put
together a page on my website with more info on Java Server Faces:
http://www.jamesholmes.com/JavaServerFaces/

-James
Struts Console
http://www.jamesholmes.com/struts/
-Original Message-
From: Davidson, Glenn [mailto:[EMAIL PROTECTED] Sent: 
Wednesday, June 11, 2003 2:15 PM
To: 'Struts Developers List'
Subject: RE: Struts can't "get its act together" - JavaPro

Chris,
I tend to agree with your assessment of JavaPro but I'd like to open
this up
a little. Right now we are faced with two choices for web development
.Net
or not .Net. I can over-simplify the arguments for and against .Net as
the
following:
.NET Pluses
Developer Productivity
Negatives
Vendor lock in.
Others (including Struts)
Pluses No vendor lock in
Negatives
Less developer Productivity
It seems like many if not most companies are more interested in
developer
productivity.
Does anyone know of, or foresee any means by which we (developers) will
be
able to be as productive using Struts/JSP/DHTML/JavaScript etc. as
people
are using .Net? I'd love to be able to make a case against .Net .
Thanks

Glenn

-Original Message-
From: Chris Gerrard [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 11, 2003 12:07 PM
To: [EMAIL PROTECTED]
Subject: Stuts can't "get its act together" - JavaPro
I found this announcement today on JavaPro's August Issue online "In
Brief" site: 
http://www.ftponline.com/javapro/2003_08/magazine/departments/inbrief/de
faul
t.asp

The blurb:
Developer Tools
TurboM2
Tired of waiting for The Apache Group to get its act together with the 
Struts initiative, Virtuas has launched a framework of its own. 
Virtuas released TurboM2 previously under the name Web Application 
Model (WAM). Since then, the company decided to alter the product to 
perform many of
the features Struts offers, and like Struts will be released under the 
open source model.

There's more, but on casual inspection it appears that JavaPro has
simply regurgitated some marketing poo from Virtuas intended to convey 
the impression that Struts is in a funk and not moving forward. (so one
should naturally move to Virtuas' TurboM2 product)

Upon casual inspection it appears that TurboM2 is a fairly direct clone
of Struts. On of Virtuas' value-added claims is that TurboM2 has 
available support and training that Struts does not.

Links:
Virtuas TurboM2: http://www.turbom2.org/index.html
Struts/TurboM2 comparison: http://www.turbom2.org/docs/Comparison.pdf
The part that disturbs me is JavaPro's presenting this whole pile as if
it were truth. Someone reading this article could well be persuaded that
yes, indeed, Struts is in trouble and they should look elsewhere. I've 
been
less than impressed with JavaPro's content for some time, and this 
erodes my confidence in their editorial control and knowledge of the 
Java world
even further.



-
To unsubscribe, e-mail: [EMAIL 

Re: Stuts can't "get its act together" - JavaPro

[Vic Cekvenich]

Of course Struts dev just released RC2!
And discussion on dev was a weeks to final 1.1!
	After "The final release of Struts 1.1 cannot happen until this 
dependency is updated to a final release of FileUpload "
I think 1.1 opens up the flood gates.

.V

Chris Gerrard wrote:
I found this announcement today on JavaPro's August Issue online "In 
Brief" site: 
http://www.ftponline.com/javapro/2003_08/magazine/departments/inbrief/default.asp 

The blurb:
Developer Tools
TurboM2
Tired of waiting for The Apache Group to get its act together with the 
Struts initiative, Virtuas has launched a framework of its own. Virtuas 
released TurboM2 previously under the name Web Application Model (WAM). 
Since then, the company decided to alter the product to perform many of 
the features Struts offers, and like Struts will be released under the 
open source model.

There's more, but on casual inspection it appears that JavaPro has 
simply regurgitated some marketing poo from Virtuas intended to convey 
the impression that Struts is in a funk and not moving forward. (so one 
should naturally move to Virtuas' TurboM2 product)

Upon casual inspection it appears that TurboM2 is a fairly direct clone 
of Struts. On of Virtuas' value-added claims is that TurboM2 has 
available support and training that Struts does not.

Links:
Virtuas TurboM2: http://www.turbom2.org/index.html
Struts/TurboM2 comparison: http://www.turbom2.org/docs/Comparison.pdf
The part that disturbs me is JavaPro's presenting this whole pile as if 
it were truth. Someone reading this article could well be persuaded that 
yes, indeed, Struts is in trouble and they should look elsewhere. I've 
been less than impressed with JavaPro's content for some time, and this 
erodes my confidence in their editorial control and knowledge of the 
Java world even further.





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

Re: Struts can't "get its act together" - JavaPro

[Vic Cekvenich]

Struts is MUCH more productive, and I would be glad to show you, how 
using Struts with OO, you can code circles around.
(I also offer the training w/ money back- excuse the sales talk) I just 
want to show you that most of my clients choose J2EE over .NET because 
it is more productive and more scalable.

.V

Davidson, Glenn wrote:
Chris,
I tend to agree with your assessment of JavaPro but I'd like to open this up
a little. Right now we are faced with two choices for web development .Net
or not .Net. I can over-simplify the arguments for and against .Net as the
following:
..NET 
Pluses
Developer Productivity
Negatives
Vendor lock in.

Others (including Struts)
Pluses 
No vendor lock in
Negatives
Less developer Productivity

It seems like many if not most companies are more interested in developer
productivity.
Does anyone know of, or foresee any means by which we (developers) will be
able to be as productive using Struts/JSP/DHTML/JavaScript etc. as people
are using .Net? I'd love to be able to make a case against .Net . 

Thanks

Glenn
 

-Original Message-
From: Chris Gerrard [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 11, 2003 12:07 PM
To: [EMAIL PROTECTED]
Subject: Stuts can't "get its act together" - JavaPro
I found this announcement today on JavaPro's August Issue online "In Brief" 
site: 
http://www.ftponline.com/javapro/2003_08/magazine/departments/inbrief/defaul
t.asp

The blurb:
Developer Tools
TurboM2
Tired of waiting for The Apache Group to get its act together with the 
Struts initiative, Virtuas has launched a framework of its own. Virtuas 
released TurboM2 previously under the name Web Application Model (WAM). 
Since then, the company decided to alter the product to perform many of the 
features Struts offers, and like Struts will be released under the open 
source model.

There's more, but on casual inspection it appears that JavaPro has simply 
regurgitated some marketing poo from Virtuas intended to convey the 
impression that Struts is in a funk and not moving forward. (so one should 
naturally move to Virtuas' TurboM2 product)

Upon casual inspection it appears that TurboM2 is a fairly direct clone of 
Struts. On of Virtuas' value-added claims is that TurboM2 has available 
support and training that Struts does not.

Links:
Virtuas TurboM2: http://www.turbom2.org/index.html
Struts/TurboM2 comparison: http://www.turbom2.org/docs/Comparison.pdf
The part that disturbs me is JavaPro's presenting this whole pile as if it 
were truth. Someone reading this article could well be persuaded that yes, 
indeed, Struts is in trouble and they should look elsewhere. I've been less 
than impressed with JavaPro's content for some time, and this erodes my 
confidence in their editorial control and knowledge of the Java world even 
further.





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

Re: ActionContext [WAS: RE: composable RequestProcessor]

[Vic Cekvenich]

I do the same thing in bP! One Context/Event object. Much simpler.

Also, the signature can then support TilesAction signature, , etc.
.V
Peter A. Pilgrim wrote:
Andrew Hill wrote:


I'd even like
create a new execute(StrutsRequestContext) method in the default Action
class, that simple calls the old execute(m, f, r, r) (for backwards
compatibility).

Im doing this in my app - though the execute signature remains the same.
Most of my actions extend some abstract action classes, and most of the
hooks the subclass overrides are passed an ActionContext bean (which 
simply
has getters for the request,response, mapping etc...). Saves a lot of 
typing
and makes the code much more readable at the expense of one more tiny 
object
being created in the execute method. I later found it a good place to add
attributes as well - like the request attributes only scoped to the 
execute
method of the action (life of the ActionContext bean).

Ive been very tempted to overide my applications RPs 
processActrionPerform
and instantiate the action context there and pass it to the actions 
execute
but havent got around to it yet.

This is what I do when I extend the base Action and DispatchAction classes.
I created a context object to store the four parameter. It makes it very
simple to add extra bits and pass them to actions.
public AcmeActionContext extends ActionContext {

ActionMapping mapping;
ActionFormform;
HttpServletRequest request;
HttpServletResponse response;
...

LoginProfile loginProfile = SomeSecurityLayer.getInstance();

}






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

Re: [VOTE] Convert RC2 to Beta 5

[Vic Cekvenich]

(Thanks Ted and others comitters CVSing fixes (David, Martin) for 
donating yet another weekend to Struts, either way).
My comprehension (not again Its not flamey this time) is this:

Ted can release today under Beta 5 beta as is (with the known failed 
test) with all the work he did. Plus for this side is... who knows when 
is the next time a release will come, and no release for Java One?, that 
was the motivation here. So it's a step sideways to go forward. +1 means 
release Today, that is how I read it. It's just a name.

Else... someone else (who has tech. skills/experience of Ted) has to 
step forward, at another time to fix and build and release.   So if you 
look at it as beta  vs RC 2... it seems RC2! But when, a week? A month? 
What about the work done last few days? So a - 1 means wait.

If you say, hey, lets release something! that works and passes most 
tests in how it's used, and lets move towards final then ... beta 5.

+0 for B5.

.V

James Turner wrote:
Frankly, since these seem to be problems in the tests and demo
applications, rather than in the base code, I'd be -1 on this.  Going to
a beta 5 seems to me to be a unnecessary step unless the problem is in
the actual core libraries themselves.  

James


-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED] 
Sent: Sunday, June 08, 2003 6:14 PM
To: Struts Developers List
Subject: [VOTE] Convert RC2 to Beta 5

In final testing of RC2, some compatibility issues have been found 
between Tomcat 3.3.1 and the struts-exercise-taglib 
application as well 
as the tiles-documentation application.

Martin Cooper has been looking into the problems and has 
found that for 
the struts-exercise-taglibs cookie test, it is the

  

expression that is failing.

The  tags earlier on the page succeeded. The 
only difference seems to be that the earlier ones all have 
setters as well as 
getters in the Tomcat CookieFacade class, whereas there is 
only a getter 
for 'name'. So this actually looks like some kind of 
JSP/reflection bug, 
not related to Struts. (The  tag must have 
worked, because 
we know the  tag is trying to access a cookie!)

Also, the (rather complex) comparison test is killing the JVM 
when run 
under TC3.

In the Tiles application, servlet exceptions are being noted. One 
example is the extendedDefinitionTag page, but there may be others.

Unless fixes to these problems are immediately forthcoming, I propose 
that we document the issues and release Stuts 1.1 beta 5.

By getting this milestone out to the community, we would have 
a better 
chance of resolving the remaining issues so that we can go to Struts 
1.1. final as soon as possible

This proposal has my +1.

-Ted.



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




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

Re: Status check?

[Vic Cekvenich]

SNIP:

Ted Husted wrote:
There's a
working candidate at http://cvs.apache.org/~husted/ - This is a preview 
only - it is *not* the final RC! but it's what we want to test.)
I downloaded and it apears to work with a sample app of mine, just FYI.

.V



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

Re: http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces

[Vic Cekvenich]

I see it spun as replacement to Struts:
http://marc.theaimsgroup.com/?l=struts-user&m=105467147713194&w=2
Above says:
"the upcoming EA4 release of JavaServer Faces includes some pretty 
dramatic improvements in the C part of the equation "

So ... more of a replacement, I comprehended (Struts is View agnostic)
But, I am all about more competition! I want to use the most effective 
tool to build apps. Bring on JSF, competition makes it better.
I think it should be clear to people that they COULD use JSF among 
others. But give them choices. Velocity, JSF, Stxx, Expresso, Cleveland, 
tapestry.. and *I* think it not cool to imply that Struts developers 
thing users SHOULD  replace Struts with JSF, there are other choices. 
And put files on apache.org.

Also... why not let Struts live? What's wrong with that.
ASF is supposed to protect projects from a single person deprecating it.
My hope was that this in April of 2002:
http://marc.theaimsgroup.com/?l=struts-dev&m=101845337317906&w=2
says:
"That actually makes it easier to write a controller as a filter " was 
the direction to explore 2.3. What changed? Majority? It feels like a choke.

http://forum.java.sun.com/thread.jsp?forum=427&thread=404617&tstart=30&trange=15
Above says Struts is dead, he comprehended same as I did.
It's a bit of railroading.
No precedent for this on ASF.
How much does JSF cost $? The promised components and IDE, when?
If Craig or anyone want's to leave Struts ... how is that an event? Many 
people left, Winterfeld left. He did not place a file on apache.org.

I say Struts should not be killed, but allowed to compete, fairly with 
JSF or others.  Let's all do Oracle Cleveland and not do Struts.

.V

Ted Husted wrote:
Vic, my friend,

You're really not getting this.

JSTL is not a "replacement" for Struts. Nor JSF is a replacement for 
Struts. They are both technologies that you can use with Struts and get 
more bang for your development buck.

Some people are saying that with a really good implementation of JSF, 
you might need Struts. But since we don't have one of those, it's just 
guessing.

When the smoke clears, people will find JSF much easier to use with 
Struts than without. For very simple applications, you might not need 
Struts. Just as you could do a very simple application with Model 1 JSPs 
today.

You're reading way too much into things. The ASF is a non-profit 
organzation that is just about helping communities develop products. No 
more, no less.

-Ted.


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

Re: http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces

[Vic Cekvenich]

First and most important, thanks for addressing the concerns!

It's fine line threaded here with lots of gray area.
I will study (legalize), and maybe respond "my" opinion as to what I 
think of it, but there are things not addressed at the first glance such 
as that there are more than one thing Struts can integrate and that JSF 
is not a replacement for Struts (on apache.org). (Ex. PHB thinking: 
"Even Struts main guy is implying to go JSF").  Once it is implied that 
Struts is limited, will users want to keep invest in it?

Regarding Servlet 2.x, no tomcat-dev's on TC list implies that 2.5 
servlet version is iPlanet. (RI for JSF is *not* Apache, it's a vendor, 
so who will say that we wont have JBoss type * TCK issues *. You can't 
"enforce" that, you (Craig) can only ASK Sun lawyers to be kind to ASF 
or sf.net).
JSTL is Apache license, so no possibility of TCK issues.

I think JSF should be given a chance of competing fairly against Struts 
(as a replacement or otherwise, if Struts is not limited; and that other 
vendors be given equal chance to compete, and that apache.org stays out 
of it.)

No addressing of precedent of a vendor integration on apache.org (or 
harder to prove "limitation" of apache project in favor of "replaceing" 
with a vendor) (Only precident I brought up was JBoss _not_ complying 
with TCK )

It would have been much simpler to place the integration jars on sf.net 
for now, and list other vendors (and not limit Struts in other ways).

Maybe I just leave the issue there, everyone can read the Craig post and 
form their opinion (people can sleep in the bed they made).

Craig R. McClanahan wrote:



.V

ps: I have personal belief that JSF hype will be followed by search for
the guilty, punishment of the innocent and praise for non participant.
My preference is Apache Struts takes no part of Sun JSF.


It's my personal belief that Vic doesn't speak for Apache, or for the
Struts developer community, on this topic :-).  Vic is not, in fact, a
part of either community that he makes this recommendation to.  I wish he
would stick to speaking for himself.
Craig
Community also includes users, at least it says so on ASF home page. 
There is a lot of "I" and "my" in ps that delineates personal feelings. 
 My belief is that Craig is a Sun employee; but that is detracting from 
above. Craig did give Struts to the community (thanks !) but now it 
belongs to community (I do not imply anything else in here)
Also OT, Craig promised me a -1 months ago (in a private e-mail) to ever 
be a struts-dev community; because I publicly stated that I think that 
EJB should not be used for persistence. (To me JSF = EJB;  *I* think 
they are over-hyped, and will lead cooperate developers away from J2EE 
ultimately., but... like I say OT if JSF is good or bad, and OT that I 
am not a Struts-dev)



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

Re: http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces

[Vic Cekvenich]

Is ASF allowed to distribute Sun JDK?  Not AFAIK.

I think main argument is license, ex: what is cost of JSF?  Is it 
similar to JBoss issue?
I am not against JSF integration w/Struts at all. The more the better.

When there is only a single choice, this can't be good, standard or not. 
No one has educated me with another example of ASF file link like this. 
(and endorsing a replacement. Ex: On Tomcat 5 there is no files on 
apache.org... use BEA, here is the jar)
I would feel better (and you would feel better for making me feel better 
:-) if others were listed as integrating with Struts with any disclaimer 
you want. (Ex: XYZ integrates with Struts but is not Standard to JCP 
666, but this jar here is standard).
OR:  put the url link on Struts site, but the files outside of 
apache.org on sf.net or wherever, so someone has a chance to think I 
trust ASF but now I have linked outside of ASF. (just in case it blows up)

Unless ASF is endorsing JSF and I  just didt't get it.

Looks like no one jumping to my side, therefore end of discussion.
With a large pool you will not please everyone, I am not pleased. Some 
diversity is OK, so just say let me pout.

.V

(on technology side, majority of my revenue contribution is project 
recovery, ya)

Steve Raeburn wrote:
Vic,

The JSF Expert group includes :

Specification Lead
Ed Burns   Sun Microsystems, Inc.
Craig R. McClanahanSun Microsystems, Inc.
Expert Group
Aligo, Inc. Apache Software Foundation
BEA Systems Bayern, Shawn
Bergsten, Hans  Berkovitz, Joseph
Bogaert, MathiasBorland Software Corporation
Carapetyan, PeteDevelopmentor
Documentum, Inc.Droplets, Inc.
EDS Fujitsu Limited
Geary, DavidHewlett-Packard
IBM ILOG
IONA Technologies PLC   Lazarus, Eric
Macromedia, Inc.Mettu, Kumar
Nash, Michael   Netdecisions Holdings United
Novell, Inc.Oracle
SAS Institute Inc.  Siemens AG
Strachan, James Sun Microsystems, Inc.
Zukowski, John A.
That's a fairly representative sample of the industry, so I think we can
definitely conclude that JSF != Sun either.
If you don't think JSF is the right technical direction, then that's one
thing, but you are undermining your argument by making this about licensing
and Sun.
Steve


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

Re: http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces

[Vic Cekvenich]

??
The BEA OS? I see where you are going  ;-)
"they are *not* just another vendor." Got it! There for excluded from 
ASF livense.

That explains the MS lawsuit. Got it. Thanks.

JSF is "standard". Like C# is. I learned something.
 :-[
Peace,
.V
David Graham wrote:
Sun licenses Java to other companies so that they can port it to their 
OSes.  A violation of that license is what the whole MS lawsuit is 
about.  Like it or not, Sun owns Java; they are *not* just another vendor.

Again, like it or not, JSF is not a framework provided by a vendor but a 
*standard* Java API.  Struts works with other relevant standard APIs 
(servlet, jsp, jstl, etc) so why not JSF?

David

"1.  License Grant. BEA Systems, Inc. ("BEA") grants you a
non-exclusive and non-transferable license for the internal
evaluation, testing , development and production use of the
accompanying software and documentation provided by BEA for WebLogic
JRockit ("JRockit"), including, but not limited to the right to
reproduce and use JRockit internally for the purpose of designing,
developing and testing Java applets and applications, and running Java
applets and applications on JRockit.
"
That's what my license says.
I wonder want the IBM SDK license says.
Look Oracle BEA ship with JRorckit, IBM with its VM... only iPLanet 
uses  Sun VM (which leaks on JSP compiles, and has other issues, it 
gets replaced in production fairly quickly)

Java is != Sun.
Java = {Sun, Bea, IBM, Kaffe.org, ... }
(to the extent that some see as Java == Sun then I say Sun == MS, why 
not just do Mono then)

If Sun goes the way way of DG or Dec does that mean end of Java?
Why not just move ASF out of the way.
ASF should represent the community, and here is a break down of Java 
Community:
http://news.netcraft.com/archives/2003/04/10/java_servlet_engines.html
That is how big part Sun should play, and soon will play. ( I get gigs 
for IBM, Oracle, BE, Tomcat, etc but never for iPlanet, anyone 
have iPlanet on their resume?)

Let me say it this way, if IBM had a technology, should there be 
apache.org file with integration to it?

I am sure that JSF will be sold and will be hyped and I will get out 
of the way of that train. We shall see what happens after that (been 
there done that with other similar things).
Why kill or limit Struts?

Still no example of another vendor on ASF?

Look, we are not getting anywhere, if it bugs you it bugs you, if it 
doesn't  then don't worry. (Maybe some ASF big shot behind the scene 
whispers to MC, because a fix is so simple)

I hope you do not speak for all developers as you assume you do.

ASF does not say "do not endorse a vendor, other than Sun"

.V

ps: http://siliconvalley.internet.com/news/article.php/2217231
see this is how you defend open source, but a bit militant I think. 
Why not just open your eyes.

David Graham wrote:

When you download the JRE/JDK you agree to a Sun license.  Java 
itself is distributed under a Sun license.  JSF is a Java standard 
released through the JCP.  You're free to have your own opinion of 
JSF but Struts *will* support it.  The Struts team believes in the 
use of standard technologies as much as possible, including JSF.

David

ASF does not ask much of people other than don't use it to endorse 
vendor products. JSF is a Sun license.

On apache.org domain we have integration to a vendor.
I asked for a president, did Jakarta in the past have integration to 
a vendor on Apache domain?
Is the SF.net implementation licensed to call itself JSF?
(JBoss issues) I do not know  legalize.

Craig has that kind of lattitude. I sugested this be better placed 
on SF.net, and that a wiki page be used to list all vendors that 
integrate to Struts, with all their stndards info and if they have 
no stndard.

It stinks to me either way. Maybe I am way off base, but it bugged 
me and now I can sleep better.

.V

repost of ps:  I have personal belief that JSF hype will be followed 
by search  for the guilty, punishment of the innocent and praise for 
non
 participant. My preference is Apache Struts takes no part of Sun JSF.

If

David Graham wrote:

I don't understand the problem you have with Struts integrating 
with JSF.  JSF is the Java *standard* web GUI library.

David

(hope this does not detract from more important issues)

http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces

To the extent that this implies Struts _should_ integrate to Sun 
JSF, I do not like it.

This is quite different than JSTL, which was an Apache License.
Maybe there should be integrations posted in cvs  apache to 
Expresso, ScioWorks (they integrate more to Struts), lots of 
Vendor IDE and J2EE servers have integration to Struts; maybe 
their integration jar?s should be posted on non Apache domain, 
lots of software on sf.net has Apache license.

Craig as original author of Struts, deservers lots of latitude in 
what he does.

I still don?t like it. If there is a president I am unaware of, I 
withdraw my objection.

.V

ps: I

Re: http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces

[Vic Cekvenich]

"1.  License Grant. BEA Systems, Inc. ("BEA") grants you a
non-exclusive and non-transferable license for the internal
evaluation, testing , development and production use of the
accompanying software and documentation provided by BEA for WebLogic
JRockit ("JRockit"), including, but not limited to the right to
reproduce and use JRockit internally for the purpose of designing,
developing and testing Java applets and applications, and running Java
applets and applications on JRockit.
"
That's what my license says.
I wonder want the IBM SDK license says.
Look Oracle BEA ship with JRorckit, IBM with its VM... only iPLanet uses 
 Sun VM (which leaks on JSP compiles, and has other issues, it gets 
replaced in production fairly quickly)

Java is != Sun.
Java = {Sun, Bea, IBM, Kaffe.org, ... }
(to the extent that some see as Java == Sun then I say Sun == MS, why 
not just do Mono then)

If Sun goes the way way of DG or Dec does that mean end of Java?
Why not just move ASF out of the way.
ASF should represent the community, and here is a break down of Java 
Community:
http://news.netcraft.com/archives/2003/04/10/java_servlet_engines.html
That is how big part Sun should play, and soon will play. ( I get gigs 
for IBM, Oracle, BE, Tomcat, etc but never for iPlanet, anyone have 
iPlanet on their resume?)

Let me say it this way, if IBM had a technology, should there be 
apache.org file with integration to it?

I am sure that JSF will be sold and will be hyped and I will get out of 
the way of that train. We shall see what happens after that (been there 
done that with other similar things).
Why kill or limit Struts?

Still no example of another vendor on ASF?

Look, we are not getting anywhere, if it bugs you it bugs you, if it 
doesn't  then don't worry. (Maybe some ASF big shot behind the scene 
whispers to MC, because a fix is so simple)

I hope you do not speak for all developers as you assume you do.

ASF does not say "do not endorse a vendor, other than Sun"

.V

ps: http://siliconvalley.internet.com/news/article.php/2217231
see this is how you defend open source, but a bit militant I think. Why 
not just open your eyes.

David Graham wrote:
When you download the JRE/JDK you agree to a Sun license.  Java itself 
is distributed under a Sun license.  JSF is a Java standard released 
through the JCP.  You're free to have your own opinion of JSF but Struts 
*will* support it.  The Struts team believes in the use of standard 
technologies as much as possible, including JSF.

David

ASF does not ask much of people other than don't use it to endorse 
vendor products. JSF is a Sun license.

On apache.org domain we have integration to a vendor.
I asked for a president, did Jakarta in the past have integration to a 
vendor on Apache domain?
Is the SF.net implementation licensed to call itself JSF?
(JBoss issues) I do not know  legalize.

Craig has that kind of lattitude. I sugested this be better placed on 
SF.net, and that a wiki page be used to list all vendors that 
integrate to Struts, with all their stndards info and if they have no 
stndard.

It stinks to me either way. Maybe I am way off base, but it bugged me 
and now I can sleep better.

.V

repost of ps:  I have personal belief that JSF hype will be followed 
by search  for the guilty, punishment of the innocent and praise for non
 participant. My preference is Apache Struts takes no part of Sun JSF.

If

David Graham wrote:

I don't understand the problem you have with Struts integrating with 
JSF.  JSF is the Java *standard* web GUI library.

David

(hope this does not detract from more important issues)

http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces

To the extent that this implies Struts _should_ integrate to Sun 
JSF, I do not like it.

This is quite different than JSTL, which was an Apache License.
Maybe there should be integrations posted in cvs  apache to 
Expresso, ScioWorks (they integrate more to Struts), lots of Vendor 
IDE and J2EE servers have integration to Struts; maybe their 
integration jar?s should be posted on non Apache domain, lots of 
software on sf.net has Apache license.

Craig as original author of Struts, deservers lots of latitude in 
what he does.

I still don?t like it. If there is a president I am unaware of, I 
withdraw my objection.

.V

ps: I have personal belief that JSF hype will be followed by search 
for the guilty, punishment of the innocent and praise for non 
participant. My preference is Apache Struts takes no part of Sun JSF.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail




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

Re: http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces

[Vic Cekvenich]

ASF does not ask much of people other than don't use it to endorse 
vendor products. JSF is a Sun license.

On apache.org domain we have integration to a vendor.
I asked for a president, did Jakarta in the past have integration to a 
vendor on Apache domain?
Is the SF.net implementation licensed to call itself JSF?
(JBoss issues) I do not know  legalize.

Craig has that kind of lattitude. I sugested this be better placed on 
SF.net, and that a wiki page be used to list all vendors that integrate 
to Struts, with all their stndards info and if they have no stndard.

It stinks to me either way. Maybe I am way off base, but it bugged me 
and now I can sleep better.

.V

repost of ps:  I have personal belief that JSF hype will be followed by 
search  for the guilty, punishment of the innocent and praise for non
 participant. My preference is Apache Struts takes no part of Sun JSF.

If

David Graham wrote:
I don't understand the problem you have with Struts integrating with 
JSF.  JSF is the Java *standard* web GUI library.

David

(hope this does not detract from more important issues)

http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces

To the extent that this implies Struts _should_ integrate to Sun JSF, 
I do not like it.

This is quite different than JSTL, which was an Apache License.
Maybe there should be integrations posted in cvs  apache to Expresso, 
ScioWorks (they integrate more to Struts), lots of Vendor IDE and J2EE 
servers have integration to Struts; maybe their integration jar?s 
should be posted on non Apache domain, lots of software on sf.net has 
Apache license.

Craig as original author of Struts, deservers lots of latitude in what 
he does.

I still don?t like it. If there is a president I am unaware of, I 
withdraw my objection.

.V

ps: I have personal belief that JSF hype will be followed by search 
for the guilty, punishment of the innocent and praise for non 
participant. My preference is Apache Struts takes no part of Sun JSF.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail


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

new members should you wish

[Vic Cekvenich]

Dear commiters,
Please consider these people at a time you decide to increase # of 
commiters.

Peter.PILGRIM, Matt Raible, Brandon Goodin, John Yu, Don Brown.

In general, they have contributed to Struts and could/should fix things 
themselves, as opposed to ask for things to be fixed, but you can form 
your opinion by monitoring their posts.

.V



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

Servlet 2.2 / JSP 1.1

[Vic Cekvenich]

http://jakarta.apache.org/struts/status.html states:
"Struts 1.2.x will include additional functional enhancements along the 
same lines as Struts 1.1. The platform requirements will remain the same 
(Servlet 2.2 / JSP 1.1)."

I missed that discussion.

(Deprecation to me means it will be dropped in some future release)
I was hoping to suggest that Tomcat 3 be deprecated (and maybe even JDK 
1.3) and deprecate logic tag and bean tag as well.
(and start looking at TC5 )

And move ALL tags to another Jar (same package names) to start SLOWLY 
porting jsp tags to Jakarta tag lib over time.

Even some commons servlet request util could be made more generically 
useful at commons.

I imagined 1.2 as no new code / features, just a few more fixes and 
above deprecations. (and move up EL. )

I imagined 2.0 as some contrib. level for light SOAP. (unless we all go 
JSF  :-P  )

Oh well.

.V



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

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

[Vic Cekvenich]

http://jakarta.apache.org/struts/faqs/database.html
(It seems out of date and possible reason why users ask JDBC questions 
on list, here is a suggested draft replacment, either way it needs a bit 
of updateing.)

Struts apps are web applications and use the J2EE resources of the 
application server (container) and a DB server. A connection pool is 
provided by your application server and configured by your application 
server. It requires a JDBC driver be installed and configured with db 
server IP address, login id and password, size of pool, etc.
Examine the application server documentation.

Once you configure this connection pool you can test it via a Servelt. Ex:

protected void doPost(HttpServletRequest req, HttpServletResponse res) {
PrintWriter out = null;
Connection conn = null;
try {
out = res.getWriter();
res.setContentType("text/html");
String foo = "Not Connected to DB";
 // test that we have a working Data source and a db Connection
 Context ctx = new InitialContext();
 if (ctx == null)
 throw new Exception("Boom - No Context");
 DataSource ds = (DataSource) ctx.lookup("java:comp/env/bppool");

 if (ds != null)
conn = ds.getConnection();
if (conn != null)
foo = "Got DB Connection " + conn.toString();
Statement stmt = conn.createStatement();
  ResultSet rs = stmt.executeQuery("select * from content");
  if (rs.next()) {
 foo = rs.getString(2);
  } //if
  stmt.close();
   conn.close();
   out.println("DB Con: " + foo);
So now you have a working connection pool.

Most people recommend that you use a DAO implementation, and not work at 
a JDBC level, but there are times and reasons to use JDBC.

There are many popular and good DAO implementations. You need to select 
how you plan to implement DAO.

The Struts Mail lists mentions Ibatis.com and Hibernate. They both come 
with excellent documentation.

Some methodologies recommend that you test the DAO in a unit test, 
before you try to use it in Struts. A DAO that does not update or multi 
row select outside of Struts, will not start working in Struts, and it 
might make it harder for you to debug where the potential problem is.



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

http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces

[Vic Cekvenich]

(hope this does not detract from more important issues)

http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces

To the extent that this implies Struts _should_ integrate to Sun JSF, I 
do not like it.

This is quite different than JSTL, which was an Apache License.
Maybe there should be integrations posted in cvs  apache to Expresso, 
ScioWorks (they integrate more to Struts), lots of Vendor IDE and J2EE 
servers have integration to Struts; maybe their integration jar’s should 
be posted on non Apache domain, lots of software on sf.net has Apache 
license.

Craig as original author of Struts, deservers lots of latitude in what 
he does.

I still don’t like it. If there is a president I am unaware of, I 
withdraw my objection.

.V

ps: I have personal belief that JSF hype will be followed by search for 
the guilty, punishment of the innocent and praise for non participant. 
My preference is Apache Struts takes no part of Sun JSF.



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

Re: forms tag ? serialaizable

[Vic Cekvenich]

If you still have a serialization problem with a UserBean declared as you
indicate above, it's likely that one of the instance variables inside
UserBean (or its superclass) cannot actually be serialized.  For example,
if you've got an instance variable of type java.sql.Connection, you'd
definitely run into problems.
OK. Thanks, I had a field problem.
.V


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

Re: Close to RC2?

[Vic Cekvenich]

Well long term  ( in order to "jettison" non MVC "features" of 
Struts, which there are a few it could jetison to commons, etc.) , I 
think data source should not be in Struts-confin, deprecated.
(see the confusion in user list  + containers provide data source pool)

So if the "old" code works. "hack it" (with old code)  and deprecate 
maybe?

Just a suggestion.

.V

Ted Husted wrote:
I think the underlying issue was that the DBCP is used to implement the 
GenericDataSource, which was not deprecated in the last release.

http://jakarta.apache.org/struts/doc-1.0.2/api/org/apache/struts/util/GenericDataSource.html 

I suppose we could fall back to the original implementation, but that 
was not as good as the DBCP and seems like a drastic change.

We might consider making the type required now and deprecating GDS in 
this release, to leave our options open.

At this point, I think the DataSource manager has become a rather neat 
tool and could even standalone as a way to manage connections to various 
datasources. But now that there is a DBCP in the Commons, we can prepare 
to let people acquire that themselves. But for now, it seems like we're 
stuck :(

-T.

David Graham wrote:

Actually, my original thought was to get rid of DBCP because it's a 
problem child dependency and not everyone needs it.  We could leave 
the  element because it's useful to those who need it 
but they would have to provide the implementation class (change the 
"type" attribute to required).

But we could just leave everything how it is and only use released 
versions of DBCP after they get the next release of it out.

Dave

On Mon, 24 Mar 2003, David Graham wrote:

> Date: Mon, 24 Mar 2003 12:38:01 -0700
> From: David Graham <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: Close to RC2?
>
> >The commons-pool dependency is indeed inherited from 
commons-dbcp.  We
> >can't actually remove GenericDataSource (in 1.1), because it wasn't
> >deprecated in 1.0 -- we'll be able to clean that up next time 
around if we
> >want (but we should warn people in the struts-config DTD that the 
whole
> > element will go away, if that's really what we want 
to do).
> >
>
> Why would the data-sources element have to go away just because
> GenericDataSource is removed?
>

What would we use instead to implement the data sources?  The
original question (as I understood it) was how to get rid of 
commons-pool,
which would also require getting rid of commons-dbcp and therefore
eliminating the org.apache.commons.dbcp.BasicDataSource implementation
class.

> >Craig
>
> David
>
Craig

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


_
The new MSN 8: advanced junk mail protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail

-
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: forms tag ? serialaizable

[Vic Cekvenich]

If your UserBean class declares "implements Serializable", this means that
UserBean also takes responsibility for saving and restoring the instance
variables of the base class as well.  If it doesn't, then your UserBean
class is broken.  The only thing the container should need to do is an
"instanceof Serializable" test.


public class UserBean extends ValidatorForm
implements Serializable, Collection { // class }
My concreate does. But the container I think sees is as 
ValidatorForm which it tags as not Serializable and throws an 
exception. I could test by making ActionForm implement Seriazable, see 
if that "fixes" it.

tia,

.V


The servlet spec requires that a container disallow setting a session
attribute that is not Serializable if you use the  element
in your web.xml file.  Tomcat implements this behavior, and it should be
portable to any other container that conforms to the spec.



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

forms tag ? serialaizable

[Vic Cekvenich]

AFAIK we can't specify the "type of class" that the form bean is in, in 
struts config. (not formbean, but )

For example, 

This would allow me to implement session fail over of session beans.

AFAIK, this was depercated in 1.1.
Yes, this can be miss-used but
So can someone educate me that this works, else it's a feature request.

Easy way to test is to add this to resin, for example:
  
WEB-INF/session
  
This give me exception that formbean is not seriazable (concreate class 
is, ie  is, but the base class 
is not. This is true of Collections as well)

tia,
Vic


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

Re: [STP] RC1 Release Plan

[Vic Cekvenich]

Would this be RC2 of Final?

.V

Ted Husted wrote:
I'll update the plan and website later, but for now, the outstanding 
RC1->RC2 list stands at five tickets [NOT RESOLVED, NOT CLOSED, STRUTS, 
NOT UNKNOWN].

http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=VERIFIED&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&product=Struts&version=0.5+Final&version=1.0+Beta+1&version=1.0+Beta+2&version=1.0+Beta+3&version=1.0+Final&version=1.0.1+Final&version=1.0.2+Final&version=1.1+Beta+1&version=1.1+Beta+2&version=1.1+Beta+3&version=1.1+RC1&version=Nightly+Build&short_desc=&short_desc_type=allwordssubstr&long_desc=&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&keywords=&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&newqueryname=&order=Bug+Number 

-T.

Ted Husted wrote:

I'm going to make run at the bug list and update the Release Plan, as 
we did for b3.

-T.



-
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] Abstraction layer betwenn the httpServlet packageand the action classes

[Vic Cekvenich]

I do something similar:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/basicportal/bP/WEB-INF/src/war/org/apache/scaffoldingLib/base/BaseAct.java
See the execute has execute(ActionEvent ae) {} and a dispatcher.
This way people can add what ever they want to Event/Context object and 
it's thread safe.

As pointed out, it makes it easier to do non HTML, like SOAP (included 
in Resin 3.1).

YAAS (Yet Anoother Action Signature).
.V


Emmanuel Feller wrote:
Hello everybody,

I am still quiet newby in struts technologies, but i am
working on a mvc framework for 2years and when i started
2months ago using struts i was supprised : everytime i want
to push some information from my action classe to my jsp i
must take the request or the session.
So writing a struts application is not simple because it
need knowledge of servlet and jsp technologies.
I am hacking the code to add an abstraction layer, but i
prefer do a proposal before submit a patch. This is a better
way to standardize the API and to have a stable release more
quickly ... or to retake a good way if i am
miss-understanding.
I propose a sessionManager, which is a technical wrapper to
the session. It is able to take care of the mappings,
request and session.
I add three context :
a ViewContext, a HashMap, into which you push your data. So
you don't have to take back the request or session anymore.
The viewContext should be use to manage business data as
well as technicals ones ...
a ModuleContext, this is an intermediate level betwenn the
request scope and the session scope. information in
available only in the module where you are.
a SessionContext, this is a wrapper for session. Information
are available at any time in any module.
One advantage of the module is the segmentation of
information, so you can't have anymore conflict into 2
modules when you push data into the session object.
I also change the signature for the execute method :
ActionForm X (SessionManager, ViewContext,
ModuleContext, ActionForm)
I do not include the mapping because i am searching an issue
to make the navigation available to the developper : it
should be automatic and only in exception case do
redirection. (i don't have found the better way yet).
I have not inserted the name of the method because i propose
an enhancement into struts-config for action tag. We should
add a command tag, if it is present, the method called will
be the named, else it will be the standard execute method.
So when you have lots of action on a screen, it will not
need lots of action class, only bigger one ...
We are able to do the transformation with backward
compatibility, ie into 1.2 family, or into 2.0 family, as
you prefer. But it will need lots of modifications into
taglibs.
We can do the modification in 2 times, the first (into 1.2)
could be only the add of the new interfaces, and preserve
backward compatibility, the second one into 2.0 family could
be total refactor of the core request processing and also
add new transport protocol (ie ftp, soap, ... ) to make
struts open for new technologies as IRC services ;)) ...
I am waiting for your comments,

Regards,
Emmanuel Feller
Senior Developper
Cap Gemini Ernst & Young
+33 2 51 17 35 00 phone 3716
+33 6 23 34 63 39


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

Re: Short term plans

[Vic Cekvenich]

Yes, it was James, and I join thanking him, et. all.

The effect is feature creep delaying a release with a limited pool of 
resources, for things that some would like to deprecate. Like in Struts 
1.2 supporting Tomcat 3.x? That takes time, and limits what can be done 
in other areas.

Surely you agree that some tags should slowly move to jakarta.taglib?

And if I can disagree on the stats, my anecdotal evidence is that 
projects in development are Tomcat 4.x (JSP and Servlet API).

Else consider adding developers (keep an eye on Matt Raible, Ben 
Tomasini, Scot Skyles, Ibatis.com guy, Tiles 201 guy, Stxx guy, 
sf.struts people,  ... )

Again, my hope is that a "quick 1.2" release is Servlet 2.3 and EL.

( Struts 2.0 wish list?: more soapy, and JSP2.0, maven, jelly, and 
http://ireport.sourceforge.net/images/screenshot6.gif drag and drop 2 
way from jsp to beans, jdk 1.4)

I am now teaching JSP 2.0 in Resin 3/Tomcat 5 in my Struts classe with 
this 2.0 syntax:
${ibean['field']}
By the time their 6 month project cycle is ready to deploy, JSP2.0 will 
be out.

Just take it into consideration, a faster development cycle, means 
making some "austerity choices" in 1.2. Alternative? Struts 1.2 in  
18 months?

.V





Craig R. McClanahan wrote:
On Fri, 28 Feb 2003, David Graham wrote:


Date: Fri, 28 Feb 2003 17:50:08 -0700
From: David Graham <[EMAIL PROTECTED]>
Reply-To: Struts Developers List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: Short term plans
The taglibs are a heavily used feature.  We get a lot of bug reports on them
so the tests are badly needed.  There is no doubt that we should use JSTL
but at this point not everyone has that option.


At JavaOne US 2002 (March 2002) I did a survey of the folks that came to
the Struts Community BOF.  Over half the people there were developing and
deploying on J2EE 1.2 (i.e. Servlet 2.2 and JSP 1.1) platforms.  Yes, it's
almost a year later now, but the situation has not *totally* changed.
JSTL (and JavaServer Faces, when it becomes available) require Servlet 2.3
and JSP 1.2, so they are not even an option for a very significant portion
of the Struts user community.  Thus, it would be irresponsible to abandon
our focus on ensuring the quality of the Struts tag libraries -- and this
would be true even if Struts was a commercial product instead of an open
source package.
That being said, it's very clear where the future is for view tier
technology.  But that's for the future (Struts 1.2 and beyond) -- and,
even for those future Struts versions, users are not always able to
convert their applications instantly.  We need to care now, and will
continue to need to care in the future, about the quality of the existing
Struts tag libraries.  I'm totally delighted that someone like David has
cared enough to create such a comprehensive test suite for a feature that
is critically important to a very large majority of current, and future,
Struts users.
Thanks David!


David


Craig


With respect, consider how much time struts-devs should spend on tags, I
kind of agree with those that say slowly move them over to taglibs and
separate jar away from "core" struts, for example if JSTL can do it.
Of course I know, open source means donating contributors kind of get to
work on what they want.
my 2 c.
.V
Karr, David wrote:

-Original Message-
From: James Mitchell [mailto:[EMAIL PROTECTED]
My plans are to finish up html this weekend, and tiles, upload, and
validator by the end of next week.  After that I hope to get all the
nested tags done between 3/15 and 3/22, then move on to the struts-el
tags.
The only thing that might delay things is the fact that my contract is
almost up and I'm desperately looking for another job.
Does anyone object or is there a special focus that anyone wants to
get


covered quickly?

Also, are there any volunteers out there wanting to help me get this
stuff nailed?


Sigh.

If your new testing setup is reasonably straightforward, I wouldn't
imagine it could be very difficult for me or someone else to clone them
(and remove some) for the Struts-EL tests.  There already is a set of
Cactus tests for Struts-EL which covered more than the original base
Struts tests did, but your new work has very likely jumped well past
that.
In short, if you've finished everything you need to do for bean, logic,
and html, and you have some doors to knock on, then give me what I need
to know and I'll implement the Struts-EL tests (or someone else, if they
wanted to do this).  If Aaron has time, he could probably do the same
for the nested tags.


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


_
The new MSN 8: smart spam protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail
-
To unsubscri

Re: Short term plans

[Vic Cekvenich]

With respect, consider how much time struts-devs should spend on tags, I 
kind of agree with those that say slowly move them over to taglibs and 
separate jar away from "core" struts, for example if JSTL can do it.

Of course I know, open source means donating contributors kind of get to 
work on what they want.

my 2 c.
.V
Karr, David wrote:
-Original Message-
From: James Mitchell [mailto:[EMAIL PROTECTED]
My plans are to finish up html this weekend, and tiles, upload, and
validator by the end of next week.  After that I hope to get all the
nested tags done between 3/15 and 3/22, then move on to the struts-el
tags.
The only thing that might delay things is the fact that my contract is
almost up and I'm desperately looking for another job.
Does anyone object or is there a special focus that anyone wants to
get

covered quickly?

Also, are there any volunteers out there wanting to help me get this
stuff nailed?


Sigh.

If your new testing setup is reasonably straightforward, I wouldn't
imagine it could be very difficult for me or someone else to clone them
(and remove some) for the Struts-EL tests.  There already is a set of
Cactus tests for Struts-EL which covered more than the original base
Struts tests did, but your new work has very likely jumped well past
that.
In short, if you've finished everything you need to do for bean, logic,
and html, and you have some doors to knock on, then give me what I need
to know and I'll implement the Struts-EL tests (or someone else, if they
wanted to do this).  If Aaron has time, he could probably do the same
for the nested tags.


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

Re: [ANNOUNCEMENT] Struts 1.1 Release Candidate 1 released

[Vic Cekvenich]

Thanks!!
I am sure everyone is thriled.
.V
Martin Cooper wrote:
The Struts team is proud to announce the release of Struts 1.1 Release
Candidate 1. This release includes some new functionality, as well as
fixes for a number of bugs which were reported against earlier versions.
The Struts Team believes that this release is ready for prime time, hence
its designation as a release candidate.
The binary distribution is available at:

http://www.apache.org/dist/jakarta/struts/binaries/

and the source distribution is available at:

http://www.apache.org/dist/jakarta/struts/source/

In addition, the library distribution, which contains updated binaries
without the sample applications, is available at:
http://www.apache.org/dist/jakarta/struts/library/

Details of the changes in this release are available in the Release Notes,
which can be found here:
http://jakarta.apache.org/struts/userGuide/release-notes-1.1-rc1.html

--
Martin Cooper


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

OT: Soap MVC Link

[Vic Cekvenich]

There was a thread while back on SOAP/Struts, somone said growth is in 
that direction, and I agree.

Here is a link related
http://www.improve-technologies.com/alpha/mvc4ws
it might be of use.
I am not sure if it's more of a Axis extension or Struts extension, I 
would hope it's 2nd.
.V



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

Re: FMT tag and form bean

[Vic Cekvenich]

Let's try again:
:-)
http://jakarta.apache.org/struts/userGuide/struts-html.html#text
This does not let me localize or format.

Lets say I have a bean that has a #, String getStartDate().

If I sometimes use this bean on a read only page, I could do JSP FMT to 
format and localize.

I sometime want to use the same bean on a R/W form submit page.
String getStartDate(), hut html:text does not format or localize. The 
traditional approach I used was to format to native types inside the 
setters/getters.

Point is I can't format a localize in html:text, but can in JSTL.

So the only place is in the bean, inside the getStartDate() {}.

The other alternative is to copy.

And I must have misunderstood what you were saying, but I think I now 
understand the issues surouding it enough.

.V



Martin Cooper wrote:
"Vic Cekvenich" <[EMAIL PROTECTED]> wrote in message
b2uf0d$5gb$[EMAIL PROTECTED]">news:b2uf0d$5gb$[EMAIL PROTECTED]...


I would like to format in the JSP if possible (for both).

Let me just restate what I think you are saying:
"Since JSTL can format strings, allways format and localize in the
formBean".



No, that doesn't make any sense. I'm saying "Since JSTL can format strings,
always format and localise in the JSP page". I don't understand why you need
to do any of it in the bean, hence my last message.



So as you point out, I can format and localize both in the bean. (Ex:
formBean.setLocale(x) )



Um, I didn't point that out at all.

--
Martin Cooper




So probably a better choice.

But... since I like how the FMT tag works not sure what "best"
approach is. I almost want to cross post to JSPTag-user, see if Geary is
around. but it's really not that big a deal.
A student in a class asked why this was and I was stuttering, so I
posted to get it of my chest and maybe as a wish list for HTML-EL tag.

You and Ted pointed out some things however.

.V



Martin Cooper wrote:


"Vic Cekvenich" <[EMAIL PROTECTED]> wrote in message
b2u5oq$p8b$[EMAIL PROTECTED]">news:b2u5oq$p8b$[EMAIL PROTECTED]...



Thanks as always Ted and Martin.
I would still have to format the number in the bean for Form, and
localize dates (for the Candian dates), etc in the bean class.  If the
page is read only, I would format in JSP.



I guess I don't understand. Why do you need to do formatting in the


bean,


and why is it different if the page is read-only? You should be able to


use


JSTL to do this in either case.

--
Martin Cooper





So far getAge() and
getAgeInt() look ok. I wonder which way the faces tag will work.
(yes, if know, if I copied data for the form bean  but if I have
nested and multi row and many to many, it's kind of a pain; one day I
will write reflection with dynaRowSet to clone nesting, localize, format
and put in basicPortal)
.V

Martin Cooper wrote:



"Vic Cekvenich" <[EMAIL PROTECTED]> wrote in message
b2t728$t7c$[EMAIL PROTECTED]">news:b2t728$t7c$[EMAIL PROTECTED]...




I have been nudging people toiwards JSTL.
A nice feature is FMT tag that formats the number, date, etc. in the
JSP. FMT tag needs the formBeans to return int!



No, it does not. If you provide a string to the format tags, such as
, it will convert it to the appropriate numeric type.


Try



the following:

- cut here -
<%@ taglib prefix="fmt" uri="http://java.sun.com/jstl/fmt"; %>

<%
  request.setAttribute("foo", "1234567890");
%>


- cut here -

To avoid any question of what other JSTL tags might be doing, I've
explicitly stored a string in a request attribute. The output from the


above



page is:

$1,234,567,890.00

The  tag did its job just fine when passed a string
instead of an integer.

--
Martin Cooper






So if one does a FORM for updates you create formbean with String
getAge(), and number formated in Java before returning the String.

If then you just want to display the # (no update) you need to create


a


bean with int getAge(), and FMT it in JSP.


So return int for JSTL and String for formBean.

A prefered solution is that HTML tag is able to do formating like FMT


tag.



.V

Also, it be nice if tiles was able to do some EL, or have a nicer way


of


FORWARDING to diferent JSP from the tile action one day.




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

Re: FMT tag and form bean

[Vic Cekvenich]

I would like to format in the JSP if possible (for both).

Let me just restate what I think you are saying:
"Since JSTL can format strings, allways format and localize in the 
formBean".

So as you point out, I can format and localize both in the bean. (Ex: 
formBean.setLocale(x) )
So probably a better choice.

But... since I like how the FMT tag works not sure what "best" 
approach is. I almost want to cross post to JSPTag-user, see if Geary is 
around. but it's really not that big a deal.
A student in a class asked why this was and I was stuttering, so I 
posted to get it of my chest and maybe as a wish list for HTML-EL tag.

You and Ted pointed out some things however.

.V



Martin Cooper wrote:
"Vic Cekvenich" <[EMAIL PROTECTED]> wrote in message
b2u5oq$p8b$[EMAIL PROTECTED]">news:b2u5oq$p8b$[EMAIL PROTECTED]...


Thanks as always Ted and Martin.
I would still have to format the number in the bean for Form, and
localize dates (for the Candian dates), etc in the bean class.  If the
page is read only, I would format in JSP.



I guess I don't understand. Why do you need to do formatting in the bean,
and why is it different if the page is read-only? You should be able to use
JSTL to do this in either case.

--
Martin Cooper




So far getAge() and
getAgeInt() look ok. I wonder which way the faces tag will work.
(yes, if know, if I copied data for the form bean  but if I have
nested and multi row and many to many, it's kind of a pain; one day I
will write reflection with dynaRowSet to clone nesting, localize, format
and put in basicPortal)
.V

Martin Cooper wrote:


"Vic Cekvenich" <[EMAIL PROTECTED]> wrote in message
b2t728$t7c$[EMAIL PROTECTED]">news:b2t728$t7c$[EMAIL PROTECTED]...



I have been nudging people toiwards JSTL.
A nice feature is FMT tag that formats the number, date, etc. in the
JSP. FMT tag needs the formBeans to return int!



No, it does not. If you provide a string to the format tags, such as
, it will convert it to the appropriate numeric type.


Try


the following:

- cut here -
<%@ taglib prefix="fmt" uri="http://java.sun.com/jstl/fmt"; %>

<%
   request.setAttribute("foo", "1234567890");
%>


- cut here -

To avoid any question of what other JSTL tags might be doing, I've
explicitly stored a string in a request attribute. The output from the


above


page is:

$1,234,567,890.00

The  tag did its job just fine when passed a string
instead of an integer.

--
Martin Cooper





So if one does a FORM for updates you create formbean with String
getAge(), and number formated in Java before returning the String.

If then you just want to display the # (no update) you need to create a
bean with int getAge(), and FMT it in JSP.


So return int for JSTL and String for formBean.

A prefered solution is that HTML tag is able to do formating like FMT


tag.



.V

Also, it be nice if tiles was able to do some EL, or have a nicer way of
FORWARDING to diferent JSP from the tile action one day.




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

Re: FMT tag and form bean

[Vic Cekvenich]

Thanks as always Ted and Martin.
I would still have to format the number in the bean for Form, and 
localize dates (for the Candian dates), etc in the bean class.  If the 
page is read only, I would format in JSP.  So far getAge() and 
getAgeInt() look ok. I wonder which way the faces tag will work.
(yes, if know, if I copied data for the form bean  but if I have 
nested and multi row and many to many, it's kind of a pain; one day I 
will write reflection with dynaRowSet to clone nesting, localize, format 
and put in basicPortal)
.V

Martin Cooper wrote:
"Vic Cekvenich" <[EMAIL PROTECTED]> wrote in message
b2t728$t7c$[EMAIL PROTECTED]">news:b2t728$t7c$[EMAIL PROTECTED]...


I have been nudging people toiwards JSTL.
A nice feature is FMT tag that formats the number, date, etc. in the
JSP. FMT tag needs the formBeans to return int!



No, it does not. If you provide a string to the format tags, such as
, it will convert it to the appropriate numeric type. Try
the following:

- cut here -
<%@ taglib prefix="fmt" uri="http://java.sun.com/jstl/fmt"; %>

<%
request.setAttribute("foo", "1234567890");
%>


- cut here -

To avoid any question of what other JSTL tags might be doing, I've
explicitly stored a string in a request attribute. The output from the above
page is:

$1,234,567,890.00

The  tag did its job just fine when passed a string
instead of an integer.

--
Martin Cooper




So if one does a FORM for updates you create formbean with String
getAge(), and number formated in Java before returning the String.

If then you just want to display the # (no update) you need to create a
bean with int getAge(), and FMT it in JSP.


So return int for JSTL and String for formBean.

A prefered solution is that HTML tag is able to do formating like FMT tag.


.V

Also, it be nice if tiles was able to do some EL, or have a nicer way of
FORWARDING to diferent JSP from the tile action one day.




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

FMT tag and form bean

[Vic Cekvenich]

I have been nudging people toiwards JSTL.
A nice feature is FMT tag that formats the number, date, etc. in the 
JSP. FMT tag needs the formBeans to return int!

So if one does a FORM for updates you create formbean with String 
getAge(), and number formated in Java before returning the String.

If then you just want to display the # (no update) you need to create a 
bean with int getAge(), and FMT it in JSP.


So return int for JSTL and String for formBean.

A prefered solution is that HTML tag is able to do formating like FMT tag.


.V

Also, it be nice if tiles was able to do some EL, or have a nicer way of 
FORWARDING to diferent JSP from the tile action one day.



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

Online presentations comitters

[Vic Cekvenich]

I think I said this but if any comitter want to attend (and has 
[EMAIL PROTECTED]), I can get the the access codes to
http://www.mail-archive.com/mvc-programmers%40basebeans.net/msg6.html

Also, if any comitter has the urge to present something, great.
.V



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

OT: Re: Last Bug!

[Vic Cekvenich]

Excuse me, I am in a bad mood:

http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/http/HttpSession.html
Can we just "ASSERT" the container servlet container is 2.2 or 2.3 and 
call the right method?

ASSERT- get it?

Benjamin Tomasini wrote:
FieldChecks doesn't extend Action, which has that method.  I think that
keeping with servlet spec 2.2 will prevent walking from request to
session to context, too.

On Wed, 2003-02-05 at 21:59, Vic Cekvenich wrote:


Stuipd answer- Xcuse me:
getServlet().getContext()?

David Graham wrote:


The last bug we have for 1.1 is stumping me.  
o.a.s.validator.FieldChecks validation methods call 
Resources.getActionError(request...

Resources.getActionError() calls Resources.getMessageResources(request)

There are several versions of Resources.getMessageResources(), one that 
takes a request and one that takes a ServletContext.

We need a version of that method that takes both arguments so it can 
look in the context if the module's bundle isn't in the request.  
However, I don't see any way of getting a ServletContext to pass in 
there starting from FieldChecks' validation methods.

Help?

Dave



_
Protect your PC - get McAfee.com VirusScan Online  
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963



-
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: Last Bug!

[Vic Cekvenich]

Stuipd answer- Xcuse me:
getServlet().getContext()?

David Graham wrote:

The last bug we have for 1.1 is stumping me.  
o.a.s.validator.FieldChecks validation methods call 
Resources.getActionError(request...

Resources.getActionError() calls Resources.getMessageResources(request)

There are several versions of Resources.getMessageResources(), one that 
takes a request and one that takes a ServletContext.

We need a version of that method that takes both arguments so it can 
look in the context if the module's bundle isn't in the request.  
However, I don't see any way of getting a ServletContext to pass in 
there starting from FieldChecks' validation methods.

Help?

Dave



_
Protect your PC - get McAfee.com VirusScan Online  
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963



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