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 2002/02/08 18:51:59 UTC
cvs commit: jakarta-turbine-3/notes security-rundata.txt NOTES Login.vm.txt adapter portlets
jvanzyl 02/02/08 09:51:59
Modified: notes Tag: rundata_security_changes NOTES
Added: notes Tag: rundata_security_changes security-rundata.txt
Removed: notes Tag: rundata_security_changes Login.vm.txt adapter
portlets
Log:
- removing some crap docs
- moved the module related notes into a separate xdoc
Revision Changes Path
No revision
No revision
1.3.2.1 +0 -139 jakarta-turbine-3/notes/NOTES
Index: NOTES
===================================================================
RCS file: /home/cvs/jakarta-turbine-3/notes/NOTES,v
retrieving revision 1.3
retrieving revision 1.3.2.1
diff -u -r1.3 -r1.3.2.1
--- NOTES 29 Dec 2001 03:32:44 -0000 1.3
+++ NOTES 8 Feb 2002 17:51:59 -0000 1.3.2.1
@@ -115,145 +115,6 @@
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
-----------------------------------------------------------------
-
- The ModuleLoader now can deal with arbitrary module
- types by having them defined in TRP. Here is what the properties
- might look like for rendering:
-
- ---
-
- module.packages=org.mycompany.newapp
-
- module.default.actions = TemplateAction
- module.default.screens = TemplateScreen
- module.default.layouts = TemplateLayout
- module.default.navigations = TemplateNavigation
-
- pipeline.default = org.apache.turbine.pipeline.ClassicPipeline
- pipeline.default.targetModuleType = screens
-
- template.default = /Default
- template.default.extension = vm
-
- ---
-
- This little configuration blob is also what is used to tell
- the ModuleLoader what types it can deal with and what the
- default module is for each type. This might not be the
- perfect setup because the default action is never
- really used, but the entry is required to allow the
- ModuleLoader to deal with 'actions' modules. Maybe Actions
- should not be modules. It might be good to make Modules
- strictly entities involved with the view in some fashion.
-
- Here is a little explanation of how rendering works
- with modules now. We'll start by using the classic Turbine
- 2.1 example where we have layouts/navigations/screens.
-
- Everything starts with a Pipeline and a target. In the case
- of the ClassicPipeline which emulates the Turbine 2.1
- model the target is the screen template. In the Turbine
- 2.1 model 'screen' templates are decorated with layout
- templates and navigation templates.
-
- So, let's go through the sequence of events that would
- occur when a particular target is requested:
-
- 1.
- Pipeline determines what the target is, in this example
- the target is defined by the 'template' parameter. This
- may give us a result of '/Index.vm'.
-
- 2.
- Pipeline determines which module corresponds to this
- target and executes it. The execution of the module
- may cause the target to be changed. For example, if
- a user has not logged in than executing the 'Index'
- module may cause the target to be changed to '/Login.vm'.
-
- 3.
- ClassicPipeline is defined to start with a layout template,
- so the layout that best matches the target is determined.
- Say the target is '/Login.vm', the ClassicPipeline would
- determine that '/Login.vm' is the best matching layout
- template so the rendering starts with this layout
- template.
-
- Here is what the '/Login.vm' layout template looks like:
-
- ---
-
- <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
- "http://www.w3.org/TR/html4/loose.dtd">
-
- <html>
- <head>
- <title>$page.Title</title>
- </head>
- <body bgcolor="$ui.bgcolor">
-
- <table width="100%">
- <tr>
- <td colspan="2">
- $renderer.render("navigations", $data, "/DefaultTop.vm")
- </td>
- </tr>
- <tr>
- <td align="left">
- $renderer.render("screens", $data, $target)
- </td>
- </tr>
- <tr>
- <td colspan="2">
- $renderer.render("navigations", $data, "/DefaultBottom.vm")
- </td>
- </tr>
- </table>
-
- </body>
- </html>
-
- ---
-
- As you notice there is a $renderer reference in the template. This
- context tool is responsible for the renderering of any 'decoration'
- templates and the target. To use the renderer you specify a
- module type, a RunData object, and a template of the specified
- module type. The renderer will then resolve the module that best
- matches the template and execute the module before the template
- is rendered.
-
- The algorthm used to match decoration templates to targets, and
- modules to targets is the same. It works the same way that the
- search for layout and navigation modules/templates did. So if
- the target is 'science,chemistry,Titanium.vm' than the
- following modules will be searched for given the properties
- listed above:
-
- science.chemistry.Titanium
- science.chemistry.Default
- science.Default
- Default
-
- And the following layout template will be
- searched for:
-
- layouts/science/chemistry/Titanium.vm
- layouts/science/chemistry/Default.vm
- layouts/science/Default.vm
- layouts/Default.vm
-
- Some problems with this right now are that there is
- no way to change how the decoration templates are
- matched to the target. For example people commonly want
- to have a particular layout for a group of users. Something
- will be added shortly to rectify this.
-
----------------------------------------------------------------
T O D O & G E N E R A L M U S I N G S
----------------------------------------------------------------
No revision
No revision
1.1.2.1 +28 -0 jakarta-turbine-3/notes/Attic/security-rundata.txt
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>