giacomo wrote:
>
> On Wed, 11 Jul 2001, giacomo wrote:
>
> Cocoon 2 does not follow this pattern. For development team you need to
> have ONE person responsible for a sitemap and thus for the design of the
> app/site they are developing. Itegration into a production environment
> should go the usual staged way.
What Jon said and what I was thinking are two different things. I was
thinking of a way to do URL mapping easily if we want it--and have Cocoon
still work if we don't want it.
> > What is wrong with the Sitemap
> > ------------------------------
> >
> > I have already voiced the opinion that the sitemap mixes too many
> > concerns (component
> > type declarations, etc.).
>
> Well, I think I've stated this before. I'd like to see the component
> definition move from sitemap.xmap into cocoon.xconf rather sooner that
> later. This will narrow the sitemap.xsl by quite a bid of code.
It _can_ be done right away. The proper entries need to be made into
cocoon.roles and cocoon.xconf and all will be happy. The only thing
I would reserve the right to define on sitemaps (esp. sub-sitemaps)
are Actions. sometimes there are specific actions that only are necessary
for a particular sub-sitemap. Then again, if we formalize the FlowMap
idea, that wouldn't be necessary.
> > There is also a problem with it being a
> > single point of
> > failure.
>
> Again, this can easily be reduced by sub sitemaps. But there is almost
> always a sigle point of failure in every system.
It just seems that the Sitemap is more fragile than any of them.
> > Just look at all the messages on Cocoon Users with the "The
> > sitemap handler's
> > sitemap is not available" errors. If the sitemap does not compile
> > correctly, the whole
> > site is dead.
>
> No. Only the part of the URI space the mentioned sitemap is mapped to. I
> have to add here that the compilation of the sitemap was an experiment
> I've made long, long ago. Suddenly it was THAT piece of C2. I really
> like to see someone build an iterpreted version to see the differences.
In order to do that, we need normal Matchers and Selectors. The CodeFactory
stuff ONLY works in a compiled setting. In fact, the existence of the
CodeFactory style selectors and matchers only serve to encourage Compile only
approach to the Sitemap.
Another problem is defining where we are going to put it in the Sitemap hierarchy.
The whole sitemap infrastructure is built around compiled sitemaps. This is
not good. There are some major plumbing issues that need to be reworked in order
to allow for the interpreted sitemap.
> > Also there is little security enforced, and the ability
> > to extend the
> > file mapping outside the Servlet's Context. These are bad things. It
> > should _never_
> > be Cocoon's responsibility to mimic all the things that Apache HTTPD can
> > do. Allowing
> > any kind of access outside of the Servlet spec approved areas (the
> > context directory
> > and the repository) is a violation of security constraints and
> > portability requirements
> > in the servlet spec.
>
> Also, if you read the first draft of the sitemap (xdocs/draft/...)
> you'll see why this is possible. The initial design was that you can
> define your context at will for a particular (sub)sitemap URI space
> combination. That it is possible to serve a file outside the context
> (ie. with the FileGenerator) is simply lazyness of the implementation.
> This has nothing to do with servlet spec or whatever. And have in mind
> that Cocoon2 is not a Servlet (it is only embeded into a servlet
> environment as one of the major implemented environments)
Ok. Now I do want to allow for a range of "filters" or matchers or
selectors that work with the Request object so that we can also filter
by Role, etc...
> > The sitemap is the most complex piece in the entire Cocoon system, and
> > as a result, it
> > is difficult for new users to comprehend it. I have had three
> > developers try to use
> > Cocoon, and they look at the sitemap and freeze. They spend too much
> > time trying to
> > understand the Sitemap, and not enough time trying to solve problems.
> > In a development
> > environment, this is not acceptable. It is very frustrating because any
> > time I tell them
> > "I have set up the Sitemap for you, ignore it for now", I find that they
> > are still obsessing
> > with it. The Sitemap as it stands is *too* powerful, and my developers
> > are tempted to
> > try to use it to solve their problems.
>
> I don't know the environment/organisation you use in the development
> cycle you are in but what you state is reality for most teams I've
> worked with. If you build a development team for a application you need
> to develop you almost always have the need for a db guru, a design guru,
> a system administrator a java guru and also average skilled people to do
> basic works so why not a sitemap guru (SoC?). Of course the smaller the
> project/team is the more skilles will be unified on a single person.
This is true. However, people are resistent to that idea--or they want
the position without knowing the details of how it works.
> > Lastly, in practice, there are a few actual pipelines
> > (generator/transformer/serializer)
> > for each site. In fact, I have one pipeline for _all_ my html code in
> > my webapps. The
> > things that differ are the Actions used in conjunction with it, or the
> > type of generator
> > I use.
>
> Ah, so it isn't that hard to write the sitemap for it, isn't it? ;)
Not for me it isn't. Then again, I have been involved with this project
for a long time. I know the inner workings better than most people on the
project due to my intimate knowledge of the framework it is built on. I
know how to work around some of its limitations (usually minor details).
For someone brand new to Cocoon there are always the questions of "What's
the difference between 1 asterisk and 2?", "How do I....". Then when they
start to catch on about the power of the sitemap they start with the, "I
can do this...", and "I can do that...".
New developers just decide that it is acceptable not to do anything and
blame it on the sitemap. I have a feeling that part of this is education,
and part of this is that the infatuation with new toys leaves people wanting
to play with them.
> > Another side affect with the Sitemap is the existence of
> > Readers. It is my belief
> > that anything simply read from a filesystem should be handled by HTTP
> > daemons like Apache,
> > TUX, or whatever you use. They are better optimized for it, and it
> > reduces the load on
> > the JVM. We still need Readers for resources that cannot be reached via
> > the filesystem
> > (i.e. the DatabaseReader).
>
> Nothing prevents you to do so. But it is way easier in the development
> phase to have Tomcat only which is easy to setup on almost every
> platform instead of additionally setup an Apache httpd on the developers
> machine. At deployment time into a production environment you can always
> grab these URLs which should be hadled by an traditional httpd instead
> of passing it to the servlet engine and Cocoon.
True. Instead of mounting Cocoon to map to "/" in the context, we could
have it react to the resources we want to transform (html, pdf, some graphics,
WML, SOAP). But people rarely venture beyond what is given to them. You
also lose the ability to map all "**/*.gif" to point to "resources/images/{1}.gif".
It's a tradeoff.
> I really like and understand the design you are explaining. And I will
> admit it is better designed that the sitemap syntax we have today
> because today we know better what all we'd like to have the sitemap to
> do for us. This comes from the fact that after the initial design some
> more components/constructs needed to be integrated even if we have spent
> alot of time designing it in the first place. These additions might not
> fit well thought into it.
I knew that this would happen. Noone _ever_ gets it right the first time.
It takes iterations. And because the Apache team has such smart people
working on these solutions, we can usually get it right the second time
around. It takes a first iteration to get the main idea accross, and the
second idea is a refinement of the first. The whole Sitemap idea is a
brand new concept and way of thinking.
I also expect that the FlowMap idea on its first incarnation will need
refinement. We will take an approach and try to make it fit as many
situations as possible until the original design is bursting at the seams.
Then when we all know what we like and dislike about it, we can make
informed decisions about the way it should be.
> I also like to see such a syntax be implemented because I cn see it is
> much more complete that what we have today.
Thank you.
> But, Berin, be honest. Do you think the learning curve is getting
> plainer with your syntax?
The number of people who percieve that they have input to the content of those
files drops. It increases the separation of concerns. A developer is going
to control a FlowMap. The syntax is simple enough to not take weeks to learn
it, and the control is enough to get a developer working right away.
The URL Map is only concerned with mapping URIs to other URL Maps or FlowMaps.
It allows the Admin to be an Admin--without worrying about the details of
graphic design (what transformers get applied where), or logic (where to apply
Actions).
The Pipeline declaration file is the realm of the graphic designers as they
control the transformers and serializers that will be applied. This will allow
a Site Designer to redesign a site by only affecting the content of the pipelines
without disturbing files that are in control of other roles.
The sitemap as it now stands merges all these concerns into one place. That is
what is so confusing about it. For the people I work with, they will appreciate
that fact, and they will only be concerned with their piece of the puzzle.
S/MIME Cryptographic Signature
