[RT] More thoughts about the publication API

[Andreas Hartmann <an...@apache.org>]

Hi Lenya developers,

currently I'm implementing a kind of "advanced publication
API" in a publication. I'd like to tell you some of my
thoughts and experiences. Maybe it makes sense to push
down some of those things into the Lenya core.

A short summary of the intention:

+---------------------------------------+
| Workflow of my publication            |
+---------------------------------------+
| API of my publication                 |
+---------------------------------------+
| Lenya API                             |
+---------------------------------------+
| Repository                            |
+---------------------------------------+

(At the moment, publication-independent classes which
should come from the core are still in my publication.)

I want to push as much functionality as possible down
the layer stack. From the bottom this looks like:

-----------------------------------------

The Lenya API provides easy-to-use access to the complete
flexibility of Lenya.

-----------------------------------------

The API of my publication covers the publication-specific
resources and their capabilities.

This level provides easy-to-use access to the complete
flexibility of my publication. It reduces the complexity
of Lenya to the requirements of the publication-specific
workflow operations.

The workflow functions operate mainly on the objects
of this layer. For simple publications, it won't be
necessary to implement this layer.

-----------------------------------------

At the top level (workflow operations), I want to deal
with quite abstract, "big" things. I don't want to care
about storage details, versioning etc. This makes it
easier to add / change functionality.

The top layer should be as lean as possible to avoid
code duplication in different workflow operations.

=========================================

Some examples:

Lenya API
---------

public interface Resource {
     ResourceVersion getVersion(...);
     void triggerWorkflow(Situation situation, String event);
     ResourceType getType();
}

API of my publication
---------------------

public class Section extends CollectionResource {
     public void addArticle(Article article) {...}
}

public class Article extends ResourceImpl {
     public String linkToComment(Comment comment} {...}
}

Workflow layer
--------------

public class DeleteArticle {
     public void delete() {
         article.getSection().remove(article);
         article.unlinkFromComments();
         article.deleteAllVersions();
         article.triggerWorkflow("delete");
     }
}

=============================================

In the publication I refer to, there's a mapping from
document IDs to resource classes. I'm using a ResourceFactory
to build Resource objects for document IDs. This is
kind of knowledge duplication (parameter-doctype.xmap).

We would have to generalize DocumentType to ResourceType and
establish a single way to obtain the ResourceType for a
resource. This could be a component, e.g. with a sitemap
lookup implementation (SourceTypeAction) and a Java
implementation (custom mapping).

OK, this were just some random thoughts.
Feel free to add your opinion, I'll do so later.

-- Andreas


---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org