Grzegorz Kossakowski skrev:
Daniel Fagerstrom napisał(a):
The responsibility of the BlockPathModule is to transform one URL to
another. The responsibility of the OM is to make a data structure of
some kind available so that parts of it can be selected by applying an
expression on it.
IMO the BlockPathModule stretches the concept of input modules outside
what they are intended for. The "servlet:" object is not exactly a
data structure and the URL is not an expression. It is also
questionable what a JEXL expression applied on a "servlet:" object
would mean.
But maybe I'm misunderstanding what you are proposing. Anyway, if you
find a nice and neat design that includes the BlockPathModule, please
just go ahead. If it OTH complicates your design, just skip it and
focus on getting the design simple and easy to understand.
I wasn't clear enough, I do not propose to "servlet:" become an object
that will be included in OM. I will give you an examples explaining the
idea:
{xpath:/cocoon/request/parameters/someParameter} means that we apply
expression "/cocoon/request/parameters/someParameter" in "xpath"
language on default (the one globally available) Object Model, now:
{servlet:forms:/some/path} means that we apply expression
"forms:/some/path" in "servlet" language. The difference is that this
expression is not applied on default Object Model. Servlet language
would just ignore OM and process this expression the same way the
BlockModulePath does now.
That means we allow expression languages to ignore OM and do on their
responsibility possible other way of applying expression. This leads to
a little bit more general understanding of Expression (intentionally
written with capital letter) that just returns value of passed
expression no matter how data needed to calculate it is being obtained.
Of course for most cases expression calculate their values while
operating on OM so that's why we provide it. To avoid every expression
language reinvent the wheel and keep everything coherent. However, we
allow exceptions...
OK, I think I get it. Seem like a neat solution.
I'd like to know a little bit more about how you plan to manage "the one
globally available" Object Model. Is it a component that is injected
into the sitemap component etc? Is it part of the call stack? Or what is
the idea?
As next step, class discovery should be implemented as we
agreed earlier. Am I right I miss something again?
Don't know. I need a clearer idea about how you intend to use the
class discovery mechanism to evaluate that. An example or two on what
it would look like in e.g. the sitemap would be great.
I think it's has nothing to do with sitemap. By class dicovery I mean
that expression would be discovered and registered in expression
compiler registry automatically so this file:
http://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-template/cocoon-template-impl/src/main/resources/META-INF/cocoon/avalon/cocoon-template-expression.xconf
Wouldn't be needed anymore. As said earlier I want to have no
configuration for expressions.
Make sense now.
===
I will be mainly off line until Monday.
/Daniel
