blob: 69d967be2e38699b48ee3b11d5a783d9218099d2 [file] [log] [blame]
Work in progress.
This proposal outlines an implementation of the "Pull API" proposed
by Jon Stevens. What we would like to provide is an easy way for
designers to restructure the Information Architechure (IA) of
a web site without the need of consulting a software engineer.
A full explanation of the Pull Model is outline <a href="">here</a>.
- use the velocity service
- types of tools that could be made
-> message manager
This would allow the designers to create a single set
of temlates and use the message manager to control
localized message handling. Something like:
$app.messageManger.WelcomeText
This would also allow a division of labour for
the process of creating the text for a locale.
The designers can concentrate on design and work
with a single set of templates while the text people
can work on making a set of properties files or
resource bundles for each of the locales to
be supported.
Allow the reloading of message bundles so that the
server doesn't have to be restarted.
Hm. Maybe the tool itself could have a little
configuration manager that checks for changes
in the source configuration and sends events
to listeners. That might be good for all tools,
efficient operation but reload new values when
needed and cache them again.
Kav:
We might also want to have simple interpolation
in any of the messages that are localized.
WelcomeText=Hi $username this is your $visit visit!
This would be very useful. These little properties
could be made little templates so the interpolation
would work.
-> ui manager
Control all aspects of the UI with this context tool.
Any part of the site that has a UI element can be
controlled with this tool. By changing a properties
file the skin of an application could be changed.
$app.uiManager.TableColor
The UI properties could be stored in a database or
in properties files. Allow for the easy switching
of skins and the reloading of skins on the fly so
that you don't have to restart the web server
to make UI changes take effect.
-> security manager
Perform security operations using the pull model because
we need control of it here. Because the security is
controlled in the screen. I wonder if we could have
a security manager that would allow the controlling
of each of the screens with a web admin tool.
No reloading detection need as each security request
requires a hit to live data anyway.
-> datamanager
Making it very easy for the designer to get information
out of the database. They would need some sort of
information based on the schema ... we could probably
produce something from the schema that designers
could use to extract information from the database.
Have a tool that assembles a particular criteria
object for a peer to use to grab a set of info.
$app.dataManager.Companies
Now what would this actually do. How can the designer
actually control the IA if it involves changing
the number of rows produced in a table.
No reloading detection need as each security request
requires a hit to live data anyway.
- creating a tool api in velocity with a little doclet
that allows us to create documentation for the
designers using the tools
- outline the creation of these tools in a little
toolbox by creating a context that can be used
over and over again by using context chaining.