Thanks for the reply...that's a shame (that you have to parse the
source) - I guess I expected too much after looking at what 'Ruby' can
do
BTW: the 'proxy functions' , I was going to keep this top-secret and
make millions from my new framework...but hey... ;-)
This is my idea (as far as I know its my idea, but I'm not so stupid
to think this hasn't been thought of before , but I couldn't find
anything out there [apart from maybe 'javascript on rails' - but
that's not available to the outside world...).
I haven't completely thought it through, but here's the sketch:
You will need: Tomcat, Rhino. A browser.
1. SERVER-SIDE: JS
function doSomething(a,b,c) {
....
}
function returnSomething(x,y,x) { ...return JSON; }
function blah(a,b,c,d,e,f,g) { return JSON... }
2. During an initialise-stage of somesort : load up this js
(_assuming_ just func/var defs or filtering everything out that is
not...) define all functions,vars in a Rhino "Context", iterate, spit
out a 'proxy' version of each function to a new .js file....
Where each 'proxy' function would share the same method sig. and
return (if any), but would be designed to run in a browser.
Each proxy-function would look something like:
function doSomething(a,b,c) {
url="
http://host:port/servlet?
function=doSomething&a=arguments[0]&b=arguments[1]&c=arguments[2]...." //
Pseudo-code, obviously a loop in reality
callSyncAjax(url);
}
function callSyncAjax(url) {
//make xmlhttprequest request here
}
I'm not sure, would probably need a 'ret_doSomething()' function as
well (so function pairs for each server-side equivalent), I'm also
thinking it should be 'sync' call not the usual 'async' call...but
again not really thought through all the options here...
Single controller servlet , server-side - which (assumes - since we
have a 'contract' of somesort in that the proxy-script was generated
from the original js) decodes the 'REST-style' request and builds up
the call to JS function server-side, the return of which gets JSON'd
up and sent back to client.
The reasons I'm thinking of this:
1. I haven't yet learnt JQuery or such like - so I might be missing a
trick already - I dunno.
2. If this worked, I like the idea of having being able to code model-
stuff entirely back-end, but then call the functionality front-end -
AND I get to
write one set of functions that could be used either side.
3. I think combined with hibernate and some 'context-pooling' on the
back-end, it could be that start of decent mini-framework (for my uses
at least).
4. I think also that it would be nice to write 'swing' apps using this
method - with very little (no) changes - of course I would have to
redo the 'view' code here, but the model/controller stuff should stay
good....
So if you ever finish your code, post somewhere would you ! It still
might make this work. (although possibly not as 'dynamic' as what I
was originally hoping - not to take anything away from your project
you understand - just disappointed that JS doesn't allow the full
extent of reflection that I thought it might have!)
Cheers
John
monojohnny said:
Finding all defined functions and returning the parameter list - and
also the 'return' (if any) ?
Interoperable, only by parsing the source code, I'm afraid.
I would like to iterate over all Javascript objects, and just generate
a 'stub' of each function which I can use to generate documentation
A similar wheel has been invented already. I have been working on another,
IMHO better, version of it for quite a while now. And no, it does not roll yet.
and 'proxy' functions etc ?
What's that?
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <
[email protected]>