You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Ted Husted <hu...@apache.org> on 2003/06/30 22:52:33 UTC
[PROPOSAL] Modular Struts Examples
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
webapps into a single "struts-docs" application, where each of the
existing applications becomes a module. (Leaving the struts-blank out,
since it is meant as a application template.)
At the same time, I would like to take Steve Raeburn up on his kind
offer to donate his Struts-Examples application
http://www.ninsky.com/struts/
to Struts and the Apache Software Foundation.
The Struts-Examples application offers a number of very useful code
samples. We can continue to grow the examples step-by-step over time and
defray many of the requests on the list for code samples.
As part of refactoring the various Struts applications into a single
application of several modules, we can also bring Steve's application on
board as another module to "Struts-Docs".
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [PROPOSAL] Modular Struts Examples
Posted by Ted Husted <hu...@apache.org>.
Vic Cekvenich wrote:
> -0.
>
> Module was... is optional and confusing. I think delay this a point
> after 1.2.
I'd say the opposite. We need to "eat our own dog food" and use modules
in our own applications or drop that line of development altogether.
Given modules in 1.1, it's hard to justify distributing all these
picyune applications, that could just as easily be modules.
> 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.
The upload example application uses the Commons-Fileupload package. If
we bring the Struts Examples module online, the file upload example
would be just one of these, and wouldn't need to be a separate application.
> I would like for 1.2 to ... (can someone set up a "wish list" wiki
> please?)
The Wiki is open to everyone. Asking someone else to setup a wiki page
is contrary to the whole idea of a wiki =:0)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [PROPOSAL] Modular Struts Examples
Posted by David Graham <gr...@yahoo.com>.
--- "Craig R. McClanahan" <cr...@apache.org> wrote:
>
>
> On Thu, 3 Jul 2003, Vic Cekvenich wrote:
>
> > Date: Thu, 03 Jul 2003 16:32:02 -0400
> > From: Vic Cekvenich <vi...@baseBeans.com>
> > Reply-To: Struts Developers List <st...@jakarta.apache.org>
> > To: struts-dev@jakarta.apache.org
> > Subject: Re: [PROPOSAL] Modular Struts Examples
> >
> >
> >
> > 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.
> >
>
> Target what? The core of Struts? As you'll see from my other message,
> I'd rather see us skip 2.3 for Struts 2.0; the incremental benefits of
> Servlet 2.4 and JSP 2.0 are well worth it.
I agree with skipping 2.3. I don't much care about the Servlet 2.4 stuff
but JSP 2.0 is a big deal.
David
>
> >
> > .V
>
> Craig
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [PROPOSAL] Modular Struts Examples
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 3 Jul 2003, Vic Cekvenich wrote:
> Date: Thu, 03 Jul 2003 16:32:02 -0400
> From: Vic Cekvenich <vi...@baseBeans.com>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: struts-dev@jakarta.apache.org
> Subject: Re: [PROPOSAL] Modular Struts Examples
>
>
>
> 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.
>
Target what? The core of Struts? As you'll see from my other message,
I'd rather see us skip 2.3 for Struts 2.0; the incremental benefits of
Servlet 2.4 and JSP 2.0 are well worth it.
>
> .V
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [PROPOSAL] Modular Struts Examples
Posted by Vic Cekvenich <vi...@baseBeans.com>.
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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [PROPOSAL] Modular Struts Examples
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 3 Jul 2003, Vic Cekvenich wrote:
> Date: Thu, 03 Jul 2003 15:27:58 -0400
> From: Vic Cekvenich <vi...@baseBeans.com>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: struts-dev@jakarta.apache.org
> Subject: Re: [PROPOSAL] Modular Struts Examples
>
> 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?
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.
>
> 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:
>
> <table border="0">
> <tr>
> <td class="text_high" width="800">
> <li> ${fb['title']}
> </td>
> </tr>
> <tr>
> <td class="text">
> <br>
> ${fb['content']}
> </td>
> </tr>
> </table>
>
> 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.
Well, if you actually use <c:out> you still have to declare the tag
library :-). But your point is well taken, that you don't even need to
use <c:out> in most cases.
>
>
> .V
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [PROPOSAL] Modular Struts Examples
Posted by Vic Cekvenich <vi...@baseBeans.com>.
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:
<table border="0">
<tr>
<td class="text_high" width="800">
<li> ${fb['title']}
</td>
</tr>
<tr>
<td class="text">
<br>
${fb['content']}
</td>
</tr>
</table>
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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts Next Generation [was Modular ...]
Posted by Ted Husted <hu...@apache.org>.
I don't know about anyone else around here, but my own goal is to find
the easiest and best way to write, maintain, and enhance business
applications. In today's enterprise environment, this means web
applications. If someone wants me to write Java applications, I write
Java applications. If someone wants me to use something else, I can use
something else. Means to an end.
IMHO, when we start focusing on this technology versus that
technology, we start to miss the point. Most of the patterns and
strategies we discuss here and on the user list transcend platform
implementation details.
A composable request processor is a composable request processor,
whether you implement it in Java, C#, or Python.
The Struts DTD is platform agnostic. It doesn't imply a specific
implementation. Right now, the action.type leads to a Action class. But
that's just an implementation detail. The soul of Struts is the
implementations that our DTD permit and encourage, not the
implementations themselves. The land is not the map.
Struts has become a proof of concept for two key ideas. First, that an
application could be driven from an XML site map. Second, that custom
tags are way better than scriplets. =:0)
We've proven (2) and (1) is becoming accepted. But, IMHO, the important
thing isn't whether we use this platform release or that platform
release, or even what platform we use. The important thing is where we
take the site map. The app is the map.
Sure, the ActionServlet is a front-controller. But, IMHO, the true
Controller, the C in MVC, is the graph of objects described by the
configuration document. Every plaform provides Models and Views, but
little is provided for the Controller. This is why Struts, and the many
projects like it, are so important. We are filling a vacuum.
I need to finish my study of JSF before proposing anything, but what I
would like to see for Struts "Next Generation" is a more expressive DTD,
especially one that could be implemented in different ways and on
different platforms. [At which point, I fully expect to branded a
heretic and driven off to SourceForge =;0)]
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [PROPOSAL] Modular Struts Examples
Posted by Vic Cekvenich <vi...@baseBeans.com>.
>
> 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 open source implementation. There's already more
> than a few books underway that will help developers understand how to use
> JavaServer Faces. And we're not even to Proposed Final Draft yet.
>
> I will take "anti-patterns" that are that successful any day of the week
> :-).
>
>
Yes, in my eyes, EJB was bad for J2EE, and made Java develoers look bad
(relatively slow, relatively complex). JBoss 4.x ships with JDO now, and
"Bitter EJB" book and aproaches are more openly talked about, people use
people use Hibrenate and iBatis, there no EJB components I can think of.
So people paid run time fees, say $5K per CPU, and ... then they would
not use major features.
That is the analogy I see with JSF. The thing is back in EJB 1.0, there
was no .NET, and now there is
(http://www.datagridgirl.com/customcolumns.aspx) .
If JSF is sucessfull like EJB is, there is a choice now, and I do now
want to be embarased as a Java Server side developer, I would rather switch.
(http://www.borland.com/csharpbuilder/demo/CsharpBuilderDemoShort.htm)
I do feel sad. In my own mind Craig is not able to persuade the JCP
comitte to simplify JSF and make it client side. I can imagine a design
by comitte, and someone try to reason with them.
(I know Craig, JSF could be use browser side rendering, like we do not
need to use Enity Beans, only Session Beans, and maybe a graphic artist
learns JSF, and we figure how to "optimize" calendar, and tree controls
.... )
Books by profesional authors that do not have production track record
and only document API are opinionated and not much use.
>>So lets say this is what JSF is, simplified as a faces tag:
>>http://jakarta.apache.org/ecs/index.html
>>That is all JSF is, Java GUI.
>>
>>Why not do Tapestry or 10 others as a view. ( I am using Flash more and
>>more, since it can also talk to C# via XML)
>
>
> With most web applicaton frameworks (and, to my limited understanding of
> Tapestry it follows this model), whatever UI component support they have
> is generally NOT available stand alone; instead, it is integrated into,
> and assumes the use of, the rest of the framework as well. Being view
> agnostic works great when you're talking about not dictating whether to
> use JSP or Velocity or FreeMarker -- it doesn't work so great at the
> component level in a page where the components assume infrastructure on
> the server side as well.
>
>
>>Jstl 1.1 is Apache license.
>
>
> One particular implementation of JSTL is Apache licensed. It's not the
> only one in the world. That's the nice thing about specs that can be
> implemented by multiple folks who compete on quality but have to ensure
> compatibility.
>
>
>> What if JSF RI has run time fees, or can
>>you state now for a fact that Sun RI will not have any run time fees?
>
>
> The RI for JavaServer Faces will be redistributable and usable in
> commercial environments once the spec goes final. Further, JavaServer
> Faces is on the list of JSRs for which Sun has guaranteed support, and
> even scholarships, for non-profit organizations that want to implement
> JavaServer Faces and then test their implementation for compatibility with
> the TCK (again, just like Servlet, JSP, JSTL, and others).
>
> So can we stop with the FUD about licensing now ?
I .. am not smart enough to figure above out, so let me restate in my
words what I understood from above: Sun JSF RI might have run time fees,
but non Sun JSF might be free run time and would not have to pay for TCK
only? (I can't see the SF.net guy paying Sun to get the TCK, so Sun
might give him a grant? ) That is why I say, I want to wait till 1.0 is
out, so I can read the license.
I have to pass architectures by legal and budget approval. And then I
have to explain why not DataGrid from www.asp.net.
>>
>>
>>Yes, 2.0 rules.
>
>
> But you can't use it yet -- it's still an EA license, and nobody can ship
> a final product that claims to implement it.
>
TC5.02 has been release as has Resin 3.1.
bP today downloads with TC5 and Resin 3 integrated, both have a great
license.
> Guess we should wait until JSP 2.0 goes final to decide whether we
want to
> use it in Struts :-).
Programmers don't have *small* egos. If JSF support, then JSP 2.0 or at
least JSP 1.2.
Did I say that it be good for ASF, J2EE, Java, and world peace if Struts
treats JSF like EJB. You can do it, here's the docs, but good luck.
JSF is GUI in Java, for those who think this is great and should be
allowed like EJB is, but not encouraged.
The reason I like Struts is that it is simple, fast, open.
Thanks Craig!!
.V
>>>
>>>
>
>
> Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [PROPOSAL] Modular Struts Examples
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 3 Jul 2003, Vic Cekvenich wrote:
> Date: Thu, 03 Jul 2003 17:22:21 -0400
> From: Vic Cekvenich <vi...@baseBeans.com>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: struts-dev@jakarta.apache.org
> Subject: Re: [PROPOSAL] Modular Struts Examples
>
>
> 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.
Simple for developers to implement if we chose to. Disastrous for Struts
users, because it would break 100% of the Action and ActionForm
implementations in the world, unless you provide backwards compatible
hooks that continue to support the existing APIs -- and that just makes
life more complicated, not less.
> >
> >
> >>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.
Forgot to mention one other crucially important factor ... JavaServer
Faces does not require the back-end bean to extend any particular
subclass, or implement any particular interface (how's THAT for a way to
avoid the whole class-versus-interface debate about ActionFom? :-).
>
> >
> > * 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.
No more so than Struts ... it's all defined by a configuration file that
maps names to classes. In Struts that's only done for form beans, in
JavaServer Faces its done globally when you evaluate a value reference
expression.
> It should map to the
> form(JSP). And then what about bean.populate()
In JavaServer Faces, each component maintains a value reference expression
pointing at the back-end model bean property (if any) that should be
updated if validation succeeds, or should be the source of dynamically
displayed data at render time. There is no need for anything like
BeanUtils.populate(), although reflection is still used on the individual
fields as value reference expressions are evaluated.
> and if there is no data
> found or ...
> Model 1!
Like it or not, there are a whole lot more developers in the world that
are familiar with Model 1 than there are familiar with Model 2, especially
in the Microsoft arena, but certainly not limited to there. In order to
make the Java platform appealing to these folks, we've got to provide
easier ways to convert than the "give up your stupid architecture and
start over" spiel that has been the primary message these people here
from us Model-2-ites.
>
> >
> > 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, but could)
> >>
> >
> >
> > In the Apache world, Maven provides similar sorts of capabilities, and
> > does not require you to give up the ability to use plain old Ant (Maven
> > can generate a build.xml file for you). If we're going to switch, I'd
> > rather go that direction (if the Maven folks would ever ship a final
> > release, at least).
> >
> > Improving the build process is definitely needed, but that's mostly for us
> > as developers, not for users.
>
> That is what I meant on Maven.
> OK, if you developers need users to do some of the leg work.
>
> >
> >
> >>Required in DTD of sturts-config the request processor element. - This
> >>nudges expert users in extending Struts in the right place, it exposes
> >>the right place overlooked.
> >
> >
> > In the "workflow" component of jakarta-commons-sandbox, one of the things
> > I really liked was using XML namespaces as an extensibility mechanism. It
> > seems like a natural way to let people integrate extensions of their own
> > into an existing standard configuration file format.
> >
> > However, DTDs are not powerful enough to allow for this -- you have to go
> > to XML Schema (or something equivalent) to support it (the way that all
> > the deployment descriptors in J2EE 1.4 are going), or else give up on the
> > idea of validation at all. That's too big a price to pay. And, as long
> > as we're based on Servlet 2.2 / JSP 1.1, we can't really get away with
> > requiring schema support, so it's tough to move forwards on this one in
> > the short term.
> >
> >
> >>Reduce number of actions and formbeans in Struts. It could be consolidated.
> >
> >
> > I can see what you're saying on form beans, but what do you mean by
> > "reduce the number of actions"?
>
> DisptachAction, LookupDispatchAction, ForwardAction, Switchaction
> (even tilesaction if you change the execute signature)
> If they can be consolidated, good I think
Actually, I think consolidating things often makes them more complicated,
rather than less. Consolidation was the philosophy that led to a
monolithic RequestProcessor that is hard to customize in multiple ways
inside the same application.
DispatchAction and LookupDispatchAction could perhaps be consolidated, but
neither has much to do with what ForwardAction and SwitchAction do.
>
> >
> >
> >>DAO - OK, here I walk a fine line.
> >>Struts is model agnostic. But slowest part of J2EE is DAO; and Struts is
> >>the most popular J2EE framework. No one outside of Struts-dev can fix
> >>this. If there can be an interface (I know, if you change it.... bla,
> >>bla) for a DAO, that is KISS, but could work for JDO, EJB, Hibrenate,
> >>RowSet, MQ, etc. etc. It would enable people to easily plug and play a
> >>model. I do not care what the signatures of this DAO are other than it
> >>must allow ANY DAO implementation to be used and shoud be unit testable
> >>for CRUD.
> >>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/basicportal/bPproj/src/war/com/baseBeans/scaFfoldingXpress/base/DAO.java
> >>Craig, I realy realy think that only you can make this happen. (That
> >>registration of DAO for JSF I did not like, interface is KISS)
> >
> >
> > There is more than one "right" way to integrate persistent data and
> > business logic into a web application, DAOs being only one of them. There
> > is more than one "right" way to design DAOs, depending on your particular
> > requirements. Whatever we do in Struts needs to recognize that it is not
> > going to be possible to shoehorn everyone's requirements into a single
> > pattern.
> >
> > For the particular case of tabular data, we should also be paying
> > attention to recent innovations in JDBC RowSet Implementations (JSR-114)
> > that just went to Public Review Draft in the JCP process.
>
> Yes, as you know I was one of the early chapions of RowSet for a long
> time ( and worked on fixing many of the bugs in the early release into
> open source pg driver.)
>
>
> I would expect
> > to see early access RI code for this stuff shortly, and it will be
> > interesting to see how well those folks did on a standardized abstraction
> > to rows and columns, with much stronger support for disconencted operation
> > cases.
> >
> > But rows and columns doesn't cover all of the world's needs either ....
> >
>
> If there are any signatures to which we can agree as DAO that would
> work... that would be great for J2EE.
> We do not need to see RI of RowSet since we know the API now.
> Yes OMG model should be supported, maybe just return Object in DAO
> interface? (datagrid, did I say that enough?)
>
> >
> >>Display tag- (Talk out of bouth sides of your mouth) Yes Stuts is view
> >>agnostic. But Display tag commiters are trying to make it updateable
> >>AFAIK. Download the display tag war and run examples. This is the
> >>colosest thing to DataGrid in JSP. Put it in Struts to get focus (and
> >>then slowly move to taglibs).
> >
> >
> > I am not personally interested in being in the proprietary custom tag
> > development business at all any more ... JSP 2.0, JSTL, and JavaServer
> > Faces have made (or will make, in the latter case) further innovations on
> > non-standards-based tag libraries a waste of long term time. We need to
> > maintain and enhance the existing implementations, and fix the things that
> > are wrong with them -- but the future is going to be based on the standard
> > APIs, if we want to continue to be a mainstream platform. We need to
> > continue to welcome and integrate the new technologies (as we've done with
> > JSTL and Faces so far).
> >
>
> Display tag is Apache license, and open source.
> DataGrid like is very important and there is nothing like that. Maybe
> based it more on JSTL or JSP2.0?
As I said at JavaOne, a high quality UI component supporting DataGrid is a
release driver for JavaServer Faces 1.0 to be viable. It wasn't ready for
the last EA release, but will be soon.
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.
>
>
> > Recast the display taglib (or anything else in the same space) as
> > JavaServer Faces components and I'll be interested in it. Incorporate JSF
> > component libraries from your favorite development tool or open source
> > project, and I'll be interested in it. Suggest that we create some of our
> > own value-added components based on Faces (so that we're not limited to
> > just JSP, and not limited to just rendering HTML), and I will be
> > interested in it.
>
> 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.
> 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". :-)
>
>
> Continue to innovate on top of the current form bean
> > architecture, and I'm probably not going to be interested in it for the
> > long term.
>
> >
> > Other Struts developers, of course, can speak for themselves.
> >
>
> 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.
>
> >
> >>Anything else out of bP that somoene likes. (Ex: j2Ee + Sturts security
> >>example, multi row updates, events - like action changed event for
> >>session clean up)
> >
> >
> > There are undoubtedly some ideas from bP (and other things built on top of
> > Struts) that can be harvested in a 1.x time frame, now that we got 1.1 out
> > the door. A lot of resistance to this in the past has been based on
> > wanting to get that (1.1) done, not by concerns about technical merit or
> > suitability for inclusion.
> >
> > (Regarding examples, having lots of small-to-medium examples seems better
> > than having few huge ones; but that's a topic for the other thread.)
> >
> Agree, more medium examples vs few big examples.
>
> > My only concern goes back to the comments about DAOs above -- when there
> > is legitimately more than one approach to dealing with a particular issue,
> > you want to be careful about baking in one-and-only-one approach into the
> > fundamental architecture. And, when there are standard APIs in the same
> > space of endeavor, you ignore them only at the risk of becoming
> > non-mainstream in the long run.
> >
> >
> >>Target servlet 2.3 and JDK 1.4. - 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....
> >
> >
> > For Struts 1.2, we have already agreed to stay with Servlet 2.2 / JSP 1.1,
> > but change our release cycle to do incremental releases much more often
> > (the way that Tomcat and the HTTPD server do it nowdays). Besides a
> > continuied commitment to backwards compatibility in APIs, this puts
> > restrictions on how frisky we can get with changes to old stuff (adding
> > new stuff actually becomes easier with the new release cycle approach).
> >
> > For Struts 2.0, I think we should actually skip Servlet 2.3 / JSP 1.2, and
> > go straight to Servlet 2.4 / JSP 2.0 / JSTL 1.1 /
>
>
> Great!!!!
>
>
>
> JavaServer Faces 1.0
> -1
> 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 open source implementation. There's already more
than a few books underway that will help developers understand how to use
JavaServer Faces. And we're not even to Proposed Final Draft yet.
I will take "anti-patterns" that are that successful any day of the week
:-).
>
> So lets say this is what JSF is, simplified as a faces tag:
> http://jakarta.apache.org/ecs/index.html
> That is all JSF is, Java GUI.
>
> Why not do Tapestry or 10 others as a view. ( I am using Flash more and
> more, since it can also talk to C# via XML)
With most web applicaton frameworks (and, to my limited understanding of
Tapestry it follows this model), whatever UI component support they have
is generally NOT available stand alone; instead, it is integrated into,
and assumes the use of, the rest of the framework as well. Being view
agnostic works great when you're talking about not dictating whether to
use JSP or Velocity or FreeMarker -- it doesn't work so great at the
component level in a page where the components assume infrastructure on
the server side as well.
>
> Jstl 1.1 is Apache license.
One particular implementation of JSTL is Apache licensed. It's not the
only one in the world. That's the nice thing about specs that can be
implemented by multiple folks who compete on quality but have to ensure
compatibility.
> What if JSF RI has run time fees, or can
> you state now for a fact that Sun RI will not have any run time fees?
The RI for JavaServer Faces will be redistributable and usable in
commercial environments once the spec goes final. Further, JavaServer
Faces is on the list of JSRs for which Sun has guaranteed support, and
even scholarships, for non-profit organizations that want to implement
JavaServer Faces and then test their implementation for compatibility with
the TCK (again, just like Servlet, JSP, JSTL, and others).
So can we stop with the FUD about licensing now ?
>
> as
> > the base platform. Because of the lengthy gestation period for J2EE 1.4
> > as a whole, it won't be long after 1.4 goes final that we'll have lots of
> > containers available to host such apps. It doesn't make sense to do any
> > fundamental architectural improvements in the core Struts APIs without
> > recognizing that this will be the commonly deployed platform by the time
> > we get done.
> >
> > Servlet 2.4's changes (request lifecycle listeners, and the ability to
> > execute filters on RD calls) are not earth-shattering, but they are
> > useful.
>
> JSP 2.0's changes, on the other hand, are very fundamental (if
> > you're using JSP as the basis for your view technology)
>
> Yes, 2.0 rules.
But you can't use it yet -- it's still an EA license, and nobody can ship
a final product that claims to implement it.
Guess we should wait until JSP 2.0 goes final to decide whether we want to
use it in Struts :-).
>
> , and eliminate the
> > need to use Java code for lots of things where it is used today. For
> > example, a page author can point at a chunk of JSP code and say, in
> > essence, "please make a custom tag out of this for me". And, of course,
> > EL expressions are evaluated anywhere in the page (even static text), so
> > tags like <bean:write> basically lose their reason to exist. And, for the
> > cases where custom tags written in Java are still required, the new
> > SimpleTag API is *substantially* easier to write aganst than the current
> > Tag/BodyTag stuff.
> >
> >
> >>I will do the legwork on any of these, if a single dev is interested in
> >>applying the diff., but most are trivial and do not need man hours. The
> >>last one I hope makes it for the 1.2 release
> >
> >
> > Nobody can decide whether or not to apply a specific change without seeing
> > precisely what you're proposing to modify. A lot of the things you've
> > suggested in this email would break backwards compatibility, and thereby
> > earn a -1 for implementation in 1.2, but might well make sense in a 2.0
> > world.
>
> Thanks.
> .V
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [PROPOSAL] Modular Struts Examples
Posted by Vic Cekvenich <vi...@baseBeans.com>.
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, but could)
>>
>
>
> In the Apache world, Maven provides similar sorts of capabilities, and
> does not require you to give up the ability to use plain old Ant (Maven
> can generate a build.xml file for you). If we're going to switch, I'd
> rather go that direction (if the Maven folks would ever ship a final
> release, at least).
>
> Improving the build process is definitely needed, but that's mostly for us
> as developers, not for users.
That is what I meant on Maven.
OK, if you developers need users to do some of the leg work.
>
>
>>Required in DTD of sturts-config the request processor element. - This
>>nudges expert users in extending Struts in the right place, it exposes
>>the right place overlooked.
>
>
> In the "workflow" component of jakarta-commons-sandbox, one of the things
> I really liked was using XML namespaces as an extensibility mechanism. It
> seems like a natural way to let people integrate extensions of their own
> into an existing standard configuration file format.
>
> However, DTDs are not powerful enough to allow for this -- you have to go
> to XML Schema (or something equivalent) to support it (the way that all
> the deployment descriptors in J2EE 1.4 are going), or else give up on the
> idea of validation at all. That's too big a price to pay. And, as long
> as we're based on Servlet 2.2 / JSP 1.1, we can't really get away with
> requiring schema support, so it's tough to move forwards on this one in
> the short term.
>
>
>>Reduce number of actions and formbeans in Struts. It could be consolidated.
>
>
> I can see what you're saying on form beans, but what do you mean by
> "reduce the number of actions"?
DisptachAction, LookupDispatchAction, ForwardAction, Switchaction
(even tilesaction if you change the execute signature)
If they can be consolidated, good I think
>
>
>>DAO - OK, here I walk a fine line.
>>Struts is model agnostic. But slowest part of J2EE is DAO; and Struts is
>>the most popular J2EE framework. No one outside of Struts-dev can fix
>>this. If there can be an interface (I know, if you change it.... bla,
>>bla) for a DAO, that is KISS, but could work for JDO, EJB, Hibrenate,
>>RowSet, MQ, etc. etc. It would enable people to easily plug and play a
>>model. I do not care what the signatures of this DAO are other than it
>>must allow ANY DAO implementation to be used and shoud be unit testable
>>for CRUD.
>>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/basicportal/bPproj/src/war/com/baseBeans/scaFfoldingXpress/base/DAO.java
>>Craig, I realy realy think that only you can make this happen. (That
>>registration of DAO for JSF I did not like, interface is KISS)
>
>
> There is more than one "right" way to integrate persistent data and
> business logic into a web application, DAOs being only one of them. There
> is more than one "right" way to design DAOs, depending on your particular
> requirements. Whatever we do in Struts needs to recognize that it is not
> going to be possible to shoehorn everyone's requirements into a single
> pattern.
>
> For the particular case of tabular data, we should also be paying
> attention to recent innovations in JDBC RowSet Implementations (JSR-114)
> that just went to Public Review Draft in the JCP process.
Yes, as you know I was one of the early chapions of RowSet for a long
time ( and worked on fixing many of the bugs in the early release into
open source pg driver.)
I would expect
> to see early access RI code for this stuff shortly, and it will be
> interesting to see how well those folks did on a standardized abstraction
> to rows and columns, with much stronger support for disconencted operation
> cases.
>
> But rows and columns doesn't cover all of the world's needs either ....
>
If there are any signatures to which we can agree as DAO that would
work... that would be great for J2EE.
We do not need to see RI of RowSet since we know the API now.
Yes OMG model should be supported, maybe just return Object in DAO
interface? (datagrid, did I say that enough?)
>
>>Display tag- (Talk out of bouth sides of your mouth) Yes Stuts is view
>>agnostic. But Display tag commiters are trying to make it updateable
>>AFAIK. Download the display tag war and run examples. This is the
>>colosest thing to DataGrid in JSP. Put it in Struts to get focus (and
>>then slowly move to taglibs).
>
>
> I am not personally interested in being in the proprietary custom tag
> development business at all any more ... JSP 2.0, JSTL, and JavaServer
> Faces have made (or will make, in the latter case) further innovations on
> non-standards-based tag libraries a waste of long term time. We need to
> maintain and enhance the existing implementations, and fix the things that
> are wrong with them -- but the future is going to be based on the standard
> APIs, if we want to continue to be a mainstream platform. We need to
> continue to welcome and integrate the new technologies (as we've done with
> JSTL and Faces so far).
>
Display tag is Apache license, and open source.
DataGrid like is very important and there is nothing like that. Maybe
based it more on JSTL or JSP2.0?
> Recast the display taglib (or anything else in the same space) as
> JavaServer Faces components and I'll be interested in it. Incorporate JSF
> component libraries from your favorite development tool or open source
> project, and I'll be interested in it. Suggest that we create some of our
> own value-added components based on Faces (so that we're not limited to
> just JSP, and not limited to just rendering HTML), and I will be
> interested in it.
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.
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.
Continue to innovate on top of the current form bean
> architecture, and I'm probably not going to be interested in it for the
> long term.
>
> Other Struts developers, of course, can speak for themselves.
>
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?
>
>>Anything else out of bP that somoene likes. (Ex: j2Ee + Sturts security
>>example, multi row updates, events - like action changed event for
>>session clean up)
>
>
> There are undoubtedly some ideas from bP (and other things built on top of
> Struts) that can be harvested in a 1.x time frame, now that we got 1.1 out
> the door. A lot of resistance to this in the past has been based on
> wanting to get that (1.1) done, not by concerns about technical merit or
> suitability for inclusion.
>
> (Regarding examples, having lots of small-to-medium examples seems better
> than having few huge ones; but that's a topic for the other thread.)
>
Agree, more medium examples vs few big examples.
> My only concern goes back to the comments about DAOs above -- when there
> is legitimately more than one approach to dealing with a particular issue,
> you want to be careful about baking in one-and-only-one approach into the
> fundamental architecture. And, when there are standard APIs in the same
> space of endeavor, you ignore them only at the risk of becoming
> non-mainstream in the long run.
>
>
>>Target servlet 2.3 and JDK 1.4. - 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....
>
>
> For Struts 1.2, we have already agreed to stay with Servlet 2.2 / JSP 1.1,
> but change our release cycle to do incremental releases much more often
> (the way that Tomcat and the HTTPD server do it nowdays). Besides a
> continuied commitment to backwards compatibility in APIs, this puts
> restrictions on how frisky we can get with changes to old stuff (adding
> new stuff actually becomes easier with the new release cycle approach).
>
> For Struts 2.0, I think we should actually skip Servlet 2.3 / JSP 1.2, and
> go straight to Servlet 2.4 / JSP 2.0 / JSTL 1.1 /
Great!!!!
JavaServer Faces 1.0
-1
JSF needs to be more open, scaleable, rich UI (right now not even
Javascript support).
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.
So lets say this is what JSF is, simplified as a faces tag:
http://jakarta.apache.org/ecs/index.html
That is all JSF is, Java GUI.
Why not do Tapestry or 10 others as a view. ( I am using Flash more and
more, since it can also talk to C# via XML)
Jstl 1.1 is Apache license. What if JSF RI has run time fees, or can
you state now for a fact that Sun RI will not have any run time fees?
as
> the base platform. Because of the lengthy gestation period for J2EE 1.4
> as a whole, it won't be long after 1.4 goes final that we'll have lots of
> containers available to host such apps. It doesn't make sense to do any
> fundamental architectural improvements in the core Struts APIs without
> recognizing that this will be the commonly deployed platform by the time
> we get done.
>
> Servlet 2.4's changes (request lifecycle listeners, and the ability to
> execute filters on RD calls) are not earth-shattering, but they are
> useful.
JSP 2.0's changes, on the other hand, are very fundamental (if
> you're using JSP as the basis for your view technology)
Yes, 2.0 rules.
, and eliminate the
> need to use Java code for lots of things where it is used today. For
> example, a page author can point at a chunk of JSP code and say, in
> essence, "please make a custom tag out of this for me". And, of course,
> EL expressions are evaluated anywhere in the page (even static text), so
> tags like <bean:write> basically lose their reason to exist. And, for the
> cases where custom tags written in Java are still required, the new
> SimpleTag API is *substantially* easier to write aganst than the current
> Tag/BodyTag stuff.
>
>
>>I will do the legwork on any of these, if a single dev is interested in
>>applying the diff., but most are trivial and do not need man hours. The
>>last one I hope makes it for the 1.2 release
>
>
> Nobody can decide whether or not to apply a specific change without seeing
> precisely what you're proposing to modify. A lot of the things you've
> suggested in this email would break backwards compatibility, and thereby
> earn a -1 for implementation in 1.2, but might well make sense in a 2.0
> world.
Thanks.
.V
>
>
>>.V
>
>
> Craig
>
>
>
>>
>>
>>V
>>
>>>
>>>Craig
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [PROPOSAL] Modular Struts Examples
Posted by James Mitchell <jm...@apache.org>.
That's great!! I'm looking forward to capitalizing on your success.....oh
wait....I'm doing that already, thanks again!!!
--
James Mitchell
Software Developer/Struts Evangelist
http://www.struts-atlanta.org
678-910-8017
AIM:jmitchtx
----- Original Message -----
From: "Ted Husted" <hu...@apache.org>
To: "Struts Developers List" <st...@jakarta.apache.org>
Sent: Wednesday, July 23, 2003 8:03 AM
Subject: Re: [PROPOSAL] Modular Struts Examples
> Just wanted to mention that I did some work on the "Struts University"
> application last week, and it seemed to work well in a classroom
> environment. I'll have another post regarding this soon.
>
>
> Ted Husted wrote:
> > I've started work on a "Struts University" application, based on Steve's
> > Struts Examples application.
> >
> > Struts University uses the same "Tomcat Example" format. The idea is
> > that the examples will be ordered and grouped to help teach Struts
> > through a series of working examples.
>
> <snip/>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [PROPOSAL] Modular Struts Examples
Posted by Ted Husted <hu...@apache.org>.
Just wanted to mention that I did some work on the "Struts University"
application last week, and it seemed to work well in a classroom
environment. I'll have another post regarding this soon.
Ted Husted wrote:
> I've started work on a "Struts University" application, based on Steve's
> Struts Examples application.
>
> Struts University uses the same "Tomcat Example" format. The idea is
> that the examples will be ordered and grouped to help teach Struts
> through a series of working examples.
<snip/>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [PROPOSAL] Modular Struts Examples
Posted by Ted Husted <hu...@apache.org>.
I've started work on a "Struts University" application, based on Steve's
Struts Examples application.
Struts University uses the same "Tomcat Example" format. The idea is
that the examples will be ordered and grouped to help teach Struts
through a series of working examples.
I've made a prototype available for review. The first example is using
an action as welcome page (via redirection). This does double duty as
the welcome page to the university application.
The prototype with the first example is up on SourceForge.
http://sourceforge.net/project/showfiles.php?group_id=49385
It's way down under the "slides" release category. I put it under the
"slides", since I may do a set of companion presentations to go with
these, so it becomes more like an actual class.
[See org.apache.struts.university.UniversityTestCase.APP_ROOT before
trying to run the test target.]
My intention is to use simple-but-effective best practices throughout
the application and examples and to also use all the standard
bells-and-whistles like Tiles and the Validator.
I'd also like to provide Struts TestCases for each example. This package
has been available on SourceForge for some time and is growing in
popularity. There are still some rough edges, but nothing that can't be
smoothed out. (One of which is that you usually need to set the local
system path to run the Mock tests.) I'm sure the examples will generate
some useful patches -- I've one pending already.
The proposed end-game would be to first consolidate our various examples
(upload, validator, tiles, Steve's examples, and more) into the Struts
University application. Then, we could considering making the
MailReader, Taglib-Exercises, University, and the Website Documentation,
all standalone modules of a single "Struts Library" application. (Blank
would remain standalone.)
It's my feeling that a single modular application will not only save
bandwidth on the binary downloads (since all the same JARs are
replicated in each), it will make everything more accessible, since the
Struts Library application can act as a portal to the modules.
Of course, I'll setup a prototype that everyone can play-test before
suggesting any changes to the HEAD.
-Ted.
--
Ted Husted,
Junit in Action - <http://www.manning.com/massol/>,
Struts in Action - <http://husted.com/struts/book.html>,
JSP Site Design - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [PROPOSAL] Modular Struts Examples
Posted by Phil Steitz <ph...@steitz.com>.
Craig R. McClanahan wrote:
>
>
>
> 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.
>
Can you expand a little on what you mean here, Craig?
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [PROPOSAL] Modular Struts Examples
Posted by Vic Cekvenich <vi...@baseBeans.com>.
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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [PROPOSAL] Modular Struts Examples
Posted by Vic Cekvenich <vi...@baseBeans.com>.
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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [PROPOSAL] Modular Struts Examples
Posted by Ted Husted <hu...@apache.org>.
Craig R. McClanahan wrote:
>>Display tag- (Talk out of bouth sides of your mouth) Yes Stuts is view
> <snip/>
> Other Struts developers, of course, can speak for themselves.
There are a ton of very cool extension for Struts, DisplayTag, SSL-Ext,
Struts-Menu, to name a very few. Many more than we could ever try to
support here.
But, the beauty of the open source world is that we don't ~need~ to
support everything here. People can setup projects at SourceForge and so
forth and do everything there that they could do here.
I'd like to see more HOW-TOs in our documentation in regard to the many
extensions. But it's up to the people using these extensions to
contribute them. I'm also hoping to get caught up on the resources page
soon, which is also sadly behind the times.
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).
-Ted.
--
Ted Husted,
Struts in Action <http://husted.com/struts/book.html>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [PROPOSAL] Modular Struts Examples
Posted by "Craig R. McClanahan" <cr...@apache.org>.
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.
>
> 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.
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.
* 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.
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, but could)
>
In the Apache world, Maven provides similar sorts of capabilities, and
does not require you to give up the ability to use plain old Ant (Maven
can generate a build.xml file for you). If we're going to switch, I'd
rather go that direction (if the Maven folks would ever ship a final
release, at least).
Improving the build process is definitely needed, but that's mostly for us
as developers, not for users.
> Required in DTD of sturts-config the request processor element. - This
> nudges expert users in extending Struts in the right place, it exposes
> the right place overlooked.
In the "workflow" component of jakarta-commons-sandbox, one of the things
I really liked was using XML namespaces as an extensibility mechanism. It
seems like a natural way to let people integrate extensions of their own
into an existing standard configuration file format.
However, DTDs are not powerful enough to allow for this -- you have to go
to XML Schema (or something equivalent) to support it (the way that all
the deployment descriptors in J2EE 1.4 are going), or else give up on the
idea of validation at all. That's too big a price to pay. And, as long
as we're based on Servlet 2.2 / JSP 1.1, we can't really get away with
requiring schema support, so it's tough to move forwards on this one in
the short term.
>
> Reduce number of actions and formbeans in Struts. It could be consolidated.
I can see what you're saying on form beans, but what do you mean by
"reduce the number of actions"?
>
> DAO - OK, here I walk a fine line.
> Struts is model agnostic. But slowest part of J2EE is DAO; and Struts is
> the most popular J2EE framework. No one outside of Struts-dev can fix
> this. If there can be an interface (I know, if you change it.... bla,
> bla) for a DAO, that is KISS, but could work for JDO, EJB, Hibrenate,
> RowSet, MQ, etc. etc. It would enable people to easily plug and play a
> model. I do not care what the signatures of this DAO are other than it
> must allow ANY DAO implementation to be used and shoud be unit testable
> for CRUD.
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/basicportal/bPproj/src/war/com/baseBeans/scaFfoldingXpress/base/DAO.java
> Craig, I realy realy think that only you can make this happen. (That
> registration of DAO for JSF I did not like, interface is KISS)
There is more than one "right" way to integrate persistent data and
business logic into a web application, DAOs being only one of them. There
is more than one "right" way to design DAOs, depending on your particular
requirements. Whatever we do in Struts needs to recognize that it is not
going to be possible to shoehorn everyone's requirements into a single
pattern.
For the particular case of tabular data, we should also be paying
attention to recent innovations in JDBC RowSet Implementations (JSR-114)
that just went to Public Review Draft in the JCP process. I would expect
to see early access RI code for this stuff shortly, and it will be
interesting to see how well those folks did on a standardized abstraction
to rows and columns, with much stronger support for disconencted operation
cases.
But rows and columns doesn't cover all of the world's needs either ....
>
> Display tag- (Talk out of bouth sides of your mouth) Yes Stuts is view
> agnostic. But Display tag commiters are trying to make it updateable
> AFAIK. Download the display tag war and run examples. This is the
> colosest thing to DataGrid in JSP. Put it in Struts to get focus (and
> then slowly move to taglibs).
I am not personally interested in being in the proprietary custom tag
development business at all any more ... JSP 2.0, JSTL, and JavaServer
Faces have made (or will make, in the latter case) further innovations on
non-standards-based tag libraries a waste of long term time. We need to
maintain and enhance the existing implementations, and fix the things that
are wrong with them -- but the future is going to be based on the standard
APIs, if we want to continue to be a mainstream platform. We need to
continue to welcome and integrate the new technologies (as we've done with
JSTL and Faces so far).
Recast the display taglib (or anything else in the same space) as
JavaServer Faces components and I'll be interested in it. Incorporate JSF
component libraries from your favorite development tool or open source
project, and I'll be interested in it. Suggest that we create some of our
own value-added components based on Faces (so that we're not limited to
just JSP, and not limited to just rendering HTML), and I will be
interested in it. Continue to innovate on top of the current form bean
architecture, and I'm probably not going to be interested in it for the
long term.
Other Struts developers, of course, can speak for themselves.
>
> Anything else out of bP that somoene likes. (Ex: j2Ee + Sturts security
> example, multi row updates, events - like action changed event for
> session clean up)
There are undoubtedly some ideas from bP (and other things built on top of
Struts) that can be harvested in a 1.x time frame, now that we got 1.1 out
the door. A lot of resistance to this in the past has been based on
wanting to get that (1.1) done, not by concerns about technical merit or
suitability for inclusion.
(Regarding examples, having lots of small-to-medium examples seems better
than having few huge ones; but that's a topic for the other thread.)
My only concern goes back to the comments about DAOs above -- when there
is legitimately more than one approach to dealing with a particular issue,
you want to be careful about baking in one-and-only-one approach into the
fundamental architecture. And, when there are standard APIs in the same
space of endeavor, you ignore them only at the risk of becoming
non-mainstream in the long run.
> Target servlet 2.3 and JDK 1.4. - 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....
For Struts 1.2, we have already agreed to stay with Servlet 2.2 / JSP 1.1,
but change our release cycle to do incremental releases much more often
(the way that Tomcat and the HTTPD server do it nowdays). Besides a
continuied commitment to backwards compatibility in APIs, this puts
restrictions on how frisky we can get with changes to old stuff (adding
new stuff actually becomes easier with the new release cycle approach).
For Struts 2.0, I think we should actually skip Servlet 2.3 / JSP 1.2, and
go straight to Servlet 2.4 / JSP 2.0 / JSTL 1.1 / JavaServer Faces 1.0 as
the base platform. Because of the lengthy gestation period for J2EE 1.4
as a whole, it won't be long after 1.4 goes final that we'll have lots of
containers available to host such apps. It doesn't make sense to do any
fundamental architectural improvements in the core Struts APIs without
recognizing that this will be the commonly deployed platform by the time
we get done.
Servlet 2.4's changes (request lifecycle listeners, and the ability to
execute filters on RD calls) are not earth-shattering, but they are
useful. JSP 2.0's changes, on the other hand, are very fundamental (if
you're using JSP as the basis for your view technology), and eliminate the
need to use Java code for lots of things where it is used today. For
example, a page author can point at a chunk of JSP code and say, in
essence, "please make a custom tag out of this for me". And, of course,
EL expressions are evaluated anywhere in the page (even static text), so
tags like <bean:write> basically lose their reason to exist. And, for the
cases where custom tags written in Java are still required, the new
SimpleTag API is *substantially* easier to write aganst than the current
Tag/BodyTag stuff.
>
> I will do the legwork on any of these, if a single dev is interested in
> applying the diff., but most are trivial and do not need man hours. The
> last one I hope makes it for the 1.2 release
Nobody can decide whether or not to apply a specific change without seeing
precisely what you're proposing to modify. A lot of the things you've
suggested in this email would break backwards compatibility, and thereby
earn a -1 for implementation in 1.2, but might well make sense in a 2.0
world.
>
> .V
Craig
>
>
>
> V
> >>
> >
> >
> > Craig
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [PROPOSAL] Modular Struts Examples
Posted by David Graham <gr...@yahoo.com>.
> 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.
Providing upload ability in Struts is needed. Struts is designed to make
developing webapps simple, not ripping out functionality and telling
people to go do it themselves.
> Maveric instead of Ant for build. My argument is this. CVS out
> CommonsSQL and use Maverick to build it. Sexy!
I don't know what you mean by this but CVS and Ant are *well* understood
by thousands of developers. There is no reason to change it now.
> 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, but could)
>
> Required in DTD of sturts-config the request processor element. - This
> nudges expert users in extending Struts in the right place, it exposes
> the right place overlooked.
>
> Reduce number of actions and formbeans in Struts. It could be
> consolidated.
>
> DAO - OK, here I walk a fine line.
> Struts is model agnostic. But slowest part of J2EE is DAO; and Struts is
>
> the most popular J2EE framework. No one outside of Struts-dev can fix
> this. If there can be an interface (I know, if you change it.... bla,
> bla) for a DAO, that is KISS, but could work for JDO, EJB, Hibrenate,
> RowSet, MQ, etc. etc. It would enable people to easily plug and play a
> model. I do not care what the signatures of this DAO are other than it
> must allow ANY DAO implementation to be used and shoud be unit testable
> for CRUD.
>
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/basicportal/bPproj/src/war/com/baseBeans/scaFfoldingXpress/base/DAO.java
> Craig, I realy realy think that only you can make this happen. (That
> registration of DAO for JSF I did not like, interface is KISS)
There is a project in the Commons sandbox called Mapper that attempts to
do exactly this. Struts has no business incorporating DAOs.
>
> Display tag- (Talk out of bouth sides of your mouth) Yes Stuts is view
> agnostic. But Display tag commiters are trying to make it updateable
> AFAIK. Download the display tag war and run examples. This is the
> colosest thing to DataGrid in JSP. Put it in Struts to get focus (and
> then slowly move to taglibs).
>
> Anything else out of bP that somoene likes. (Ex: j2Ee + Sturts security
> example, multi row updates, events - like action changed event for
> session clean up)
>
> Target servlet 2.3 and JDK 1.4. - 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....
>
> I will do the legwork on any of these, if a single dev is interested in
> applying the diff., but most are trivial and do not need man hours. The
> last one I hope makes it for the 1.2 release
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
>
>
>
> V
> >>
> >
> >
> > Craig
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>
=== message truncated ===
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [PROPOSAL] Modular Struts Examples
Posted by Vic Cekvenich <vi...@baseBeans.com>.
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
> <html:file> 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 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.
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, but could)
Required in DTD of sturts-config the request processor element. - This
nudges expert users in extending Struts in the right place, it exposes
the right place overlooked.
Reduce number of actions and formbeans in Struts. It could be consolidated.
DAO - OK, here I walk a fine line.
Struts is model agnostic. But slowest part of J2EE is DAO; and Struts is
the most popular J2EE framework. No one outside of Struts-dev can fix
this. If there can be an interface (I know, if you change it.... bla,
bla) for a DAO, that is KISS, but could work for JDO, EJB, Hibrenate,
RowSet, MQ, etc. etc. It would enable people to easily plug and play a
model. I do not care what the signatures of this DAO are other than it
must allow ANY DAO implementation to be used and shoud be unit testable
for CRUD.
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/basicportal/bPproj/src/war/com/baseBeans/scaFfoldingXpress/base/DAO.java
Craig, I realy realy think that only you can make this happen. (That
registration of DAO for JSF I did not like, interface is KISS)
Display tag- (Talk out of bouth sides of your mouth) Yes Stuts is view
agnostic. But Display tag commiters are trying to make it updateable
AFAIK. Download the display tag war and run examples. This is the
colosest thing to DataGrid in JSP. Put it in Struts to get focus (and
then slowly move to taglibs).
Anything else out of bP that somoene likes. (Ex: j2Ee + Sturts security
example, multi row updates, events - like action changed event for
session clean up)
Target servlet 2.3 and JDK 1.4. - 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....
I will do the legwork on any of these, if a single dev is interested in
applying the diff., but most are trivial and do not need man hours. The
last one I hope makes it for the 1.2 release
.V
V
>>
>
>
> Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [PROPOSAL] Modular Struts Examples
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 2 Jul 2003, Vic Cekvenich wrote:
> Date: Wed, 02 Jul 2003 06:55:06 -0400
> From: Vic Cekvenich <vi...@baseBeans.com>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: struts-dev@jakarta.apache.org
> Subject: Re: [PROPOSAL] Modular Struts Examples
>
> -0.
>
> Module was... is optional and confusing. I think delay this a point
> after 1.2.
>
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".
> 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
<html:file> 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. 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 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 :-)
>
> (after 1.2 consolidate actions and beans classes).
>
> .V
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [PROPOSAL] Modular Struts Examples
Posted by Vic Cekvenich <vi...@baseBeans.com>.
-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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [PROPOSAL] Modular Struts Examples
Posted by Rob Leland <rl...@apache.org>.
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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [PROPOSAL] Modular Struts Examples
Posted by David Graham <gr...@yahoo.com>.
I made a plea a while back for a module example app to test module
features in. It looks like I may get my wish after all :-).
+1 but modules seem buggy at the moment so maybe we should fix those
problems first.
David
--- Ted Husted <hu...@apache.org> 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
>
> webapps into a single "struts-docs" application, where each of the
> existing applications becomes a module. (Leaving the struts-blank out,
> since it is meant as a application template.)
>
> At the same time, I would like to take Steve Raeburn up on his kind
> offer to donate his Struts-Examples application
>
> http://www.ninsky.com/struts/
>
> to Struts and the Apache Software Foundation.
>
> The Struts-Examples application offers a number of very useful code
> samples. We can continue to grow the examples step-by-step over time and
>
> defray many of the requests on the list for code samples.
>
> As part of refactoring the various Struts applications into a single
> application of several modules, we can also bring Steve's application on
>
> board as another module to "Struts-Docs".
>
> -Ted.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [PROPOSAL] Modular Struts Examples
Posted by Ted Husted <hu...@apache.org>.
Vic Cekvenich wrote:
> 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
The list of applications we ship now is
struts-blank
struts-documentation (website)
struts-example (MailReader)
struts-exercise-taglib
struts-template
struts-upload
struts-validator
tiles-documentation
I would suggest we can reduce this list to
struts-blank
struts-docs
by making the others modules to struts-docs, and adding an new module,
struts-examples, based on Steve's application.
Template can be removed altoghether, I think. The content of Upload and
Validator can be moved into the Examples module. So, I'd foresee four
modules in struts-docs
examples
exercise-taglibs
mailreader
website
At first there would probably be a tiles-docs module too, but it's
possible that we can reduce those to a section in the examples module.
I think the examples approach to demonstrating how to do things will be
more effective than what we are doing now, with only a small additional
investment of effort. The source page gives you a place to show how it
all fits together, and also to add notes if necessary.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [PROPOSAL] Modular Struts Examples
Posted by Vic Cekvenich <vi...@baseBeans.com>.
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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [PROPOSAL] Modular Struts Examples
Posted by Ted Husted <hu...@apache.org>.
+1 on integration testing. =:)
Though, I think that we will find that once the Examples application is
available, it will turn into a fertile ground for testing the
integration of new features. Rather than trying to stretch the
MailReader to fill a new use case, we can do a use-case example and make
that another of the Examples.
I'm working on a cookbook project that does this for a ton of examples.
It takes a bit of work to keep it all together, but with a few simple
conventions, it can be quite manageable.
For taglibs, I'd suggest we try to add or extend a taglib-exercise for
any new tag or tag enhancement, but IMHO those tests work best as simple
Model 1 creatures without dependencies on other objects.
-Ted
David Graham wrote:
> However we combine the apps I want to make sure MailReader continues to be
> suitable for testing changes in. I often run through and/or modify
> MailReader to test changes before committing them.
>
> David
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [PROPOSAL] Modular Struts Examples
Posted by David Graham <gr...@yahoo.com>.
However we combine the apps I want to make sure MailReader continues to be
suitable for testing changes in. I often run through and/or modify
MailReader to test changes before committing them.
David
--- Ted Husted <hu...@apache.org> 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: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: [PROPOSAL] Modular Struts Examples
Posted by Steve Raeburn <st...@ninsky.com>.
> -----Original Message-----
> From: Ted Husted [mailto:husted@apache.org]
> Sent: July 3, 2003 4:40 AM
> To: Struts Developers List
> Subject: Re: [PROPOSAL] Modular Struts Examples
>
>
> 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.
Perhaps I overstated it when I said "best practices". What I meant is that
in a set of examples aimed at newcomers we should favour clarity over
elegance. That may mean doing things that we wouldn't do in a production
app. I certainly don't intend to demonstrate *bad* practices.
For instance, in my current set of examples there's a great deal of
duplication of code in both the actions and JSPs that would normally be
eliminated. I felt it was important for each example to be self-contained so
that users would not get confused by having to refer to many different
sections of the app to understand how the example worked.
> 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 =:)
See above on why I'm not sure this is so good :-)
My reasoning behind suggesting the two apps is that the former would provide
a minimal demonstration of the functions of Struts where the example is
self-contained and stripped down to the bare minimum in order to not confuse
the user with infrastructure details. The latter would show how to do things
"the right way" in concert with other features. ("The right way" here
meaning one of several possible right ways).
To my mind we're addressing two different issues. The first is functional;
"How do I do ...?" and the second is architectural, "What's the best way to
design ...?". My concern is that combining the two will make it harder than
necessary to understand the simple examples. If they can both be addressed
in the same application without sacrificing clarity then I'm all for it.
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [PROPOSAL] Modular Struts Examples
Posted by Ted Husted <hu...@apache.org>.
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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: [PROPOSAL] Modular Struts Examples
Posted by Steve Raeburn <st...@ninsky.com>.
I think the examples themselves are OK but there's no single place you can
look to find an answer.
I realise that people *should* be able to find everything they need from
what's already there, but I think we need to go the extra mile to put the
information in front of them. It's really self-interest on my part- I'd like
Struts to be *even* more widely adopted but it would be nice not to have to
keep answering the same old questions. If we are able to repeatedly refer
these questions to a single source for the answer, then it *might* just
stick that that's the place to look before you ask a question! If not then
it's still easier to ask people to LATFE (look at the examples ;-))
And if we have a really clear set of introductory functional examples, that
makes it more reasonable IMHO to have a more realistic working example that
need not cater so much to absolute beginners.
Steve
> -----Original Message-----
> From: David Graham [mailto:grahamdavid1980@yahoo.com]
> Sent: July 2, 2003 1:39 PM
> To: Struts Developers List
> Subject: RE: [PROPOSAL] Modular Struts Examples
>
>
> Do users find the examples confusing? I often refer people to the
> struts-example and struts-validator apps for help so I don't think they're
> under publicized. I'm not sure that consolidating the examples would make
> them easier to understand. I certainly want an example module app and an
> app that demonstrates a real world example would also be helpful.
>
> David
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: [PROPOSAL] Modular Struts Examples
Posted by David Graham <gr...@yahoo.com>.
Do users find the examples confusing? I often refer people to the
struts-example and struts-validator apps for help so I don't think they're
under publicized. I'm not sure that consolidating the examples would make
them easier to understand. I certainly want an example module app and an
app that demonstrates a real world example would also be helpful.
David
--- Steve Raeburn <st...@ninsky.com> wrote:
> There are currently seven different webapps within the Struts
> distribution
> that users are referred to for examples of Struts usage:
>
> - struts-blank
> - struts-example
> - struts-excercise-taglib
> - struts-template (not so much)
> - tiles-documentation
> - struts-upload
> - struts-validator
>
> Not to mention the examples hosted at Sourceforge.
>
> Judging by the repetitive nature of certain questions on the user list
> there
> is a problem with finding/understanding the examples and/or
> finding/understanding the documentation.
>
> I have observed that requests for examples tend to fall into two
> distinct
> categories:
> 1. examples demonstrating usage of a particular tag or feature
> 2. examples of best practice in using the Struts framework
>
> I would like to see the existing examples consolidated to just two
> applications, each targeted at one of the categories just mentioned.
>
> The first example application would provide many discrete examples, each
> demonstrating the use of just one feature of struts. This application
> should
> be easy to understand for a new Struts user, should be simple to deploy
> (drop-in war deployment with no configuration required) and should
> become
> *the* point of reference for the Struts documentation and mailing lists.
> It
> could also be used a library of cut-and-paste code. Based on the Tomcat
> examples, I have created what could be the basis for this app
> (http://www.ninsky.com/struts).
>
> 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 :-)
>
> 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.
>
> Struts-blank would continue as the basic starter application template.
>
> I would hope that consolidating the examples and effectively publicizing
> them would help reduce the support burden (call me a dreamer!) and
> enable
> users to become more productive with Struts more quickly.
>
> Steve
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: [PROPOSAL] Modular Struts Examples
Posted by Steve Raeburn <st...@ninsky.com>.
There are currently seven different webapps within the Struts distribution
that users are referred to for examples of Struts usage:
- struts-blank
- struts-example
- struts-excercise-taglib
- struts-template (not so much)
- tiles-documentation
- struts-upload
- struts-validator
Not to mention the examples hosted at Sourceforge.
Judging by the repetitive nature of certain questions on the user list there
is a problem with finding/understanding the examples and/or
finding/understanding the documentation.
I have observed that requests for examples tend to fall into two distinct
categories:
1. examples demonstrating usage of a particular tag or feature
2. examples of best practice in using the Struts framework
I would like to see the existing examples consolidated to just two
applications, each targeted at one of the categories just mentioned.
The first example application would provide many discrete examples, each
demonstrating the use of just one feature of struts. This application should
be easy to understand for a new Struts user, should be simple to deploy
(drop-in war deployment with no configuration required) and should become
*the* point of reference for the Struts documentation and mailing lists. It
could also be used a library of cut-and-paste code. Based on the Tomcat
examples, I have created what could be the basis for this app
(http://www.ninsky.com/struts).
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 :-)
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.
Struts-blank would continue as the basic starter application template.
I would hope that consolidating the examples and effectively publicizing
them would help reduce the support burden (call me a dreamer!) and enable
users to become more productive with Struts more quickly.
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org