@Jonathon I agree that if this functionality was used to build a generic interface, you'd end up with something dull and ugly.
But I'm not interested in having it build the interface. I'm more interested in dynamically creating a clone of the server side object structure and API, so that I can build custom interfaces on top of that, without having to code each and every little handler function. I imagine it as something as magical as jQuery: all you have to do is include this relatively simple JavaScript file, and VOILA, you've got a development environment that matches the capabilities of your server. @Joe I will try to make it out tonight! On Mon, Nov 15, 2010 at 11:56 AM, Jonathon Wilson <[email protected]>wrote: > It's neat, but I've found this technique is only useful when you're really > building a 'generic' client which doesn't know ahead of time what > functionality will be available. 99 times out of 100, you're going to want > to put code in the client that actually uses those "available methods" > appropriately -- which is part of the display logic. The only way around > this is to then build the corresponding generic "display logic" which offers > those dynamic choices up to the user. These are very flexible UIs, but they > often end up looking very utilitarian because you can't put any prior > knowledge into them about what the commands are and how they'll be used. > > I've built a couple of these previously using XML RPC (which has a built-in > mechanism for querying what methods are available, etc. similar to what > you've described, just not as javascript specific). They worked, but only > for an in-house developers-only thing where the actual experience wasn't > very important. > > In the right setting, it does save you a bit of monkey work and can be > useful -- I've just found that the next part of development -- how you > actually use the available server methods often benefits from just knowing > what to call and calling it. It simplifies that part of the code. > > Like all things -- its a trade off. Good in some cases: In others, less so. > > -- > Our Web site: http://www.RefreshAustin.org/ > > You received this message because you are subscribed to the Google Groups > "Refresh Austin" group. > > [ Posting ] > To post to this group, send email to [email protected] > Job-related postings should follow http://tr.im/refreshaustinjobspolicy > We do not accept job posts from recruiters. > > [ Unsubscribe ] > To unsubscribe from this group, send email to > [email protected]<refresh-austin%[email protected]> > > [ More Info ] > For more options, visit this group at > http://groups.google.com/group/Refresh-Austin > -- Our Web site: http://www.RefreshAustin.org/ You received this message because you are subscribed to the Google Groups "Refresh Austin" group. [ Posting ] To post to this group, send email to [email protected] Job-related postings should follow http://tr.im/refreshaustinjobspolicy We do not accept job posts from recruiters. [ Unsubscribe ] To unsubscribe from this group, send email to [email protected] [ More Info ] For more options, visit this group at http://groups.google.com/group/Refresh-Austin
