Adam Ratcliffe <[EMAIL PROTECTED]> 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.
