Carsten Ziegeler skrev:
Leszek Gawron schrieb:
Carsten Ziegeler wrote:
In general I agree with this - it makes learning Cocoon internal a
little bit easier. But I think the current environment api is not our
biggest problem. Anyways, our current Request object has more
functionality as the servlet request object, e.g. to get the sitemap
prefix and sitemap uri and more important the request attribute handling
for internal requests. How can we keep this functionality when switching
to the servlet api?
Moreover we have just introduced Session.getAttributes,
Request.getParamters and so on. There are no equivalents in pure HTTP
interfaces.
Yepp, I actually thought about this last night and I think now, we
should not ditch this abstraction. If we would ditch it, we have to cope
with two problems: compatibility (noone wants to rewrite all of the
code) and additional functions (which are used throughout Cocoon).
Now, we could solve both problems by extending the servlet apis, but
then we still use our own interfaces in the end and nothing changes.
In the recent discussions many people want to see controllers as first
class citicens in Cocoon, so that we can use flowscript or javaflow as
the main controller, that calls the sitemap controller in turn. Also we
need room to start experimenting with new controllers, as the
"convention" controller that Berin started to work on.
The blocks architecture allready contains two new controllers: a block
dispatch controller that is the main controller and take care of mounted
blocks and delegate the controll to a block controller that represents
a particular block. The block controller in turn calls a sitemap controller.
Now I would like to generalise this so that the block controller can be
configured to dispatch to any controller not just be hard wired to the
sitemap controller.
Also I would like to make the various controllers as independent of each
other as possible to break down the current monolithic state of Cocoon
core that makes it such a pain to develop in.
Now for these new developments we should IMO not depend on the
unnecessary complication that our environment abstraction means.
At least I would like to use the servlet apis on the controller level.
We could introduce the own environment abstarction first inside the
sitemap controller.
I did several Cocoon development training courses in the last years and
I think our own abstraction by itself was never the problem. The big
problem most times is, that people do not know/see that we actually have
a request object and how they can obtain it in there own code. If you
compare our pipeline component interfaces with interfaces from other web
frameworks there is an obvious difference: other frameworks/specs
(servlets, portlets etc.) always have a request and response object
directly in the signature of a method. So it's directly visible.
Our components have a map called object model and everything is hidden
in this map. So, I think changing this would be much more helpful for
newbies. They directly see a request/response object somewhere and than
it's obvious how to use them no matter what the package of that object is.
Look, Cocoons current messiness depends on a large amount of small
things. If we not are able to improve these areas one at a time Cocoon
will stay as messy as it is.
So now we have the situation that we all agree about that there is need
for a radical improvement of Cocoon in general. But it seem rather hard
get any decisions about changing anything in particular.
Maybe Cocoon of today is what we deserve ;)
Now, basically another problem we have which is somehow related to this
is that our components get pooled. I think if we would switch to a
factory based approach for sitemap components (like we discussed and
already started), we could change the interface for those factories and
directly path the request/response object into them. I have the hope
that this will decrease the learning curve in this area.
Ok. Any link to the discussion?
/Daniel
