| 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. |