jvanzyl 01/07/13 11:44:34
Added: notes Login.vm.txt NOTES NOTES.fulcrum ecs.removal
ilkka-notes pipeline portlets validation
Log:
- adding notes so people can read as i go.
Revision Changes Path
1.1 jakarta-turbine/notes/Login.vm.txt
Index: Login.vm.txt
===================================================================
<!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, $template)
</td>
</tr>
<tr>
<td colspan="2">
$renderer.render("navigations", $data, "/DefaultBottom.vm")
</td>
</tr>
</table>
</body>
</html>
1.1 jakarta-turbine/notes/NOTES
Index: NOTES
===================================================================
----------------------------------------------------------------
N O T E S
----------------------------------------------------------------
Turbine.java:
o Configuration has to be removed or swapped for a
Configuration interface that uses ExtendedProperties
as a concrete implementation. A Configuration interface
in the commons would be ideal. (ln 152)
o The ModuleLoader is used but ideally there should be
a ModuleLoader in each app so that an app can be
completely separate. Maybe the ModuleLoader should be
modified to use a its own ClassLoader. (ln 249)
More on the ModuleLoader below.
o The Pipeline is used but again each app should probably
define its own Pipeline. In most cases an app will
use a standard Pipeline but we want apps to live
in their own world. Turbine will become a controller
for apps in a way. (ln 292)
More on the Pipeline below.
o The Log class should probably be removed and there
should be a Turbine.getCategory() so that all Turbine
classes can log using that. (ln 303)
o Check the initialization as Gonzalo notice some
problems in a demo that involved numerous clients.
Is the syncronization we are using correct? (ln 313)
o Possibly create a TurbineRequestDispatcher to deal
with each request. Hopefully most of the processing
that is taking place in doGet() will be handled by
the Pipeline by adding more Valves. (ln 356)
o The whole processing could use some work, it's still
a bit confusing as to what is actually going on (ln 384-615)
o The handleException has to be cleaned up because there
are no Page modules anymore. This should probably also
be handled by the Pipeline. We also need to deal with outputing
the error in content types other than text/html. (ln 656)
----------------------------------------------------------------
P I P E L I N E
----------------------------------------------------------------
Right now the Pipeline is very primitive. In its
current state it is behaving very much like a
Page module in 2.1. The methods being executed
in the Pipeline are currently fixed, but each
method currently being invoked should be turned
into a Valve. You should be able to add Valves
to a Pipeline using an XML configuration and
the Pipeline will than invoke each Valve in
the Pipeline. Catalina also uses a ValveContext
which can be used to control the flow of invocation.
For example, invoking one Valve may preclude the
invocation of the next Valve in the Pipeline.
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.
----------------------------------------------------------------
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
----------------------------------------------------------------
o have a single set of modules, push everything into
the template engine services.
DONE
o detach scheduler service
DONE
but it needs a mechanism to search through a set of
packages for jobs.
o clean up the whole hierarchy the utils and security.
Martin is working on security
o placement of most used classes, probably don't want them
buried
org.apache.turbine.RunData;
org.apache.turbine.TemplateContext;
o have another mechanism for direct output an equivalent
raw page or something.
o torque and the extension mechanism
o think about the caching relationship between turbine
itself and the template service.
It might be wise to move the template service into
a proper piece of turbine code so that I can get
away from the singleton crap of the services. There
probably needs to be a template service per app.
These need to be lightweight so that many components
don't weigh the system down.
o need a way to use arbitrary modules in the template
service make the properties and aggregation model
a lot more general.
general module cache
possible integration with the module loader
o need to get rid of vel Configuration class.
o standard way of developing so that look and feel
of parent application is obeyed. how to do this
so that style sheets can be used as well as
the ui manger. or have the ui manager deal
with both
o how to display the same content to multiple locales
on multiple devices.
o jyve for Turbine
o torque
-> generate turbine user class with torque
-> get rid of TurbineMapBuilder
-> generate JobEntry class (DONE: martin)
-> populators
-> reuse resolver
-> base model between intake and torque
-> XML -> HTML needs to be fixed
-> use the digester instead of sax directly
-> JDBC -> XML needs work (DONE: fedor)
-> timestamping for torque like anakia
-> example for dump/import
o try and find out about dynamic bean properties
how to set properties in reusable components
o policy Service
o descriptions for schemas
o use constants throughout source
o tdk app that can act as a testbed and a sample
of what turbine can do
o tdk development model. take ideas from scarab.
the idea of an import descriptor so that any
turbine app can be pulled into the tdk
o application service. flux will be the first
example.
o look at classloaders and using the bsf for modules
o tool for taking patches and making xdocs with
them. or make a tool to manage patches so that
i don't have to deal with mail where i lose
track.
o cleanup the services
-> use ExtendedProperties class but put a configuration
class in front of it
o subapp to administer ldap entries
o turbine resource not as a service
Turbine.getConfiguration() works, so we just
have to get rid of TurbineResources now.
o incorporate bsf the module loader
o flash5 admin app
o turbine flash service
o turbine weather service
o turbine rss service. can use the digester example
o service repository
o view service. processing of modules using the
idea of a pipeline. turbine would have a default
pipeline and lifecycle. this way the old module
processing could co-exist with the new service
and people would have to change their TRP to use
the new method. this would avoid conflicts in use
but allow us to refactor the module processing which
is currently a mess IMO
o the ui manager should be able to store skins in any
form, the same with the message manager. can probably
use the stuff craig has for the message manager.
a general resource system would be cool.
Note from jeff about sql generation on id table stuff.
<ekkerbj> idtable/Control.vm needs to skip table defs that have nosql set.
The names of the gen'd idtable.sql files are not getting the ${project}
resolved ( only and issue with multiple database defs in schema ). The
build.xml for a gen'd application needs to somehow know the name of the
idtable.sql files in the case where there are multiple databases defined in
the schema.
<ekkerbj> It's all an issue with multiple databases defined in the schema
and the idtable/* tempaltes.
<ekkerbj> Another issue in sql/Control.vm: The name of the gen'd .sql file
is different when multiple db's are defined in the schemea ( same issue with
idtable/Control.vm ) and this breaks the default build.xml for a tdk add
when it attempt to run the .sql script.
<ekkerbj> Again all releated to multiple db's defined in the schema.
There is a patch in the pipeline but I haven't looked at
it closely.
o defaultIdMethod doesn't work in torque.
? I think Martin fixed this.
o look for the layout matching problem.
FIXED: was due to top level Default.class in Flux
o Need a detailed migration document
o tool to transform the sources for migration
o proxy builder
o scheduler service needs to be entirely decoupled
the worker thread is bound.
DONE
o anywhere where threads are used we should move
to using the Executor class in Doug Lea's concurrent
package.
o a proper caching service needs to be created
o add ObjectUtils methods to torque templates to decouple
from turbine.
o turbine will consist of a set of components, it would be
nice to have a notification system letting people know
there are new pieces available and what the changes
are. has to be dead simple to upgrade a system.
o template settings should be template engine specific
for them to run properly together.
o content filtering mechansism.
o replace TurbineException in services with FulcrumException
o how to map a set of users to a look and feel
o how to do site branding
o JobEntry class is still dependent on the TurbineMapBuilder
o Lucene service
o Slide service
o Turbine application registry. would be nice to get
an idea of what turbine is being used for.
o flux in a jar
o torque in a jar
o remove messages from TRP and the relavant sources.
they should either be in templates or resources accessible
to designers.
o Would it be possible to use BeanUtils from the commons
to replace all the reflection code in PP. More
than likely. We should reuse as much as possible
from the commons.
o Ilkka noted a concern with the use the structure of
Turbine.java. It is present in 'ilkka-notes'. I'm not
sure if it is such a problem with the services being
completely separate but I definitely don't want to put
us in a box we can't get out of. Ilkka's comments
are totally appreciated and nothing is cast in stone
we can rememedy any short comings before we release.
o All the parser classes could probably be moved out
of the turbine util. what is actually being used? It's
a little hard to tell.
o Did we every figure out how to localize parameters
coming back from PP? And there's a lot of duplicated
code in PP that looks like the Configuration interface.
Maybe PP could extend ExtendedProperties of a Configuration
interface.
o While trying to move all the parser into the same package
i see how couple all these things are. moving a couple
classes broke way more code than i thought possible. yuck.
Upon further looking, it was my import qualifier putting
parent import references in the classes.
o the RunData/RunData service stuff has to be grouped
better. maybe the ServerData class could be eliminated
all together. get rid of all the object creation possible.
o get rid of as much object creation for a request as possible.
ServerData immediately comes to mind.
1.1 jakarta-turbine/notes/NOTES.fulcrum
Index: NOTES.fulcrum
===================================================================
o need to make a simple logging component that
can be passed into the services framework. this
will require a decent api for a logging component.
o need a way to startup a service when the servlet
starts. this is a general feature of the service
framework.
o have to worry about references between the
services.
o hiding how the storage of the configuration,
the services should just get properties from
the service manager.
o getManager() or put the getInstance in one
of the base classes.
o convert all our services over to using the
new way and deprecate the old methods.
o make TurbineConfig fully backward compatible
if i've broken it.
o make all the naming consistent there are problems
with some of the properties not belonging to services.
have to cleanly separate what belongs to the services
and what are actually properties of turbine.
1.1 jakarta-turbine/notes/ecs.removal
Index: ecs.removal
===================================================================
These are the remaining classes with ECS references:
org/apache/turbine/util/TimeSelector.java
org/apache/turbine/RunData.java
org/apache/turbine/services/rundata/DefaultTurbineRunData.java
org/apache/turbine/util/template/TemplatePageAttributes.java
org/apache/turbine/util/mail/HtmlEmail.java
org/apache/turbine/util/SelectorBox.java
1.1 jakarta-turbine/notes/ilkka-notes
Index: ilkka-notes
===================================================================
Subject: Turbine 2.2
Date: Friday, July 13, 2001 3:35 AM
From: Ilkka Priha <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Jason,
There's a serious limitation in flexibility of Turbine 2.2 compared with
2.1. The Turbine servlet is now final and contains critical static methods
that are referenced all around the system. Even TurbineConstants are
referenced through the Turbine servlet. This makes it almost impossible to
use Turbine from other environments than the servlet environment and even
customization of that one has been prohibited.
I think that a servlet is an implementation of a API making it possible to
access your software from a certain type of execution environment that in
this case happens to be Sun's servlet environment. However, to make your
software available for other environments also, like stand-alone apps, RPC
apps, Corba apps, embedded apps, JME2 apps, etc. you need to provide many
other access points to your software also. So the servlet should only
implement the access methods and call your proprietory API independent
initialization and configuraration tools. Then other access point methods
can also be implemented calling the same tools. Not any of the objects
INSIDE your software should refer to the servlet object because it's meaning
is to be one of the objects that the OUTSIDE world sees to access your
software.
So there should be some other independent static object, like TurbineConfig,
providing all the static methods now included in the Turbine servlet. The
servlet only initializes the TurbineConfig, but other objects can initialize
it as well. All references to the Turbine servlet should be changed to
references to TurbineConstants and TurbineConfig.
I hope I could exlain this correctly. It's actually a small change in the
object structure but opens a lot more alternatives on how to integrate
Turbine to different environments. And this is also required to be
compatible with 2.1 :-)
-- Ilkka
1.1 jakarta-turbine/notes/pipeline
Index: pipeline
===================================================================
Have to figure out the pipeline API and the the view mechanism
together. I know there are misfits:
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.
1.1 jakarta-turbine/notes/portlets
Index: portlets
===================================================================
o weather
o movie listings
o horoscope
o news
o rss
o webmail
o calendaring
1.1 jakarta-turbine/notes/validation
Index: validation
===================================================================
o a little tool could be made so that what has to be present
in forms is made available to designers.
<form action="$form.Action" method="post">
$form.Title.Label <!-- localized -->
<input name="$form.Title.Name"
value="$form.Title.Value">
$form.Title.Help <!-- localized -->
$form.Title.Label <!-- localized -->
<input name="$form.Author.Name"
value="$form.Author.Value">
$form.Author.Help <!-- localized -->
<input type="submit" name="$form.Action.Name"
value="$form.Action.Value">
</form>
o this has to be completely easy to use for designers.
what is currently in the templates for intake is
too difficult. i showed it to two designers i know
and said it was too complicated for them.
design/validation/flow control are separate concerns.
you may have someone smart enough to do everything
but roles should not be forced on people because all
the functionality is placed in the template.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
