Just a heads up, after a long day of research, it seems that what I've created is similar to Java's Dynamic Proxy Classes.
http://download.oracle.com/javase/1.3/docs/guide/reflection/proxy.html Thanks for the feedback, dudes. b On Mon, Nov 15, 2010 at 2:35 PM, Andy Couch <[email protected]> wrote: > 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]<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
