You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by jv...@apache.org on 2001/12/29 04:32:44 UTC
cvs commit: jakarta-turbine-3/notes NOTES
jvanzyl 01/12/28 19:32:44
Modified: notes NOTES
Log:
- some notes on the pipeline format as dan is doing some work on
it now. dan if you get the pipeline working i'll plug in the xml->object
mapping.
Revision Changes Path
1.3 +50 -22 jakarta-turbine-3/notes/NOTES
Index: NOTES
===================================================================
RCS file: /home/cvs/jakarta-turbine-3/notes/NOTES,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- NOTES 29 Dec 2001 01:19:27 -0000 1.2
+++ NOTES 29 Dec 2001 03:32:44 -0000 1.3
@@ -65,30 +65,58 @@
Something like the following may be used to define
a Pipeline for an application:
- <application>
- <pipeline className="org.mycompany.newapp.pipeline.MyPipeline">
- <valve className="org.mycompany.newapp.valve.ValveA"/>
- <valve className="org.mycompany.newapp.valve.ValveB"/>
- <valve className="org.mycompany.newapp.valve.ValveC"/>
- <valve className="org.mycompany.newapp.valve.ValveD"/>
- <valve className="org.mycompany.newapp.valve.ValveE"/>
- </pipeline>
- </application>
+ ---
- We could use the Digester classes in the commons to easily
- parse this into a Pipeline object.
-
- The classic view mechanism from Turbine 2.x must be integrated into
- the Pipeline API. There are misfits with this:
-
- o portal view doesn't follow classic
- o binary output doesn't follow classic model
- o output of markups other than html
- o output of xml tranformations
-
- We want to be able to output anything in a flexible manner.
- Rigth now we are constrained by the classic model.
+ This is the format that can be automatically mapped to an
+ object with the little mapper in statum.
+ <pipeline>
+ <class>org.apache.turbine.pipeline.ClassicPipeline</class>
+ <valves>
+ <valve>
+ <class>org.apache.turbine.pipeline.Valve1</class>
+ </valve>
+ <valve>
+ <class>org.apache.turbine.pipeline.Valve2</class>
+ </valve>
+ <valve>
+ <class>org.apache.turbine.pipeline.Valve3</class>
+ </valve>
+ </valves>
+ </pipeline>
+
+ The reasoning for defining everything in the body text is
+ keep the object data and the mapping meta data separate. If
+ there are special mapping requirements, pulling in an external
+ file for example, than they are specified with attributes.
+
+ The format may be verbose but the benefit is clear separation
+ of mapping information and the object information and you
+ don't need to write a lick of code to map this to an object.
+
+ The mapper is also capable of pulling in a set of objects and
+ placing them in a list. So the mapper can easily process a set
+ of pipeline descriptors like the example above.
+
+ The valves can also be defined in separate files and referenced
+ like so:
+
+ <pipeline>
+ <class>org.apache.turbine.pipeline.ClassicPipeline</class>
+ <valves>
+ <valve xid="valve1">
+ <valve xid="valve2">
+ <valve xid="valve3">
+ </valves>
+ </pipeline>
+
+ And the valve objects will be created automatically and added
+ to the pipeline. So by using references things get easier
+ and it promotes reuse. So people who don't like extra typing
+ don't have that much to complain about :-)
+
+ ---
+
----------------------------------------------------------------
M O D U L E S
----------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>