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] [ More Info ] For more options, visit this group at http://groups.google.com/group/Refresh-Austin
