You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@polygene.apache.org by ni...@apache.org on 2015/07/08 11:43:12 UTC
[09/11] zest-qi4j git commit: Wrong encoding must have been used earlier. Changed to UTF-8 for all tradmarks ™, and merged in DocUpdate branch
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/manual/src/docs/userguide/preface.txt
----------------------------------------------------------------------
diff --git a/manual/src/docs/userguide/preface.txt b/manual/src/docs/userguide/preface.txt
index fd47975..668d5b1 100644
--- a/manual/src/docs/userguide/preface.txt
+++ b/manual/src/docs/userguide/preface.txt
@@ -20,7 +20,7 @@
[[preface, Preface]]
= Preface =
-This is the reference manual for Zest� version {qi4j-version}, written by members of the Zest� Community.
+This is the reference manual for Zest™ version {qi4j-version}, written by members of the Zest™ Community.
The main parts of the manual are:
@@ -28,11 +28,11 @@ The main parts of the manual are:
* <<tutorials>> -- learn how to use Zest.
* <<core-api>> -- detailed information on how to use Zest.
* <<libraries>> -- detailed information on the many libraries available for Zest.
-* <<extensions>> -- detailed information each of the Zest� extensions, such as entity stores,
+* <<extensions>> -- detailed information each of the Zest™ extensions, such as entity stores,
indexing, caching and runtime metrics.
The material is practical, technical, and focused on answering specific questions.
-It addresses how things work, what to do and what to avoid to successfully use Zest� in domain rich applications.
+It addresses how things work, what to do and what to avoid to successfully use Zest™ in domain rich applications.
The goal is to be thumb-through and rule-of-thumb friendly.
@@ -40,7 +40,7 @@ Each section should stand on its own, so you can hop right to whatever interests
When possible, the sections distill "rules of thumb" which you can keep in mind whenever you wander out of the house
without this manual in your back pocket.
-The included code examples are executed when Zest� is built and tested.
+The included code examples are executed when Zest™ is built and tested.
_Who should read this?_
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/manual/src/docs/userguide/tools.txt
----------------------------------------------------------------------
diff --git a/manual/src/docs/userguide/tools.txt b/manual/src/docs/userguide/tools.txt
index 2be9669..2a4b1e0 100644
--- a/manual/src/docs/userguide/tools.txt
+++ b/manual/src/docs/userguide/tools.txt
@@ -24,11 +24,11 @@
== Overview ==
-The Zest� SDK comes with usefull development tools. Theses tools can come in
+The Zest™ SDK comes with usefull development tools. Theses tools can come in
handy when assembled into your <<def-application>> in development
<<def-application-mode>>.
-The tools are available in the +tools/+ directory of the Zest� SDK.
+The tools are available in the +tools/+ directory of the Zest™ SDK.
:leveloffset: 2
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/manual/src/docs/website/samples.txt
----------------------------------------------------------------------
diff --git a/manual/src/docs/website/samples.txt b/manual/src/docs/website/samples.txt
index 5d09260..f029138 100644
--- a/manual/src/docs/website/samples.txt
+++ b/manual/src/docs/website/samples.txt
@@ -24,16 +24,16 @@
== Overview ==
-The Zest� SDK comes with several sample applications. This is a very good place
+The Zest™ SDK comes with several sample applications. This is a very good place
to look for code examples and recipes.
-The samples are available in the +samples/+ directory of the Zest� SDK.
+The samples are available in the +samples/+ directory of the Zest™ SDK.
[[sample-dci, DCI Sample]]
== DCI Sample ==
Sample of how DCI (Data, Context & Interaction) pattern is implemented using
-Zest� core only.
+Zest™ core only.
https://github.com/Qi4j/qi4j-sdk/tree/develop/samples/dci[Browse Source]
@@ -41,7 +41,7 @@ https://github.com/Qi4j/qi4j-sdk/tree/develop/samples/dci[Browse Source]
== DCI Cargo Sample ==
Sample of how DCI (Data, Context & Interaction) pattern is implemented with
-Zest�, for Eric Evans DDD sample.
+Zest™, for Eric Evans DDD sample.
This sample, contributed by Marc Grue, is described in details on his
website: http://marcgrue.com/
@@ -67,7 +67,7 @@ https://github.com/Qi4j/qi4j-sdk/tree/develop/samples/rental[Browse Source]
// [[sample-scala,Scala Sample]]
// == Scala Sample ==
//
-// Sample of how to use Scala with Zest�.
+// Sample of how to use Scala with Zest™.
//
// https://github.com/Qi4j/qi4j-sdk/tree/develop/samples/scala[Browse Source]
@@ -76,7 +76,7 @@ https://github.com/Qi4j/qi4j-sdk/tree/develop/samples/rental[Browse Source]
NOTE: This sample use PostgreSQL and drop all of its data once run in order to be runnable multiple times.
-Sample of how to fully use Zest� SQL support : <<library-sql>>, <<extension-es-sql>> and <<extension-indexing-sql>>.
+Sample of how to fully use Zest™ SQL support : <<library-sql>>, <<extension-es-sql>> and <<extension-indexing-sql>>.
https://github.com/Qi4j/qi4j-sdk/tree/develop/samples/sql-support[Browse Source]
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/manual/src/docs/website/tutorials.txt
----------------------------------------------------------------------
diff --git a/manual/src/docs/website/tutorials.txt b/manual/src/docs/website/tutorials.txt
index 0214c98..8e2d9ce 100644
--- a/manual/src/docs/website/tutorials.txt
+++ b/manual/src/docs/website/tutorials.txt
@@ -25,15 +25,15 @@
== Overview ==
TIP: Theses tutorials are based on actual code found in the `tutorials/` directory of the
-http://qi4j.org/downloads.html[Zest� SDK sources]. You should start your favorite editor and find the code related to
+http://qi4j.org/downloads.html[Zest™ SDK sources]. You should start your favorite editor and find the code related to
this tutorial, run it and play with it.
-In this section you will find a comprehensive set of tutorials about Composite Oriented Programming using Zest�.
+In this section you will find a comprehensive set of tutorials about Composite Oriented Programming using Zest™.
-[[tutorials-intro,Zest� in 2 hours 42 minutes]]
-=== Zest� in 2 hours 42 minutes ===
+[[tutorials-intro,Zest™ in 2 hours 42 minutes]]
+=== Zest™ in 2 hours 42 minutes ===
-This quite long introduction to Zest� will start by brushing up an overview of the problems Zest� solve, teach you what
+This quite long introduction to Zest™ will start by brushing up an overview of the problems Zest™ solve, teach you what
Composite Oriented Programming is and guide you through the process of writing a complete Application around an adapted
Hello World example.
@@ -42,9 +42,9 @@ Hello World example.
- <<thirty-minutes-intro>>
- <<two-hours-intro>>
-=== Getting real with Zest� ===
+=== Getting real with Zest™ ===
-Throughout this set of tutorials it will be shown how to depend on Zest� in your build, how to assemble a complete
+Throughout this set of tutorials it will be shown how to depend on Zest™ in your build, how to assemble a complete
application, how to create and work with Composites and Services, how to use contextual fragments and leverage
properties.
@@ -67,10 +67,10 @@ typical application.
- <<howto-configure-service>>
- <<howto-use-io>>
-=== Zest� Development ===
+=== Zest™ Development ===
-This last set of tutorials you'll learn how to build the Zest� SDK from sources including this very documentation website
-, the Zest� manual, binaries and sources distributions.
+This last set of tutorials you'll learn how to build the Zest™ SDK from sources including this very documentation website
+, the Zest™ manual, binaries and sources distributions.
- <<build-system>>
- <<community-docs>>
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/samples/dci-cargo/README.txt
----------------------------------------------------------------------
diff --git a/samples/dci-cargo/README.txt b/samples/dci-cargo/README.txt
index 4f71f53..b588156 100644
--- a/samples/dci-cargo/README.txt
+++ b/samples/dci-cargo/README.txt
@@ -1,7 +1,7 @@
DCI Sample
==========
-This is a port of the DDD Sample application to the DCI paradigm using Java, Zest� and Wicket.
+This is a port of the DDD Sample application to the DCI paradigm using Java, Zest™ and Wicket.
The code is licensed under the Apache Software License 2.0 and lastest revisions are
available from https://github.com/dci.
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/tools/envisage/src/docs/envisage.txt
----------------------------------------------------------------------
diff --git a/tools/envisage/src/docs/envisage.txt b/tools/envisage/src/docs/envisage.txt
index 9ad460f..01551c0 100644
--- a/tools/envisage/src/docs/envisage.txt
+++ b/tools/envisage/src/docs/envisage.txt
@@ -20,7 +20,7 @@
[[tools-envisage,Envisage Tool]]
= Envisage =
-Envisage is a Swing based visualization tool for the Zest� Application model.
+Envisage is a Swing based visualization tool for the Zest™ Application model.
Visualizations can be printed to PDFs.
== Usage ==
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/tutorials/composites/src/docs/step1.txt
----------------------------------------------------------------------
diff --git a/tutorials/composites/src/docs/step1.txt b/tutorials/composites/src/docs/step1.txt
index e49d127..df8ce5c 100644
--- a/tutorials/composites/src/docs/step1.txt
+++ b/tutorials/composites/src/docs/step1.txt
@@ -22,7 +22,7 @@
== Initial Hello World ==
-This whole tutorial describes how to step-by-step modify a typical HelloWorld "application" into a full-fledged Zest�
+This whole tutorial describes how to step-by-step modify a typical HelloWorld "application" into a full-fledged Zest™
Composite Oriented application. Here is the initial code of HelloWorld.
[snippet,java]
@@ -36,7 +36,7 @@ tag=initial
In this step we start with a basic Java class, which when invoked will concatenate the two properties "phrase"
and "name". If invoked with the properties set to "Hello" and "World" respectively it will hence return "Hello World".
-Zest� relies heavily on the use of interfaces. This makes it possible for an object to externally implement a number of
+Zest™ relies heavily on the use of interfaces. This makes it possible for an object to externally implement a number of
interfaces which internally is backed by a number of Mixins, some of which you may have written yourself, and some of
which may have been reused. This also makes it easy to introduce Modifiers (aka "interceptors", aka "advice"), which
are Fragments which execute before and/or after the method on the Mixin is invoked.
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/tutorials/composites/src/docs/step2.txt
----------------------------------------------------------------------
diff --git a/tutorials/composites/src/docs/step2.txt b/tutorials/composites/src/docs/step2.txt
index 80b675c..1268ce1 100644
--- a/tutorials/composites/src/docs/step2.txt
+++ b/tutorials/composites/src/docs/step2.txt
@@ -29,8 +29,8 @@ Constraints. In this tutorial we will only use Mixins. When a TransientComposite
framework will inspect the interface to determine what the TransientComposite instance should look like in terms of
used Fragments.
-In Zest� all method parameters are considered mandatory unless marked as @Optional. Therefore you can remove the null
-checks in the Mixin. If a null value is passed in an exception will be thrown by Zest�.
+In Zest™ all method parameters are considered mandatory unless marked as @Optional. Therefore you can remove the null
+checks in the Mixin. If a null value is passed in an exception will be thrown by Zest™.
Steps for this tutorial:
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/tutorials/composites/src/docs/step5.txt
----------------------------------------------------------------------
diff --git a/tutorials/composites/src/docs/step5.txt b/tutorials/composites/src/docs/step5.txt
index 79cdd0c..054d1ad 100644
--- a/tutorials/composites/src/docs/step5.txt
+++ b/tutorials/composites/src/docs/step5.txt
@@ -27,7 +27,7 @@ restriction we can make is to denote a type. Any other constraints on the input
optional, integer ranges, string regular expressions, and so on, cannot be expressed, and so we have to put this into
Javadoc, and then manually add these checks in the implementation class.
-In Zest� there is the option to use Constraints, which are further restrictions on the parameters. This is implemented
+In Zest™ there is the option to use Constraints, which are further restrictions on the parameters. This is implemented
by having an annotation that describes what the Constraint does, and then an implementation class that checks whether a
specific value fulfills the Constraint or not.
@@ -35,8 +35,8 @@ NOTE: The previous steps had a dependency to the <<core-api>> only. The constrai
introduce a new dependency to the <<library-constraints>>, where all the constraint related classes reside. So
update your classpath settings accordingly.
-There are a number of pre-written constraints in Zest� which you can use. The null check of the original HelloWorld
-version is already handled by default since Zest� considers method parameters to be mandatory if not explicitly marked
+There are a number of pre-written constraints in Zest™ which you can use. The null check of the original HelloWorld
+version is already handled by default since Zest™ considers method parameters to be mandatory if not explicitly marked
with the @Optional annotation. So, instead of doing that check we will add other checks that are useful to make, such
as ensuring that the passed in string is not empty.
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/tutorials/composites/src/docs/step7.txt
----------------------------------------------------------------------
diff --git a/tutorials/composites/src/docs/step7.txt b/tutorials/composites/src/docs/step7.txt
index 8f6e561..bdec58a 100644
--- a/tutorials/composites/src/docs/step7.txt
+++ b/tutorials/composites/src/docs/step7.txt
@@ -22,11 +22,11 @@
Previous step was <<tut-composites-step6>>.
-One of the goals of Zest� is to give you domain modeling tools that allow you to more concisely use domain concepts in
+One of the goals of Zest™ is to give you domain modeling tools that allow you to more concisely use domain concepts in
code. One of the things we do rather often is model Properties of objects as getters and setters. But this is a very
weak model, and does not give you any access to metadata about the property, and also makes common tasks like UI binding
non-trivial. There is also a lot of repetition of code, which is unnecessary. Using JavaBeans conventions one typically
-have to have code in five places for one property, whereas in Zest� the same thing can be achieved with one line of code.
+have to have code in five places for one property, whereas in Zest™ the same thing can be achieved with one line of code.
But lets start out easy. To declare a property you have to make a method in a mixin type that returns a value of the
type Property, and which does not take any parameters. Here's a simple example:
@@ -43,14 +43,14 @@ For now you will be responsible for implementing these methods, but later on the
reducing Properties to one-liners!
In the Mixin implementation of the interface with the Property declaration you should have an injection of the Property,
-which is created for you by Zest�. The injection can be done in a field like this:
+which is created for you by Zest™. The injection can be done in a field like this:
[source,java]
----
@State Property<String> name;
----
-The State dependency injection annotation means that Zest� will inject the Property for you. The field has the name
+The State dependency injection annotation means that Zest™ will inject the Property for you. The field has the name
"name", which matches the name in the interface, and therefore that Property is injected. You can then implement the
method trivially by just returning the "name" field.
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/tutorials/composites/src/docs/step8.txt
----------------------------------------------------------------------
diff --git a/tutorials/composites/src/docs/step8.txt b/tutorials/composites/src/docs/step8.txt
index c41208f..90225ce 100644
--- a/tutorials/composites/src/docs/step8.txt
+++ b/tutorials/composites/src/docs/step8.txt
@@ -33,7 +33,7 @@ java.lang.proxy.InvocationHandler. This has a single "invoke" method which is pa
TransientComposite in this case), the method, and the arguments. The Fragment is then allowed to implement the method
any way it wants.
-Since interfaces with only Properties is such a common case Zest� already has a generic Mixin that implements the
+Since interfaces with only Properties is such a common case Zest™ already has a generic Mixin that implements the
Properties management described above, but for the builtin Property type instead of the getter/setter variant. The
class is aptly named PropertyMixin.
@@ -43,7 +43,7 @@ Steps for this tutorial:
- Remove the HelloWorldStateMixin
- Add a GenericPropertyMixin, and have it implement InvocationHandler
-- Inject "@State StateHolder state" in the mixin. The StateHolder interface will give you access to the Properties for the TransientComposite which Zest� manages for you
+- Inject "@State StateHolder state" in the mixin. The StateHolder interface will give you access to the Properties for the TransientComposite which Zest™ manages for you
- On call to invoke(), delegate to the StateHolder interface to get the Property for the invoked method
- Add an @AppliesTo annotation to the Mixin and implement the AppliesToFilter with a rule that matches only methods that return Property values.
- Add the mixin to the TransientComposite.
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/tutorials/composites/src/docs/step9.txt
----------------------------------------------------------------------
diff --git a/tutorials/composites/src/docs/step9.txt b/tutorials/composites/src/docs/step9.txt
index 6addfd3..6e6047f 100644
--- a/tutorials/composites/src/docs/step9.txt
+++ b/tutorials/composites/src/docs/step9.txt
@@ -31,7 +31,7 @@ This forces the mixin to implement the TransientComposite type, which would norm
implement all methods, including those found in the TransientComposite interface. However, since we are only really
interested in implementing the say() method we will mark this by declaring that the Mixin "implements" the
TransientComposite type, but is also "abstract". This, using pure Java semantics, makes it possible to avoid having to
-implement all methods. Zest� will during the initialization phase detect that the Mixin only handles the say() method,
+implement all methods. Zest™ will during the initialization phase detect that the Mixin only handles the say() method,
and therefore only map it to that specific method. In order to instantiate the Mixin it will generate a subclass which
implements the remaining methods in the TransientComposite type, as no-ops. These will never be called however, and is
there purely for the purpose of being able to instantiate the Mixin. The Mixin is considered to be an Abstract Fragment.
@@ -39,7 +39,7 @@ there purely for the purpose of being able to instantiate the Mixin. The Mixin i
To hide the state from the client we need to use what is called Private Mixins. A Private Mixin is any mixin that is
referenced by another Mixin by using the @This injection, but which is not included in the TransientComposite type. As
long as there is a Mixin implementation declared for the interface specified by the @This injection it will work, since
-Zest� can know how to implement the interface. But since it is not extended by the TransientComposite type there is no
+Zest™ can know how to implement the interface. But since it is not extended by the TransientComposite type there is no
way for a user of the TransientComposite to access it. That Mixin becomes an implementation detail. This can be used
either for encapsulation purposes, or for referencing utility mixins that help the rest of the code implement some
interface, but which itself should not be exposed.
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/tutorials/composites/src/docs/tut-composites.txt
----------------------------------------------------------------------
diff --git a/tutorials/composites/src/docs/tut-composites.txt b/tutorials/composites/src/docs/tut-composites.txt
index cb06854..1020d93 100644
--- a/tutorials/composites/src/docs/tut-composites.txt
+++ b/tutorials/composites/src/docs/tut-composites.txt
@@ -21,14 +21,14 @@
= Transient Composites Tutorial =
TIP: Theses tutorials are based on actual code found in the `tutorials/` directory of the
-http://qi4j.org/downloads.html[Zest� SDK sources]. You should start your favorite editor and find the code related to
+http://qi4j.org/downloads.html[Zest™ SDK sources]. You should start your favorite editor and find the code related to
this tutorial, run it and play with it.
Throughout this set of tutorials it will be shown how to create and work with Composites, which
-is the basic element in Zest�. We will refactor one HelloWorld class to take advantage of the various
-features in Zest�. These refactorings will make it easier to reuse parts of the class,
+is the basic element in Zest™. We will refactor one HelloWorld class to take advantage of the various
+features in Zest™. These refactorings will make it easier to reuse parts of the class,
and introduce new features without having to change existing code. We will also look
-at some of the existing classes, or Fragments, available in Zest� that you can reuse
+at some of the existing classes, or Fragments, available in Zest™ that you can reuse
so that you don't have to write everything yourself.
- <<tut-composites-step1>>
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/tutorials/introduction/src/docs/background.txt
----------------------------------------------------------------------
diff --git a/tutorials/introduction/src/docs/background.txt b/tutorials/introduction/src/docs/background.txt
index a24f821..96fcb5f 100644
--- a/tutorials/introduction/src/docs/background.txt
+++ b/tutorials/introduction/src/docs/background.txt
@@ -19,22 +19,22 @@
[[introduction-background,Background]]
= Background =
-Zest� is the first Composite Oriented Programming implementation leveraging the Java 5 platform, so that everything you
-know from Java 5 still applies. You can mix Zest� with your ordinary Java code as much as you want. All your existing
-Java tools works just like before, and Zest� does not introduce any new programming language, no special development
+Zest™ is the first Composite Oriented Programming implementation leveraging the Java 5 platform, so that everything you
+know from Java 5 still applies. You can mix Zest™ with your ordinary Java code as much as you want. All your existing
+Java tools works just like before, and Zest™ does not introduce any new programming language, no special development
tools needed and no XML is required.
== Purpose ==
-Zest� addresses the programming problems from the top-down, starting with the Domain Model and Business Rules needs,
+Zest™ addresses the programming problems from the top-down, starting with the Domain Model and Business Rules needs,
and let those requirements flow downwards in the software stack and dictate the requirements for underlying layers
such as persistence, messaging, querying and more. This means that the business value developer is left to
concentrate on the domain models and the actual application bringing the value, instead of creating massive amounts
of glue code to tie underlying technologies together.
== Problem Descriptions ==
-Zest� didn't appear out of the blue, when the founders of the project had nothing better to do. It is the result of
+Zest™ didn't appear out of the blue, when the founders of the project had nothing better to do. It is the result of
observation of problems in real applications, and the experience from previous attempts to address or correct these
-problems, that has led to the Zest� vision.
+problems, that has led to the Zest™ vision.
== Object Oriented Programming (OOP) ==
How can OOP be a problem? We and others have observed that there is a fundamental flaw in the OOP model. In fact, we
@@ -117,4 +117,4 @@ ServerContextualInvoiceEntity, and then persist the changes.
Composite Oriented Programming is heavily influenced by the book "Domain Driven Design" by Eric Evans. And we are
trying to use his analysis of the problem to provide the mechanisms needed to get the job done quicker and more
reliably. Mr Evans talks about Applications, Layers, Modules, Specifications, SideEffects and so forth, and all of
-these should be present in a Composite Oriented Programming implementation, and to a large extent it is in Zest�.
+these should be present in a Composite Oriented Programming implementation, and to a large extent it is in Zest™.
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/tutorials/introduction/src/docs/qi4j-cop.txt
----------------------------------------------------------------------
diff --git a/tutorials/introduction/src/docs/qi4j-cop.txt b/tutorials/introduction/src/docs/qi4j-cop.txt
index 175ce7b..0726ab8 100644
--- a/tutorials/introduction/src/docs/qi4j-cop.txt
+++ b/tutorials/introduction/src/docs/qi4j-cop.txt
@@ -17,6 +17,6 @@
* under the License.
///////////////////////////////////////////////////////////////
-[[qi4j-cop,COP with Java and Zest�]]
-= COP with Java and Zest� =
+[[qi4j-cop,COP with Java and Zest™]]
+= COP with Java and Zest™ =
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/tutorials/introduction/src/docs/state-modeling.txt
----------------------------------------------------------------------
diff --git a/tutorials/introduction/src/docs/state-modeling.txt b/tutorials/introduction/src/docs/state-modeling.txt
index 0dff931..0c5ec82 100644
--- a/tutorials/introduction/src/docs/state-modeling.txt
+++ b/tutorials/introduction/src/docs/state-modeling.txt
@@ -18,11 +18,11 @@
///////////////////////////////////////////////////////////////
[[state-modeling,State Modeling]]
-= Zest� and state modeling =
+= Zest™ and state modeling =
(From Rickard Oberg's blog, http://www.jroller.com/rickard/entry/qi4j_and_state_modeling, 2009-02-19)
-In the Zest� project we strive to being able to express our domain as directly as possible, with as little translation
+In the Zest™ project we strive to being able to express our domain as directly as possible, with as little translation
as possible between how we think about a domain and how it is actually coded.
This then affects our entire view of how application frameworks should be constructed, and what we consider good and
bad ways of implementing certain features.
@@ -36,7 +36,7 @@ In Domain Driven Design terms, POJOs are not in our Ubiquitous Language.
From a DDD perspective we want to talk about Entities and Values, Properties and Associations.
If our code does not reflect this, then there is translation going on, and translation inevitably leads to information loss.
-In Zest�, where Composites and not Objects, are the basic construct, we have created specialized forms to model these
+In Zest™, where Composites and not Objects, are the basic construct, we have created specialized forms to model these
concepts more explicitly.
We have EntityComposites and ValueComposites, each with different ways of creating them and managing them.
Both EntityComposites and ValueComposites can then have Properties, as first-class objects, but Properties in
@@ -93,7 +93,7 @@ For Collections they are set to empty collections of the type indicated.
"@UseDefaults Property<List<String>> addresses();" would be initialized to an empty ArrayList, for example.
In addition I have set surName() to be @Optional.
-In Zest� we have defined all properties to be not-null as the default, and the same goes for all parameters in method
+In Zest™ we have defined all properties to be not-null as the default, and the same goes for all parameters in method
invocations.
If you explicitly want to allow properties to be null, so that for example "Madonna" would be an acceptable name,
then you can mark it as @Optional.
@@ -134,7 +134,7 @@ What should have been a neat and tidy little package is instead a anorectic litt
around your code, looking all soggy and unappetizing.
What to do about this?
-One of the great inventions of Zest�, I believe, is the notion of private mixins.
+One of the great inventions of Zest™, I believe, is the notion of private mixins.
That we can have mixins in an object which are explicitly HIDDEN from usage outside of it.
How can we use this for state modeling?
What you'd want to do is to model the state of an Entity as a private mixin, which is hidden from clients, and then
@@ -164,10 +164,10 @@ Entity doesn't need the "Listable" interface the mixin will never be instantiate
And so much more...
-The above is just a small taste of what you can do with state modeling in Zest�.
+The above is just a small taste of what you can do with state modeling in Zest™.
There is also support for associations and many-associations, the notion of aggregates, and a complete pluggable
system for persistence and indexing/querying of data.
-To end with, here's a sample of how some other state modeling concepts can be expressed in Zest�:
+To end with, here's a sample of how some other state modeling concepts can be expressed in Zest™:
[snippet,java]
-----------
@@ -177,5 +177,5 @@ tag=more
I hope they are self-explanatory.
-My hope is that with Composite Oriented Programming and Zest� we can come one step closer to being able to express our
+My hope is that with Composite Oriented Programming and Zest™ we can come one step closer to being able to express our
domain as clearly as possible in code.
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/tutorials/introduction/src/docs/whats-an-object.txt
----------------------------------------------------------------------
diff --git a/tutorials/introduction/src/docs/whats-an-object.txt b/tutorials/introduction/src/docs/whats-an-object.txt
index 08009e0..11bb20d 100644
--- a/tutorials/introduction/src/docs/whats-an-object.txt
+++ b/tutorials/introduction/src/docs/whats-an-object.txt
@@ -47,7 +47,7 @@ is the OBSERVER of the object, meaning, the algorithm, that gets to decide what
This is the same in real life. I don't get to decide how I communicate with you. I have to use english, and I have to
use email, and I have to send it to a specific mailing list. It is the algorithm of the interaction between us, the
-Zest� dev mailing list, that has set these rules, not *I* as a participant in this interaction. The same should,
+Zest™ dev mailing list, that has set these rules, not *I* as a participant in this interaction. The same should,
obviously, be the case for objects.
So, with the understanding that algorithms should define roles for collaborating objects, and objects should then
@@ -63,7 +63,7 @@ This "solution", which is caused by this fundamental flaw in "class oriented pro
causes a number of other problems, such as the "self schizophrenia" problem, whereby there is no way to tell where the
object really is. There is no "this" pointer that has any relevant meaning.
-The Composite pattern, as implemented in COP and Zest�, gets around this by simply saying that the composite, as a
+The Composite pattern, as implemented in COP and Zest™, gets around this by simply saying that the composite, as a
whole, is an object. Tada, we now have a "this" pointer, and a coherent way to deal with the object graph as though it
was a single object. We are now able to get back to the strengths of the procedural approach, which allows the
implementer of the algorithm to define the roles needed for the algorithm. The roles can either be specific to an
@@ -77,7 +77,7 @@ necessary to read composite code when trying to understand algorithms. The assum
more algorithms than composites, therefore it has to be easy to ready algorithms, and only when necessary dive down into
composite code.
-When talking about Composites as Objects in Zest� it is most relevant to look at Entities, since these represent physical
+When talking about Composites as Objects in Zest™ it is most relevant to look at Entities, since these represent physical
objects in a model, rather than algorithms or services, or other non-instance-oriented things.
If Entities should implement roles, via mixins, in order to interact with each other through algorithms, then the
@@ -134,7 +134,7 @@ code and read it. If we have read the mixin code once, and the same mixin is reu
it easier for us to understand it the next time we see it being used in another algorithm.
To summarize thus far, we have looked at why OOP so far has not worked out, why this is the case, and how COP deals
-with it, and how we can implement a better solution of Entities using Zest�. All is well!
+with it, and how we can implement a better solution of Entities using Zest™. All is well!
The next step is to start using these Entities in algorithms. Algorithms are usually stateless, or at least they don't
have any state that survives the execution of the algorithm. There is input, some calculation, and then output. In
@@ -189,15 +189,15 @@ The interaction method "delegate" is testable, both with mocks of the input, and
roles. The implementations are also testable, and if the same mixin is used over and over for the implementation, then
only one set of tests is needed for each role interface.
-To summarize we have in COP/Zest� a way to get the best from procedural and object-oriented programming. As we have seen
+To summarize we have in COP/Zest™ a way to get the best from procedural and object-oriented programming. As we have seen
the functionality falls into three categories, the entities implementing objects, the services implementing
interactions, and the user interface implementing the context. This also maps well to the ideas of ModelViewController,
which in turn maps well to the new ideas from Mr Reenskaug (inventor of MVC) called DCI: Data-Context-Interaction. As a
-side-effect of this discussion we have therefore also seen how COP/Zest� can be used to implement DCI, which is an
+side-effect of this discussion we have therefore also seen how COP/Zest™ can be used to implement DCI, which is an
important next step in understanding objects and their interactions, the fundamentals of which (I believe) are captured
on this page.
That's it. Well done if you've read this far :-)
Comments and thoughts to qi4j-dev forum at Google Groups on this are highly appreciated. This is very very important topics,
-and crucial to understanding/explaining why COP/Zest� is so great! :-)
+and crucial to understanding/explaining why COP/Zest™ is so great! :-)
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/tutorials/introduction/tenminutes/src/docs/ten-minutes.txt
----------------------------------------------------------------------
diff --git a/tutorials/introduction/tenminutes/src/docs/ten-minutes.txt b/tutorials/introduction/tenminutes/src/docs/ten-minutes.txt
index 1d298c7..baca4b6 100644
--- a/tutorials/introduction/tenminutes/src/docs/ten-minutes.txt
+++ b/tutorials/introduction/tenminutes/src/docs/ten-minutes.txt
@@ -17,18 +17,18 @@
* under the License.
///////////////////////////////////////////////////////////////
-[[ten-minutes-intro,Zest� in 10 minutes]]
-= Zest� in 10 minutes =
+[[ten-minutes-intro,Zest™ in 10 minutes]]
+= Zest™ in 10 minutes =
TIP: Theses tutorials are based on actual code found in the `tutorials/` directory of the
-http://qi4j.org/downloads.html[Zest� SDK sources]. You should start your favorite editor and find the code related to
+http://qi4j.org/downloads.html[Zest™ SDK sources]. You should start your favorite editor and find the code related to
this tutorial, run it and play with it.
- * Zest� does not introduce any new programming language, no additional compilers needed and all your existing tools
+ * Zest™ does not introduce any new programming language, no additional compilers needed and all your existing tools
work just like before. It is pure Java.
- * Zest� works with Composites.
- * The equivalent of an Object instance in OOP, is a Composite instance in Zest�.
+ * Zest™ works with Composites.
+ * The equivalent of an Object instance in OOP, is a Composite instance in Zest™.
* Composites are constructed from Fragments.
* Fragments are Mixins, Concerns, Constraints and SideEffects.
* Only Mixins carry Composite state. The others are shared between Composite instances.
@@ -62,14 +62,14 @@ tag=allClass
Extending the ConcernOf is a convenience mechanism, instead of an explicit @ConcernFor annotation on a private field,
which can be used in rare occasions when you are not able to extend. This base class defines the `next` field, which is
-set up by the Zest� runtime and points to the next fragment in the call stack.
+set up by the Zest™ runtime and points to the next fragment in the call stack.
-We can also see that the InventoryService is provided to the concern, which is done with dependency injection. Zest�
+We can also see that the InventoryService is provided to the concern, which is done with dependency injection. Zest™
also supports dependency injection via constructors and methods.
-The above example is obviously doing persistence, and we have no code handling this. But Zest� supports persistence
-directly in its Core, and it is taken care of by Zest�, since it is declared as an EntityComposite.
-Nothing else is needed, provided that the Zest� Runtime has been setup with one or more persisted EntityStores. But
+The above example is obviously doing persistence, and we have no code handling this. But Zest™ supports persistence
+directly in its Core, and it is taken care of by Zest™, since it is declared as an EntityComposite.
+Nothing else is needed, provided that the Zest™ Runtime has been setup with one or more persisted EntityStores. But
we have a naming convention that EntityComposites have "Entity" as the suffix in its name.
There are other built-in Composite subtypes as well, such as ValueComposite and ServiceComposite. This distinction helps
@@ -93,10 +93,10 @@ tag=allClass
-----------
The MailService is dependency injected, as we have seen before.
-@This is telling Zest� that the SideEffect needs a reference to the Composite instance that it belongs to.
+@This is telling Zest™ that the SideEffect needs a reference to the Composite instance that it belongs to.
By asking for both the HasCustomer and the HasLineItems types, we get type-safety and don't need to bother with casts.
-In fact, Zest� will ensure that you can't even cast the `hasCustomer` instance to the HasLineItems type.
+In fact, Zest™ will ensure that you can't even cast the `hasCustomer` instance to the HasLineItems type.
By not referencing the aggregated interface OrderEntity, we reduce the coupling of this SideEffect and it can be used
in any other Composite where the HasCustomer and HasLineItems combination is used, for instance in an InvoiceEntity.
@@ -105,5 +105,5 @@ So, build the report, send it via the MailService.
== Conclusion ==
-In this short introduction, we have covered the essence of Zest�. We have looked at what is a Composite, seen some of the
+In this short introduction, we have covered the essence of Zest™. We have looked at what is a Composite, seen some of the
Fragments in action, and how simple it is to turn a Composite into a persisted Composite, known as an EntityComposite.
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/tutorials/introduction/thirtyminutes/src/docs/thirty-minutes.txt
----------------------------------------------------------------------
diff --git a/tutorials/introduction/thirtyminutes/src/docs/thirty-minutes.txt b/tutorials/introduction/thirtyminutes/src/docs/thirty-minutes.txt
index 80ad021..55c9412 100644
--- a/tutorials/introduction/thirtyminutes/src/docs/thirty-minutes.txt
+++ b/tutorials/introduction/thirtyminutes/src/docs/thirty-minutes.txt
@@ -17,16 +17,16 @@
* under the License.
///////////////////////////////////////////////////////////////
-[[thirty-minutes-intro,Zest� in 30 minutes]]
-= Zest� in 30 minutes =
+[[thirty-minutes-intro,Zest™ in 30 minutes]]
+= Zest™ in 30 minutes =
TIP: Theses tutorials are based on actual code found in the `tutorials/` directory of the
-http://qi4j.org/downloads.html[Zest� SDK sources]. You should start your favorite editor and find the code related to
+http://qi4j.org/downloads.html[Zest™ SDK sources]. You should start your favorite editor and find the code related to
this tutorial, run it and play with it.
-This introduction will deepen your understanding of Zest�, as we touches on a couple of the common features of Zest�. It
-is expected that you have gone through and understood the "Zest� in 10 minutes" introduction.
+This introduction will deepen your understanding of Zest™, as we touches on a couple of the common features of Zest™. It
+is expected that you have gone through and understood the "Zest™ in 10 minutes" introduction.
If you want to reproduce what's explained in this tutorial, remember to depend on the Core Runtime artifact that depends
on Core API, Core SPI, Core Bootstrap and Core Functional & I/O APIs:
@@ -56,8 +56,8 @@ source=tutorials/introduction/thirtyminutes/src/main/java/org/qi4j/demo/thirtymi
tag=2
-----------
-Quite a lot of Zest� features are leveraged above;
-[1] Property is a first class citizen in Zest�, instead of getters/setters naming convention to declare properties.
+Quite a lot of Zest™ features are leveraged above;
+[1] Property is a first class citizen in Zest™, instead of getters/setters naming convention to declare properties.
[2] ValueComposite for Action means that it is among other things Immutable.
[3] The Action extends a Property. We call that Property subtyping and highly recommended.
[4] The CompositeBuilder creates Immutable Action instances.
@@ -87,7 +87,7 @@ tag=4
The above construct is called a Generic Concern, since it implements java.lang.reflect.InvocationHandler instead of the
interface of the domain model. The ConcernOf baseclass will also need to be of InvocationHandler type, and the
-Zest� Runtime will handle the chaining between domain model style and this generic style of interceptor call chain.
+Zest™ Runtime will handle the chaining between domain model style and this generic style of interceptor call chain.
Finally, we need to declare the Concern in the OrderEntity;
@@ -109,7 +109,7 @@ Glad you asked. It is done via the Query API. It is important to understand that
the persistence concern of storage and retrieval. This enables many performance optimization opportunities as well as a
more flexible Indexing strategy. The other thing to understand is that the Query API is using the domain model, in Java,
and not some String based query language. We have made this choice to ensure refactoring safety. In rare cases, the
-Query API is not capable enough, in which case Zest� still provides the ability to look up and execute native queries.
+Query API is not capable enough, in which case Zest™ still provides the ability to look up and execute native queries.
Let's say that we want to find a particular Order from its SequenceNumber.
@@ -152,13 +152,13 @@ This covers the most basic Query capabilities and how to use it. For Querying to
assembled during bootstrap. At the time of this writing, only an RDF indexing subsystem exist, and is added most easily
by assembly.addAssembler( new RdfNativeSesameStoreAssembler() ).
-It can be a bit confusing to see Zest� use Java itself as a Query language, but since we have practically killed the
+It can be a bit confusing to see Zest™ use Java itself as a Query language, but since we have practically killed the
classes and only operate with interfaces, it is possible to do a lot of seemingly magic stuff. Just keep in mind that
it is pure Java, albeit heavy use of dynamic proxies to capture the intent of the query.
== Conclusion ==
-We have now explored a couple more intricate features of Zest�, hopefully without being overwhelmed with details on how
-to create applications from scratch, how to structure applications, and how the entire Zest� Extension system works.
+We have now explored a couple more intricate features of Zest™, hopefully without being overwhelmed with details on how
+to create applications from scratch, how to structure applications, and how the entire Zest™ Extension system works.
We have looked at how to add a Concern that uses a private Mixin, we have touched a bit on Generic Concerns, and
finally a short introduction to the Query API.
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/tutorials/introduction/twohours/src/docs/two-hours.txt
----------------------------------------------------------------------
diff --git a/tutorials/introduction/twohours/src/docs/two-hours.txt b/tutorials/introduction/twohours/src/docs/two-hours.txt
index fa14f5d..5a6d066 100644
--- a/tutorials/introduction/twohours/src/docs/two-hours.txt
+++ b/tutorials/introduction/twohours/src/docs/two-hours.txt
@@ -17,12 +17,12 @@
* under the License.
///////////////////////////////////////////////////////////////
-[[two-hours-intro,Zest� in 2 hours]]
-= Zest� in 2 hours =
+[[two-hours-intro,Zest™ in 2 hours]]
+= Zest™ in 2 hours =
NOTE: This tutorial is not written yet. Learn how to contribute in <<community-docs>>.
-This introduction assumes that the "Zest� in 10 minutes" and "Zest� in 30 minutes" introductions has been read and
+This introduction assumes that the "Zest™ in 10 minutes" and "Zest™ in 30 minutes" introductions has been read and
understood.
In this introduction we will touch on the core concepts of UnitOfWork, Application structure and Bootstrap API.
@@ -34,7 +34,7 @@ interact with the underlying persistence system. This is done via EntitySessions
- Application Structure -
- * There are one Application per Zest� instance.
+ * There are one Application per Zest™ instance.
* An Application consists of one or more Layers.
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/tutorials/introduction/twominutes/src/docs/two-minutes.txt
----------------------------------------------------------------------
diff --git a/tutorials/introduction/twominutes/src/docs/two-minutes.txt b/tutorials/introduction/twominutes/src/docs/two-minutes.txt
index a5c0c04..8720aaf 100644
--- a/tutorials/introduction/twominutes/src/docs/two-minutes.txt
+++ b/tutorials/introduction/twominutes/src/docs/two-minutes.txt
@@ -17,14 +17,14 @@
* under the License.
///////////////////////////////////////////////////////////////
-[[two-minutes-intro,Zest� in 2 minutes]]
-= Zest� in 2 minutes =
+[[two-minutes-intro,Zest™ in 2 minutes]]
+= Zest™ in 2 minutes =
TIP: Theses tutorials are based on actual code found in the `tutorials/` directory of the
-http://qi4j.org/downloads.html[Zest� SDK sources]. You should start your favorite editor and find the code related to
+http://qi4j.org/downloads.html[Zest™ SDK sources]. You should start your favorite editor and find the code related to
this tutorial, run it and play with it.
-To show that Zest� is not necessarily complex, not hard to get going with and easy to deploy, we are first showing the
+To show that Zest™ is not necessarily complex, not hard to get going with and easy to deploy, we are first showing the
classic HelloWorld, as small as it can get and still be Composite Oriented Programming and not only standard OOP.
If you want to reproduce what's explained in this tutorial, remember to depend on the Core Runtime artifact that depends
@@ -64,7 +64,7 @@ source=tutorials/introduction/twominutes/src/main/java/org/qi4j/demo/twominute/M
tag=documentation
-----------
-. The SingletonAssembler is a convenience class that creates a Zest� Runtime instance and an application with one layer
+. The SingletonAssembler is a convenience class that creates a Zest™ Runtime instance and an application with one layer
and one module in it.
. We declare a TransientComposite of type `Speaker`.
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/tutorials/services/src/docs/step1.txt
----------------------------------------------------------------------
diff --git a/tutorials/services/src/docs/step1.txt b/tutorials/services/src/docs/step1.txt
index 21f72d2..761d324 100644
--- a/tutorials/services/src/docs/step1.txt
+++ b/tutorials/services/src/docs/step1.txt
@@ -23,13 +23,13 @@
In this tutorial we start with basic Java classes, to simulate a very simple Library where you can borrow
and return books.
-Zest� relies heavily on the use of interfaces. This makes it possible for an object
+Zest™ relies heavily on the use of interfaces. This makes it possible for an object
to externally implement a number of interfaces which internally is backed by a number
of Mixins, some of which you may have written yourself, and some of which may have been
reused. This is also true for services, which we are to cover in this tutorial.
The first task is therefore to refactor the code so that the methods are implemented from an
-interface instead, and to essentially make the identical "application" into a Zest� application.
+interface instead, and to essentially make the identical "application" into a Zest™ application.
We also want the Book to be a ValueComposite.
Steps for this tutorial:
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/tutorials/services/src/docs/step2.txt
----------------------------------------------------------------------
diff --git a/tutorials/services/src/docs/step2.txt b/tutorials/services/src/docs/step2.txt
index f0c5db0..b3b9079 100644
--- a/tutorials/services/src/docs/step2.txt
+++ b/tutorials/services/src/docs/step2.txt
@@ -21,7 +21,7 @@
= Step 2 - Hooking into the Service Activation =
Services can be "activated" and "passivated". Applications can be notified of this occurring
-by Zest� runtime by assembling them with an Activator.
+by Zest™ runtime by assembling them with an Activator.
Activators methods are called around "activation" and "passivation": beforeActivation,
afterActivation, beforeActivation, afterPassivation. The
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/tutorials/services/src/docs/step3.txt
----------------------------------------------------------------------
diff --git a/tutorials/services/src/docs/step3.txt b/tutorials/services/src/docs/step3.txt
index 62363ef..f81f3e1 100644
--- a/tutorials/services/src/docs/step3.txt
+++ b/tutorials/services/src/docs/step3.txt
@@ -20,13 +20,13 @@
[[tut-services-step3,Step 3 - Reading the Service Configuration]]
= Step 3 - Reading the Service Configuration =
-Services typically have configuration. Configurations are directly supported in Zest�. A
+Services typically have configuration. Configurations are directly supported in Zest™. A
ConfigurationComposite is a subtype of EntityComposite. That is because
configurations are stored in EntityStores, can be modified in runtime by client code and has
the same semantics as regular entities.
-Zest� also handles the bootstrapping of configuration for the services. If the ConfigurationComposite is
-not found in the configured entity store, then Zest� will automatically locate a properties file for each
+Zest™ also handles the bootstrapping of configuration for the services. If the ConfigurationComposite is
+not found in the configured entity store, then Zest™ will automatically locate a properties file for each
service instance, read those properties into a ConfigurationComposite instance, save that to the
entity store and provide the values to the service. The properties file must be with the same name as
the service instance with the extension "properties" in the same package as the service.
http://git-wip-us.apache.org/repos/asf/zest-qi4j/blob/88b203bb/tutorials/services/src/docs/tut-services.txt
----------------------------------------------------------------------
diff --git a/tutorials/services/src/docs/tut-services.txt b/tutorials/services/src/docs/tut-services.txt
index fc051d9..8edcdb7 100644
--- a/tutorials/services/src/docs/tut-services.txt
+++ b/tutorials/services/src/docs/tut-services.txt
@@ -21,13 +21,13 @@
= Services Composites Tutorial =
TIP: Theses tutorials are based on actual code found in the `tutorials/` directory of the
-http://qi4j.org/downloads.html[Zest� SDK sources]. You should start your favorite editor and find the code related to
+http://zest.apache.org/download.html[Zest™ SDK sources]. You should start your favorite editor and find the code related to
this tutorial, run it and play with it.
In this other set of tutorials it will be shown how to create and work with Service Composites, which are composites
that extends from the ServiceComposite class. We will refactor one a very simple Library where you can borrow and
-return books to take advantage of the various features in Zest�. These refactorings will benefit from automatic Service
+return books to take advantage of the various features in Zest™. These refactorings will benefit from automatic Service
activation and Configuration Entities management.
- <<tut-services-step1>>