On Fri, 2 Feb 2001, Philipp Rotmann, Linksystem Muenchen wrote:
> Hi,
Greetings!
> Henri wanted to post a spec draft.
Sorry, founding a company has taken 190% of my free time.
The original version was lost in a harddrive crash, so
here's a quick rewrite.
Snippet interoperability spec
=============================
Copyright (C)2001 The Midgard Project Ry
Copyright (C)2001 Nemein Solutions Oy
Introduction
------------
CodeSnippets is a new utility introduced in Midgard 1.4 for helping
the management and distribution of Midgard-based applications and code
libraries. To meet these goals, we must define common standards on how
the snippets function, and how they are named.
Version history
---------------
24.1.2001
Initially created (Henri Bergius)
SnippetDir naming
-----------------
To ensure that snippets produced by different organizations have
unique path names, we have tied the snippetdir path to the domain name
of the organization that has produced the snippet.
The first part of the snippetdir path comes from the toplevel domain
the organization uses, for example 'com', 'org' or 'fi'.
The second part of the snippetdir path comes from the domain name of
the organization, for example 'nemein' or 'midgard-project'.
The third part of the snippetdir path contains the category the
snippet belongs to, for example 'data' for data abstraction snippets
or 'main' for important libraries. This categorization can be defined
by the developer organization.
For individual developers who do not own a domainname, there is the
'personal' toplevel snippetdir. Each developer can then use his own
name as the name of the second part of the path, separated with a
dash.
The snippetdir path is always written in lowercase ASCII letters.
Examples:
/com/nemein/data
contains data abstraction classes developed by Nemein Solutions Oy
/org/midgard-project/interface
contains interface generation libraries used at the Midgard Project's
Web site
/personal/henri-bergius/
contains snippets created by Henri Bergius for his personal site.
Snippets and classes
--------------------
TODO
Variable handling
-----------------
Since HTTP is a stateless protocol, variables need to be handled
between different page views by the application snippet. To avoid
namespace conflicts, we're using the following standard for variable
names.
The variable names should always be prefixed with the name of the
class the variables are handled by.
If you have a snippet with path "/com/nemein/data/article" that
contains an application for handling Midgard article records. The
application's main class is named "com_nemein_data_article". Instead
of using the variable name "title" for the title of your article, use
"com_nemein_data_article_title".
In the 'edit' view you would then have something like:
echo "<p>Title: <input type=\"text\"
name=\"com_nemein_data_article_title\"
value=\"$this->title\">";
In the 'save' method:
global $com_nemein_data_article_title;
$this->title = $com_nemein_data_article_title;
Preference handling
-------------------
The configuration parameters and preferences for an application should
be stored in a standard way. All parameters related to the application
should reside under a domain named by the snippet's main class
(e.g. com_nemein_data_article).
Global preferences are defined by the site administrator, and are
stored as parameters to the snippet itself.
Personal preferences can be defined by users, and are stored as
parameters to the user.
...and a lot more to come, including default methods, etc.
> phr
/Bergie
--
-- Henri Bergius -- +358 40 525 1334 -- [EMAIL PROTECTED] --
http://www.iki.fi/Henri.Bergius
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
