cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: [RT] from linkmaps to flowmaps
Date Mon, 05 Mar 2001 17:37:05 GMT
Stefano Mazzocchi wrote:
> But let's move on: C1 is so limited in functionality that is not even
> useful to comment on it, so let's skip it.

C1 leaves WebApp navigation and other facilities to you, hence easier
integration with Turbine, et. al.  C2 takes away some of those integration
points because of the Sitemap--a powerful feature.

> C2 gives you a clear and elegant projection of the site using a
> "rotation" (given by the pipeline model and the declarative matching
> architecture) that is very effective in separating crosscutting
> concerns.
> But is it really so?

:)  I've got some input, so we will see below:

>  1) plan and design the URI space!

This is part of Analysis and Design.  At our company we use a modified
Flow Chart to depict WebApp flow.  It came in very handy when we
redesigned how the user interacts with the site, and came up with the
concept of Parallel Actions.  A Parrallel Action is simply an action
that works on several records simultaneously.

>  2) estimate link degradation

In a real Web Application, the links between pages are relatively
constant--the information displayed on the pages changes with the
underlying data.

>  3) agglomerate links dependening on their order of
>     degradation, possibly on different pages.

Maybe this is because I never got anything above a Recording Arts
Specialized Associate Degree, and learned how to program later; but
I am not quite sure what you are referring to here.

> To answer such a question we must define what a "linkmap" is: a
> collection of relations between resources.
> XLink provides sufficient expressivity to write such a thing and
> XPointer provides sufficient granularity to link very specific parts of
> a resource.
> But is this really useful?

No.  The Flowmap or automatic navigational components are required.

> The solution I envision is the creation of a "flowmap" where the web-app
> designer is not focused on intermediate locations (resources), but in
> the flow of the application, much like you procedural languages let you
> program by writing a flow, not filling memory slots declaratively with
> instructions.

I have a navigational Action that I developed that will only let a viewer
see pages after they have logged in.  When fully fleshed out, it will
fill the "void" in my immediate need.  However it only solves part of the
problem--so the FlowMap concept looks very interesting to me.

> So, what is a flowmap?
> Take a piece of paper, avoid thinking you are writing an application for
> the web, so avoid taking into consideration technical constraints (like
> the request/response paradigm, intrinsic statelessness, low bandwidth,
> proxying, etc..) and draw a diagram of the latest application you wrote.
> What you should outline, at this stage, is the 'skeleton' of the flow:
> this should be drawn to give the other people in the team the overlall
> picture of what the application is doing.
> So, let's see, let's take something like
>          identification
>                ^
>                |
>                v
>  (enter) ---> home ---> (exit)
>                ^
>                |
>                +--> read article <-()-> post comment
>                |
>                +-()-> set preferences
>                |
>                +-()-> add article
>                |
>                +-(editor)-> accept submission
> where:
>  (enter) indicates the entrance of the application
>  (exit) guess what? :)
>  ---> indicates a 'general flow' [no restriction on identity]
>  <---> indicates a 'bidirectional flow'
>  -(???)-> indicates a 'restricted flow'
>  -()-> indicates a 'identificated flow'

This is very similar to the Modified Flow Charts we use to map the
Flow of the Application.  In fact, we will typically break up one
large webapp into smaller ones.  For instance, we have a product
called VendorExchange that is designed to act as an interface
between Vendors and Retailers.  It manages the workflow of getting
a product approved for sale in the Retailer's stores.  There are
several smaller Webapps in the larger one, namely: Product submittal,
Product Display submittal, Promotion information management,
and Cost Changes for existing products.

Each of these smaller webapps have some similar structure (to make
it easier for the end user).  So a FlowMap to be really useful has
to support the notion of of Sub Flows, or Heirarchical Flow Maps.

> an 'identificated flow' requires that the user is identified.

In other words: the user is logged in or Authenticated.

> a 'restricted flow' is a specialized 'identification flow' that requires
> identification and belonging to a specific identification group which
> has enough rights to enter.

Restated, the Authenticated user must be Authorized.  Let me interject
that many times the same record has different views based on the Role
or Authorization of the user.  For example, in the afforementioned
WebApp, a new Product that is submitted to a Retailer has information
that the Vendor must enter and view.  Once submitted, the application
is in a read-only state for that user--BUT THE FLOW HAS NOT CHANGED.
The next person in the WorkFlow, typically the one who manages a
specific Category of products has to review the submitted information,
and enter some proprietary information for the Retailer that only
internal users can view.

Again, the information shown has changed, but the FLOW is the same.
Flow being described as the movement between one page of the form and
the next.

