Grzegorz Kossakowski skrev:
Daniel Fagerstrom napisał(a):
Grzegorz Kossakowski skrev:
...
or newly introduced
BlockPathModule (broadly known as "servlet:" in sitemap references).
This modules can be viewed as expression languages
and their equivalents should be plugged into our unified expression
handling mechanisms.
I implemented the BlockPathModule to be able to use the
LinkRewriterTransformer, not because it is particularly elegant to
implement it in this way. I would give this part lower priority.
So how it would be done after implementing unified expressions? I
thought that BlockPathModule would become just "servlet" expression and
LinkRewriterTransformer would be given list of expressions instead of
list of input modules. What's your idea?
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.
For link rewriting for the servlet: protocol I would prefer a special
purpose link rewriter that takes care of the context path, servlet path
and servlet service mount path. But that doesn't need to be part of your
task.
...
Actual work will consist of:
* creation of approporiate, well-thought API
* implementation of various expression languages, two main
implementations I want to focus on are: JXPath and Jexl/JS
Expression languages are implemented
http://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-template/cocoon-template-impl/src/test/java/org/apache/cocoon/components/expression/,
what is lacking is using them outside the template block.
I wasn't aware that they are already implemented and used in Cocoon.
However, considering goals I outlined it's sure that some work with
expression's itself is needed.
I think that we should get rid of Avalon's dependencies and use Spring
instead.
That would be great.
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 would propose that you look if the converter stuff could be within
your project scope, possibly by decreasing the ambition in some other
area. The converter idea is described here
http://marc.info/?l=xml-cocoon-dev&m=109941971317696&w=2,
http://marc.info/?l=xml-cocoon-dev&m=109960841308357&w=2, there is
even a partial implementation:
http://issues.apache.org/bugzilla/show_bug.cgi?id=32223.
The conveter would simplify both template and cforms use considerably.
It would also allow us to cleanup the implementation of cforms.
I agree that work on converters would be more valuable than artificial
fight with IMs.
However I fail to see the scope of converters. Your original idea was to
create type converters that able to do bidirectional conversion between
particular type and string and you thought that it would be reasonable
to have only one per type.
Already that would be a great addition.
Someone suggested that it would be great to
have type<->XML converters too.
I'm against that. It would blur the scope and complicate the integration
in the rest of Cocoon considerably.
Someone else asked for being able to
have many converters for single type and be able to have a choice which
to choose in particular situation.
This was mainly for handling dates and numerals, like for the coverters
in CForm. So that you could write something like share#percent or
today#daytime, (where the first part is the object and the second the
selector).
I think that I could take converters into account but would like to hear
your opinion what are the limits of flexibility they should give.
They should IMO only be String -> String. I think the selectors would be
nice for handling L10N with a minimum of expression writing.
/Daniel
