Dear forum,
I've created a set of modules for which I want to find a proper name. At
the moment I've named the top level AppState for Application State. I
will explain what it does and what the sub modules do below it. You will
see that there is also some reinvention of existing wheels but, of
course, slightly different. I would like to have comments and
suggestions too on that.
The thought was that most programs have always the same ordinary tasks
to do like logging, storing data, communicating with servers, processing
commandline arguments etcetera thereby thinking of a 'state of being'.
There are modules out there for these things but not under one hood.
This set uses some of the modules already on the CPAN.
*AppState*
This module is a singleton module and does not do much except for
looking around for plugins in certain directories. The user of the
AppState object can ask for the plugin objects to do several tasks.
AppState keeps the addresses so when asked again it will give the same
object address back. Very handy when opening a log file in one part of
the program and use it again in another. AppState controls also some
directories in which to store files for logging, pids, temp files and
config.
*AppState::Config*
Configuration file control. At the moment it uses the modules YAML,
Storable, Datadumper, JSON, FreezeThaw and Memcached to load and store
data in several formats. I have to check out if I can use other modules
such as Config::Any or Application::Config
*AppState::Log*
Logging of actions from anywhere in the program. Main differences from
other modules are
* Check for repeated messages
* Check of repetition of the date and time so there is more room for
the message
* Flag to show warning/error messages on STDOUT
* Flag to die on error. Takes away the need to have an extra test to
die after logging.
* Show stack dump on warning/error messages without path to file of
module. This makes it a lot cleaner and easier to find the line in
your code. The path to a modules file is not needed most of the time.
*AppState::Process*
Process control and communication. Purpose is to create server processes
and to communicate with a such server. There is one method only at the
moment which is IPC messaging. Ideas are to use dbus and several network
communication protocols to get to MongoDb, Http servers etc. From this
you can see that it is not necessary to
create your own server but that it should be possible to reach existing
servers too.
*AppState::CommandLine*
Command-line options and argument processing. Module uses Getopt::Long
to get the options. The extra is that this module accepts extra
descriptions text from the caller to create a proper help message
explaining the complete use of the program. I believe there is such a
module available but it misses the possibility to add explanation text
of any arguments.
*AppState::PluginManager*
Plugin manager. This is the bases of several modules in this set. While
there are a few implementations for this purpose this one does the following
- Search for plugins in specified directories.
- Instanciate plugin objects only when called for.
- Plugin object addresses can be saved for next request or thrown away.
- Check plugins for obligatory methods and add stubs when not available.
*AppState::NodeTree*
Nodetree builder. Builds a hierarchical structure of node objects in
memory from a given data structure. After the build one can traverse the
tree in several ways. While traversing it calls user functions to do
something at each node. Methods must still be added to search for nodes
and manipulate the node tree.
Well, this is it. However, I've been busy and created another set of
modules to convert data into other representations. It's based on a few
of the modules above. The module is called Data2any. It started as a
program to convert yaml into xml using a module Yaml2xml. With the above
modules it is possible to read the data from other representations and
changed the name into Data2xml. A short while ago I've extracted a
specific part from the main module as a Xml translator module so changed
the name again into Data2any.
*Data2any*
Module to control the data to something-else translation process.
*Data2any::Tools*
*Data2any::TranslatorTools*
Tool boxes for the plugins and translators
*Data2any::Xml*
Translator to convert to xml
*Data2any::Xml::****
Location of plugins used with the Xml translator
*
Data2any::Xml::LinkFile.pm
*Example plugin to include files from other locations instead of using
XML xinclude and others.
*Data2any::Xml::LorumIpsum
*Example plugin to generate text to fill in paragraphs and the like.*
*
Ideas for translators are Tex and LaTex, specific Xml dialects such as
Docbook, Html5 or something like that to support more control on what is
acceptable for that specific language. Other ideas I have are not really
using a module as a translator but for creating a GUI interface based on
Wx or Tk in the same way Qt designer and KDE Kommander has its GUI saved
in xml.
Hopefully this info will not give a headache.
I wish you all a happy new year,
Marcel Timmerman