> We can starting noting a few properties of a flowmap:
> 1) there must be no end stages, the flowmap must describe a fully
> connected graph between the (enter) and (exit) dummy stages.

True.  For our workflow apps, the "enter" would start at login, and
the "exit" would start at logout.

> This is very important: the absence of such a fully connected graph does
> *NOT* make the application unusable, but this is only because of "back"
> functionalities in your browser.

I would venture to say that the "back" button in a webapp with
important information is a dangerous thing.  There are methods of detecting
if the back button or stop button has been pressed so that you can force
a "forwards only" flow for the user.

> In short, a fully connected flowmap avoids the 'dead end' problem.

Absolutely necessary.

> 2) the site of the flowmap represents a good estimation of the web-app
> complexity and gives an fuzzy metric.

Pre-planning the flow of information gives you a better idea of the useability
of the webapp.  Too much recursion is a *bad* thing, but carefully managed
flow can help a user use the system.

> This is very important: while the sitemap size gives a fuzzy metric on
> the publishing effort and its growth over time rates site scalability on
> production, the flowmap size gives an estimation of the effort required
> to implement it.

My sitemap is fairly small compared to the one included in the Cocoon Samples,
because at this time, I only need a few features and flow is managed by a
Navigation Action.

> 3) the flowmap gives an immediate view of the application and, most
> important, identifies immediately the 'restricted areas' and the groups
> that are allowed to enter them.

If you didn't do this already, before building the webapp, you are asking
for rework later.  There are some common sense conclusions that you can
come up with before unleashing your webapp on the world.

> This creates a contract between the administration concern island (who
> is in charge of designing the restrictions) and the logic concern island
> (who is in charge of implementing them).

It is important to point out here, that the role of the Administrator has
to be clearly defined.  The Sitemap merges the concern of administration of
publishing constraints and the selection of Actions for forms, etc.  This
is a clash as a multipage form navigation needs to be easily maintained by
a Developer--not an Admin.

> This is already long enough so I'll stop here.

Alot has been said, but most in the last section.

> A few questions need to be answered and I'll like to hear your comments
> on them:
> 1) can the flowmap be used not only for description, but directly for
> design like we do for the sitemap?

Yes.  In fact, it could be designed like an orthagonal view of the sitemap.
It needs to describe the flow of Form pages and implicitly their handlers.
There also needs to be a method of conditionally selecting pipeline elements
and flow based on runtime information such as variables returned from an

> 2) if so, is there a way to completely remove aspect overlap between
> sitemaps and flowmaps and make them totally independent given a few
> solid contracts between the two?

It would be equivalent to Mounting a SiteMap.  In fact, to the Cocoon system,
they would both be a SiteMap--however the semantics of specifying flow, error
handling, and navigational rules needs to apply here.  Actions have there
place in both views of the URI space, but they are more pronounced in the
FlowMap idea.

> 3) if so, which contracts? is URI space enough?

No. URI Space is only one of the flows that need to be handled.  We as a
company are going to use 3rd Party Workflow Engines to manage record movement
between roles, however that does not affect the flow of the form to the user.

The concerns that have to be managed are:

* URI Space
* Authentication/Authorization for certain URIs
* Action definition and use.
* Automatic backtracking based on errors.
* Back button and Stop button detection (some apps require that a transaction
  can only be executed once).

> 4) where would actions be described?

It should be able to be described in both places.  The FlowMap will need a
different set of Actions.

> 5) whose concern would flowmap maintenance be?

The developer's.  There might be a use-case for a Business Analyst to alter
the flow of the webapp--but form handling semantics and rules need to be
handled by the developer.

> 6) would the introduction of the flowmap concept require changes in
> cocoon's core design?

No.  It would require another MarkupLanguage that creates a Sitemap object
by the different semantics of the FlowMap.

The functionality of the sitemap is same, but the semantics regarding flow
and definition of the pipeline are different.

There is a number of things that can be done by Actions--and careful planning
can yield some very flexible results.  For example, the DatabaseActions that
I created use an XML configuration file to determine how they are used in a
given flow.  This is sort of a secondary mapping of URI to logic.  In other
words, one Action is used in multiple locations, but the specifics of its
action are handled by an orthagonal view of the semantics.  OK, I think I
just confused myself there:

Database{Add|Delete|Update}Action is defined once.  However based on one
parameter, I specify a configuration file that maps the Request parameters
to database columns in a table.  This is very important as it enables the
Action to be reused with different mappings based on the URI space.

However, it feels clumsy managing the Flow of a Webapp via URIs.  Thus the
Navigation Action I am developing.  It will follow the same semantics of
the DatabaseActions, as the flow of navigation will alter the stylesheet
based on Role, and status of the transaction (draft, pending, approved, rejected).

View raw message