cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@STJUDE.ORG>
Subject RE: rich clients in Flash with Cocoon?
Date Tue, 12 Oct 2004 13:44:27 GMT
Adam Ratcliffe <> writes:

> >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.
> I'm wondering to what extent customization of a SWF for a 
> given client needs to be handled at compile time. Runtime 
> setting of the properties of UI elements, such as their 
> visibility, based upon the XML dataset could handle a wide 
> range of customization requirements.

That's a good question. Basically it's a trade off between a fat client
and a thin client.  The more understanding of the data you put on the
front end the less a declarative form of client like Laszlo is going to
make sense.  I don't think there is a single best answer.

In our case we have requirements for things like type-ahead and combo
boxes that aren't met by HTML.  However, once a page is generated it
really doesn't need a lot of other client side intelligence (though good
client side validation and conditional element exposure is also required
it can be done with traditional JavaScript/HTML).

> I haven't used CForms yet, it sounds like the binding of 
> these components on the server-side would more frequently 
> result in the creation of unique LZX source.
Yes, the question is, how often is a particular form going to be reused?
For us, we can't really tell, on any given day it could be once or it
could be 1000's of times.  In such cases I think the answer is good
cache management and not trying to build heavy weight clients.

> I'm not suggesting that we don't need a Laszlo serializer, it 
> sounds like a good idea, interested in getting a better idea 
> of cases in which it would be useful to handle per-client 
> variation through creation of unique LZX.
Well, I've been doing Client Server systems for some 15 years now.
Every time I get into building heavy weight clients I run into issues of
distributed code management that just aren't worth the hassle.  If
you're truly doing per-client customization you may have a unique case
that justifies solving these problems. However, I rarely encounter a
situation that calls for true per client customization.  Usually, at
worse, it ends up being aggregation of standardized components in a
frame type system.   Having said that, let me note that you need to
strike a balance.  Keeping things like color and font management on the
client side often solves a lot of issues that might otherwise result in
generation of unique pages.

View raw message