On Sun, 15 Jul 2001, Berin Loritsch wrote:
> > Why not drop Actions altogether and instead put XSP taglibs in that place?
>
> Why not drop XSP altogether and instead put everything in the sitemap?
Suits me, but the current Sitemap design doesn't support this. It would
have to be changed significantly for users to be able to plug their custom
code in it. So I don't think it's feasible, but hey, surprise me :)
> Personally, I don't like runtime generated and compiled classes.
That's an implementation issue, I could care less about it (as a user). I
want to write my custom code, put it somewhere and have an XML interface
to it. When I look into the repository of Cooon1 I see my code - the code
I wrote went to that place, so be it. I don't care how Cocoon deals with
my code internally, I only care about the external interface and that it's
fast enough :)
> While
> they are great for quickly getting a system to run, they are a pain to
> debug. Was the problem my markup? Was the problem in the code?
I've deployed several large apps under Cocoon1 and found debugging XSP
quite easy. Maintenance and Enhancements are a snap, so I am very
reluctant to let go of Cocoon1, because it scales amazingly well into
large projects. If you say that you have deployed and maintained large
apps under Cocoon2 and debugging Actions was much easier, I'll have to
believe you.
> Also, I like separating my code into concern areas if at all possible.
> Actions and XSP pages have different responsibilities.
That's what I find so unelegant about Cocoon2. You have to learn a number
of different techniques to accomplish a number of different things. This
makes it very hard to re-use anything across projects. And it cuts down on
a developer's freedom to implement a system the way he thinks is the right
way. So I hate SoC - Cocoon1 lets me hate it, while at the same time
allowing me to use it.
> All that being said, there are a number of people who would like to see
> compiled Actions. However, noone wants to take the responsibility yet
> of creating the Action markup and compilation procedure.
Maybe it would be like XSP in the end :)
> When you add the fact that Actions have no display function (by design),
> there is little to gain by incorporating compiled actions. You will
> find that it is easier to create and maintain Java actions than compiled
> actions.
If it's fast enough it doesn't have to compiled. All I want is a place
where to put my logic (one place, not many places) and have an XML
interface to it. I want to be able to take my logic out of Cocoon and into
another system and make it work there. I don't want to take half of Cocoon
with me to get my custom logic to work elsewhere :)
Ulrich
--
Ulrich Mayring
DENIC eG, Softwareentwicklung
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>
