Re: [midgard-user] Snippet and other namespace conventions (was: Re: [midgard-user] Migrating Content to Sitegroups)

[Philipp Rotmann, Linksystem Muenchen]

     Hi Henri,

On 02.02.01 (16:22), Henri Bergius wrote:
> Sorry, founding a company has taken 190% of my free time.

Good luck then -- I guess it will offer Midgard services of some
kind ... ? I can easily understand your lack of time under that
circumstances :-)

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

As a personal name is not unique, I'd suggest to work with the
hostname of the server a publicly accessible Midgard site is
running on. I can see the disadvantage of that idea (as there
will also be people without a server or midgard account on a
server with permanent internet connectivity), but I think this
kind of problem is less likely to happen and simpler to cope
with.

> The snippetdir path is always written in lowercase ASCII letters.

... and separated by slashes, as of the Midgard documentation.
Asgard uses uppercase letters also, just as a note.

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

In fact, I'd try to avoid two levels of locally meaningless
snippetdirs by (again) backing Emile's approach and using a
mixture of both your ideas to the following outcome:

  com.nemein/data/...

and maybe

  com.nemein.webmail/stuff/...

for another server of yours;

  org.midgard-project/interface/intl/

for il8n code and

  org.envida.bergie/...

just for you :-)  If you don't have a permanent internet
connection (not even a pseudo-permanent one with different IP
addresses, for which you could get a hostname at dyndns.org),
you're on your own, well ...


> Snippets and classes
> --------------------
> 
> TODO

What about "strip delimiters of any kind and uppercase every
first letter" => OrgEnvidaBergieTestbedMidgardInterfaceIntl ;-)

PHP doesn't properly support different namespaces besides
classes, does it? That would be a killer feature ...

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

This gets quite complex when done right ... :-/

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

Why not simply by the snippet itself (delimiters converted to
underscores or uppercased letters)? A "main" class might not be
unique for some snippets.

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

Thanks for taking the time!

Re-thinking the whole namespace stuff before ... I guess, we
could also go the Perl module way and simply use common names,
'avoiding' (better: offering the possibility to avoid) namespace
clashes by registration in a central repository.

How does the java stuff handle class naming? Do they have
another level of namespaces ('packages'?) or do java hackers
actually call their classes
arpa.in-addr.138.2.30.195.phr.personal.funstuff.petprj.data? ;-)

     phr
-- 
Linksystem Muenchen GmbH                          [EMAIL PROTECTED]
Schloerstrasse 10                           http://www.link-m.de
80634 Muenchen                              Tel. 089 / 890 518-0
We make the Net work.                       Fax 089 / 890 518-77

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]