Austin JavaScript is *tomorrow* night, right? On Mon, Nov 15, 2010 at 2:24 PM, Ben Brown <[email protected]> wrote:
> @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]<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
