You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@shale.apache.org by ra...@apache.org on 2006/10/24 22:34:46 UTC
svn commit: r467469 - in /shale/framework/trunk/src/site: site.xml
xdoc/background.xml xdoc/index.xml
Author: rahul
Date: Tue Oct 24 13:34:45 2006
New Revision: 467469
URL: http://svn.apache.org/viewvc?view=rev&rev=467469
Log:
Move the background section from the front page to its own page.
SHALE-306
Added:
shale/framework/trunk/src/site/xdoc/background.xml (with props)
Modified:
shale/framework/trunk/src/site/site.xml
shale/framework/trunk/src/site/xdoc/index.xml
Modified: shale/framework/trunk/src/site/site.xml
URL: http://svn.apache.org/viewvc/shale/framework/trunk/src/site/site.xml?view=diff&rev=467469&r1=467468&r2=467469
==============================================================================
--- shale/framework/trunk/src/site/site.xml (original)
+++ shale/framework/trunk/src/site/site.xml Tue Oct 24 13:34:45 2006
@@ -17,7 +17,7 @@
</links>
<menu name="Shale">
- <item name="Background" href="/index.html#background"/>
+ <item name="Background" href="/background.html"/>
<item name="Features" href="/index.html#features"/>
<item name="Download" href="/index.html#download"/>
<item name="Documentation" href="/index.html#documentation"/>
Added: shale/framework/trunk/src/site/xdoc/background.xml
URL: http://svn.apache.org/viewvc/shale/framework/trunk/src/site/xdoc/background.xml?view=auto&rev=467469
==============================================================================
--- shale/framework/trunk/src/site/xdoc/background.xml (added)
+++ shale/framework/trunk/src/site/xdoc/background.xml Tue Oct 24 13:34:45 2006
@@ -0,0 +1,110 @@
+<?xml version="1.0"?>
+<document>
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to you under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+ <properties>
+ <title>Shale Framework - Background</title>
+ </properties>
+
+ <body>
+
+ <section name="Shale Framework">
+
+ <a name="background"/>
+ <subsection name="Background">
+
+ <p>Little did anyone know, when the first few lines of code were
+ committed to the <a href="http://struts.apache.org">Struts</a>
+ CVS repository in June 2000, that a revolution was brewing. Prior
+ to that time, there were few useful models for best practices for
+ the architecture of web based applications. The best we could do
+ was handwaving about "Model 1" and "Model 2" approaches.</p>
+
+ <p>The original implementation of Struts, which was released as a
+ 1.0 product approximately one year later, changed all that. As
+ more and more people came to understand the advantages of building
+ on top of a stable and supported framework, and as more and more
+ developers adopted it for their own application development, and
+ as more and more books helped everyone understand how to use the
+ framework correctly, and as more and more development tools provided
+ support for building Struts based applications, the word changed.
+ A small open source project became a defacto industry standard that,
+ even today, is very popular.</p>
+
+ <p>But that was then ... and this is now. In the years that Struts
+ has been around (five and counting as of this writing), vastly
+ improved technologies have become available from many talented
+ architects and designers. Moore's Law has continued its seemingly
+ inexhaustible progress. Developers have grown in their ability to
+ understand the benefits of a monolithic controller architecture ...
+ as well as increasingly developing preferences towards agility,
+ code reuse, unit tests, and building applications by composition
+ instead of inheritance.</p>
+
+ <p>One of the critical success factors for Struts has been, and
+ continues to be, an obvious commitment on the part of the Struts
+ developers towards backwards compatibility. This has led to Struts
+ being both praised (for protecting the investment of developers
+ with thousands of applications critically dependent on the framework)
+ and dissed (for being a dinosaur compared to all the "latest and
+ greatest" favorite technological approaches). History has shown,
+ in terms of its continued popularity, that this is a good
+ strategic approach.</p>
+
+ <p>But, it is also time to harvest many of the great ideas that have
+ matured in the last several years. It is time to base a web tier
+ framework on top of the new standard API in this space (JavaServer Faces),
+ and eliminate the need to implement redundant features, instead of just
+ treating JSF as a UI component technology. It is time to answer the
+ question "if we knew then what we know now, what would Struts have
+ looked like?"</p>
+
+ <p>Thus, Shale is a modern web application framework,
+ fundamentally based on JavaServer Faces, and focused on improving
+ ease of use for developers adopting JSF as a foundational technology
+ in their own development environments. At the same time, the
+ architecture of Shale is a set of fine grained services (and service
+ options) that can be combined as needed to meet particular application
+ requirements, rather than a monolithic request processor that is hard
+ to customize and extend. In addition, integration links for other
+ frameworks and framework components are provided, to ease development
+ when combinations of technologies are required.</p>
+
+ <blockquote><em>EDITOR'S NOTE: Why "Shale"? As others have pointed out,
+ the cultural rules of engagement at Apache encourage both evolution
+ and revolution in software designs. Revolutions are typically assigned
+ code names while they are under discussion, gaining access to the
+ branding of the overall project once they are accepted (or, going off
+ on their own if they are not). Other proposals for Struts 2.x have
+ talked about tearing down the walls inside the framework, and those
+ are Good Things. Shale's architecture, on the other hand, is based
+ on the principle that we should fundamentally divide the notion of a
+ web application framework into solid individual layers, much as we
+ see geologically in shale deposits around our volcanoes and coastlines.
+ Each layer of the framework should focus on the specific requirements
+ that are relevant to that layer -- and use of one layer should not
+ necessarily require the use of all the rest (although it's certainly
+ reasonable for synergies to exist if all the layers are chosen :-).
+ Hence, "shale".</em></blockquote>
+
+ </subsection>
+
+ </section>
+
+ </body>
+
+</document>
Propchange: shale/framework/trunk/src/site/xdoc/background.xml
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: shale/framework/trunk/src/site/xdoc/background.xml
------------------------------------------------------------------------------
svn:keywords = Date Author Id Revision HeadURL
Modified: shale/framework/trunk/src/site/xdoc/index.xml
URL: http://svn.apache.org/viewvc/shale/framework/trunk/src/site/xdoc/index.xml?view=diff&rev=467469&r1=467468&r2=467469
==============================================================================
--- shale/framework/trunk/src/site/xdoc/index.xml (original)
+++ shale/framework/trunk/src/site/xdoc/index.xml Tue Oct 24 13:34:45 2006
@@ -24,85 +24,6 @@
<section name="Shale Framework">
- <a name="background"/>
- <subsection name="Background">
-
- <p>Little did anyone know, when the first few lines of code were
- committed to the <a href="http://struts.apache.org">Struts</a>
- CVS repository in June 2000, that a revolution was brewing. Prior
- to that time, there were few useful models for best practices for
- the architecture of web based applications. The best we could do
- was handwaving about "Model 1" and "Model 2" approaches.</p>
-
- <p>The original implementation of Struts, which was released as a
- 1.0 product approximately one year later, changed all that. As
- more and more people came to understand the advantages of building
- on top of a stable and supported framework, and as more and more
- developers adopted it for their own application development, and
- as more and more books helped everyone understand how to use the
- framework correctly, and as more and more development tools provided
- support for building Struts based applications, the word changed.
- A small open source project became a defacto industry standard that,
- even today, is very popular.</p>
-
- <p>But that was then ... and this is now. In the years that Struts
- has been around (five and counting as of this writing), vastly
- improved technologies have become available from many talented
- architects and designers. Moore's Law has continued its seemingly
- inexhaustible progress. Developers have grown in their ability to
- understand the benefits of a monolithic controller architecture ...
- as well as increasingly developing preferences towards agility,
- code reuse, unit tests, and building applications by composition
- instead of inheritance.</p>
-
- <p>One of the critical success factors for Struts has been, and
- continues to be, an obvious commitment on the part of the Struts
- developers towards backwards compatibility. This has led to Struts
- being both praised (for protecting the investment of developers
- with thousands of applications critically dependent on the framework)
- and dissed (for being a dinosaur compared to all the "latest and
- greatest" favorite technological approaches). History has shown,
- in terms of its continued popularity, that this is a good
- strategic approach.</p>
-
- <p>But, it is also time to harvest many of the great ideas that have
- matured in the last several years. It is time to base a web tier
- framework on top of the new standard API in this space (JavaServer Faces),
- and eliminate the need to implement redundant features, instead of just
- treating JSF as a UI component technology. It is time to answer the
- question "if we knew then what we know now, what would Struts have
- looked like?"</p>
-
- <p>Thus, Shale is a modern web application framework,
- fundamentally based on JavaServer Faces, and focused on improving
- ease of use for developers adopting JSF as a foundational technology
- in their own development environments. At the same time, the
- architecture of Shale is a set of fine grained services (and service
- options) that can be combined as needed to meet particular application
- requirements, rather than a monolithic request processor that is hard
- to customize and extend. In addition, integration links for other
- frameworks and framework components are provided, to ease development
- when combinations of technologies are required.</p>
-
- <blockquote><em>EDITOR'S NOTE: Why "Shale"? As others have pointed out,
- the cultural rules of engagement at Apache encourage both evolution
- and revolution in software designs. Revolutions are typically assigned
- code names while they are under discussion, gaining access to the
- branding of the overall project once they are accepted (or, going off
- on their own if they are not). Other proposals for Struts 2.x have
- talked about tearing down the walls inside the framework, and those
- are Good Things. Shale's architecture, on the other hand, is based
- on the principle that we should fundamentally divide the notion of a
- web application framework into solid individual layers, much as we
- see geologically in shale deposits around our volcanoes and coastlines.
- Each layer of the framework should focus on the specific requirements
- that are relevant to that layer -- and use of one layer should not
- necessarily require the use of all the rest (although it's certainly
- reasonable for synergies to exist if all the layers are chosen :-).
- Hence, "shale".</em></blockquote>
-
- </subsection>
-
<a name="foundations"/>
<subsection name="Foundations">