Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <431CBACB.7030608@omnytex.com>
Date: Mon, 05 Sep 2005 17:38:19 -0400
From: "Frank W. Zammetti" <fzlists@omnytex.com>
Reply-To: fzlists@omnytex.com
Organization: Omnytex Technologies
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: Struts Developers List <dev@struts.apache.org>
Subject: Re: Website Updates
References: <8b3ce37905090513325e86e896@mail.gmail.com>
 <8b3ce37905090514107fc7161e@mail.gmail.com>
 <A009D94C-B329-4304-8575-01AD91EA5313@mac.com>
In-Reply-To: <A009D94C-B329-4304-8575-01AD91EA5313@mac.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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