By generating JS code that includes a return value, this can then be returned to a value that is processed by your own code.
I've attached some WIP code that uses php to communicate with a mysql db.
Any comments would be greatly appreciated.
Henrik Våglin wrote:
Well I'm most interested in this. I also have begun
sketching out a possible model for a
server-side/dynapi communication. It was sent to the
list some month back if you would care to check it out
(it should be in the backlog archive of this or the
help mailing list, otherwise you could mail me
offlist)Basically my idea goes further than one serverside
soloution and is rather interface for communication
with serverside scripts (much like Dan Steinman's
DynAPI1 ServerTasks on which it is based). This
however, following the model, shouldn't present any
issues as it would be easy enough to interface with
any serverside and even clientside methods. The model
probably needs some finising touches to make fit.How about creating a DynAPI2 subproject at
sourceforge?Henrik Våglin [ [EMAIL PROTECTED] ]
--- Raymond Smith <[EMAIL PROTECTED]> skrev: >
Update, for those who follow "the life and times of
> the rock".
>
> I used DynAPI2++ because it seems an appropriate
> acronym, in my mind at
> least. I hope what follows will add clarity.
>
> I believe the nucleus of the API is very solid and
> will only get better as
> the following are integrated:
>
> 1) Resolve "garbage collection" issues (memory
> leak). I'm 90% sure that
> referential circles are the crux of the current
> API's memory consumption and
> inability to release it. Part of this is supported
> by some recent readings
> of mine that actually discussed the use of
> "reference pointers" to keep
> garbage collection from removing an object you may
> not be done with (not a
> problem we are dealing with). This will make more
> sense later.
>
> 2) Fine tune and optimize the code.
>
> 3) Learn (as developers) how to effectively "use"
> this tool because I think
> it opens up a world of opportunities and requires an
> ability to embrace and
> adapt subtle paradigm shifts as to how
> web-environments are designed and
> created.
>
> 4) As the browser base continues to mature, it will
> continue to open up new
> layers of opportunity. The 5+ browsers are
> certainly more robust then the
> 4.0's.
>
> Which leads to the ++ part of DynAPI2++.
>
> As I see it, this API will be used at two levels.
> First, as a tool to
> introduce navigational enhancements to "conventional
> web pages" and secondly
> to serve as a very sophisticated "client interface"
> to web objects that
> extend server-side applications.
>
> Let me clarify what I mean by "conventional web
> pages". To me these are
> static sites up to and including low level 2-tier
> client/server
> architectures (no middleware). This world tends to
> include PHP, MySQL, PERL
> and uses server calls directly to the database,
> which then responds to the
> query.
>
> The next level, is extending the "clients widget
> interface" to link up with
> a web object interface thus allowing for dynamic
> client interfacing to
> dynamic server-side web application interfaces
> (object to object data
> exchange through an adapter or translator). This
> would open up a world of
> new and exciting opportunities. Also, I think it's
> a critical component to
> allowing this API to be extended into whole new
> areas of market opportunity.
> This level is far more complicated and includes DCOM
> (.NET), RMI, ORB's,
> XML, Java and a host of very sophisticated
> databases.
>
> This is the area that has extreme interest to me
> because it would allow for
> the creation of very sophisticated and dynamic web
> applications and also
> would position this API for what is projected to be
> the future of
> client/server technologies.
>
> The ++ is basically the need (in my mind) to work on
> the "adapters" that
> would allow us to link JS based client interfaces to
> (eventually) a broad
> based variety of successful server-side application
> architectures.
>
> I'm still researching a lot of areas in the hopes of
> narrowing down what
> might be the first "best" target platform,
> client/server to begin to flush
> out the details and challenge areas. Not even sure
> that this interests the
> current group of developers here, or if it's to
> abstract and complicated for
> a DHTML API.
>
> Anyway, keep you posted. Like to here your input
> and thoughts also.
>
> Laters,
>
> Ray
>
>
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> [EMAIL PROTECTED]
>
http://lists.sourceforge.net/lists/listinfo/dynapi-dev=====
// Henrik Vaglin**************************************************
Visit my comics artpage at
http://photos.yahoo.com/bc/hvaglin?d&.flabel=fld5&.src=bc
**************************************************__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev
--
Michael Pemberton
[EMAIL PROTECTED]
ICQ: 12107010
server.zip