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 <te...@gmail.com> on 2005/09/05 22:32:44 UTC
Website Updates
In between coping with a crashed server on my local network, I've
started to make the "final" round of changes on the new website.
I'll be committing these as I go along, but I thought it appropriate
to post the reworked text for the Site and Core homepages directly to
the list. We had talked about the project's goal in terms of a
particular technology ("Struts Classic"). In this version, the
underlying "Model 2" goal bubbles up to the first sentance. From day
one, the idea that Struts exists to promote Model 2 application
architectures has always been there, we've just never put that
sentence front and center before.
----
Welcome to Apache Struts!
The goal of the Apache Struts project is to encourage application
architectures based on the "Model 2" approach, a variation of the
classic Model-View-Controller (MVC) design paradigm. Under Model 2, a
servlet manages business logic execution, and presentation logic
resides mainly in server pages.
The Apache Struts project encourages Model 2 designs in two ways.
First, by providing open source frameworks and toolkits that help
developers build applications for the web. Second, by providing
friendly and honest mailing lists where both newcomers and veterans
can discuss how to use Struts software in their own Model 2
applications.
Originally, the Apache Struts software was distributed as one
monolithic bundle. Today, the Struts project is comprised of several
subprojects. Each subproject has its own website, documentation, and
release cycle, and may be downloaded separately. The six original
Apache Struts subprojects -- Core, Taglibs, Tiles, Extras,
Applications, and EL -- are also being bundled into a distribution
known as "Struts Classic".
Apache Struts is a volunteer project and all support for the framework
is provided by unpaid volunteers. This documentation bundle and the
mailing lists are the primary ways to learn how to use Struts. The
next few pages are devoted to helping you understand what resources
are available to you. Since Apache Struts is a volunteer project, and
our resources are limited, it is important that we first help you help
yourself.
Struts is a project of the The Apache Software Foundation. The
official Apache Struts home page is at http://struts.apache.org/.
----
The rest of the Welcome page text now lives under Struts Core:
----
Welcome to Struts Core
Struts Core provides the invisible underpinnings every professional
web application needs to survive. Struts Core is a flexible control
layer based on standard technologies like Java Servlets, JavaBeans,
ResourceBundles, and XML, as well as various Jakarta Commons packages.
Core helps you create an extensible development environment for your
application, based on published standards and proven design patterns.
Struts Core provides its own Controller component and integrates with
other technologies to provide the Model and the View. For the Model,
Core can interact with standard data access technologies, like JDBC
and EJB, as well as most any third-party packages, like Hibernate,
iBATIS, or Object Relational Bridge. For the View, Core works well
with JavaServer Pages, including JSTL and JSF, as well as Velocity
Templates, XSLT, and other presentation systems.
Struts Core in a Nutshell
A web application uses a deployment descriptor to initialize resources
like servlets and taglibs. The deployment descriptor is formatted as a
XML document and named "web.xml". Likewise, Core uses a configuration
file to initialize its own resources. These resources include
ActionForms to collect input from users, ActionMappings to direct
input to server-side Actions, and ActionForwards to select output
pages.
Here's a simple Struts configuration (struts-config.xml) for a login workflow:
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE struts-config PUBLIC
"-//Apache Software Foundation//DTD Struts Configuration 1.3//EN"
"http://struts.apache.org/dtds/struts-config_1_3.dtd">
<struts-config>
<form-beans>
<form-bean
name="logonForm"
type="app.LogonForm"/>
</form-beans>
<action-mappings>
<action
path="/Welcome"
forward="/pages/Welcome.jsp"/>
<action
path="/Logon"
forward="/pages/Logon.jsp"/>
<action
path="/LogonSubmit"
type="app.LogonAction"
name="logonForm"
scope="request"
validate="true"
input="/pages/Logon.jsp">
<forward
name="success"
path="/pages/Welcome.jsp"/>
<forward
name="failure"
path="/pages/Logon.jsp"/>
</action>
<action
path="/Logoff"
type="app.LogoffAction">
<forward
name="success"
path="/pages/Logoff.jsp"/>
</action>
</action-mappings>
<message-resources parameter="resources.application"/>
</struts-config>
There are several other resources you can specify in Struts
configuration files. You can specify validations for the ActionForms
in an XML descriptor, using the Struts Validator. A standard
extension, Tiles, helps you build pages from smaller fragments.
Struts Core is an extensible framework. Every class deployed by Core
can be replaced by your own default class. The properties of your
default class can be set using the Digester's set-property feature.
This is one reason why there are so many contributor extensions for
Struts Core. Core provides a base framework, but you can still write
your application your way.
For more about Struts and its underlying technologies, see the User
Guide and the Developer Guides.
Is Struts Core the best choice for every project?
No. If you need to write a very simple application, with a handful of
pages, then you might consider a "Model 1" solution that uses only
server pages.
But, if you are writing a more complicated application, with dozens of
pages, that need to be maintained over time, then Struts can help. For
more about whether Model 1 or or MVC/Model 2 is right for you, see
Understanding JavaServer Pages Model 2 architecture and Issues in
Struts Adoption.
What about JSTL and JavaServer Faces?
Next: Struts Core User Guide
----
I really must commend Wendy and James for the excellent work on the
new Struts build. It's working well, and I'm having fun with it. :)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Website Updates
Posted by Wendy Smoak <ja...@wendysmoak.com>.
From: "Ted Husted" <te...@gmail.com>
> Do we expect to have PDF versions of the documentation?
> It's listed on the Website conversion,
> * http://wiki.apache.org/struts/StrutsWebsiteConversion
> and I wondered if anyone was working on it, or had reason to be optimistic
> :)
Yes. I filed a bug against the xdoc plugin that was generating duplicate
ids, which FOP could not deal with. (Basically asking them to give us back
the 'href' attribute for section and subsection tags that we had in our
custom stylesheet.) I got a couple of updates from JIRA yesterday. It
looks like the fix is in version 1.10, but I don't see a release yet.
In addition, James mentioned the PDF plugin yesterday, so maybe he'll get to
it sooner. :)
I think the duplicate section names were in the User Guide-- try 'maven pdf'
in the other sub-projects and see what you get. IIRC, we might need to
create a pdf-navigation.xml file and use -Dmaven.pdf.navigationFile if we
need to exclude/change what's in the pdf vs. the website.
I can't find it now, but I ran across a Maven property that will generate
the website without the reports sections. That might work for distributing
the documentation in HTML format.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Website Updates
Posted by Ted Husted <te...@gmail.com>.
Do we expect to have PDF versions of the documentation?
It's listed on the Website conversion,
* http://wiki.apache.org/struts/StrutsWebsiteConversion
and I wondered if anyone was working on it, or had reason to be optimistic :)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Website Updates
Posted by Christian Meder <ch...@absolutegiganten.org>.
On Tue, 2005-09-06 at 16:49 -0400, Ted Husted wrote:
> On 9/6/05, Christian Meder <ch...@absolutegiganten.org> wrote:
> > How is "Struts Classic" related to this whole discussion ?
> >
> > IMHO Struts Classic describes the core component best. At least that's
> > the part with which I started doing Java web application development 4
> > years ago so it's definitely the oldest part of the Struts framework.
>
> The "Struts Classic" label is being used to describe a distribution of
> the six orginal subprojects, which includes Core:
>
> > Originally, the Apache Struts software was distributed as one
> > monolithic bundle. Today, the Struts project is comprised of several
> > subprojects. Each subproject has its own website, documentation, and
> > release cycle, and may be downloaded separately. The six original
> > Apache Struts subprojects -- Core, Taglibs, Tiles, Extras,
> > Applications, and EL -- are also being bundled into a distribution
> > known as "Struts Classic".
>
> The Core subproject does not include components like the Taglibs and
> Tiles. Experience proves that we *do* want to separate these
> components into separate subprojects. The "best available" version of
> each will be bundled as Struts Classic, as a convenient one-stop
> download.
>
> Then, if we want to bring out a fix or change in one component, we do
> not need to parade out all the rest. In the past, useful and stable
> improvements to one component have been "trapped" behind unstable
> improvements to another component, frustrating everyone. The
> subproject strategy will let us bring out improvements to one
> subproject without freezing development in other subproject .
Ok. Understood and no arguing about the subproject strategy. Absolutely
makes sense.
Although I've got to admit that intuitively I would've associated only
core and taglibs with a "classic" label in the historic sense. All the
other components mentioned always felt like addons.
Christian
--
Christian Meder, email: chris@absolutegiganten.org
The Way-Seeking Mind of a tenzo is actualized
by rolling up your sleeves.
(Eihei Dogen Zenji)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Website Updates
Posted by Ted Husted <te...@gmail.com>.
On 9/6/05, Christian Meder <ch...@absolutegiganten.org> wrote:
> How is "Struts Classic" related to this whole discussion ?
>
> IMHO Struts Classic describes the core component best. At least that's
> the part with which I started doing Java web application development 4
> years ago so it's definitely the oldest part of the Struts framework.
The "Struts Classic" label is being used to describe a distribution of
the six orginal subprojects, which includes Core:
> Originally, the Apache Struts software was distributed as one
> monolithic bundle. Today, the Struts project is comprised of several
> subprojects. Each subproject has its own website, documentation, and
> release cycle, and may be downloaded separately. The six original
> Apache Struts subprojects -- Core, Taglibs, Tiles, Extras,
> Applications, and EL -- are also being bundled into a distribution
> known as "Struts Classic".
The Core subproject does not include components like the Taglibs and
Tiles. Experience proves that we *do* want to separate these
components into separate subprojects. The "best available" version of
each will be bundled as Struts Classic, as a convenient one-stop
download.
Then, if we want to bring out a fix or change in one component, we do
not need to parade out all the rest. In the past, useful and stable
improvements to one component have been "trapped" behind unstable
improvements to another component, frustrating everyone. The
subproject strategy will let us bring out improvements to one
subproject without freezing development in other subproject .
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Website Updates
Posted by Christian Meder <ch...@absolutegiganten.org>.
On Mon, 2005-09-05 at 17:10 -0400, Ted Husted wrote:
> Here's an odd idea: What if we called Struts "Core", Struts "Config" instead?
>
> After all, the purpose of the codebase is to realize the struts-config
> XML file. What goes into Struts "Core" might be ambiguous, but what
> goes inot Struts Config is defined, by, well, the struts-config XML
> declaration.
How is "Struts Classic" related to this whole discussion ?
IMHO Struts Classic describes the core component best. At least that's
the part with which I started doing Java web application development 4
years ago so it's definitely the oldest part of the Struts framework.
Christian
--
Christian Meder, email: chris@absolutegiganten.org
The Way-Seeking Mind of a tenzo is actualized
by rolling up your sleeves.
(Eihei Dogen Zenji)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Website Updates
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Ted Husted wrote:
> The moniker "Core" did make a lot of sense when we were thinking that
> the other Struts subprojects would depend on Core. But, we dismissed
> that idea when we decided to host Shale. Now, should we decide to host
> Struts Ti one day, we would have two Java subprojects not dependant on
> "Core". By deciding to work on subprojects like Ti and Shale, the
> volunteers seems to be sending a clear message that Struts is not just
> about Struts Core anymore. So, perhaps, we should give that codebase
> it's own identity. And, we do have to call it something. We're having
> great success with Maven, and Maven expects artifacts to have names.
> The closest we could come to a no-name artifact would be
> struts-struts-1.3.0 -- which is too odd, even for me :)
Good points... struts-struts-1.3.0... maybe it should be factored out to
struts^2-1.3.0? ;)
The interesting thing about Shale and Ti though is that they are, as I
understand it, proposals for where to take Struts next. At least,
that's how they started out. Let's say one of them was choosen... what
would it be called then? I would think it would simply be called
Struts, right?
The point of course being that whatever the official "thing" is at any
given point in time should probably be called simply Struts. It sounds
to me like core did make some sense at the time, but it seems like that
time has passed.
And with one of the main stated goals of Ti being simplicity, "Struts"
fits that goal best I think :)
Frank
> -T.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Website Updates
Posted by Martin Cooper <mf...@gmail.com>.
On 9/5/05, Joe Germuska <Jo...@germuska.com> wrote:
>
> Ted:
>
> I hear what you're saying, but I think that "struts-core" is the most
> accurate label for the things included in that artifact.
> Conceptually, it is "Struts 1.x core", but that's too verbose.
>
> I'm for sticking with "core".
I'm with Joe on this. I really do think that 'core' is the most appropriate
moniker. It's true that not all of the other subprojects plug into it, but I
don't see that as a requirement for calling what really is the core of the
framework 'core'.
--
Martin Cooper
Joe
>
>
> >The moniker "Core" did make a lot of sense when we were thinking that
> >the other Struts subprojects would depend on Core. But, we dismissed
> >that idea when we decided to host Shale. Now, should we decide to host
> >Struts Ti one day, we would have two Java subprojects not dependant on
> >"Core". By deciding to work on subprojects like Ti and Shale, the
> >volunteers seems to be sending a clear message that Struts is not just
> >about Struts Core anymore. So, perhaps, we should give that codebase
> >it's own identity. And, we do have to call it something. We're having
> >great success with Maven, and Maven expects artifacts to have names.
> >The closest we could come to a no-name artifact would be
> >struts-struts-1.3.0 -- which is too odd, even for me :)
> >
> >-T.
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >For additional commands, e-mail: dev-help@struts.apache.org
>
>
> --
> Joe Germuska
> Joe@Germuska.com
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction" -The Ex
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Website Updates
Posted by Joe Germuska <Jo...@Germuska.com>.
Ted:
I hear what you're saying, but I think that "struts-core" is the most
accurate label for the things included in that artifact.
Conceptually, it is "Struts 1.x core", but that's too verbose.
I'm for sticking with "core".
Joe
>The moniker "Core" did make a lot of sense when we were thinking that
>the other Struts subprojects would depend on Core. But, we dismissed
>that idea when we decided to host Shale. Now, should we decide to host
>Struts Ti one day, we would have two Java subprojects not dependant on
>"Core". By deciding to work on subprojects like Ti and Shale, the
>volunteers seems to be sending a clear message that Struts is not just
>about Struts Core anymore. So, perhaps, we should give that codebase
>it's own identity. And, we do have to call it something. We're having
>great success with Maven, and Maven expects artifacts to have names.
>The closest we could come to a no-name artifact would be
>struts-struts-1.3.0 -- which is too odd, even for me :)
>
>-T.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Website Updates
Posted by Wendy Smoak <ja...@wendysmoak.com>.
From: "Ted Husted" <te...@gmail.com>
> And, we do have to call it something. We're having
> great success with Maven, and Maven expects artifacts to have names.
> The closest we could come to a no-name artifact would be
> struts-struts-1.3.0 -- which is too odd, even for me :)
Maven doesn't care what you call it. :)
If you want it to be struts-1.3.0.jar, then put
<artifactId>struts</artifactId> in (currently) core/project.xml. (And
change the dependencies in the other sub-projects to the new name.)
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Website Updates
Posted by Ted Husted <te...@gmail.com>.
On 9/5/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
> I agree, config is a little too left-field (even though it does make
> sense as Ted describes).
>
> I'm not actually too thrilled with even saying "core" frankly... I would
> be more in favor of simply calling core "Struts" and all the
> sub-projects "Struts-xxx". I understand the reasoning of adding core to
> the name, but I personally think it'll just confuse people a bit (not
> much hopefully, but a bit).
>
> Frank
The moniker "Core" did make a lot of sense when we were thinking that
the other Struts subprojects would depend on Core. But, we dismissed
that idea when we decided to host Shale. Now, should we decide to host
Struts Ti one day, we would have two Java subprojects not dependant on
"Core". By deciding to work on subprojects like Ti and Shale, the
volunteers seems to be sending a clear message that Struts is not just
about Struts Core anymore. So, perhaps, we should give that codebase
it's own identity. And, we do have to call it something. We're having
great success with Maven, and Maven expects artifacts to have names.
The closest we could come to a no-name artifact would be
struts-struts-1.3.0 -- which is too odd, even for me :)
-T.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Website Updates
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
I agree, config is a little too left-field (even though it does make
sense as Ted describes).
I'm not actually too thrilled with even saying "core" frankly... I would
be more in favor of simply calling core "Struts" and all the
sub-projects "Struts-xxx". I understand the reasoning of adding core to
the name, but I personally think it'll just confuse people a bit (not
much hopefully, but a bit).
Frank
James Mitchell wrote:
>
> You are right, that seems odd.
>
> I really like 'core' since it seems (to me anyway) to encapsulate the
> 'core' of the framework, but I'm not married to it, and I know how
> (sometimes) being too close to something makes it harder to see the
> 'forrest' ;)
>
> Your thoughts?
>
> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> Consulting / Mentoring / Freelance
> EdgeTech, Inc.
> http://www.edgetechservices.net/
> 678.910.8017
> AIM: jmitchtx
> Yahoo: jmitchtx
> MSN: jmitchell@apache.org
> Skype: callto://jmitchtx
>
>
>
>
>
> On Sep 5, 2005, at 5:10 PM, Ted Husted wrote:
>
>> Here's an odd idea: What if we called Struts "Core", Struts "Config"
>> instead?
>>
>> After all, the purpose of the codebase is to realize the struts-config
>> XML file. What goes into Struts "Core" might be ambiguous, but what
>> goes inot Struts Config is defined, by, well, the struts-config XML
>> declaration.
>>
>> Here's that new home page again, with s/Core/Config:
>>
>>
>>> Welcome to Struts Config
>>>
>>> Struts Config provides the invisible underpinnings every professional
>>> web application needs to survive. Struts Config is a flexible control
>>> layer based on standard technologies like Java Servlets, JavaBeans,
>>> ResourceBundles, and XML, as well as various Jakarta Commons packages.
>>> Config helps you create an extensible development environment for your
>>> application, based on published standards and proven design patterns.
>>>
>>> Struts Config provides its own Controller component and integrates with
>>> other technologies to provide the Model and the View. For the Model,
>>> Config can interact with standard data access technologies, like JDBC
>>> and EJB, as well as most any third-party packages, like Hibernate,
>>> iBATIS, or Object Relational Bridge. For the View, Config works well
>>> with JavaServer Pages, including JSTL and JSF, as well as Velocity
>>> Templates, XSLT, and other presentation systems.
>>>
>>> Struts Config in a Nutshell
>>>
>>> A web application uses a deployment descriptor to initialize resources
>>> like servlets and taglibs. The deployment descriptor is formatted as a
>>> XML document and named "web.xml". Likewise, Config uses a configuration
>>> file to initialize its own resources. These resources include
>>> ActionForms to collect input from users, ActionMappings to direct
>>> input to server-side Actions, and ActionForwards to select output
>>> pages.
>>>
>>> Here's a simple Struts configuration (struts-config.xml) for a login
>>> workflow:
>>>
>>> <?xml version="1.0" encoding="ISO-8859-1" ?>
>>> <!DOCTYPE struts-config PUBLIC
>>> "-//Apache Software Foundation//DTD Struts Configuration
>>> 1.3//EN"
>>> "http://struts.apache.org/dtds/struts-config_1_3.dtd">
>>> <struts-config>
>>> <form-beans>
>>> <form-bean
>>> name="logonForm"
>>> type="app.LogonForm"/>
>>> </form-beans>
>>> <action-mappings>
>>> <action
>>> path="/Welcome"
>>> forward="/pages/Welcome.jsp"/>
>>> <action
>>> path="/Logon"
>>> forward="/pages/Logon.jsp"/>
>>> <action
>>> path="/LogonSubmit"
>>> type="app.LogonAction"
>>> name="logonForm"
>>> scope="request"
>>> validate="true"
>>> input="/pages/Logon.jsp">
>>> <forward
>>> name="success"
>>> path="/pages/Welcome.jsp"/>
>>> <forward
>>> name="failure"
>>> path="/pages/Logon.jsp"/>
>>> </action>
>>> <action
>>> path="/Logoff"
>>> type="app.LogoffAction">
>>> <forward
>>> name="success"
>>> path="/pages/Logoff.jsp"/>
>>> </action>
>>> </action-mappings>
>>> <message-resources parameter="resources.application"/>
>>> </struts-config>
>>>
>>> There are several other resources you can specify in Struts Config
>>> configuration files. You can specify validations for the ActionForms
>>> in an XML descriptor, using the Struts Validator. A standard
>>> extension, Tiles, helps you build pages from smaller fragments.
>>>
>>> Struts Config is an extensible framework. Every class deployed by
>>> Config
>>> can be replaced by your own default class. The properties of your
>>> default class can be set using the Digester's set-property feature.
>>> This is one reason why there are so many contributor extensions for
>>> Struts Config . Config provides a base framework, but you can still
>>> write
>>> your application your way.
>>>
>>> For more about Struts and its underlying technologies, see the User
>>> Guide and the Developer Guides.
>>>
>>> Is Struts Config the best choice for every project?
>>>
>>> No. If you need to write a very simple application, with a handful of
>>> pages, then you might consider a "Model 1" solution that uses only
>>> server pages.
>>>
>>> But, if you are writing a more complicated application, with dozens of
>>> pages, that need to be maintained over time, then Struts Config can
>>> help. For
>>> more about whether Model 1 or or MVC/Model 2 is right for you, see
>>> Understanding JavaServer Pages Model 2 architecture and Issues in
>>> Struts Adoption.
>>>
>>> What about JSTL and JavaServer Faces?
>>>
>>> Next: Struts Config User Guide
>>>
>>
>> -T.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Website Updates
Posted by James Mitchell <ja...@mac.com>.
You are right, that seems odd.
I really like 'core' since it seems (to me anyway) to encapsulate the
'core' of the framework, but I'm not married to it, and I know how
(sometimes) being too close to something makes it harder to see the
'forrest' ;)
Your thoughts?
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: jmitchell@apache.org
Skype: callto://jmitchtx
On Sep 5, 2005, at 5:10 PM, Ted Husted wrote:
> Here's an odd idea: What if we called Struts "Core", Struts
> "Config" instead?
>
> After all, the purpose of the codebase is to realize the struts-config
> XML file. What goes into Struts "Core" might be ambiguous, but what
> goes inot Struts Config is defined, by, well, the struts-config XML
> declaration.
>
> Here's that new home page again, with s/Core/Config:
>
>
>> Welcome to Struts Config
>>
>> Struts Config provides the invisible underpinnings every professional
>> web application needs to survive. Struts Config is a flexible control
>> layer based on standard technologies like Java Servlets, JavaBeans,
>> ResourceBundles, and XML, as well as various Jakarta Commons
>> packages.
>> Config helps you create an extensible development environment for
>> your
>> application, based on published standards and proven design patterns.
>>
>> Struts Config provides its own Controller component and integrates
>> with
>> other technologies to provide the Model and the View. For the Model,
>> Config can interact with standard data access technologies, like JDBC
>> and EJB, as well as most any third-party packages, like Hibernate,
>> iBATIS, or Object Relational Bridge. For the View, Config works well
>> with JavaServer Pages, including JSTL and JSF, as well as Velocity
>> Templates, XSLT, and other presentation systems.
>>
>> Struts Config in a Nutshell
>>
>> A web application uses a deployment descriptor to initialize
>> resources
>> like servlets and taglibs. The deployment descriptor is formatted
>> as a
>> XML document and named "web.xml". Likewise, Config uses a
>> configuration
>> file to initialize its own resources. These resources include
>> ActionForms to collect input from users, ActionMappings to direct
>> input to server-side Actions, and ActionForwards to select output
>> pages.
>>
>> Here's a simple Struts configuration (struts-config.xml) for a
>> login workflow:
>>
>> <?xml version="1.0" encoding="ISO-8859-1" ?>
>> <!DOCTYPE struts-config PUBLIC
>> "-//Apache Software Foundation//DTD Struts Configuration
>> 1.3//EN"
>> "http://struts.apache.org/dtds/struts-config_1_3.dtd">
>> <struts-config>
>> <form-beans>
>> <form-bean
>> name="logonForm"
>> type="app.LogonForm"/>
>> </form-beans>
>> <action-mappings>
>> <action
>> path="/Welcome"
>> forward="/pages/Welcome.jsp"/>
>> <action
>> path="/Logon"
>> forward="/pages/Logon.jsp"/>
>> <action
>> path="/LogonSubmit"
>> type="app.LogonAction"
>> name="logonForm"
>> scope="request"
>> validate="true"
>> input="/pages/Logon.jsp">
>> <forward
>> name="success"
>> path="/pages/Welcome.jsp"/>
>> <forward
>> name="failure"
>> path="/pages/Logon.jsp"/>
>> </action>
>> <action
>> path="/Logoff"
>> type="app.LogoffAction">
>> <forward
>> name="success"
>> path="/pages/Logoff.jsp"/>
>> </action>
>> </action-mappings>
>> <message-resources parameter="resources.application"/>
>> </struts-config>
>>
>> There are several other resources you can specify in Struts Config
>> configuration files. You can specify validations for the ActionForms
>> in an XML descriptor, using the Struts Validator. A standard
>> extension, Tiles, helps you build pages from smaller fragments.
>>
>> Struts Config is an extensible framework. Every class deployed by
>> Config
>> can be replaced by your own default class. The properties of your
>> default class can be set using the Digester's set-property feature.
>> This is one reason why there are so many contributor extensions for
>> Struts Config . Config provides a base framework, but you can
>> still write
>> your application your way.
>>
>> For more about Struts and its underlying technologies, see the User
>> Guide and the Developer Guides.
>>
>> Is Struts Config the best choice for every project?
>>
>> No. If you need to write a very simple application, with a handful of
>> pages, then you might consider a "Model 1" solution that uses only
>> server pages.
>>
>> But, if you are writing a more complicated application, with
>> dozens of
>> pages, that need to be maintained over time, then Struts Config
>> can help. For
>> more about whether Model 1 or or MVC/Model 2 is right for you, see
>> Understanding JavaServer Pages Model 2 architecture and Issues in
>> Struts Adoption.
>>
>> What about JSTL and JavaServer Faces?
>>
>> Next: Struts Config User Guide
>>
>
> -T.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Website Updates
Posted by Ted Husted <te...@gmail.com>.
Here's an odd idea: What if we called Struts "Core", Struts "Config" instead?
After all, the purpose of the codebase is to realize the struts-config
XML file. What goes into Struts "Core" might be ambiguous, but what
goes inot Struts Config is defined, by, well, the struts-config XML
declaration.
Here's that new home page again, with s/Core/Config:
> Welcome to Struts Config
>
> Struts Config provides the invisible underpinnings every professional
> web application needs to survive. Struts Config is a flexible control
> layer based on standard technologies like Java Servlets, JavaBeans,
> ResourceBundles, and XML, as well as various Jakarta Commons packages.
> Config helps you create an extensible development environment for your
> application, based on published standards and proven design patterns.
>
> Struts Config provides its own Controller component and integrates with
> other technologies to provide the Model and the View. For the Model,
> Config can interact with standard data access technologies, like JDBC
> and EJB, as well as most any third-party packages, like Hibernate,
> iBATIS, or Object Relational Bridge. For the View, Config works well
> with JavaServer Pages, including JSTL and JSF, as well as Velocity
> Templates, XSLT, and other presentation systems.
>
> Struts Config in a Nutshell
>
> A web application uses a deployment descriptor to initialize resources
> like servlets and taglibs. The deployment descriptor is formatted as a
> XML document and named "web.xml". Likewise, Config uses a configuration
> file to initialize its own resources. These resources include
> ActionForms to collect input from users, ActionMappings to direct
> input to server-side Actions, and ActionForwards to select output
> pages.
>
> Here's a simple Struts configuration (struts-config.xml) for a login workflow:
>
> <?xml version="1.0" encoding="ISO-8859-1" ?>
> <!DOCTYPE struts-config PUBLIC
> "-//Apache Software Foundation//DTD Struts Configuration 1.3//EN"
> "http://struts.apache.org/dtds/struts-config_1_3.dtd">
> <struts-config>
> <form-beans>
> <form-bean
> name="logonForm"
> type="app.LogonForm"/>
> </form-beans>
> <action-mappings>
> <action
> path="/Welcome"
> forward="/pages/Welcome.jsp"/>
> <action
> path="/Logon"
> forward="/pages/Logon.jsp"/>
> <action
> path="/LogonSubmit"
> type="app.LogonAction"
> name="logonForm"
> scope="request"
> validate="true"
> input="/pages/Logon.jsp">
> <forward
> name="success"
> path="/pages/Welcome.jsp"/>
> <forward
> name="failure"
> path="/pages/Logon.jsp"/>
> </action>
> <action
> path="/Logoff"
> type="app.LogoffAction">
> <forward
> name="success"
> path="/pages/Logoff.jsp"/>
> </action>
> </action-mappings>
> <message-resources parameter="resources.application"/>
> </struts-config>
>
> There are several other resources you can specify in Struts Config
> configuration files. You can specify validations for the ActionForms
> in an XML descriptor, using the Struts Validator. A standard
> extension, Tiles, helps you build pages from smaller fragments.
>
> Struts Config is an extensible framework. Every class deployed by Config
> can be replaced by your own default class. The properties of your
> default class can be set using the Digester's set-property feature.
> This is one reason why there are so many contributor extensions for
> Struts Config . Config provides a base framework, but you can still write
> your application your way.
>
> For more about Struts and its underlying technologies, see the User
> Guide and the Developer Guides.
>
> Is Struts Config the best choice for every project?
>
> No. If you need to write a very simple application, with a handful of
> pages, then you might consider a "Model 1" solution that uses only
> server pages.
>
> But, if you are writing a more complicated application, with dozens of
> pages, that need to be maintained over time, then Struts Config can help. For
> more about whether Model 1 or or MVC/Model 2 is right for you, see
> Understanding JavaServer Pages Model 2 architecture and Issues in
> Struts Adoption.
>
> What about JSTL and JavaServer Faces?
>
> Next: Struts Config User Guide
-T.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Website Updates
Posted by Ted Husted <te...@gmail.com>.
On 9/5/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> What needs to be done with Taglibs? You added it to the Wiki, but there's
> nothing under site/xdocs for it. I'm fairly sure that the files under
> taglib/doc can be deleted-- I used them to create the JSP 1.2 TLDs that now
> live in taglib/src/tld, and those are being used to create Taglibdoc and
> Taglib Reference pages, as well as being included in the .jar file.
We have to extract the taglibs docs from the UserGuide. Most of the
Developers Guide will need to be moved under Taglibs.
-T.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Website Updates
Posted by Wendy Smoak <ja...@wendysmoak.com>.
From: "Ted Husted" <te...@gmail.com>
> I really must commend Wendy and James for the excellent work on the
> new Struts build. It's working well, and I'm having fun with it. :)
Thanks for taking on the rewrites and the final reorganization... it's been
fun seeing it all come together this weekend.
What needs to be done with Taglibs? You added it to the Wiki, but there's
nothing under site/xdocs for it. I'm fairly sure that the files under
taglib/doc can be deleted-- I used them to create the JSP 1.2 TLDs that now
live in taglib/src/tld, and those are being used to create Taglibdoc and
Taglib Reference pages, as well as being included in the .jar file.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Website Updates
Posted by Wendy Smoak <ja...@wendysmoak.com>.
From: "Wendy Smoak" <ja...@wendysmoak.com>
>> Where do we stand on moving the rest of the nightly builds to Maven?
> Standalone Tiles has a good Maven build,
I looked again, and Maven is only building tiles-core.jar for Tiles, not the
documentation/example webapp. So it's in the same situation as Faces, Maven
is really only building the website (and only incidentally compiling the
source code in order to produce some reports.)
It's somewhere on the list, but below things like updating the remaining
tlds to JSP 1.2.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Website Updates
Posted by Wendy Smoak <ja...@wendysmoak.com>.
From: "Ted Husted" <te...@gmail.com>
> Where do we stand on moving the rest of the nightly builds to Maven?
>
> Can we assume that Shale, Struts Faces, and Standalone Tiles
> (currently in the Sandbox) will all be built by Maven, and remove the
> dichotomy on the Acquiring page?
Standalone Tiles has a good Maven build, Shale is under construction, (the
website won out this weekend,) and Faces has only enough to compile the core
library and build its site. (I have uncommitted changes for Faces, IIRC we
were negotiating on dependencies, but not a full Maven build.)
IMO, all the nightlies should be in one place regardless of whether they're
being built with Ant or Maven. I don't think the "customers" of the nightly
builds care what was used to create them, and it would make the Acquiring
page simpler.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Website Updates
Posted by Ted Husted <te...@gmail.com>.
Where do we stand on moving the rest of the nightly builds to Maven?
Can we assume that Shale, Struts Faces, and Standalone Tiles
(currently in the Sandbox) will all be built by Maven, and remove the
dichotomy on the Acquiring page?
-T.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Website Updates
Posted by James Mitchell <ja...@mac.com>.
Hey that look great!
(I only wish I had more time to help)
Keep up the good work!
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: jmitchell@apache.org
Skype: callto://jmitchtx
On Sep 5, 2005, at 4:32 PM, Ted Husted wrote:
> In between coping with a crashed server on my local network, I've
> started to make the "final" round of changes on the new website.
>
> I'll be committing these as I go along, but I thought it appropriate
> to post the reworked text for the Site and Core homepages directly to
> the list. We had talked about the project's goal in terms of a
> particular technology ("Struts Classic"). In this version, the
> underlying "Model 2" goal bubbles up to the first sentance. From day
> one, the idea that Struts exists to promote Model 2 application
> architectures has always been there, we've just never put that
> sentence front and center before.
>
> ----
>
> Welcome to Apache Struts!
>
> The goal of the Apache Struts project is to encourage application
> architectures based on the "Model 2" approach, a variation of the
> classic Model-View-Controller (MVC) design paradigm. Under Model 2, a
> servlet manages business logic execution, and presentation logic
> resides mainly in server pages.
>
> The Apache Struts project encourages Model 2 designs in two ways.
> First, by providing open source frameworks and toolkits that help
> developers build applications for the web. Second, by providing
> friendly and honest mailing lists where both newcomers and veterans
> can discuss how to use Struts software in their own Model 2
> applications.
>
> Originally, the Apache Struts software was distributed as one
> monolithic bundle. Today, the Struts project is comprised of several
> subprojects. Each subproject has its own website, documentation, and
> release cycle, and may be downloaded separately. The six original
> Apache Struts subprojects -- Core, Taglibs, Tiles, Extras,
> Applications, and EL -- are also being bundled into a distribution
> known as "Struts Classic".
>
> Apache Struts is a volunteer project and all support for the framework
> is provided by unpaid volunteers. This documentation bundle and the
> mailing lists are the primary ways to learn how to use Struts. The
> next few pages are devoted to helping you understand what resources
> are available to you. Since Apache Struts is a volunteer project, and
> our resources are limited, it is important that we first help you help
> yourself.
>
> Struts is a project of the The Apache Software Foundation. The
> official Apache Struts home page is at http://struts.apache.org/.
>
> ----
>
> The rest of the Welcome page text now lives under Struts Core:
>
> ----
>
> Welcome to Struts Core
>
> Struts Core provides the invisible underpinnings every professional
> web application needs to survive. Struts Core is a flexible control
> layer based on standard technologies like Java Servlets, JavaBeans,
> ResourceBundles, and XML, as well as various Jakarta Commons packages.
> Core helps you create an extensible development environment for your
> application, based on published standards and proven design patterns.
>
> Struts Core provides its own Controller component and integrates with
> other technologies to provide the Model and the View. For the Model,
> Core can interact with standard data access technologies, like JDBC
> and EJB, as well as most any third-party packages, like Hibernate,
> iBATIS, or Object Relational Bridge. For the View, Core works well
> with JavaServer Pages, including JSTL and JSF, as well as Velocity
> Templates, XSLT, and other presentation systems.
>
> Struts Core in a Nutshell
>
> A web application uses a deployment descriptor to initialize resources
> like servlets and taglibs. The deployment descriptor is formatted as a
> XML document and named "web.xml". Likewise, Core uses a configuration
> file to initialize its own resources. These resources include
> ActionForms to collect input from users, ActionMappings to direct
> input to server-side Actions, and ActionForwards to select output
> pages.
>
> Here's a simple Struts configuration (struts-config.xml) for a
> login workflow:
>
> <?xml version="1.0" encoding="ISO-8859-1" ?>
> <!DOCTYPE struts-config PUBLIC
> "-//Apache Software Foundation//DTD Struts Configuration
> 1.3//EN"
> "http://struts.apache.org/dtds/struts-config_1_3.dtd">
> <struts-config>
> <form-beans>
> <form-bean
> name="logonForm"
> type="app.LogonForm"/>
> </form-beans>
> <action-mappings>
> <action
> path="/Welcome"
> forward="/pages/Welcome.jsp"/>
> <action
> path="/Logon"
> forward="/pages/Logon.jsp"/>
> <action
> path="/LogonSubmit"
> type="app.LogonAction"
> name="logonForm"
> scope="request"
> validate="true"
> input="/pages/Logon.jsp">
> <forward
> name="success"
> path="/pages/Welcome.jsp"/>
> <forward
> name="failure"
> path="/pages/Logon.jsp"/>
> </action>
> <action
> path="/Logoff"
> type="app.LogoffAction">
> <forward
> name="success"
> path="/pages/Logoff.jsp"/>
> </action>
> </action-mappings>
> <message-resources parameter="resources.application"/>
> </struts-config>
>
> There are several other resources you can specify in Struts
> configuration files. You can specify validations for the ActionForms
> in an XML descriptor, using the Struts Validator. A standard
> extension, Tiles, helps you build pages from smaller fragments.
>
> Struts Core is an extensible framework. Every class deployed by Core
> can be replaced by your own default class. The properties of your
> default class can be set using the Digester's set-property feature.
> This is one reason why there are so many contributor extensions for
> Struts Core. Core provides a base framework, but you can still write
> your application your way.
>
> For more about Struts and its underlying technologies, see the User
> Guide and the Developer Guides.
>
> Is Struts Core the best choice for every project?
>
> No. If you need to write a very simple application, with a handful of
> pages, then you might consider a "Model 1" solution that uses only
> server pages.
>
> But, if you are writing a more complicated application, with dozens of
> pages, that need to be maintained over time, then Struts can help. For
> more about whether Model 1 or or MVC/Model 2 is right for you, see
> Understanding JavaServer Pages Model 2 architecture and Issues in
> Struts Adoption.
>
> What about JSTL and JavaServer Faces?
>
> Next: Struts Core User Guide
>
> ----
>
> I really must commend Wendy and James for the excellent work on the
> new Struts build. It's working well, and I'm having fun with it. :)
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org