Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <48623D2E.7040307@tt.com.au>
Date: Wed, 25 Jun 2008 22:42:22 +1000
From: Kamal <bhatt@tt.com.au>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Plugging that big XSP shaped hole
References: <4860E19C.20705@tt.com.au> <48621787.8070800@apache.org>
In-Reply-To: <48621787.8070800@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


>
> As the author of xsp-action, I have to say it was an ugly hack, meant 
> primarily for speeding up development cycles at a time when we did not 
> have flowscript nor hot code replace in Java debuggers.
>
> Now your use case is right, and I agree that flowscript is overly 
> complex when all you need is a simple action that prepares some data 
> or defines routing in a pipeline as in your use case. And we talked 
> several times in the past about a JS-action that would sort of unify 
> flowscript and actions, but IIRC it was never implemented.

Was it not implemented because it was deemed too difficult or because no 
one had the time to do it?


>>
>>
>> Is this possible? In some cases, I think this will be a neat solution 
>> as you still have a clear separation between logic and presentation, 
>> but you don't need to open three separate files to see what is going 
>> on. Also, I don't see this as a replacement for flowscript, just 
>> another tool in the toolbox that is Cocoon.
>>
>> Considering the lack of a response to this functionality, I suspect 
>> that it isn't doable or it is viewed as undesirable. If it is either 
>> of these, can I please get an explanation? I suspect is a fairly big 
>> task and it is probably something (at this point in time) I am not 
>> capable of doing. That said, if no one has an objection to the 
>> functionality and I can get some guidance, I am happy to look at 
>> implementing it.
>
> Hmm... This proposal is clearly mixing logic and presentation, which 
> is what Cocoon is all against! And this is one for the reasons that 
> led to deprecate XSP that opens the door to writing all application 
> logic in <xsp:logic> elements.
>
>
I am definitely in agreement with you about how Cocoon should be against 
mixing of logic and presentation. In fact, I would go further and say 
that is goal of XML. However, I disagree with your assertion that my 
proposal is a mixing of logic and presentation. It has a clear 
separation of logic and presentation, this just done in one file. The 
idea would be that you would have one and only one Flow section and one 
and only one presentation section. With Javascript defined in the Flow 
section, you would have the ability to dynamically setup organic objects 
to do what was required in the Presentation section.

The problem with XSPs (IMHO) was not that XSPs had logic and 
presentation in the same file, it was the intermixing of logic and 
presentation (not to mention the ugly mixing of java and XML). My 
proposal does not have this problem as if enforces the separation. Also, 
I am concerned that in deprecating XSPs we have replaced one set of 
problems (the intermixing of logic and presentation) with problems that 
are almost as big - a lack of transparency and sitemap bloat. The 
sitemap bloat I have talked about. What I mean by lack of transparency 
is best described with an example. If I find a bug with a particular 
URL, in the past, all I had to do was find the appropriate pipeline and 
all the information and files I needed to debug the problem would have 
been there. Now, in the flowscript world, I would have to find the 
appropriate pipeline. This would have a function call. I would then have 
to search through all my flowscripts to find that function call, after 
which I would have to look through the function to find out where the 
send page is. When this is done, I go find that pipeline and then open 
up the JX Template. Phew, that is a lot of work just to see what is 
going on. It is no longer transparent as to what is going on. In cases 
where there is complex logic associated with specifying what route to 
take flowscripts are necessary (not to mention the easiest solution), 
but I don't see the need for the overhead in the case when you want to, 
for example, query a database, process the results and hand off the 
resultant object to a JXTemplate to format the content.

Cheers.