hmmm....

I have been rolling this around in my head for the last few days. Here is some of my thoughts:

1.) Separation of concerns.. I am not sure that a cocoon component really needs to built... what is wrong with having an app with two contexts? ie:
http://domain/laszlo/app1
which would get datsets etc from:
http://domain/cocoon/somepipline(s)
although I am of course noticing there is quite a bit of jar duplication between the two.


2.) CForms.. I have just gotten a grip on, and subsequently addicted to, cforms and flow with POJOs. Can the laszlo form objects be bound to widgets? ( I could just be dumb in this regard... insight is appreciated) Looks to me that to use cforms, we would have have to generate the app for each request.. to create repeaters and such.

I am not against anything at all... I am really weak on cocoon internals, but I am very excited by the idea of laszlo apps :)


Sylvain Wallez wrote:

Hunsberger, Peter wrote:

Adam Ratcliffe <[EMAIL PROTECTED]> writes:



This sounded to me like they were using Cocoon as an XML data source for binding to a Laszlo dataset requiring no integration of the technologies.

While a Laszlo serializer would certainly be interesting I imagine that recompiling the SWF for each request would hurt performance.


Don't think anyone is suggesting that you recompile a SWF for each
request.



One of the key advantages I see in using RIA technologies like Laszlo is that you get a continuous user interface without the need to keep going back to the server to get new pages. A precompiled SWF calling back to Cocoon for XML data would seem to be able to do that today.


We could in theory have a couple 100 different SWF's many of which are
slight variations on each other. We'd generate the Laszlo source for
them from Cocoon, customized for each user as needed and then send the
resultant compiled SWF over to the client. Those SWF would then hang
around on the client bouncing XML back and forth with Cocoon.



Exactly.

And the produced SWF data would be stored in the Cocoon cache, thus avoiding recreating them from scratch each time a particular SWF is requested. Just as we already do today with all other formats.

Sylvain




Reply via email to