Max Pfingsthorn wrote:
<snip type="a bunch of implementation stuff"/>
The "handleControllerCall" function can be written in flowscript or even use
the great new java flow as shown by Torsten Curdt during the get together. Not sure how
that class reloading works, but if you put the controller classes in the same path, I
guess the reloading feature would work there as well. So, you can do something like...:
if(action==null) action="index";
contr =
Package.org.apache.cocoon.util.ClassUtils.newInstance("controllers."+controller+"Controller");
if(id==null)
contr[action]();
else
contr[action](id); //well, a little more processing here to get the object
with this id first
cocoon.sendPage("views/"+controller+"/"+action);
Right?
max
One of the nice features of the Rails implementation is the fact that a
class method maps to an action. It makes the code very easy to test,
and therefore very appealing.
Think about it, if you were going to write a unit test, would you rather
invoke a scripting engine or simply execute against a class?
Also, the inherent simplicity of concepts where a developer can leverage
the Java skills that they already have is very enticing. The controller
would essentially inherit a base class that takes care of the reflective
resolution of the actions, and all is well. It just works. My major
complaint against flowscript isn't the concept--its the feeling that I
am flying without a net. I don't have a convenient way of testing the
javascript. I can't use an IDE to make things even easier. There is
something to be said for using the autocomplete function of your
favorite IDE as apposed to trying to remember how everything is mapped
to the FOM.
Again, why should the developer have to type out cocoon.sendPage(...)
when the sitemap implementation takes care of it for you.
